From exim@www1.ietf.org Mon Mar 1 07:52:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15996 for ; Mon, 1 Mar 2004 07:52: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 1Axmtt-00088L-R9 for xcon-archive@odin.ietf.org; Mon, 01 Mar 2004 07:52:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21Cq0UP031255 for xcon-archive@odin.ietf.org; Mon, 1 Mar 2004 07:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axmts-000882-00 for xcon-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 07:52:00 -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 HAA15904 for ; Mon, 1 Mar 2004 07:51:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axmtr-0002uV-00 for xcon-web-archive@ietf.org; Mon, 01 Mar 2004 07:51:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxmsG-0002Wy-00 for xcon-web-archive@ietf.org; Mon, 01 Mar 2004 07:50:21 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Axmqq-0002Ci-01 for xcon-web-archive@ietf.org; Mon, 01 Mar 2004 07:48:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Axmed-0005zn-Q2 for xcon-web-archive@ietf.org; Mon, 01 Mar 2004 07:36:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxmeQ-0005z0-QL; Mon, 01 Mar 2004 07:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axme8-0005vq-4l for xcon@optimus.ietf.org; Mon, 01 Mar 2004 07:35:44 -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 HAA14934 for ; Mon, 1 Mar 2004 07:35:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axme7-0000nD-00 for xcon@ietf.org; Mon, 01 Mar 2004 07:35:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxmdN-0000ht-00 for xcon@ietf.org; Mon, 01 Mar 2004 07:34:58 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1Axmcn-0000Z2-00 for xcon@ietf.org; Mon, 01 Mar 2004 07:34:21 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i21CXo0p016124; Mon, 1 Mar 2004 06:33:51 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <10MYQQF7>; Mon, 1 Mar 2004 06:33:50 -0600 Message-ID: <9ACE0CEE075B494096C86C23878BF85906A34E@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Drage, Keith (Keith)'" , Adam Roach , Eric Burger , "'xcon@ietf.org'" Subject: RE: [XCON] CPCP Requirement: Hidden Participants Date: Mon, 1 Mar 2004 06:33:41 -0600 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Er... I reponded to Eric, not to you. His message was the first in which legal intercept was raised. /a > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Saturday, February 28, 2004 19:04 > To: 'Adam Roach'; 'Eric Burger'; 'xcon@ietf.org' > Subject: RE: [XCON] CPCP Requirement: Hidden Participants > > > It would have been better that you replied to one of the > later messages in this thread. > > Your comments make it look like my own comments below refer > to legal intercept, when they do not. We have already agreed > that hidden participants are nothing to do with legal intercept. > > regards > > Keith > > > -----Original Message----- > > From: Adam Roach [mailto:adam@dynamicsoft.com] > > Sent: 26 February 2004 03:46 > > To: Eric Burger; 'xcon@ietf.org' > > Subject: RE: [XCON] CPCP Requirement: Hidden Participants > > > > > > I know this issue has been settled, but just as a general > > announcement for any work in any working group: the IAB > > and IESG have stated positions on the topic of legal > > intercept that are (to my understanding) binding on all > > IETF protocols. > > > > These positions are detailed in RFC 2804, and are > > summarized as follows: "The IETF has decided not to consider > > requirements for wiretapping as part of the process for > > creating and maintaining IETF standards." > > > > /a > > > > > -----Original Message----- > > > From: Eric Burger [mailto:eburger@snowshore.com] > > > Sent: Tuesday, January 20, 2004 10:01 > > > To: xcon@ietf.org > > > Subject: RE: [XCON] CPCP Requirement: Hidden Participants > > > > > > > > > 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 > > > > > > > > > > > > I believe hidden users are appropriate. > > > > > > > > I do not believe that this adds complexity to the > > > > specifications (particularly to the specification of CPCP), > > > > so I see no need to make it a DEFER as far as the > > > > specifications are concerned. It may add complexity to the > > > > implementation, so I am quite happy to see it a MAY in the > > > > requirements, so that it is optional to implement. > > > > > > > > As regards the legal implications of hidden users, then yes, > > > > there may be priveleged users that are able to request the > > > > identity of hidden users (along with an indication that they > > > > are hidden). This of course requires the enabling of such a > > > > privileged user in the first place. > > > > > > > > Secondly, it may not be necessary to identify hidden users, > > > > but merely that there are hidden users in the conference (in > > > > addition to any that may have made themselves visible). Some > > > > countries require some form of tone or announcement on voice > > > > conferences when someone else is listening in. They also > > > > require an announcement or other indication in the call is > > > > being recorded. > > > > > > > > regards > > > > > > > > Keith > > > > > > > > Keith Drage > > > > Lucent Technologies > > > > drage@lucent.com > > > > tel: +44 1793 776249 > > > > > > > > > > > > > -----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 > > > > > > > > > > > > > > > > > > > > > > > > > > -----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 > > > > > > > > > > > > > > > > > > Related to this is there a requirement that, while not > > > > > revealing the > > > > > > identity of a hidden user, the conference policy contains > > > > > > state indication > > > > > > about either the presence of hidden users, or the > > > > > > possibility/preclusion > > > > > > that such hidden users may be present? > > > > > > > > > > > > I am anticipating that: > > > > > > 1) Laws may exist that require notification of such. > > > > > > > > > > That's a good point. This might require changes to the > > > > > conference event package to indicate if there are hidden > > > > > participants or not, and if so, how many. > > > > > > > > > > The question remain: is there a need for such a feature (to > > > > > hide users?)? > > > > > > > > > > Regards, > > > > > Hisham > > > > > > > > > > > 2) In some conferences, participants may want technical > > > > > > assurance that > > > > > > hidden users are not possible before they speak. > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > >http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > > > > > REQ-A7: It SHOULD be possible to participate in a > > conference as a > > > > hidden user. Hidden user is present in a conference, but > > > his presence > > > > is not revealed. > > > > > > > > REQ-E10: It MUST be possible to allow and disallow > > > hidden membership > > > > in a conference. > > > > > > > >Should a conference policy, using CPCP, specify if a user > > > can be hidden? > > > >This means that the conference state package does not report the > > > >participation on the hidden user. CPCP is used to identify > > > which users are > > > >hidden. The list of hidden users is only manipulated by a > > > privileged user > > > >such as the moderator. > > > > > > > >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 Mar 2 19:02:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10821 for ; Tue, 2 Mar 2004 19:02:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJpk-0003OI-Iu for xcon-archive@odin.ietf.org; Tue, 02 Mar 2004 19:01:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2301u1A013033 for xcon-archive@odin.ietf.org; Tue, 2 Mar 2004 19:01:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJpk-0003O8-Cf for xcon-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 19:01: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 TAA10787 for ; Tue, 2 Mar 2004 19:01:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyJph-00001m-00 for xcon-web-archive@ietf.org; Tue, 02 Mar 2004 19:01:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyJol-0007ff-00 for xcon-web-archive@ietf.org; Tue, 02 Mar 2004 19:00:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyJnt-0007YJ-00 for xcon-web-archive@ietf.org; Tue, 02 Mar 2004 19:00:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJnt-0003Hi-Fd; Tue, 02 Mar 2004 19:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJnp-0003HL-Uo for xcon@optimus.ietf.org; Tue, 02 Mar 2004 18:59: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 SAA10724 for ; Tue, 2 Mar 2004 18:59:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyJnm-0007Xm-00 for xcon@ietf.org; Tue, 02 Mar 2004 18:59:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyJmr-0007Qn-00 for xcon@ietf.org; Tue, 02 Mar 2004 18:58:57 -0500 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx with esmtp (Exim 4.12) id 1AyJmQ-0007JY-00 for xcon@ietf.org; Tue, 02 Mar 2004 18:58:30 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTZ00MDB3WOHU@firewall.mci.com> for xcon@ietf.org; Tue, 02 Mar 2004 23:58:00 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTZ004013WO9L@pmismtp01.mcilink.com> for xcon@ietf.org; Tue, 02 Mar 2004 23:58:00 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.152.12]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTZ002PS3WMZ9@pmismtp01.mcilink.com> for xcon@ietf.org; Tue, 02 Mar 2004 23:58:00 +0000 (GMT) Date: Tue, 02 Mar 2004 17:57:56 -0600 From: Alan Johnston X-Sender: Alan.Johnston@pop.mcit.com To: xcon@ietf.org Message-id: <5.2.1.1.0.20040302175630.02799e30@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Subject: [XCON] Fwd: WG session exploring XCAP Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 FYI for those here at the IETF and interested in XCAP. Thanks, Alan Johnston MCI sip:alan@sipstation.com >Date: Tue, 02 Mar 2004 00:47:31 -0600 >From: Robert Sparks >Subject: [Simple] WG session exploring XCAP >Sender: simple-admin@ietf.org >To: simple@ietf.org >As discussed in yesterday's session, SIMPLE will hold >a second meeting to explore XCAP in more depth. > >This session will be Thursday at 1300 in the Onyx room, >which is in the terminal room complex. This room will seat >roughly 50 people. > >Agenda : > >1300-1500 Walkthrough of XCAP > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Mar 2 21:43:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22773 for ; Tue, 2 Mar 2004 21:43: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 1AyMLb-0003jG-AJ for xcon-archive@odin.ietf.org; Tue, 02 Mar 2004 21:42:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i232gx4C014302 for xcon-archive@odin.ietf.org; Tue, 2 Mar 2004 21:42:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyMLa-0003ib-F9 for xcon-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 21:42: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 VAA22750 for ; Tue, 2 Mar 2004 21:42:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyMLX-0002oL-00 for xcon-web-archive@ietf.org; Tue, 02 Mar 2004 21:42:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyMKb-0002gV-00 for xcon-web-archive@ietf.org; Tue, 02 Mar 2004 21:41:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyMJf-0002Yf-00 for xcon-web-archive@ietf.org; Tue, 02 Mar 2004 21:40:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyMJh-0003Z6-Nl; Tue, 02 Mar 2004 21:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyMIk-0003S2-86 for xcon@optimus.ietf.org; Tue, 02 Mar 2004 21:40: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 VAA22655 for ; Tue, 2 Mar 2004 21:39:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyMIh-0002QF-00 for xcon@ietf.org; Tue, 02 Mar 2004 21:39:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyMHk-0002I4-00 for xcon@ietf.org; Tue, 02 Mar 2004 21:39:01 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AyMGv-000224-00 for xcon@ietf.org; Tue, 02 Mar 2004 21:38:09 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i232beaZ020811 for ; Tue, 2 Mar 2004 21:37:40 -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 VAA08178 for ; Tue, 2 Mar 2004 21:37:40 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Mar 2004 21:37:40 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B648D@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'xcon@ietf.org'" Date: Tue, 2 Mar 2004 21:37:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [XCON] Meeting re IM Private Messages Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Just in case there are people who are interested in conferencing issues, but not on the SIMPLE mail list, be aware that there is a thread that proposes a "Private Message" to a member of an IM chat session which is different from a sidebar. The fundamental difference is whether a new dialog is required. You might recall a similar discussion when we concluded (against my views) that sidebars would be a separate dialog. Some of us think that a private message is just a sidebar, others view them as different. We are going to discuss this over lunch tomorrow in IETF59. Meet at the reg area. Brian _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Mar 3 00:18:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02093 for ; Wed, 3 Mar 2004 00:18:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOlg-0005k2-Ux for xcon-archive@odin.ietf.org; Wed, 03 Mar 2004 00:18:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i235I4PO022064 for xcon-archive@odin.ietf.org; Wed, 3 Mar 2004 00:18:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOlg-0005jn-OC for xcon-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 00:18: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 AAA02030 for ; Wed, 3 Mar 2004 00:18:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyOle-0003va-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 00:18:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyOkf-0003me-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 00:17:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyOjg-0003d7-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 00:16:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOjh-0005FT-Ll; Wed, 03 Mar 2004 00:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOin-0004sV-C3 for xcon@optimus.ietf.org; Wed, 03 Mar 2004 00:15: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 AAA01843 for ; Wed, 3 Mar 2004 00:15:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyOik-0003TR-00 for xcon@ietf.org; Wed, 03 Mar 2004 00:15:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyOhl-0003J7-00 for xcon@ietf.org; Wed, 03 Mar 2004 00:14:01 -0500 Received: from pmesmtp04.mci.com ([199.249.20.36]) by ietf-mx with esmtp (Exim 4.12) id 1AyOgl-00034l-00 for xcon@ietf.org; Wed, 03 Mar 2004 00:12:59 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HTZ00AB2IGUDM@firewall.mci.com> for xcon@ietf.org; Wed, 03 Mar 2004 05:12:30 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HTZ00301IGUXZ@pmismtp01.mcilink.com>; Wed, 03 Mar 2004 05:12:30 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.122.3]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HTZ002ATIGPSS@pmismtp01.mcilink.com>; Wed, 03 Mar 2004 05:12:30 +0000 (GMT) Date: Tue, 02 Mar 2004 23:12:24 -0600 From: Alan Johnston Subject: Re: [XCON] Meeting re IM Private Messages X-Sender: Alan.Johnston@pop.mcit.com To: "Rosen, Brian" , "'xcon@ietf.org'" Message-id: <5.2.1.1.0.20040302230717.02759e68@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.1 required=5.0 tests=AWL autolearn=no version=2.60 Thanks for pointing this out, Brian. This, plus today's discussion of nicknames in sipping made me realize that we seem to have lost a CPCP requirement that a participant be able to request identify anonymity with respect to the other participants in the conference. I know the design team talked about this long ago. This information would then be used to override the normal information provided in the sipping conference package. If such a mechanism were present, it could be extended to cover nick names, in which a participant would use CPCP to set a nickname that could be used in place of their normal display name and URI. Thanks, Alan Johnston MCI sip:alan@sipstation.com At 09:37 PM 3/2/2004 -0500, Rosen, Brian wrote: >Just in case there are people who are interested in conferencing issues, but >not on the SIMPLE mail list, be aware that there is a thread that proposes >a "Private Message" to a member of an IM chat session which is different >from a sidebar. The fundamental difference is whether a new dialog is >required. You might recall a similar discussion when we concluded (against >my views) that sidebars would be a separate dialog. Some of us think that a >private message is just a sidebar, others view them as different. > >We are going to discuss this over lunch tomorrow in IETF59. Meet at the reg >area. > >Brian > > > > >_______________________________________________ >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 Mar 3 08:50:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26800 for ; Wed, 3 Mar 2004 08:50:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWkx-0000BB-SN for xcon-archive@odin.ietf.org; Wed, 03 Mar 2004 08:49:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23DnpFD000682 for xcon-archive@odin.ietf.org; Wed, 3 Mar 2004 08:49:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWkx-0000At-L6 for xcon-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 08:49: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 IAA26741 for ; Wed, 3 Mar 2004 08:49:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyWkw-0005d7-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 08:49:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyWk7-0005Po-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 08:48:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyWjB-0005FP-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 08:48:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWjC-0008Qb-2h; Wed, 03 Mar 2004 08:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWiv-0008Py-KH for xcon@optimus.ietf.org; Wed, 03 Mar 2004 08:47: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 IAA26647 for ; Wed, 3 Mar 2004 08:47: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 1AyWif-0005Bj-00 for xcon@ietf.org; Wed, 03 Mar 2004 08:47:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyWhp-000512-00 for xcon@ietf.org; Wed, 03 Mar 2004 08:46:38 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AyWgt-0004pb-00 for xcon@ietf.org; Wed, 03 Mar 2004 08:45:39 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i23DjZC20012; Wed, 3 Mar 2004 15:45:36 +0200 (EET) X-Scanned: Wed, 3 Mar 2004 15:45:30 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i23DjU7i002544; Wed, 3 Mar 2004 15:45:30 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00YRYrka; Wed, 03 Mar 2004 15:45:28 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i23DjR728641; Wed, 3 Mar 2004 15:45:27 +0200 (EET) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Mar 2004 15:45:27 +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-XCAP needs clarification on dial-out lists Date: Wed, 3 Mar 2004 15:45:25 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797828@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP-XCAP needs clarification on dial-out lists Thread-Index: AcQBAZDJAMpiOHrzRpiFZ3SWHIjFAAAJCqgw To: , X-OriginalArrivalTime: 03 Mar 2004 13:45:27.0011 (UTC) FILETIME=[C8F4A330:01C40125] 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,EXCUSE_3,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I agree. /Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Adam Roach > Sent: 03.March.2004 10:16 > To: 'xcon@ietf.org' > Subject: [XCON] CPCP-XCAP needs clarification on dial-out lists >=20 >=20 > [not as chair] >=20 > "Asking the focus to invite a user into the conference is=20 > achieved by > sending a HTTP PUT request to the CPS that modifies the=20 > Dial-Out List > (DL) adding URIs to it. The CPS then triggers the focus to send the > conference invitation, eg: SIP INVITE(s) as needed.=20 > Similarly, a user > can be removed from the Dial-out list by issuing a HTTP DELETE > removing the URIs." >=20 > I can't find anywhere in the document what the semantics > associated with removing a user from a dial-out list > might be during an active conference. Does that cause > the user to be removed from the conference, similar to > setting their ACL list entry to "expelled"? >=20 > This needs to be clearly specified. My personal preference > is that removing someone from the dial-out list does > *not* kick them out of the conference if they are already > present -- we already have a mechanism to do that with > the ACL list. >=20 > /a >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Mar 3 08:53:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26973 for ; Wed, 3 Mar 2004 08:53: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 1AyWne-0000OA-0H for xcon-archive@odin.ietf.org; Wed, 03 Mar 2004 08:52:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23DqbX7001488 for xcon-archive@odin.ietf.org; Wed, 3 Mar 2004 08:52:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWnd-0000Nv-Fg for xcon-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 08:52: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 IAA26961 for ; Wed, 3 Mar 2004 08:52:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyWnc-00069t-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 08:52:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyWmc-0005zo-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 08:51:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyWm5-0005qk-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 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 1AyWm5-0000Fu-PU; Wed, 03 Mar 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 1AyWlV-0000DC-Nr for xcon@optimus.ietf.org; Wed, 03 Mar 2004 08:50: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 IAA26818 for ; Wed, 3 Mar 2004 08:50: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 1AyWlU-0005mU-00 for xcon@ietf.org; Wed, 03 Mar 2004 08:50:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyWkV-0005Ym-00 for xcon@ietf.org; Wed, 03 Mar 2004 08:49:24 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1AyWjU-0005Fu-00 for xcon@ietf.org; Wed, 03 Mar 2004 08:48:21 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i23DmIh19594; Wed, 3 Mar 2004 15:48:18 +0200 (EET) X-Scanned: Wed, 3 Mar 2004 15:48:04 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i23Dm4vc010002; Wed, 3 Mar 2004 15:48:04 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00oiAyGW; Wed, 03 Mar 2004 15:48:02 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i23Dm1701150; Wed, 3 Mar 2004 15:48:01 +0200 (EET) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Mar 2004 15:47: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] Meeting re IM Private Messages Date: Wed, 3 Mar 2004 15:47:55 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797829@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Meeting re IM Private Messages Thread-Index: AcQA3sY93WcLpTQqR/a/dmWQIMjizgARwzVQ To: , , X-OriginalArrivalTime: 03 Mar 2004 13:47:55.0760 (UTC) FILETIME=[219DEF00:01C40126] 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 Conference policy should indicate if an anonymous user is allowed to = participate or not (note that we agreed that for closed conferences, an = anonymous user needs to be authenticated as well. He is only anonymous = to other participants). So, after a user's identity is asserted, he can put "anonymous" in the = from header and send whatever nickname he wants in the INVITE. /Hisham > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On Behalf Of ext > Alan Johnston > Sent: 03.March.2004 07:12 > To: Rosen, Brian; 'xcon@ietf.org' > Subject: Re: [XCON] Meeting re IM Private Messages >=20 >=20 > Thanks for pointing this out, Brian. >=20 > This, plus today's discussion of nicknames in sipping made me=20 > realize that=20 > we seem to have lost a CPCP requirement that a participant be able to=20 > request identify anonymity with respect to the other=20 > participants in the=20 > conference. I know the design team talked about this long=20 > ago. This=20 > information would then be used to override the normal=20 > information provided=20 > in the sipping conference package. >=20 > If such a mechanism were present, it could be extended to=20 > cover nick names,=20 > in which a participant would use CPCP to set a nickname that=20 > could be used=20 > in place of their normal display name and URI. >=20 > Thanks, > Alan Johnston > MCI > sip:alan@sipstation.com >=20 > At 09:37 PM 3/2/2004 -0500, Rosen, Brian wrote: > >Just in case there are people who are interested in=20 > conferencing issues, but > >not on the SIMPLE mail list, be aware that there is a thread=20 > that proposes > >a "Private Message" to a member of an IM chat session which=20 > is different > >from a sidebar. The fundamental difference is whether a new=20 > dialog is > >required. You might recall a similar discussion when we=20 > concluded (against > >my views) that sidebars would be a separate dialog. Some of=20 > us think that a > >private message is just a sidebar, others view them as different. > > > >We are going to discuss this over lunch tomorrow in IETF59. =20 > Meet at the reg > >area. > > > >Brian > > > > > > > > > >_______________________________________________ > >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 Mar 3 17:06:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29375 for ; Wed, 3 Mar 2004 17:06: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 1AyeUu-0007A2-Tv for xcon-archive@odin.ietf.org; Wed, 03 Mar 2004 17:05:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23M5miB027525 for xcon-archive@odin.ietf.org; Wed, 3 Mar 2004 17:05:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyeUu-00079s-PJ for xcon-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 17:05: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 RAA29363 for ; Wed, 3 Mar 2004 17:05:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyeUs-00004f-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 17:05:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyeTx-0007j9-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 17:04:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyeTD-0007as-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 17:04:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyeTE-00074M-3E; Wed, 03 Mar 2004 17:04:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyeST-000717-5J for xcon@optimus.ietf.org; Wed, 03 Mar 2004 17:03: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 RAA29232 for ; Wed, 3 Mar 2004 17:03:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyeSR-0007PY-00 for xcon@ietf.org; Wed, 03 Mar 2004 17:03:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyeRQ-00075u-00 for xcon@ietf.org; Wed, 03 Mar 2004 17:02:13 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AyePm-0006kK-00 for xcon@ietf.org; Wed, 03 Mar 2004 17:00:30 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 18229; Wed, 03 Mar 2004 16:59:52 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Mar 2004 17:00:00 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB1A28F@zoe.office.snowshore.com> Thread-Topic: Comments on draft-evan-sipping-media-policy-requirements-00 Thread-Index: AcQBatMTyZDnoHkLSQGonNHUsAwwJg== From: "Eric Burger" To: "IETF XCON Discussion List (E-mail)" Content-Transfer-Encoding: quoted-printable Subject: [XCON] Comments on draft-evan-sipping-media-policy-requirements-00 Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable First and foremost, this is NOT a requirements document. It proposes a = solution and then wraps requirements around that solution. I will not comment on the solution. I will, however, comment on the = requirements. These are all in section 6. REQ-GP1: A participant MUST be able to specify its own unique topology. OK, so long as we recognize this is a property of the protocol, not of = the media resource. In fact, I would offer this as a requirement: =20 REQ-GP1': A media resource MUST be able to reject a policy request. REQ-GP2: It must be possible for a group of users to receive the same mix. This mix may be a conference common mix. Isn't this the definition of a conference? I suppose that it is OK to = spell this out, in case someone forgot why we are here. REQ-GP3:It MUST be possible to dynamically modify the number of contributing streams associated with a mixer. Is "number of contributing streams" the number of active talkers = physically in the mix, or the number of active talkers in the = conference. If it is the latter, the requirement is OK, but needs to be = clearer. If it is the former, then requirement is NOT OK. What is the = use case? Assuming the latter, how about: REQ-GP3: It MUST be possible to dynamically set the size of the = conference. REQ-GP4: It MUST be possible to define the mixing function for each participant in the conference. This is written in the terms of the solution. What is the requirement = here? REQ-GP6: It SHOULD be possible to send a participant multiple streams from one mixer. This requirement is to enable support for end- point mixing. NO. REQ-GP6 is clearly out of scope for the charter of XCON. REQ-GP7: It SHOULD be possible to define relationships between different mixers. The relationships can be time synchronized such as specifying that the audio mixer and video mixer is a pair to establish lip-synchs. NO! This again is written in terms of the solution, not the = requirement. This is only a problem BECAUSE the solution is written in = terms of DSP resources. The requirement is: REQ-GP7: It MUST be possible to request synchronization between related = media streams. [Don't forget REQ-GP1' -- the media resource can always = say it cannot do synchronization.] REQ-GP8: It SHOULD be possible to define the number of different topologies and the number of streams in each of them that will be mixed in a mixer. For example the conference will support only one video topology that will go to all the participants, the video topology will support 2x2 display, or each participant will be able to receive his own audio topology that will include up to 4 contributing sources. I do not understand this requirement at all. Please elaborate. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Mar 3 19:17:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09345 for ; Wed, 3 Mar 2004 19:17:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygXl-0000M2-RE for xcon-archive@odin.ietf.org; Wed, 03 Mar 2004 19:16:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i240Gr9w001356 for xcon-archive@odin.ietf.org; Wed, 3 Mar 2004 19:16:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygXl-0000Ln-ML for xcon-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 19:16:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09301 for ; Wed, 3 Mar 2004 19:16:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AygXk-0001nV-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 19:16:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AygWp-0001cv-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 19:15:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AygVy-0001Qo-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 19:15:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygVy-00005f-Uu; Wed, 03 Mar 2004 19:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygVd-0008Vy-Ji for xcon@optimus.ietf.org; Wed, 03 Mar 2004 19:14: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 TAA09100 for ; Wed, 3 Mar 2004 19:14:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AygVc-0001Gr-00 for xcon@ietf.org; Wed, 03 Mar 2004 19:14:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AygUb-00011B-00 for xcon@ietf.org; Wed, 03 Mar 2004 19:13:38 -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 1AygTU-0000Ok-00 for xcon@ietf.org; Wed, 03 Mar 2004 19:12:29 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id <1YRKW04Q>; Thu, 4 Mar 2004 02:10:58 +0200 Message-ID: From: "Even, Roni" To: Eric Burger , "IETF XCON Discussion List (E-mail)" Subject: RE: [XCON] Comments on draft-evan-sipping-media-policy-requiremen ts-00 Date: Thu, 4 Mar 2004 02:10:57 +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, see inline Roni ************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Thursday, March 04, 2004 12:00 AM To: IETF XCON Discussion List (E-mail) Subject: [XCON] Comments on draft-evan-sipping-media-policy-requirements-00 First and foremost, this is NOT a requirements document. It proposes a solution and then wraps requirements around that solution. I will not comment on the solution. I will, however, comment on the requirements. These are all in section 6. REQ-GP1: A participant MUST be able to specify its own unique topology. OK, so long as we recognize this is a property of the protocol, not of the media resource. In fact, I would offer this as a requirement: RE: Is the sentence "The protocol must enable a participant to create his own topology" REQ-GP1': A media resource MUST be able to reject a policy request. REQ-GP2: It must be possible for a group of users to receive the same mix. This mix may be a conference common mix. Isn't this the definition of a conference? I suppose that it is OK to spell this out, in case someone forgot why we are here. RE: I think this is a more general requirement since it allows, for example, to have two different mixes and each group will get a different mix. REQ-GP3:It MUST be possible to dynamically modify the number of contributing streams associated with a mixer. Is "number of contributing streams" the number of active talkers physically in the mix, or the number of active talkers in the conference. If it is the latter, the requirement is OK, but needs to be clearer. If it is the former, then requirement is NOT OK. What is the use case? RE: It is the former, this is media policy and not conference policy. The cases are: for audio - start with mixing the 3 loudest speakers and change to mixing only 2 loudest. For video - start with a layout of 2x2 and move to layout of 1. Assuming the latter, how about: REQ-GP3: It MUST be possible to dynamically set the size of the conference. RE: this is conference policy REQ-GP4: It MUST be possible to define the mixing function for each participant in the conference. This is written in the terms of the solution. What is the requirement here? RE: the requirement is that if there are 5 participants in the call each can have a different combination of the mix of the other participants. It is obvious for video where each participant may see different participants. You could look at the video mix as two dimensional one is that each participant may see window composed of n*m sub-windows where n and m are per participant. The second dimension is that the content of each sub-window is different for each participant. This enable the participants to force their own view of the conference. the requirement is general since it may be used for other media though I would see less use for it in audio REQ-GP6: It SHOULD be possible to send a participant multiple streams from one mixer. This requirement is to enable support for end- point mixing. NO. REQ-GP6 is clearly out of scope for the charter of XCON. This requirement for supporting end point mixing was there. I think that I have to look back at how we defined a mixer to see if it from one mixer (I think the framework define one mixer that receive all the same sources (people video, audio, presentation video) and creates the specific streams for each of the participants. REQ-GP7: It SHOULD be possible to define relationships between different mixers. The relationships can be time synchronized such as specifying that the audio mixer and video mixer is a pair to establish lip-synchs. NO! This again is written in terms of the solution, not the requirement. This is only a problem BECAUSE the solution is written in terms of DSP resources. The requirement is: REQ-GP7: It MUST be possible to request synchronization between related media streams. [Don't forget REQ-GP1' -- the media resource can always say it cannot do synchronization.] RE: OK, I agree. REQ-GP8: It SHOULD be possible to define the number of different topologies and the number of streams in each of them that will be mixed in a mixer. For example the conference will support only one video topology that will go to all the participants, the video topology will support 2x2 display, or each participant will be able to receive his own audio topology that will include up to 4 contributing sources. I do not understand this requirement at all. Please elaborate. RE: Since a mixer receives all the sources (see my answer for GP6) and may create more then one different mix it must be possible to the participant to limit the number of the different mixes allowed to be created. An example is that I want to start a video conference and would like to limit the conference to allow only one video mix for all the participants since I am getting billed by the number of different mixes I use (mixing resource cost money) _______________________________________________ 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 Mar 3 19:29:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09743 for ; Wed, 3 Mar 2004 19:29:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygjP-00013B-C2 for xcon-archive@odin.ietf.org; Wed, 03 Mar 2004 19:28:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i240StCJ004031 for xcon-archive@odin.ietf.org; Wed, 3 Mar 2004 19:28:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygjP-00012w-5a for xcon-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 19:28: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 TAA09702 for ; Wed, 3 Mar 2004 19:28:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AygjN-0003dy-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 19:28:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AygiT-0003UV-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 19:27:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyghY-0003Le-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 19:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyghZ-0000qG-3K; Wed, 03 Mar 2004 19:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyghT-0000pm-Ej for xcon@optimus.ietf.org; Wed, 03 Mar 2004 19:26: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 TAA09648 for ; Wed, 3 Mar 2004 19:26:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyghR-0003KJ-00 for xcon@ietf.org; Wed, 03 Mar 2004 19:26:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyggV-0003BI-00 for xcon@ietf.org; Wed, 03 Mar 2004 19:25:56 -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 1Aygfj-0002tx-00 for xcon@ietf.org; Wed, 03 Mar 2004 19:25:07 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id <1YRKW0X8>; Thu, 4 Mar 2004 02:24:21 +0200 Message-ID: From: "Even, Roni" To: "IETF XCON Discussion List (E-mail)" Date: Thu, 4 Mar 2004 02:24:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [XCON] draft-burger-xcon-mmodels-00 Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi, I think that this is a good direction to have pre-defined conference types based on the scenarios since it will make it easy to initiate those media mixes without having to worry too much about topology. For the video to change afterward the contents of the sub-windows may be simpler. As for the document I think that Individual End-Point Negotiation is out of scope since we are addressing centralized conference where the negotiation should be with the central entity while the media may be mixed by the users. For example in multicast case the central entity will give the permission to send media. The central entity may also negotiate the conference common codecs for each media which is difficult in the model described. Roni ************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Mar 3 20:10:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11633 for ; Wed, 3 Mar 2004 20:10:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhN6-0005Cv-2m for xcon-archive@odin.ietf.org; Wed, 03 Mar 2004 20:09:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2419uLM020011 for xcon-archive@odin.ietf.org; Wed, 3 Mar 2004 20:09:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhN5-0005Cg-TR for xcon-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 20:09: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 UAA11611 for ; Wed, 3 Mar 2004 20:09:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyhN3-0002lv-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 20:09:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyhM8-0002cN-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 20:08:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyhLE-0002Tg-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 20:08:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhLF-00051M-GF; Wed, 03 Mar 2004 20:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhL9-0004zv-FP for xcon@optimus.ietf.org; Wed, 03 Mar 2004 20:07: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 UAA11586 for ; Wed, 3 Mar 2004 20:07:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyhL7-0002Sb-00 for xcon@ietf.org; Wed, 03 Mar 2004 20:07:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyhKF-0002JF-00 for xcon@ietf.org; Wed, 03 Mar 2004 20:06:59 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AyhJO-0001wx-00 for xcon@ietf.org; Wed, 03 Mar 2004 20:06:06 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i2415b0p028203 for ; Wed, 3 Mar 2004 19:05:37 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <10MYQR09>; Wed, 3 Mar 2004 19:05:36 -0600 Message-ID: <9ACE0CEE075B494096C86C23878BF85906A36B@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'xcon@ietf.org'" Date: Wed, 3 Mar 2004 19:05:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [XCON] Supplemental SIMPLE meeting about XCAP 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 For anyone who missed the announcement: there will be a supplemental meeting of the SIMPLE working group to serve as a tutorial for XCAP. It will take place at 1:00 PM in the Onyx room, which is accessed by going through the front part of the terminal room. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Mar 3 21:01:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15037 for ; Wed, 3 Mar 2004 21:01:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiAH-0002M8-03 for xcon-archive@odin.ietf.org; Wed, 03 Mar 2004 21:00:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2420iga009053 for xcon-archive@odin.ietf.org; Wed, 3 Mar 2004 21:00:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiAF-0002Lw-Vf for xcon-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 21:00:44 -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 VAA14967 for ; Wed, 3 Mar 2004 21:00:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiAD-0004lQ-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 21:00:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayi8Y-0004N4-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 20:58:58 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayi7g-0004DV-01 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 20:58:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ayi7e-0003pm-NK for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 20:58:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayi7c-00023h-Fk; Wed, 03 Mar 2004 20:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayi6f-00021J-G6 for xcon@optimus.ietf.org; Wed, 03 Mar 2004 20:57: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 UAA14788 for ; Wed, 3 Mar 2004 20:56:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayi6d-000436-00 for xcon@ietf.org; Wed, 03 Mar 2004 20:56:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayi5k-0003tx-00 for xcon@ietf.org; Wed, 03 Mar 2004 20:56:04 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1Ayi5K-0003iI-00 for xcon@ietf.org; Wed, 03 Mar 2004 20:55:38 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i241t90p008286 for ; Wed, 3 Mar 2004 19:55:09 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <10MYQSAW>; Wed, 3 Mar 2004 19:55:09 -0600 Message-ID: <9ACE0CEE075B494096C86C23878BF85906A36D@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'xcon@ietf.org'" Date: Wed, 3 Mar 2004 19:55:05 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [XCON] Proposed working group item: draft-koskelainen-xcon-xcap-cpcp-usa ge-02.txt Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 [as chair] During today's XCON meeting, a poll to determine the position of participants in the room regarding accepting draft-koskelainen-xcon-xcap-cpcp-usage-02.txt as a working group item was proposed. Specifically, the proposed adoption was made contingent on a reorganization of the document such that the XML schema and the XCAP usage are separate (possibly in different sections; possibly in different documents). Relevant to the decision, the discussion leading to the consensus poll included general agreement that other protocols (in addition to XCAP) may be used or developed for manipulation of conference policy. The room registered strong support for the above stated positions. Any objections to adopting the above document with the described changes should be brought to the list immediately. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Mar 8 15:09:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25254 for ; Mon, 8 Mar 2004 15:09: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 1B0R3V-0003dy-Ko for xcon-archive@odin.ietf.org; Mon, 08 Mar 2004 15:08:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28K8rn1014005 for xcon-archive@odin.ietf.org; Mon, 8 Mar 2004 15:08:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0R3V-0003dc-6u for xcon-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 15:08: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 PAA25210 for ; Mon, 8 Mar 2004 15:08:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0R3S-0003e5-00 for xcon-web-archive@ietf.org; Mon, 08 Mar 2004 15:08:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0R2Z-0003Te-00 for xcon-web-archive@ietf.org; Mon, 08 Mar 2004 15:07:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0R1f-0003IF-00 for xcon-web-archive@ietf.org; Mon, 08 Mar 2004 15:06:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0R1g-0002V7-NH; Mon, 08 Mar 2004 15:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0R1T-0002Nh-8q for xcon@optimus.ietf.org; Mon, 08 Mar 2004 15:06: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 PAA24993 for ; Mon, 8 Mar 2004 15:06:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0R1Q-0003Fk-00 for xcon@ietf.org; Mon, 08 Mar 2004 15:06:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0R0X-00034R-00 for xcon@ietf.org; Mon, 08 Mar 2004 15:05:49 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1B0QzV-0002m7-00 for xcon@ietf.org; Mon, 08 Mar 2004 15:04:45 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i28K4EZh015881 for ; Mon, 8 Mar 2004 14:04:14 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <10MYQ4CW>; Mon, 8 Mar 2004 14:04:15 -0600 Message-ID: <9ACE0CEE075B494096C86C23878BF85906A379@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'xcon@ietf.org'" Date: Mon, 8 Mar 2004 14:04:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [XCON] Open Issue: Hidden Participants Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 [as chair] At the XCON meeting, there was a rather lively discussion that continued the "Hidden Participants" discussion that had started on the list. It was agreed that the topic was worth discussion, but that we did not have enough time to pursue it in the meeting. I'm calling on everyone, especially those involved in the meeting discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to continue this discussion so we can close this issue in the near future. Alan and I would like to be able to last-call this document shortly, and this is the key issue that needs to be resolved before a new revision of the draft can be produced. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Mar 8 15:58:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01360 for ; Mon, 8 Mar 2004 15:58:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RpO-00030s-AP for xcon-archive@odin.ietf.org; Mon, 08 Mar 2004 15:58:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28KwMgs011581 for xcon-archive@odin.ietf.org; Mon, 8 Mar 2004 15:58:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RpO-00030i-5N for xcon-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 15:58: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 PAA01305 for ; Mon, 8 Mar 2004 15:58:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0RpM-0006kk-00 for xcon-web-archive@ietf.org; Mon, 08 Mar 2004 15:58:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Rnk-0006Ct-00 for xcon-web-archive@ietf.org; Mon, 08 Mar 2004 15:56:44 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0RlD-0005aW-00 for xcon-web-archive@ietf.org; Mon, 08 Mar 2004 15:54:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0RlC-0007fH-5l for xcon-web-archive@ietf.org; Mon, 08 Mar 2004 15:54:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RlA-0002i6-MP; Mon, 08 Mar 2004 15: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 1B0Rkq-0002hi-Dl for xcon@optimus.ietf.org; Mon, 08 Mar 2004 15:53: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 PAA00423 for ; Mon, 8 Mar 2004 15:53:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Rko-0005QP-00 for xcon@ietf.org; Mon, 08 Mar 2004 15:53:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Rj3-0004w3-00 for xcon@ietf.org; Mon, 08 Mar 2004 15:51:50 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1B0Rh4-0004A2-00 for xcon@ietf.org; Mon, 08 Mar 2004 15:49:46 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i28Kn6Zh024888 for ; Mon, 8 Mar 2004 14:49:06 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <10MYQ41B>; Mon, 8 Mar 2004 14:49:07 -0600 Message-ID: <9ACE0CEE075B494096C86C23878BF85906A37F@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'xcon@ietf.org'" Date: Mon, 8 Mar 2004 14:49:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C4054E.CC0F01A0" Subject: [XCON] Draft Meeting Minutes 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C4054E.CC0F01A0 Content-Type: text/plain; charset="iso-8859-1" [as chair] I have attached a draft version of the minutes of the XCON meeting last week. Please review them and let me know about any omissions or inaccuracies you may discover. I will be sending these minutes (modulo any such changes) to be archived on Friday, so please get any feedback to me by then. I would also like to extend my thanks to Paul Kyzivat for taking minutes for us during this meeting. /a ------_=_NextPart_000_01C4054E.CC0F01A0 Content-Type: text/plain; name="xcon-minutes.txt" Content-Disposition: attachment; filename="xcon-minutes.txt" Content-Transfer-Encoding: quoted-printable The following drafts were discussed: - draft-ietf-xcon-conference-scenarios-00.txt - Chairs Presented by working group chairs for Nermeen Ismail and Roni Even. Plan to submit 01 version for WG last call. - draft-ietf-xcon-floor-control-req-00.txt - Joerg Ott Includes some proposed policies that the authors aren't certain = about.=20 Would like others to comment. Cullen Jennings suggested that it is impossible to know with = certainty=20 who a participant is, and this provides a different way of looking at = privacy requirements. Brian Rosen voiced a requirement for the ability for a floor holder = to=20 pass the floor - different from automated floor control. Dave Lindbergh commented this is focused on parlimentary model.=20 Wanted to know if pannel discussion or roundtable is supported. Joerg = Ott said this is was possible, depending on floor policy. Keith Drage requested a better abstract before going to WGLC. Also, = said=20 there may be need to add floor policy to conference framework. Wants=20 clarity on whether floor policy is to be covered by this doc or the=20 conference policy requirements. The chairs said plan is for WGLC within the next 2-3 weeks. - draft-ietf-xcon-cpcp-reqs-02.txt - Hisham Khartabil Update of additions/removals. Rohan stated it seemed CPCP is intended = for humans, but he thought this will only be used by automata. He=20 doesn't think he is being understood. He said it should be possible = to=20 mark an entity that should be hidden, but there may not need to be = any=20 complex policy to control this. This is for things that would be=20 annoying to see, such as automata like recorders. This policy would=20 affect conference policy notifications. Eric Burger thought that would be useful *if* those special kinds of=20 roles are implemented by regular participants - but that is not the = only=20 way to implement those functions. Roni Even thought this might be a=20 media policy. But Rohan didn't. Dave Lindbergh thinks there are different kinds of conferences. For = some=20 hidden participants are fine, for others not. It may be important for = security to know if there are hidden participants. * There was no concensus. Further discussion to the list. There was extensive discussion on the definition of start time and=20 end-time. Cullen Jennins argued that the time the first participant=20 arrives cannot be the start time, because the start time is inserted = in=20 policy a priori. Eric disagreed. There seemed to be lack of=20 understanding between them. Rohan Mahy said there are four parameters, not two: = cannot-start-before,=20 cannot-continue-after, start-policy, end-policy. Roni Even said this has nothing to do with resource reservation. Eric = Burger said this is definitely tied to resource reservation, or else=20 there is no point. Cullen thought reservations are way out of scope. He said that the following are both important numbers: when mixing = can=20 begin, when dialouts happen. Suggests not calling it start-time. * Some concensus for: don't-mix-before-time, dialout-time. Also need policy to say mixing won't happen until key participant=20 arrives. Someone also brought up case the dialout doesn't happen = until a=20 key participant arrives. * Cullen and Rohan were asked to send text. (Roni Evan points out that dial-out might not happen until a key participant arrives, so the policy needs to account for such a case). Discusson on conference ends policy. Outcome was conclusion this is = tied=20 to key participants via some sort of policy. Keith Drage requested clarification on where media policy will be=20 defined, because this document currently doesn't. Roni Even said this = in=20 intended to be done in a separate document even though it may be=20 realized by same protocol. Keith felt this needs to be clarified = because=20 the conf framework says that cpcp will include media policy. Brian Rosen said there is a need to define Role. More work needed here= -=20 role is mentioned but not really defined. This relates to anonymity: one might not expose identity, but they might want to expose roles. * The document will be revised based on the open issues discussed above, and then enter a last-call period. - draft-koskelainen-xcon-xcap-cpcp-usage-02.txt - Hisham Khartabil Alan Johnston asked if others felt it was ok to have multiple = conference=20 URIs for one conference, or whether it would be better to have only = one=20 plus aliases. Alan thought framework said should be only one. = Somebody=20 said intent was not to be sip-biased. Hisham didn't think that we = need a single URI for identification; that there can be several different URIs that identify the conference equally. Brian Rosen said these should all be requested aliases while the true uri would be assigned and must be a gruu (and consequently not specified in the policy). Cullen Jennngs thought that like IM, we may need a special uri scheme that isn't bound to any of the protocols. Rohan Mahy said that typically there is an address (e.g. phone = number)=20 of a server plus an access code to enter the conference. In that case = that isn't a conference uri, but something else. Brian things there = may=20 be need for extension to carry this address used for conference = access. Alan indicated that clarification might be necessary about what it would mean to have several SIP URIs identifying the same conference. There was a long discussion of the suitability of xcap as a mechanism = for cpcp, what http methods are most suitable for xcap, and whose=20 problem it is if xcap is/isn't appropriate for the job. Orit Levin proposed splitting the document in two. Keep xml document=20 separate from the protocol. Aki thought splitting schema from = protocol=20 is a bad idea. Brian Rosen didn't want majority of work held up based = on=20 disagreement over protocol issues. Rohan said work is supposed to = apply=20 to multiple communities, but sipping community wants to use xcap and = we=20 shouldn't make it hard to do. He suggested not splitting document, = but=20 partitioning it so that there is a separate section on application to = xcap. Orit didn't want to encourage "vandals" to implement this using = other protocols. She would still prefer to split the document. = Jonathan=20 said it is normal case that there is a mandatory-to-implement = protocol=20 to ensure interop, without precluding other protocols. Keith Drage = said=20 if there are multiple equal protocols you should split the document, = but=20 if one is special then it ought to be in the document. Aki is ok with = restructuring the doc, but wonders why - he hasn't seen any other=20 transport being proposed. Lisa was in favor of splitting because will = need something else for xmpp to use this. * The chairs attempted to summarize: some sort of cencensus about=20 restructions/splitting the document so as to have xcap being *a* way = to=20 manipulate the document. * Alison asked about need for stronger statement regarding role of = xcap=20 before the next meeting. Wants a statement about it in the = deliverables,=20 that there will be an xcap transport based proposed standard. * Took hum of people wanting to take forward work using an xcap usage = for conference control. Hum was positive. * Agreed to take as WG item if document is suitably reorganized. No=20 agreement whether that will require a split. - draft-burger-xcon-mmodels-00.txt - Eric Burger Presented in "lecture mode" with questions postponed in order to save = time. He enumerated three media manipulation models: low level device = control, application level device control, dynamic device control, = and=20 he listed pros and cons of each. Rohan says this is fear mongering - that low level device control = graph=20 model doesn't have the problems asserted. Says H.248 is much worse = than=20 the graph model. He said that Eric hasn't demonstrated that his = proposal=20 meets the scenarios. - draft-jennings-xcon-media-control-00.txt - Cullen Jennings This presented an alternative approach to media control, based on=20 templates. Alan Johnston said he liked this approach. Roni Even = thought=20 model was good, but remains to be seen how many templates are needed. = But he is concerned whether complex cases can be handled. Brian Rosen = responded that the issue is whether a small number of templates can=20 handle a large number of the cases. If a small number don't cover=20 *enough* of the cases then this isn't a good approach. Need to do = work=20 to verify this. Rohan doesn't think we have enough info to move forward. Thinks = Eric's=20 draft doesn't have enough content. Cullen thinks there is enough so=20 people can see how they would build templates for particular cases, = but=20 Rohan disagreed - said it will break down for hard cases, that there = is=20 a big problem naming things. The chairs took several hums to determine the way forward with this work. Four options were offered: - flow graph approach: nobody - template approach: several - both are incorrect: a few - don't have enough info - wait: many * Consensus determined to be that we should attempt to understand the issues better before making a decision. ------_=_NextPart_000_01C4054E.CC0F01A0-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Mar 8 18:03:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09347 for ; Mon, 8 Mar 2004 18:03:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TmB-00060V-Ai for xcon-archive@odin.ietf.org; Mon, 08 Mar 2004 18:03:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28N3BYV023083 for xcon-archive@odin.ietf.org; Mon, 8 Mar 2004 18:03:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TmB-000607-1l for xcon-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 18:03: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 SAA09250 for ; Mon, 8 Mar 2004 18:03:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Tm8-0006kG-00 for xcon-web-archive@ietf.org; Mon, 08 Mar 2004 18:03:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Tl5-0006VH-00 for xcon-web-archive@ietf.org; Mon, 08 Mar 2004 18:02:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0Tk7-0006I4-00 for xcon-web-archive@ietf.org; Mon, 08 Mar 2004 18:01:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Tk9-00049j-EQ; Mon, 08 Mar 2004 18:01:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TjO-0003xZ-7b for xcon@optimus.ietf.org; Mon, 08 Mar 2004 18:00:18 -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 SAA09107 for ; Mon, 8 Mar 2004 18:00:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TjL-00064o-00 for xcon@ietf.org; Mon, 08 Mar 2004 18:00:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TiI-0005nX-00 for xcon@ietf.org; Mon, 08 Mar 2004 17:59:12 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1B0TgX-00058g-00; Mon, 08 Mar 2004 17:57:21 -0500 Received: from mail5.microsoft.com ([157.54.6.156]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 8 Mar 2004 14:56:48 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Mon, 8 Mar 2004 14:56:53 -0800 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 08 Mar 2004 14:56:44 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 8 Mar 2004 14:56:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Mon, 8 Mar 2004 14:56:34 -0800 Message-ID: Thread-Topic: How to express a GRUU property of a URI Thread-Index: AcQFYJruImVLdbYOSK259EjcxxFWUw== From: "Orit Levin" To: Cc: , X-OriginalArrivalTime: 08 Mar 2004 22:56:41.0188 (UTC) FILETIME=[9EC44A40:01C40560] Subject: [XCON] How to express a GRUU property of a URI Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40560.B99650C3" ------_=_NextPart_001_01C40560.B99650C3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Guys, Based on the last week comments, there is a requirement to optionally distinguish between information per user's AOR vs. per his/her GRUU(s) in XML documents (outside of SIP signaling messages). =20 Mentioned examples were Conference Package and Presence documents. (I suspect more usage cases are to come.) In my view, it is a matter of specific system implementation/architecture whether, when, and why you need to expose this information. (I do find it useful in some cases.) =20 Both presence documents and conference package are user-centric and (to the most parts) signaling-agnostic. I don't think it is wise to expand the existing XML schemas by doubling each URI placeholder to include signaling details, etc. I think it is more appropriate to define an optional URI parameter (e.g. "gruu") that can be appended to any SIP URI. By doing so, we can express the fact that a URI has GRUU properties without modifying existing XML schemas and without defining extended XML schemas in the future. =20 By doing so, it is up to the document provider to decide which level of granularity it wants to expose without making changes to existing XML schema. =20 What do you think? =20 Orit. PS: Please, reply to SIP list only. I just wanted to bring this question to the attention of SIMPLE and XCON communities in one shot. =20 =20 =20 =20 =20 ------_=_NextPart_001_01C40560.B99650C3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Guys,
Based = on the last=20 week comments, there is a requirement to optionally distinguish=20 between information per user's AOR vs.=20 per his/her GRUU(s) in XML documents (outside of SIP signaling = messages).
 
Mentioned examples=20 were Conference Package and Presence documents. (I suspect more usage = cases are=20 to come.)
In my = view, it is a=20 matter of specific system implementation/architecture whether, when, and = why you=20 need to expose this information. (I do find it useful in some=20 cases.)
 
Both = presence=20 documents and conference package are user-centric and (to the most = parts)=20 signaling-agnostic. I don't think it is wise to expand the existing XML = schemas=20 by doubling each URI placeholder to include signaling details, etc. I = think it=20 is more appropriate to define an optional URI parameter (e.g. = "gruu") that=20 can be appended to any SIP URI. By doing so, we can express = the fact=20 that a URI has GRUU properties without modifying existing XML schemas = and=20 without defining extended XML schemas in the future.
 
By = doing so, it is=20 up to the document provider to decide which level of granularity it = wants to=20 expose without making changes to existing XML = schema.
 
What = do you=20 think?
 
Orit.
PS: = Please, reply to=20 SIP list only. I just wanted to bring this question to the attention of = SIMPLE=20 and XCON communities in one shot.
 
 
 
 
 
------_=_NextPart_001_01C40560.B99650C3-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Mar 8 18:34:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11662 for ; Mon, 8 Mar 2004 18:34:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0UFy-0003oZ-Hx for xcon-archive@odin.ietf.org; Mon, 08 Mar 2004 18:33:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28NXwGE014662 for xcon-archive@odin.ietf.org; Mon, 8 Mar 2004 18:33:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0UFy-0003oP-BQ for xcon-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 18:33: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 SAA11631 for ; Mon, 8 Mar 2004 18:33:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0UFv-0003zN-00 for xcon-web-archive@ietf.org; Mon, 08 Mar 2004 18:33:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0UEx-0003pp-00 for xcon-web-archive@ietf.org; Mon, 08 Mar 2004 18:32:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0UE3-0003gU-00 for xcon-web-archive@ietf.org; Mon, 08 Mar 2004 18:31:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0UE4-0003gV-Rc; Mon, 08 Mar 2004 18:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0UE0-0003gG-0T for xcon@optimus.ietf.org; Mon, 08 Mar 2004 18:31: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 SAA11573 for ; Mon, 8 Mar 2004 18:31:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0UDw-0003fI-00 for xcon@ietf.org; Mon, 08 Mar 2004 18:31:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0UCy-0003VY-00 for xcon@ietf.org; Mon, 08 Mar 2004 18:30:52 -0500 Received: from brmx1.fl.icn.siemens.com ([12.147.96.32]) by ietf-mx with esmtp (Exim 4.12) id 1B0UBx-0003F4-00 for xcon@ietf.org; Mon, 08 Mar 2004 18:29:49 -0500 Received: from fdns2.rolm.com (fdns2.rolm.com [165.218.1.59]) by brmx1.fl.icn.siemens.com (8.9.3p092403/8.9.3) with ESMTP id SAA00818 for ; Mon, 8 Mar 2004 18:29:46 -0500 (EST) Received: from stca200a.bus.sc.rolm.com (stca200a.bus.sc.rolm.com [165.218.68.180]) by fdns2.rolm.com (8.12.10/8.12.10) with ESMTP id i28NTlO7024179 for ; Mon, 8 Mar 2004 15:29:47 -0800 (PST) Received: by stca200a.bus.sc.rolm.com with Internet Mail Service (5.5.2657.72) id ; Mon, 8 Mar 2004 15:29:46 -0800 Message-ID: From: "Kozdon, Peter" To: "'xcon@ietf.org'" Subject: RE: [XCON] Open Issue: Hidden Participants Date: Mon, 8 Mar 2004 15:27:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hidden listeners operation is probably illegal in many US states as well as in many countries - when you make a call there is a requirement in California the all parties are aware of the presence of a 3rd party or recording device, note- that party may be anonymous, etc.. (Exception -- legal intercept.) We should follow the similar logic for XCON - provide an indication of a recording device and/or anonymous participant's) Peter Kozdon -----Original Message----- From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of Adam Roach Sent: Monday, March 08, 2004 12:04 PM To: 'xcon@ietf.org' Subject: [XCON] Open Issue: Hidden Participants [as chair] At the XCON meeting, there was a rather lively discussion that continued the "Hidden Participants" discussion that had started on the list. It was agreed that the topic was worth discussion, but that we did not have enough time to pursue it in the meeting. I'm calling on everyone, especially those involved in the meeting discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to continue this discussion so we can close this issue in the near future. Alan and I would like to be able to last-call this document shortly, and this is the key issue that needs to be resolved before a new revision of the draft can be produced. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Mar 9 15:33:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21596 for ; Tue, 9 Mar 2004 15:33: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 1B0nuH-0001kt-2g for xcon-archive@odin.ietf.org; Tue, 09 Mar 2004 15:32:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29KWrP6006746 for xcon-archive@odin.ietf.org; Tue, 9 Mar 2004 15:32:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nuG-0001kj-Tj for xcon-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 15:32: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 PAA21581 for ; Tue, 9 Mar 2004 15:32:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0nuF-0006M4-00 for xcon-web-archive@ietf.org; Tue, 09 Mar 2004 15:32:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0ntN-0006CB-00 for xcon-web-archive@ietf.org; Tue, 09 Mar 2004 15:31:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0nsW-00060h-00 for xcon-web-archive@ietf.org; Tue, 09 Mar 2004 15:31:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nsU-0001dB-Cy; Tue, 09 Mar 2004 15: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 1B0nsI-0001bP-K6 for xcon@optimus.ietf.org; Tue, 09 Mar 2004 15:30: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 PAA21384 for ; Tue, 9 Mar 2004 15:30:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0nsH-0005yX-00 for xcon@ietf.org; Tue, 09 Mar 2004 15:30:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0nrI-0005lS-00 for xcon@ietf.org; Tue, 09 Mar 2004 15:29:48 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1B0nqM-0005QX-00 for xcon@ietf.org; Tue, 09 Mar 2004 15:28:50 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 850; Tue, 09 Mar 2004 15:27:49 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Open Issue: Hidden Participants Date: Tue, 9 Mar 2004 15:28:20 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D8428F6@zoe.office.snowshore.com> Thread-Topic: [XCON] Open Issue: Hidden Participants Thread-Index: AcQFZZN7qyw1/qvpSLyiak2aBN+0ZAAq9XbQ From: "Eric Burger" To: "Kozdon, Peter" , 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 think we got caught up on the name. There are two needs. The first, which I think we may have consensus on, is the need for = anonymous participants. That is, participants that are present in the = conference, but do not have their identities revealed. The second, which is more blurry, is the need for participants that are = truly hidden. Some want to use hidden participants for automatons, = e.g., IVR systems or conference recorders. (IMHO, bad idea, but that is = really just MHO, not strictly black-and-white.) We do have consensus that Lawful Intercept is entirely orthogonal to = conference participants. However, the logic of the above follows. Just = as IVR systems or conference recorders are not really participants, = neither is LI hardware. If we say that the approach for IVR is to plumb = in as a hidden participant, then LI would have the same approach. If we = say that IVR is something different, e.g., just a part of the conference = mixer, then it is truly "not there". Likewise, I would expect LI to be = "not there" -- something outside the XCON framework entirely. > -----Original Message----- > From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > Sent: Monday, March 08, 2004 6:28 PM > To: 'xcon@ietf.org' > Subject: RE: [XCON] Open Issue: Hidden Participants >=20 >=20 > Hidden listeners operation is probably illegal in many US=20 > states as well as > in many countries - when you make a call there is a requirement in > California the all parties are aware of the presence of a 3rd party or > recording device, note- that party may be anonymous, etc..=20 > (Exception -- > legal intercept.) >=20 > We should follow the similar logic for XCON - provide an=20 > indication of a > recording device and/or anonymous participant's)=20 >=20 > Peter Kozdon >=20 >=20 >=20 > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On=20 > Behalf Of Adam > Roach > Sent: Monday, March 08, 2004 12:04 PM > To: 'xcon@ietf.org' > Subject: [XCON] Open Issue: Hidden Participants >=20 > [as chair] >=20 > At the XCON meeting, there was a rather lively discussion=20 > that continued the > "Hidden Participants" discussion that had started on the=20 > list. It was agreed > that the topic was worth discussion, but that we did not have=20 > enough time to > pursue it in the meeting. >=20 > I'm calling on everyone, especially those involved in the=20 > meeting discussion > (Rohan, Alan, Eric, Roni, Hisham, Dave) to continue this=20 > discussion so we > can close this issue in the near future. Alan and I would=20 > like to be able to > last-call this document shortly, and this is the key issue=20 > that needs to be > resolved before a new revision of the draft can be produced. >=20 > /a >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Mar 9 19:33:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09494 for ; Tue, 9 Mar 2004 19:33: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 1B0ree-0006cN-Uw for xcon-archive@odin.ietf.org; Tue, 09 Mar 2004 19:33:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A0X0aw025435 for xcon-archive@odin.ietf.org; Tue, 9 Mar 2004 19: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 1B0ree-0006cA-P8 for xcon-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 19:33:00 -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 TAA09434 for ; Tue, 9 Mar 2004 19:32:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0red-0005Su-00 for xcon-web-archive@ietf.org; Tue, 09 Mar 2004 19:32:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0rdf-0005Hh-00 for xcon-web-archive@ietf.org; Tue, 09 Mar 2004 19:32:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0rck-00056V-00 for xcon-web-archive@ietf.org; Tue, 09 Mar 2004 19:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0rck-0006XJ-Rn; Tue, 09 Mar 2004 19: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 1B0rci-0006Wd-Eb for xcon@optimus.ietf.org; Tue, 09 Mar 2004 19:31:00 -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 TAA09362 for ; Tue, 9 Mar 2004 19:30:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0rcg-00055v-00 for xcon@ietf.org; Tue, 09 Mar 2004 19:30:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0rbg-0004t4-00 for xcon@ietf.org; Tue, 09 Mar 2004 19:29: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 1B0rai-0004aj-00 for xcon@ietf.org; Tue, 09 Mar 2004 19:28:56 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2A0SOc10340 for ; Tue, 9 Mar 2004 18:28:24 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <17CKKLJB>; Wed, 10 Mar 2004 00:28:23 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00B631AD6@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Eric Burger , "Kozdon, Peter" , xcon@ietf.org Subject: RE: [XCON] Open Issue: Hidden Participants Date: Wed, 10 Mar 2004 00:28:22 -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=AWL autolearn=no version=2.60 See below Keith > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: 09 March 2004 20:28 > To: Kozdon, Peter; xcon@ietf.org > Subject: RE: [XCON] Open Issue: Hidden Participants > snipped > > > We do have consensus that Lawful Intercept is entirely > orthogonal to conference participants. However, the logic of > the above follows. Just as IVR systems or conference > recorders are not really participants, neither is LI > hardware. If we say that the approach for IVR is to plumb in > as a hidden participant, then LI would have the same > approach. If we say that IVR is something different, e.g., > just a part of the conference mixer, then it is truly "not > there". Likewise, I would expect LI to be "not there" -- > something outside the XCON framework entirely. > The test to me is does the entity follow the rules for joining the conference that any other participant has to. Lawful Intercept certainly does not. I would agree with you that there is a case for IVR systems and conference recorders being automatically included as part of the conference function, and therefore they are not participants in the conference. Is it possible that such devices could also, for example, be referred in as normal participants. I'm in a conference, and suddenly decide that the current portion of the call should be recorded, and therefore send the appropriate REFER causing the recording device to join as a participant. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Mar 10 10:24:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15082 for ; Wed, 10 Mar 2004 10:24: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 1B15Yg-0004ke-IT for xcon-archive@odin.ietf.org; Wed, 10 Mar 2004 10:23:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AFNkqi018263 for xcon-archive@odin.ietf.org; Wed, 10 Mar 2004 10:23:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B15Yg-0004kU-BB for xcon-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 10:23:46 -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 KAA15026 for ; Wed, 10 Mar 2004 10:23:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B15Ye-0003LR-00 for xcon-web-archive@ietf.org; Wed, 10 Mar 2004 10:23:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B15XW-00033z-00 for xcon-web-archive@ietf.org; Wed, 10 Mar 2004 10:22:35 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B15WX-0002gA-00 for xcon-web-archive@ietf.org; Wed, 10 Mar 2004 10:21:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B15WY-0004S9-2u for xcon-web-archive@ietf.org; Wed, 10 Mar 2004 10:21:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B15WB-0004Fn-UU; Wed, 10 Mar 2004 10:21:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B15Vk-0003xS-6U for xcon@optimus.ietf.org; Wed, 10 Mar 2004 10:20:44 -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 KAA14448 for ; Wed, 10 Mar 2004 10:20:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B15Vh-0002RE-00 for xcon@ietf.org; Wed, 10 Mar 2004 10:20:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B15Tc-0001lf-00 for xcon@ietf.org; Wed, 10 Mar 2004 10:18: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 1B15RK-0000xd-00 for xcon@ietf.org; Wed, 10 Mar 2004 10:16:10 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 3066; Wed, 10 Mar 2004 10:15:06 -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] Open Issue: Hidden Participants Date: Wed, 10 Mar 2004 10:14:56 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB24396@zoe.office.snowshore.com> Thread-Topic: [XCON] Open Issue: Hidden Participants Thread-Index: AcQGNpusiZGxEkvPQkG5OMrDIHAvhgAe3vGA From: "Eric Burger" To: "Drage, Keith (Keith)" 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable We are always free to invite in a machine. The question is whether that = is a fundamental, architectural decision for how to do IVR, and thus = *requires* them to be hidden, or is it just something a user or = moderator can do (just REFER or INVITE them to the conference). If you believe it is a fundamental need, then they must be hidden, to = make user interfaces for the bulk of implementations reasonable. If you believe it is just a convenience (which is my personal stand), = then they don't need to be totally hidden. Frankly, IMHO it is a style choice, so I will accept the consensus, = either way it goes. > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Tuesday, March 09, 2004 7:28 PM > To: Eric Burger; Kozdon, Peter; xcon@ietf.org > Subject: RE: [XCON] Open Issue: Hidden Participants >=20 >=20 > See below >=20 > Keith >=20 > > -----Original Message----- > > From: Eric Burger [mailto:eburger@snowshore.com] > > Sent: 09 March 2004 20:28 > > To: Kozdon, Peter; xcon@ietf.org > > Subject: RE: [XCON] Open Issue: Hidden Participants > >=20 > snipped > >=20 > >=20 > > We do have consensus that Lawful Intercept is entirely=20 > > orthogonal to conference participants. However, the logic of=20 > > the above follows. Just as IVR systems or conference=20 > > recorders are not really participants, neither is LI=20 > > hardware. If we say that the approach for IVR is to plumb in=20 > > as a hidden participant, then LI would have the same=20 > > approach. If we say that IVR is something different, e.g.,=20 > > just a part of the conference mixer, then it is truly "not=20 > > there". Likewise, I would expect LI to be "not there" --=20 > > something outside the XCON framework entirely. > >=20 > The test to me is does the entity follow the rules for=20 > joining the conference that any other participant has to.=20 > Lawful Intercept certainly does not. >=20 > I would agree with you that there is a case for IVR systems=20 > and conference recorders being automatically included as part=20 > of the conference function, and therefore they are not=20 > participants in the conference. Is it possible that such=20 > devices could also, for example, be referred in as normal=20 > participants. I'm in a conference, and suddenly decide that=20 > the current portion of the call should be recorded, and=20 > therefore send the appropriate REFER causing the recording=20 > device to join as a participant. >=20 >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Mar 10 13:35:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25073 for ; Wed, 10 Mar 2004 13:35: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 1B18Xp-0000Ut-Mx for xcon-archive@odin.ietf.org; Wed, 10 Mar 2004 13:35:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AIZ5xX001907 for xcon-archive@odin.ietf.org; Wed, 10 Mar 2004 13:35:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18Xp-0000Uf-DV for xcon-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 13:35: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 NAA25026 for ; Wed, 10 Mar 2004 13:35:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B18Xn-0006et-00 for xcon-web-archive@ietf.org; Wed, 10 Mar 2004 13:35:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B18Wz-0006Sj-00 for xcon-web-archive@ietf.org; Wed, 10 Mar 2004 13:34:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B18Vq-0006HT-00 for xcon-web-archive@ietf.org; Wed, 10 Mar 2004 13:33:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18Vq-00008I-IO; Wed, 10 Mar 2004 13:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18VZ-0008U4-Dp for xcon@optimus.ietf.org; Wed, 10 Mar 2004 13:32: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 NAA24885 for ; Wed, 10 Mar 2004 13:32:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B18VX-0006Ec-00 for xcon@ietf.org; Wed, 10 Mar 2004 13:32:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B18Uc-00064s-00 for xcon@ietf.org; Wed, 10 Mar 2004 13:31:46 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B18Tg-0005nM-00 for xcon@ietf.org; Wed, 10 Mar 2004 13:30:48 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 10 Mar 2004 10:35:32 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2AIUFU7004921; Wed, 10 Mar 2004 13:30:15 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGR32751; Wed, 10 Mar 2004 13:30:14 -0500 (EST) Message-ID: <404F5EB6.3080301@cisco.com> Date: Wed, 10 Mar 2004 13:30:14 -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: Eric Burger CC: "Drage, Keith (Keith)" , xcon@ietf.org Subject: Re: [XCON] Open Issue: Hidden Participants References: <4A3384433CE2AB46A63468CB207E209DB24396@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric, I think there are two distinct cases here that are getting mixed: - participants that wish to remain unobserved - participants that watchers may want to ignore The former is the case that is similar to legal intercept. Other than permitting anonymous participants to register (or not) I don't think anything needs to be done to support this. I think Rohan was concerned about the latter. This need can be satisfied by ensuring that the participant list is annotated with enough attributes so that a watcher can choose to suppress the display of those participants that are uninteresting to its user. AFAIK there are no regulatory issues in this. So, if participants that are recorders or IVRs are identifiable as such, then a watcher *may* choose to hide the display of them. This would be strictly a UI implementation issue for a particular client. Paul Eric Burger wrote: > We are always free to invite in a machine. The question is whether that is a fundamental, architectural decision for how to do IVR, and thus *requires* them to be hidden, or is it just something a user or moderator can do (just REFER or INVITE them to the conference). > > If you believe it is a fundamental need, then they must be hidden, to make user interfaces for the bulk of implementations reasonable. > > If you believe it is just a convenience (which is my personal stand), then they don't need to be totally hidden. > > Frankly, IMHO it is a style choice, so I will accept the consensus, either way it goes. > > >>-----Original Message----- >>From: Drage, Keith (Keith) [mailto:drage@lucent.com] >>Sent: Tuesday, March 09, 2004 7:28 PM >>To: Eric Burger; Kozdon, Peter; xcon@ietf.org >>Subject: RE: [XCON] Open Issue: Hidden Participants >> >> >>See below >> >>Keith >> >> >>>-----Original Message----- >>>From: Eric Burger [mailto:eburger@snowshore.com] >>>Sent: 09 March 2004 20:28 >>>To: Kozdon, Peter; xcon@ietf.org >>>Subject: RE: [XCON] Open Issue: Hidden Participants >>> >> >>snipped >> >>> >>>We do have consensus that Lawful Intercept is entirely >>>orthogonal to conference participants. However, the logic of >>>the above follows. Just as IVR systems or conference >>>recorders are not really participants, neither is LI >>>hardware. If we say that the approach for IVR is to plumb in >>>as a hidden participant, then LI would have the same >>>approach. If we say that IVR is something different, e.g., >>>just a part of the conference mixer, then it is truly "not >>>there". Likewise, I would expect LI to be "not there" -- >>>something outside the XCON framework entirely. >>> >> >>The test to me is does the entity follow the rules for >>joining the conference that any other participant has to. >>Lawful Intercept certainly does not. >> >>I would agree with you that there is a case for IVR systems >>and conference recorders being automatically included as part >>of the conference function, and therefore they are not >>participants in the conference. Is it possible that such >>devices could also, for example, be referred in as normal >>participants. I'm in a conference, and suddenly decide that >>the current portion of the call should be recorded, and >>therefore send the appropriate REFER causing the recording >>device to join as a participant. >> >> >> > > > > _______________________________________________ > 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 Mar 10 13:37:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25220 for ; Wed, 10 Mar 2004 13:37: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 1B18ZW-0000bE-AS for xcon-archive@odin.ietf.org; Wed, 10 Mar 2004 13:36:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AIaoiH002298 for xcon-archive@odin.ietf.org; Wed, 10 Mar 2004 13:36:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18ZW-0000az-6C for xcon-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 13:36: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 NAA25207 for ; Wed, 10 Mar 2004 13:36:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B18ZU-0006zk-00 for xcon-web-archive@ietf.org; Wed, 10 Mar 2004 13:36:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B18Yc-0006pv-00 for xcon-web-archive@ietf.org; Wed, 10 Mar 2004 13:35:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B18Xk-0006eQ-00 for xcon-web-archive@ietf.org; Wed, 10 Mar 2004 13:35:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18Xl-0000SK-Cm; Wed, 10 Mar 2004 13:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18Wt-0000Ml-26 for xcon@optimus.ietf.org; Wed, 10 Mar 2004 13:34:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24923 for ; Wed, 10 Mar 2004 13:34:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B18Wq-0006RP-00 for xcon@ietf.org; Wed, 10 Mar 2004 13:34:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B18Vh-0006GM-00 for xcon@ietf.org; Wed, 10 Mar 2004 13:32:54 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1B18V2-00063Z-00 for xcon@ietf.org; Wed, 10 Mar 2004 13:32:12 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 845; Wed, 10 Mar 2004 13:31:08 -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] Open Issue: Hidden Participants Date: Wed, 10 Mar 2004 13:31:36 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209DB243A3@zoe.office.snowshore.com> Thread-Topic: [XCON] Open Issue: Hidden Participants Thread-Index: AcQGzb36TJIjgjWWTSe9OeX3Gy2j8AAACBSQ From: "Eric Burger" To: "Paul Kyzivat" 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I like it (hidden indicator)! > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, March 10, 2004 1:30 PM > To: Eric Burger > Cc: Drage, Keith (Keith); xcon@ietf.org > Subject: Re: [XCON] Open Issue: Hidden Participants >=20 >=20 > Eric, >=20 > I think there are two distinct cases here that are getting mixed: >=20 > - participants that wish to remain unobserved > - participants that watchers may want to ignore >=20 > The former is the case that is similar to legal intercept. Other than=20 > permitting anonymous participants to register (or not) I don't think=20 > anything needs to be done to support this. >=20 > I think Rohan was concerned about the latter. This need can=20 > be satisfied=20 > by ensuring that the participant list is annotated with enough=20 > attributes so that a watcher can choose to suppress the=20 > display of those=20 > participants that are uninteresting to its user. AFAIK there are no=20 > regulatory issues in this. >=20 > So, if participants that are recorders or IVRs are=20 > identifiable as such,=20 > then a watcher *may* choose to hide the display of them. This=20 > would be=20 > strictly a UI implementation issue for a particular client. >=20 > Paul >=20 > Eric Burger wrote: > > We are always free to invite in a machine. The question is=20 > whether that is a fundamental, architectural decision for how=20 > to do IVR, and thus *requires* them to be hidden, or is it=20 > just something a user or moderator can do (just REFER or=20 > INVITE them to the conference). > >=20 > > If you believe it is a fundamental need, then they must be=20 > hidden, to make user interfaces for the bulk of=20 > implementations reasonable. > >=20 > > If you believe it is just a convenience (which is my=20 > personal stand), then they don't need to be totally hidden. > >=20 > > Frankly, IMHO it is a style choice, so I will accept the=20 > consensus, either way it goes. > >=20 > >=20 > >>-----Original Message----- > >>From: Drage, Keith (Keith) [mailto:drage@lucent.com] > >>Sent: Tuesday, March 09, 2004 7:28 PM > >>To: Eric Burger; Kozdon, Peter; xcon@ietf.org > >>Subject: RE: [XCON] Open Issue: Hidden Participants > >> > >> > >>See below > >> > >>Keith > >> > >> > >>>-----Original Message----- > >>>From: Eric Burger [mailto:eburger@snowshore.com] > >>>Sent: 09 March 2004 20:28 > >>>To: Kozdon, Peter; xcon@ietf.org > >>>Subject: RE: [XCON] Open Issue: Hidden Participants > >>> > >> > >>snipped > >> > >>> > >>>We do have consensus that Lawful Intercept is entirely=20 > >>>orthogonal to conference participants. However, the logic of=20 > >>>the above follows. Just as IVR systems or conference=20 > >>>recorders are not really participants, neither is LI=20 > >>>hardware. If we say that the approach for IVR is to plumb in=20 > >>>as a hidden participant, then LI would have the same=20 > >>>approach. If we say that IVR is something different, e.g.,=20 > >>>just a part of the conference mixer, then it is truly "not=20 > >>>there". Likewise, I would expect LI to be "not there" --=20 > >>>something outside the XCON framework entirely. > >>> > >> > >>The test to me is does the entity follow the rules for=20 > >>joining the conference that any other participant has to.=20 > >>Lawful Intercept certainly does not. > >> > >>I would agree with you that there is a case for IVR systems=20 > >>and conference recorders being automatically included as part=20 > >>of the conference function, and therefore they are not=20 > >>participants in the conference. Is it possible that such=20 > >>devices could also, for example, be referred in as normal=20 > >>participants. I'm in a conference, and suddenly decide that=20 > >>the current portion of the call should be recorded, and=20 > >>therefore send the appropriate REFER causing the recording=20 > >>device to join as a participant. > >> > >> > >> > >=20 > >=20 > >=20 > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > >=20 >=20 >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Wed Mar 10 21:55:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22446 for ; Wed, 10 Mar 2004 21:55: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 1B1GLk-0002pi-Ga for xcon-archive@odin.ietf.org; Wed, 10 Mar 2004 21:55:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B2t8iJ010884 for xcon-archive@odin.ietf.org; Wed, 10 Mar 2004 21:55:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1GLk-0002pT-99 for xcon-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 21:55:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22422 for ; Wed, 10 Mar 2004 21:55:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1GLh-0002Qu-00 for xcon-web-archive@ietf.org; Wed, 10 Mar 2004 21:55:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1GKk-0002JU-00 for xcon-web-archive@ietf.org; Wed, 10 Mar 2004 21:54:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1GKd-0002CE-00 for xcon-web-archive@ietf.org; Wed, 10 Mar 2004 21: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 1B1GKf-0002lS-5T; Wed, 10 Mar 2004 21: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 1B1GJr-0002j8-5d for xcon@optimus.ietf.org; Wed, 10 Mar 2004 21:53:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22377 for ; Wed, 10 Mar 2004 21:53:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1GJo-0002BE-00 for xcon@ietf.org; Wed, 10 Mar 2004 21:53:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1GIt-00023N-00 for xcon@ietf.org; Wed, 10 Mar 2004 21:52:12 -0500 Received: from mail.siemenscom.com ([12.146.131.10]) by ietf-mx with esmtp (Exim 4.12) id 1B1GIG-0001vG-00 for xcon@ietf.org; Wed, 10 Mar 2004 21:51:33 -0500 Received: from fdns2.rolm.com (fdns2.rolm.com [165.218.1.59]) by mail.siemenscom.com (8.9.3p092403/8.9.3) with ESMTP id SAA15451; Wed, 10 Mar 2004 18:51:02 -0800 (PST) Received: from stca200a.bus.sc.rolm.com (stca200a.bus.sc.rolm.com [165.218.68.180]) by fdns2.rolm.com (8.12.10/8.12.10) with ESMTP id i2B2pSo1017587; Wed, 10 Mar 2004 18:51:28 -0800 (PST) Received: by stca200a.bus.sc.rolm.com with Internet Mail Service (5.5.2657.72) id ; Wed, 10 Mar 2004 18:51:28 -0800 Message-ID: From: "Kozdon, Peter" To: Eric Burger , xcon@ietf.org Subject: RE: [XCON] Open Issue: Hidden Participants Date: Wed, 10 Mar 2004 18:49:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I agree that automatons are processing resources and could be considered as logical parts of the conference fabric, for example an IVR could monitor the conference and provide a trigger in response to a phrase that could be consumed elsewhere. Similarly a device that announces participants, etc.. However, IMHO a conference recorder does not fall into this category and should probably be a visible resource maybe with an indicator to show whether it is or is not active. Similarly - a player resources which delivers content or information to the conference should also be visible - it seems desirable to know where such content is coming from. -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Tuesday, March 09, 2004 1:28 PM To: Kozdon, Peter; xcon@ietf.org Subject: RE: [XCON] Open Issue: Hidden Participants I think we got caught up on the name. There are two needs. The first, which I think we may have consensus on, is the need for anonymous participants. That is, participants that are present in the conference, but do not have their identities revealed. The second, which is more blurry, is the need for participants that are truly hidden. Some want to use hidden participants for automatons, e.g., IVR systems or conference recorders. (IMHO, bad idea, but that is really just MHO, not strictly black-and-white.) We do have consensus that Lawful Intercept is entirely orthogonal to conference participants. However, the logic of the above follows. Just as IVR systems or conference recorders are not really participants, neither is LI hardware. If we say that the approach for IVR is to plumb in as a hidden participant, then LI would have the same approach. If we say that IVR is something different, e.g., just a part of the conference mixer, then it is truly "not there". Likewise, I would expect LI to be "not there" -- something outside the XCON framework entirely. > -----Original Message----- > From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > Sent: Monday, March 08, 2004 6:28 PM > To: 'xcon@ietf.org' > Subject: RE: [XCON] Open Issue: Hidden Participants > > > Hidden listeners operation is probably illegal in many US states as > well as in many countries - when you make a call there is a > requirement in California the all parties are aware of the presence of > a 3rd party or recording device, note- that party may be anonymous, > etc.. > (Exception -- > legal intercept.) > > We should follow the similar logic for XCON - provide an indication of > a recording device and/or anonymous participant's) > > Peter Kozdon > > > > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of > Adam Roach > Sent: Monday, March 08, 2004 12:04 PM > To: 'xcon@ietf.org' > Subject: [XCON] Open Issue: Hidden Participants > > [as chair] > > At the XCON meeting, there was a rather lively discussion that > continued the "Hidden Participants" discussion that had started on the > list. It was agreed that the topic was worth discussion, but that we > did not have enough time to pursue it in the meeting. > > I'm calling on everyone, especially those involved in the meeting > discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to continue this > discussion so we can close this issue in the near future. Alan and I > would like to be able to last-call this document shortly, and this is > the key issue that needs to be resolved before a new revision of the > draft can be produced. > > /a > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 11 00:31:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28327 for ; Thu, 11 Mar 2004 00:31: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 1B1In4-0003fP-Hi for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 00:31:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B5VUwH014086 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 00:31:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1In4-0003f1-AV for xcon-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 00:31:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28323 for ; Thu, 11 Mar 2004 00:31:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1In1-0002Km-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 00:31:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1ImA-0002BR-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 00:30:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1Ilc-00021S-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 00:30:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Ile-0003Xg-3T; Thu, 11 Mar 2004 00: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 1B1Il4-0003UD-2P for xcon@optimus.ietf.org; Thu, 11 Mar 2004 00:29: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 AAA28236 for ; Thu, 11 Mar 2004 00:29:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Il1-000208-00 for xcon@ietf.org; Thu, 11 Mar 2004 00:29:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Ik1-0001sM-00 for xcon@ietf.org; Thu, 11 Mar 2004 00:28:22 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1B1Iji-0001jF-00 for xcon@ietf.org; Thu, 11 Mar 2004 00:28:02 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i2B5RTX7002808; Wed, 10 Mar 2004 23:27:29 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Mar 2004 23:27:28 -0600 Message-ID: <9ACE0CEE075B494096C86C23878BF85906A3A3@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Kozdon, Peter'" , Eric Burger , xcon@ietf.org Subject: RE: [XCON] Open Issue: Hideable Participants Date: Wed, 10 Mar 2004 23:27:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 [not as chair] I don't think anyone is currently arguing whether indication of such automata should be available to the users. Most of what I've heard people say on this list -- after Korea, at least -- seems to agree that such elements *should* be indicated in the protocol. Note that this is not the same thing as saying that they must be forcibly rendered to users regardless of the users want, which is what you seem to be arguing for. What I've heard -- and I agree with this viewpoint -- is that there should be some flag that indicates "this element is a facilitator, not a participant," so that users who don't *care* about seeing such elements (existence proof: me) could configure their clients not to display them. To expand on the flag's meaning, it would make the most sense to have it mean more precisely "this element is not truly a participant, but is providing some service related to the conference." In other words, I would want it to cover e.g. human transcribers, human translators, etc., in addition to automata. As Eric points out, I think people are getting hung up on the name without thinking the issue through completely. I've updated the subject line accordingly. /a > -----Original Message----- > From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > Sent: Wednesday, March 10, 2004 20:50 > To: Eric Burger; xcon@ietf.org > Subject: RE: [XCON] Open Issue: Hidden Participants > > > I agree that automatons are processing resources and could be > considered as > logical parts of the conference fabric, for example an IVR > could monitor the > conference and provide a trigger in response to a phrase that could be > consumed elsewhere. Similarly a device that announces > participants, etc.. > However, IMHO a conference recorder does not fall into this > category and > should probably be a visible resource maybe with an indicator to show > whether it is or is not active. Similarly - a player resources which > delivers content or information to the conference should also > be visible - > it seems desirable to know where such content is coming from. > > > > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Tuesday, March 09, 2004 1:28 PM > To: Kozdon, Peter; xcon@ietf.org > Subject: RE: [XCON] Open Issue: Hidden Participants > > I think we got caught up on the name. > > There are two needs. > > The first, which I think we may have consensus on, is the > need for anonymous > participants. That is, participants that are present in the > conference, but > do not have their identities revealed. > > The second, which is more blurry, is the need for > participants that are > truly hidden. Some want to use hidden participants for > automatons, e.g., > IVR systems or conference recorders. (IMHO, bad idea, but > that is really > just MHO, not strictly black-and-white.) > > We do have consensus that Lawful Intercept is entirely orthogonal to > conference participants. However, the logic of the above > follows. Just as > IVR systems or conference recorders are not really > participants, neither is > LI hardware. If we say that the approach for IVR is to plumb > in as a hidden > participant, then LI would have the same approach. If we say > that IVR is > something different, e.g., just a part of the conference > mixer, then it is > truly "not there". Likewise, I would expect LI to be "not there" -- > something outside the XCON framework entirely. > > > -----Original Message----- > > From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > > Sent: Monday, March 08, 2004 6:28 PM > > To: 'xcon@ietf.org' > > Subject: RE: [XCON] Open Issue: Hidden Participants > > > > > > Hidden listeners operation is probably illegal in many US states as > > well as in many countries - when you make a call there is a > > requirement in California the all parties are aware of the > presence of > > a 3rd party or recording device, note- that party may be anonymous, > > etc.. > > (Exception -- > > legal intercept.) > > > > We should follow the similar logic for XCON - provide an > indication of > > a recording device and/or anonymous participant's) > > > > Peter Kozdon > > > > > > > > -----Original Message----- > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of > > Adam Roach > > Sent: Monday, March 08, 2004 12:04 PM > > To: 'xcon@ietf.org' > > Subject: [XCON] Open Issue: Hidden Participants > > > > [as chair] > > > > At the XCON meeting, there was a rather lively discussion that > > continued the "Hidden Participants" discussion that had > started on the > > list. It was agreed that the topic was worth discussion, > but that we > > did not have enough time to pursue it in the meeting. > > > > I'm calling on everyone, especially those involved in the meeting > > discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to continue this > > discussion so we can close this issue in the near future. > Alan and I > > would like to be able to last-call this document shortly, > and this is > > the key issue that needs to be resolved before a new > revision of the > > draft can be produced. > > > > /a > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 11 09:19:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03032 for ; Thu, 11 Mar 2004 09:19: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 1B1R1E-0001SN-Hv for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 09:18:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BEIegU005590 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 09:18:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1R1E-0001S2-6R for xcon-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 09:18: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 JAA03018 for ; Thu, 11 Mar 2004 09:18:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1R1C-0006oN-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 09:18:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1R0L-0006ge-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 09:17:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1Qzc-0006Yl-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 09:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Qze-0001Ji-0Q; Thu, 11 Mar 2004 09:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1QzH-0001Hd-Vy for xcon@optimus.ietf.org; Thu, 11 Mar 2004 09:16: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 JAA02961 for ; Thu, 11 Mar 2004 09:16:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1QzG-0006Wc-00 for xcon@ietf.org; Thu, 11 Mar 2004 09:16:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1QyR-0006NP-00 for xcon@ietf.org; Thu, 11 Mar 2004 09:15:48 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1B1QxU-000654-00 for xcon@ietf.org; Thu, 11 Mar 2004 09:14:48 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i2BEE1aZ012348; Thu, 11 Mar 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 JAA10250; Thu, 11 Mar 2004 09:14:01 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Mar 2004 09:14:01 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B64DB@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Adam Roach'" , "'Kozdon, Peter'" , Eric Burger , xcon@ietf.org Subject: RE: [XCON] Open Issue: Hideable Participants Date: Thu, 11 Mar 2004 09:14:00 -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.1 required=5.0 tests=AWL autolearn=no version=2.60 Seems to me that you are on the right track, but we need to go farther. We have to classify these participants so that the UI, if it wanted to, could render an appropriate indication. The example of the recorder is pretty compelling. Just knowing that there is an automaton out there is one thing. Knowing its a recorder is another. So, really you don't want a flag, you want an enunumeration. It may actually be a list, because a single automaton could have multiple functions. Brian > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Thursday, March 11, 2004 12:27 AM > To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org > Subject: RE: [XCON] Open Issue: Hideable Participants > > > [not as chair] > > I don't think anyone is currently arguing whether indication > of such automata should be available to the users. Most > of what I've heard people say on this list -- after Korea, > at least -- seems to agree that such elements *should* > be indicated in the protocol. Note that this is not the > same thing as saying that they must be forcibly rendered > to users regardless of the users want, which is what you > seem to be arguing for. > > What I've heard -- and I agree with this viewpoint -- is > that there should be some flag that indicates "this element > is a facilitator, not a participant," so that users who don't > *care* about seeing such elements (existence proof: me) > could configure their clients not to display them. > > To expand on the flag's meaning, it would make the most > sense to have it mean more precisely "this element is not > truly a participant, but is providing some service related > to the conference." In other words, I would want it to > cover e.g. human transcribers, human translators, etc., > in addition to automata. > > As Eric points out, I think people are getting hung up on > the name without thinking the issue through completely. > I've updated the subject line accordingly. > > /a > > > -----Original Message----- > > From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > > Sent: Wednesday, March 10, 2004 20:50 > > To: Eric Burger; xcon@ietf.org > > Subject: RE: [XCON] Open Issue: Hidden Participants > > > > > > I agree that automatons are processing resources and could be > > considered as > > logical parts of the conference fabric, for example an IVR > > could monitor the > > conference and provide a trigger in response to a phrase > that could be > > consumed elsewhere. Similarly a device that announces > > participants, etc.. > > However, IMHO a conference recorder does not fall into this > > category and > > should probably be a visible resource maybe with an > indicator to show > > whether it is or is not active. Similarly - a player resources which > > delivers content or information to the conference should also > > be visible - > > it seems desirable to know where such content is coming from. > > > > > > > > -----Original Message----- > > From: Eric Burger [mailto:eburger@snowshore.com] > > Sent: Tuesday, March 09, 2004 1:28 PM > > To: Kozdon, Peter; xcon@ietf.org > > Subject: RE: [XCON] Open Issue: Hidden Participants > > > > I think we got caught up on the name. > > > > There are two needs. > > > > The first, which I think we may have consensus on, is the > > need for anonymous > > participants. That is, participants that are present in the > > conference, but > > do not have their identities revealed. > > > > The second, which is more blurry, is the need for > > participants that are > > truly hidden. Some want to use hidden participants for > > automatons, e.g., > > IVR systems or conference recorders. (IMHO, bad idea, but > > that is really > > just MHO, not strictly black-and-white.) > > > > We do have consensus that Lawful Intercept is entirely orthogonal to > > conference participants. However, the logic of the above > > follows. Just as > > IVR systems or conference recorders are not really > > participants, neither is > > LI hardware. If we say that the approach for IVR is to plumb > > in as a hidden > > participant, then LI would have the same approach. If we say > > that IVR is > > something different, e.g., just a part of the conference > > mixer, then it is > > truly "not there". Likewise, I would expect LI to be "not there" -- > > something outside the XCON framework entirely. > > > > > -----Original Message----- > > > From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > > > Sent: Monday, March 08, 2004 6:28 PM > > > To: 'xcon@ietf.org' > > > Subject: RE: [XCON] Open Issue: Hidden Participants > > > > > > > > > Hidden listeners operation is probably illegal in many US > states as > > > well as in many countries - when you make a call there is a > > > requirement in California the all parties are aware of the > > presence of > > > a 3rd party or recording device, note- that party may be > anonymous, > > > etc.. > > > (Exception -- > > > legal intercept.) > > > > > > We should follow the similar logic for XCON - provide an > > indication of > > > a recording device and/or anonymous participant's) > > > > > > Peter Kozdon > > > > > > > > > > > > -----Original Message----- > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On > Behalf Of > > > Adam Roach > > > Sent: Monday, March 08, 2004 12:04 PM > > > To: 'xcon@ietf.org' > > > Subject: [XCON] Open Issue: Hidden Participants > > > > > > [as chair] > > > > > > At the XCON meeting, there was a rather lively discussion that > > > continued the "Hidden Participants" discussion that had > > started on the > > > list. It was agreed that the topic was worth discussion, > > but that we > > > did not have enough time to pursue it in the meeting. > > > > > > I'm calling on everyone, especially those involved in the meeting > > > discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to > continue this > > > discussion so we can close this issue in the near future. > > Alan and I > > > would like to be able to last-call this document shortly, > > and this is > > > the key issue that needs to be resolved before a new > > revision of the > > > draft can be produced. > > > > > > /a > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 11 10:09:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05245 for ; Thu, 11 Mar 2004 10:09:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Rna-000856-DB for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 10:08:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BF8cdA031055 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 10:08:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Rna-00084c-4R for xcon-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 10:08: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 KAA05173 for ; Thu, 11 Mar 2004 10:08:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1RnY-0005fx-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 10:08:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Rme-0005Y1-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 10:07:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1Rlz-0005RF-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 10:06:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Rm0-0007TV-4a; Thu, 11 Mar 2004 10:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Rlc-0007NO-Aq for xcon@optimus.ietf.org; Thu, 11 Mar 2004 10:06: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 KAA04982 for ; Thu, 11 Mar 2004 10:06:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Rla-0005PJ-00 for xcon@ietf.org; Thu, 11 Mar 2004 10:06:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Rkb-0005Gh-00 for xcon@ietf.org; Thu, 11 Mar 2004 10:05:34 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1B1Rjc-00052i-00 for xcon@ietf.org; Thu, 11 Mar 2004 10:04:32 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 11 Mar 2004 07:02:06 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2BF3xUk018058; Thu, 11 Mar 2004 10:04:00 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGR96231; Thu, 11 Mar 2004 10:03:58 -0500 (EST) Message-ID: <40507FDE.1050409@cisco.com> Date: Thu, 11 Mar 2004 10:03:58 -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: "Rosen, Brian" CC: "'Adam Roach'" , "'Kozdon, Peter'" , Eric Burger , xcon@ietf.org Subject: Re: [XCON] Open Issue: Hideable Participants References: <313680C9A886D511A06000204840E1CF070B64DB@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree with Brian. I think this is more-or-less a "role" for the participant, with the possibility of a single participant fulfilling multiple roles. One instance of this is already covered - when a participant is another focus. This potentially overlaps with callee-caps. We already have is-focus, message-taker, automaton & attendant there, all of which are relevant here. Paul Rosen, Brian wrote: > Seems to me that you are on the right track, but we need to go farther. > We have to classify these participants so that the UI, if it wanted to, > could render an appropriate indication. The example of the recorder > is pretty compelling. Just knowing that there is an automaton out there > is one thing. Knowing its a recorder is another. So, really you > don't want a flag, you want an enunumeration. It may actually be > a list, because a single automaton could have multiple functions. > > Brian > > >>-----Original Message----- >>From: Adam Roach [mailto:adam@dynamicsoft.com] >>Sent: Thursday, March 11, 2004 12:27 AM >>To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org >>Subject: RE: [XCON] Open Issue: Hideable Participants >> >> >>[not as chair] >> >>I don't think anyone is currently arguing whether indication >>of such automata should be available to the users. Most >>of what I've heard people say on this list -- after Korea, >>at least -- seems to agree that such elements *should* >>be indicated in the protocol. Note that this is not the >>same thing as saying that they must be forcibly rendered >>to users regardless of the users want, which is what you >>seem to be arguing for. >> >>What I've heard -- and I agree with this viewpoint -- is >>that there should be some flag that indicates "this element >>is a facilitator, not a participant," so that users who don't >>*care* about seeing such elements (existence proof: me) >>could configure their clients not to display them. >> >>To expand on the flag's meaning, it would make the most >>sense to have it mean more precisely "this element is not >>truly a participant, but is providing some service related >>to the conference." In other words, I would want it to >>cover e.g. human transcribers, human translators, etc., >>in addition to automata. >> >>As Eric points out, I think people are getting hung up on >>the name without thinking the issue through completely. >>I've updated the subject line accordingly. >> >>/a >> >> >>>-----Original Message----- >>>From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>Sent: Wednesday, March 10, 2004 20:50 >>>To: Eric Burger; xcon@ietf.org >>>Subject: RE: [XCON] Open Issue: Hidden Participants >>> >>> >>>I agree that automatons are processing resources and could be >>>considered as >>>logical parts of the conference fabric, for example an IVR >>>could monitor the >>>conference and provide a trigger in response to a phrase >> >>that could be >> >>>consumed elsewhere. Similarly a device that announces >>>participants, etc.. >>>However, IMHO a conference recorder does not fall into this >>>category and >>>should probably be a visible resource maybe with an >> >>indicator to show >> >>>whether it is or is not active. Similarly - a player resources which >>>delivers content or information to the conference should also >>>be visible - >>>it seems desirable to know where such content is coming from. >>> >>> >>> >>>-----Original Message----- >>>From: Eric Burger [mailto:eburger@snowshore.com] >>>Sent: Tuesday, March 09, 2004 1:28 PM >>>To: Kozdon, Peter; xcon@ietf.org >>>Subject: RE: [XCON] Open Issue: Hidden Participants >>> >>>I think we got caught up on the name. >>> >>>There are two needs. >>> >>>The first, which I think we may have consensus on, is the >>>need for anonymous >>>participants. That is, participants that are present in the >>>conference, but >>>do not have their identities revealed. >>> >>>The second, which is more blurry, is the need for >>>participants that are >>>truly hidden. Some want to use hidden participants for >>>automatons, e.g., >>>IVR systems or conference recorders. (IMHO, bad idea, but >>>that is really >>>just MHO, not strictly black-and-white.) >>> >>>We do have consensus that Lawful Intercept is entirely orthogonal to >>>conference participants. However, the logic of the above >>>follows. Just as >>>IVR systems or conference recorders are not really >>>participants, neither is >>>LI hardware. If we say that the approach for IVR is to plumb >>>in as a hidden >>>participant, then LI would have the same approach. If we say >>>that IVR is >>>something different, e.g., just a part of the conference >>>mixer, then it is >>>truly "not there". Likewise, I would expect LI to be "not there" -- >>>something outside the XCON framework entirely. >>> >>> >>>>-----Original Message----- >>>>From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>>Sent: Monday, March 08, 2004 6:28 PM >>>>To: 'xcon@ietf.org' >>>>Subject: RE: [XCON] Open Issue: Hidden Participants >>>> >>>> >>>>Hidden listeners operation is probably illegal in many US >>> >>states as >> >>>>well as in many countries - when you make a call there is a >>>>requirement in California the all parties are aware of the >>> >>>presence of >>> >>>>a 3rd party or recording device, note- that party may be >>> >>anonymous, >> >>>>etc.. >>>>(Exception -- >>>>legal intercept.) >>>> >>>>We should follow the similar logic for XCON - provide an >>> >>>indication of >>> >>>>a recording device and/or anonymous participant's) >>>> >>>>Peter Kozdon >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On >>> >>Behalf Of >> >>>>Adam Roach >>>>Sent: Monday, March 08, 2004 12:04 PM >>>>To: 'xcon@ietf.org' >>>>Subject: [XCON] Open Issue: Hidden Participants >>>> >>>>[as chair] >>>> >>>>At the XCON meeting, there was a rather lively discussion that >>>>continued the "Hidden Participants" discussion that had >>> >>>started on the >>> >>>>list. It was agreed that the topic was worth discussion, >>> >>>but that we >>> >>>>did not have enough time to pursue it in the meeting. >>>> >>>>I'm calling on everyone, especially those involved in the meeting >>>>discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to >>> >>continue this >> >>>>discussion so we can close this issue in the near future. >>> >>>Alan and I >>> >>>>would like to be able to last-call this document shortly, >>> >>>and this is >>> >>>>the key issue that needs to be resolved before a new >>> >>>revision of the >>> >>>>draft can be produced. >>>> >>>>/a >>>> >>>>_______________________________________________ >>>>XCON mailing list >>>>XCON@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/xcon >>>> >>>>_______________________________________________ >>>>XCON mailing list >>>>XCON@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/xcon >>>> >>>> >>> >>>_______________________________________________ >>>XCON mailing list >>>XCON@ietf.org >>>https://www1.ietf.org/mailman/listinfo/xcon >>> >> >>_______________________________________________ >>XCON mailing list >>XCON@ietf.org >>https://www1.ietf.org/mailman/listinfo/xcon >> > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 11 10:11:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05471 for ; Thu, 11 Mar 2004 10:11:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1RpZ-0000GH-OG for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 10:10:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BFAfGL000999 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 10:10:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1RpZ-0000G0-Gz for xcon-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 10:10: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 KAA05417 for ; Thu, 11 Mar 2004 10:10:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1RpX-0005wM-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 10:10:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Rob-0005pB-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 10:09:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1Rnv-0005ht-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 10:08:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Rnw-0008G4-NB; Thu, 11 Mar 2004 10:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Rng-00086e-SK for xcon@optimus.ietf.org; Thu, 11 Mar 2004 10:08:44 -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 KAA05208 for ; Thu, 11 Mar 2004 10:08:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Rne-0005gw-00 for xcon@ietf.org; Thu, 11 Mar 2004 10:08:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Rml-0005ZF-00 for xcon@ietf.org; Thu, 11 Mar 2004 10:07:49 -0500 Received: from pmesmtp01.wcom.com ([199.249.20.1] helo=pmesmtp01.mci.com) by ietf-mx with esmtp (Exim 4.12) id 1B1RmI-0005RC-00 for xcon@ietf.org; Thu, 11 Mar 2004 10:07:18 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HUF00MFR39515@firewall.mci.com> for xcon@ietf.org; Thu, 11 Mar 2004 15:05:30 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HUF00A0133UMF@pmismtp01.mcilink.com>; Thu, 11 Mar 2004 15:05:30 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.153.216]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HUF00AAZ38YEW@pmismtp01.mcilink.com>; Thu, 11 Mar 2004 15:05:25 +0000 (GMT) Date: Thu, 11 Mar 2004 09:05:22 -0600 From: Alan Johnston Subject: RE: [XCON] Open Issue: Hideable Participants X-Sender: Alan.Johnston@pop.mcit.com To: "Rosen, Brian" , "'Adam Roach'" , "'Kozdon, Peter'" , Eric Burger , xcon@ietf.org Message-id: <5.2.1.1.0.20040311085819.02d0c018@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.1 required=5.0 tests=AWL autolearn=no version=2.60 Note that we are talking about the ability to mark, using CPCP, the type of participant in a conference. This information is then conveyed to the participants in a conference using the Conference Package. The latest version of the conference package includes an attribute for the conference-info tag to indicate whether the conference is being recorded. From Section 4.1 (http://www.ietf.org/internet-drafts/draft-ietf-sipping-conference-package-03.txt): recording: This optional attribute indicates whether the conference is being recorded at this moment ("on") or not ("off"). We need to decide if this is sufficient information or whether more is needed. Also, it sounds like we need a new attribute to the user tag to indicate "hidden" - that is, not a real participant in the conference as Adam describes below. Thanks, Alan Johnston MCI sip:alan@sipstation.com At 09:14 AM 3/11/2004 -0500, Rosen, Brian wrote: >Seems to me that you are on the right track, but we need to go farther. >We have to classify these participants so that the UI, if it wanted to, >could render an appropriate indication. The example of the recorder >is pretty compelling. Just knowing that there is an automaton out there >is one thing. Knowing its a recorder is another. So, really you >don't want a flag, you want an enunumeration. It may actually be >a list, because a single automaton could have multiple functions. > >Brian > > > -----Original Message----- > > From: Adam Roach [mailto:adam@dynamicsoft.com] > > Sent: Thursday, March 11, 2004 12:27 AM > > To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org > > Subject: RE: [XCON] Open Issue: Hideable Participants > > > > > > [not as chair] > > > > I don't think anyone is currently arguing whether indication > > of such automata should be available to the users. Most > > of what I've heard people say on this list -- after Korea, > > at least -- seems to agree that such elements *should* > > be indicated in the protocol. Note that this is not the > > same thing as saying that they must be forcibly rendered > > to users regardless of the users want, which is what you > > seem to be arguing for. > > > > What I've heard -- and I agree with this viewpoint -- is > > that there should be some flag that indicates "this element > > is a facilitator, not a participant," so that users who don't > > *care* about seeing such elements (existence proof: me) > > could configure their clients not to display them. > > > > To expand on the flag's meaning, it would make the most > > sense to have it mean more precisely "this element is not > > truly a participant, but is providing some service related > > to the conference." In other words, I would want it to > > cover e.g. human transcribers, human translators, etc., > > in addition to automata. > > > > As Eric points out, I think people are getting hung up on > > the name without thinking the issue through completely. > > I've updated the subject line accordingly. > > > > /a > > > > > -----Original Message----- > > > From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > > > Sent: Wednesday, March 10, 2004 20:50 > > > To: Eric Burger; xcon@ietf.org > > > Subject: RE: [XCON] Open Issue: Hidden Participants > > > > > > > > > I agree that automatons are processing resources and could be > > > considered as > > > logical parts of the conference fabric, for example an IVR > > > could monitor the > > > conference and provide a trigger in response to a phrase > > that could be > > > consumed elsewhere. Similarly a device that announces > > > participants, etc.. > > > However, IMHO a conference recorder does not fall into this > > > category and > > > should probably be a visible resource maybe with an > > indicator to show > > > whether it is or is not active. Similarly - a player resources which > > > delivers content or information to the conference should also > > > be visible - > > > it seems desirable to know where such content is coming from. > > > > > > > > > > > > -----Original Message----- > > > From: Eric Burger [mailto:eburger@snowshore.com] > > > Sent: Tuesday, March 09, 2004 1:28 PM > > > To: Kozdon, Peter; xcon@ietf.org > > > Subject: RE: [XCON] Open Issue: Hidden Participants > > > > > > I think we got caught up on the name. > > > > > > There are two needs. > > > > > > The first, which I think we may have consensus on, is the > > > need for anonymous > > > participants. That is, participants that are present in the > > > conference, but > > > do not have their identities revealed. > > > > > > The second, which is more blurry, is the need for > > > participants that are > > > truly hidden. Some want to use hidden participants for > > > automatons, e.g., > > > IVR systems or conference recorders. (IMHO, bad idea, but > > > that is really > > > just MHO, not strictly black-and-white.) > > > > > > We do have consensus that Lawful Intercept is entirely orthogonal to > > > conference participants. However, the logic of the above > > > follows. Just as > > > IVR systems or conference recorders are not really > > > participants, neither is > > > LI hardware. If we say that the approach for IVR is to plumb > > > in as a hidden > > > participant, then LI would have the same approach. If we say > > > that IVR is > > > something different, e.g., just a part of the conference > > > mixer, then it is > > > truly "not there". Likewise, I would expect LI to be "not there" -- > > > something outside the XCON framework entirely. > > > > > > > -----Original Message----- > > > > From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > > > > Sent: Monday, March 08, 2004 6:28 PM > > > > To: 'xcon@ietf.org' > > > > Subject: RE: [XCON] Open Issue: Hidden Participants > > > > > > > > > > > > Hidden listeners operation is probably illegal in many US > > states as > > > > well as in many countries - when you make a call there is a > > > > requirement in California the all parties are aware of the > > > presence of > > > > a 3rd party or recording device, note- that party may be > > anonymous, > > > > etc.. > > > > (Exception -- > > > > legal intercept.) > > > > > > > > We should follow the similar logic for XCON - provide an > > > indication of > > > > a recording device and/or anonymous participant's) > > > > > > > > Peter Kozdon > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On > > Behalf Of > > > > Adam Roach > > > > Sent: Monday, March 08, 2004 12:04 PM > > > > To: 'xcon@ietf.org' > > > > Subject: [XCON] Open Issue: Hidden Participants > > > > > > > > [as chair] > > > > > > > > At the XCON meeting, there was a rather lively discussion that > > > > continued the "Hidden Participants" discussion that had > > > started on the > > > > list. It was agreed that the topic was worth discussion, > > > but that we > > > > did not have enough time to pursue it in the meeting. > > > > > > > > I'm calling on everyone, especially those involved in the meeting > > > > discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to > > continue this > > > > discussion so we can close this issue in the near future. > > > Alan and I > > > > would like to be able to last-call this document shortly, > > > and this is > > > > the key issue that needs to be resolved before a new > > > revision of the > > > > draft can be produced. > > > > > > > > /a > > > > > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > _______________________________________________ > > > > XCON mailing list > > > > XCON@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > > > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@ietf.org > > > https://www1.ietf.org/mailman/listinfo/xcon > > > > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 11 14:29:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17730 for ; Thu, 11 Mar 2004 14:29:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1VrO-0000cS-GB for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 14:28:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BJSo4O002366 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 14:28:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1VrO-0000c3-0t for xcon-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 14:28: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 OAA17702 for ; Thu, 11 Mar 2004 14:28:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1VrL-00049j-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 14:28:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1VqT-00040O-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 14:27:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1Vpc-0003sO-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 14:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Vpd-0000Um-Rs; Thu, 11 Mar 2004 14:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1VpO-0000TR-Ed for xcon@optimus.ietf.org; Thu, 11 Mar 2004 14:26:46 -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 OAA17629 for ; Thu, 11 Mar 2004 14:26:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1VpL-0003pq-00 for xcon@ietf.org; Thu, 11 Mar 2004 14:26:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1VoN-0003gh-00 for xcon@ietf.org; Thu, 11 Mar 2004 14:25:44 -0500 Received: from syd-iport-1.cisco.com ([64.104.193.196]) by ietf-mx with esmtp (Exim 4.12) id 1B1VnS-0003T3-00 for xcon@ietf.org; Thu, 11 Mar 2004 14:24:46 -0500 Received: from syd-core-1.cisco.com (64.104.193.198) by syd-iport-1.cisco.com with ESMTP; 11 Mar 2004 11:37:19 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2BMN6YH005257; Fri, 12 Mar 2004 06:23:09 +0800 (WST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARC19816; Thu, 11 Mar 2004 11:22:35 -0800 (PST) In-Reply-To: <313680C9A886D511A06000204840E1CF070B64DB@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B64DB@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9A03D2B0-7391-11D8-8BC0-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: xcon@ietf.org, Eric Burger , Rohan Mahy , "'Kozdon, Peter'" , "'Adam Roach'" From: Rohan Mahy Subject: Re: [XCON] Open Issue: Hideable Participants Date: Thu, 11 Mar 2004 11:23:39 -0800 To: "Rosen, Brian" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian, There are many different orthogonal attributes we should be able to get access to. This "non-interesting" participant or "facilitator" attribute is orthogonal to your status as an automaton or human. I don't think an enumeration here is a good substitute for this attribute. It may be that indicating a recorder is a good value to add to the "actor" media feature tag, which currently has a msg-taker value, or that we can reuse the msg-taker value for the recorder. The goal is maximum orthogonality. We probably can't achieve complete orthogonality but I think we can get very close. thanks, -rohan On Mar 11, 2004, at 6:14 AM, Rosen, Brian wrote: > Seems to me that you are on the right track, but we need to go farther. > We have to classify these participants so that the UI, if it wanted to, > could render an appropriate indication. The example of the recorder > is pretty compelling. Just knowing that there is an automaton out > there > is one thing. Knowing its a recorder is another. So, really you > don't want a flag, you want an enunumeration. It may actually be > a list, because a single automaton could have multiple functions. > > Brian > >> -----Original Message----- >> From: Adam Roach [mailto:adam@dynamicsoft.com] >> Sent: Thursday, March 11, 2004 12:27 AM >> To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org >> Subject: RE: [XCON] Open Issue: Hideable Participants >> >> >> [not as chair] >> >> I don't think anyone is currently arguing whether indication >> of such automata should be available to the users. Most >> of what I've heard people say on this list -- after Korea, >> at least -- seems to agree that such elements *should* >> be indicated in the protocol. Note that this is not the >> same thing as saying that they must be forcibly rendered >> to users regardless of the users want, which is what you >> seem to be arguing for. >> >> What I've heard -- and I agree with this viewpoint -- is >> that there should be some flag that indicates "this element >> is a facilitator, not a participant," so that users who don't >> *care* about seeing such elements (existence proof: me) >> could configure their clients not to display them. >> >> To expand on the flag's meaning, it would make the most >> sense to have it mean more precisely "this element is not >> truly a participant, but is providing some service related >> to the conference." In other words, I would want it to >> cover e.g. human transcribers, human translators, etc., >> in addition to automata. >> >> As Eric points out, I think people are getting hung up on >> the name without thinking the issue through completely. >> I've updated the subject line accordingly. >> >> /a >> >>> -----Original Message----- >>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>> Sent: Wednesday, March 10, 2004 20:50 >>> To: Eric Burger; xcon@ietf.org >>> Subject: RE: [XCON] Open Issue: Hidden Participants >>> >>> >>> I agree that automatons are processing resources and could be >>> considered as >>> logical parts of the conference fabric, for example an IVR >>> could monitor the >>> conference and provide a trigger in response to a phrase >> that could be >>> consumed elsewhere. Similarly a device that announces >>> participants, etc.. >>> However, IMHO a conference recorder does not fall into this >>> category and >>> should probably be a visible resource maybe with an >> indicator to show >>> whether it is or is not active. Similarly - a player resources which >>> delivers content or information to the conference should also >>> be visible - >>> it seems desirable to know where such content is coming from. >>> >>> >>> >>> -----Original Message----- >>> From: Eric Burger [mailto:eburger@snowshore.com] >>> Sent: Tuesday, March 09, 2004 1:28 PM >>> To: Kozdon, Peter; xcon@ietf.org >>> Subject: RE: [XCON] Open Issue: Hidden Participants >>> >>> I think we got caught up on the name. >>> >>> There are two needs. >>> >>> The first, which I think we may have consensus on, is the >>> need for anonymous >>> participants. That is, participants that are present in the >>> conference, but >>> do not have their identities revealed. >>> >>> The second, which is more blurry, is the need for >>> participants that are >>> truly hidden. Some want to use hidden participants for >>> automatons, e.g., >>> IVR systems or conference recorders. (IMHO, bad idea, but >>> that is really >>> just MHO, not strictly black-and-white.) >>> >>> We do have consensus that Lawful Intercept is entirely orthogonal to >>> conference participants. However, the logic of the above >>> follows. Just as >>> IVR systems or conference recorders are not really >>> participants, neither is >>> LI hardware. If we say that the approach for IVR is to plumb >>> in as a hidden >>> participant, then LI would have the same approach. If we say >>> that IVR is >>> something different, e.g., just a part of the conference >>> mixer, then it is >>> truly "not there". Likewise, I would expect LI to be "not there" -- >>> something outside the XCON framework entirely. >>> >>>> -----Original Message----- >>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>> Sent: Monday, March 08, 2004 6:28 PM >>>> To: 'xcon@ietf.org' >>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>> >>>> >>>> Hidden listeners operation is probably illegal in many US >> states as >>>> well as in many countries - when you make a call there is a >>>> requirement in California the all parties are aware of the >>> presence of >>>> a 3rd party or recording device, note- that party may be >> anonymous, >>>> etc.. >>>> (Exception -- >>>> legal intercept.) >>>> >>>> We should follow the similar logic for XCON - provide an >>> indication of >>>> a recording device and/or anonymous participant's) >>>> >>>> Peter Kozdon >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On >> Behalf Of >>>> Adam Roach >>>> Sent: Monday, March 08, 2004 12:04 PM >>>> To: 'xcon@ietf.org' >>>> Subject: [XCON] Open Issue: Hidden Participants >>>> >>>> [as chair] >>>> >>>> At the XCON meeting, there was a rather lively discussion that >>>> continued the "Hidden Participants" discussion that had >>> started on the >>>> list. It was agreed that the topic was worth discussion, >>> but that we >>>> did not have enough time to pursue it in the meeting. >>>> >>>> I'm calling on everyone, especially those involved in the meeting >>>> discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to >> continue this >>>> discussion so we can close this issue in the near future. >>> Alan and I >>>> would like to be able to last-call this document shortly, >>> and this is >>>> the key issue that needs to be resolved before a new >>> revision of the >>>> draft can be produced. >>>> >>>> /a >>>> >>>> _______________________________________________ >>>> XCON mailing list >>>> XCON@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/xcon >>>> >>>> _______________________________________________ >>>> XCON mailing list >>>> XCON@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/xcon >>>> >>>> >>> >>> _______________________________________________ >>> XCON mailing list >>> XCON@ietf.org >>> https://www1.ietf.org/mailman/listinfo/xcon >>> >> >> _______________________________________________ >> XCON mailing list >> XCON@ietf.org >> https://www1.ietf.org/mailman/listinfo/xcon >> > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 11 14:34:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18038 for ; Thu, 11 Mar 2004 14:34: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 1B1VwQ-0001Pm-KO for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 14:34:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BJY2Xb005432 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 14:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1VwQ-0001PX-EV for xcon-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 14:34: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 OAA17984 for ; Thu, 11 Mar 2004 14:33:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1VwN-0004uS-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 14:33:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1VvO-0004jT-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 14:32:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1VuS-0004a3-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 14:32:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1VuU-000154-9x; Thu, 11 Mar 2004 14: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 1B1VuK-000149-Fg for xcon@optimus.ietf.org; Thu, 11 Mar 2004 14:31: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 OAA17838 for ; Thu, 11 Mar 2004 14:31:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1VuH-0004YJ-00 for xcon@ietf.org; Thu, 11 Mar 2004 14:31:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1VtP-0004R1-00 for xcon@ietf.org; Thu, 11 Mar 2004 14:30:56 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1B1Vt7-0004JP-00 for xcon@ietf.org; Thu, 11 Mar 2004 14:30:37 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i2BJThaZ020916; Thu, 11 Mar 2004 14:29:43 -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 OAA25539; Thu, 11 Mar 2004 14:29:43 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Mar 2004 14:29:43 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B64E1@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Rohan Mahy'" Cc: xcon@ietf.org, Eric Burger , "'Kozdon, Peter'" , "'Adam Roach'" Subject: RE: [XCON] Open Issue: Hideable Participants Date: Thu, 11 Mar 2004 14:29:42 -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.1 required=5.0 tests=AWL autolearn=no version=2.60 Rohan I'm not sure I agree. I clearly do want to provide information across the wire unambiguously, but I don't think a lot of binary attributes is a good way to do that. I think we are talking about a role, rather than an attribute. A single automaton, like a single human, is capable of multiple roles, so you need a list in both cases. Brian > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Thursday, March 11, 2004 2:24 PM > To: Rosen, Brian > Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam > Roach' > Subject: Re: [XCON] Open Issue: Hideable Participants > > > Brian, > > There are many different orthogonal attributes we should be > able to get > access to. This "non-interesting" participant or "facilitator" > attribute is orthogonal to your status as an automaton or human. I > don't think an enumeration here is a good substitute for this > attribute. It may be that indicating a recorder is a good > value to add > to the "actor" media feature tag, which currently has a msg-taker > value, or that we can reuse the msg-taker value for the > recorder. The > goal is maximum orthogonality. We probably can't achieve complete > orthogonality but I think we can get very close. > > thanks, > -rohan > > > On Mar 11, 2004, at 6:14 AM, Rosen, Brian wrote: > > > Seems to me that you are on the right track, but we need to > go farther. > > We have to classify these participants so that the UI, if > it wanted to, > > could render an appropriate indication. The example of the recorder > > is pretty compelling. Just knowing that there is an automaton out > > there > > is one thing. Knowing its a recorder is another. So, really you > > don't want a flag, you want an enunumeration. It may actually be > > a list, because a single automaton could have multiple functions. > > > > Brian > > > >> -----Original Message----- > >> From: Adam Roach [mailto:adam@dynamicsoft.com] > >> Sent: Thursday, March 11, 2004 12:27 AM > >> To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org > >> Subject: RE: [XCON] Open Issue: Hideable Participants > >> > >> > >> [not as chair] > >> > >> I don't think anyone is currently arguing whether indication > >> of such automata should be available to the users. Most > >> of what I've heard people say on this list -- after Korea, > >> at least -- seems to agree that such elements *should* > >> be indicated in the protocol. Note that this is not the > >> same thing as saying that they must be forcibly rendered > >> to users regardless of the users want, which is what you > >> seem to be arguing for. > >> > >> What I've heard -- and I agree with this viewpoint -- is > >> that there should be some flag that indicates "this element > >> is a facilitator, not a participant," so that users who don't > >> *care* about seeing such elements (existence proof: me) > >> could configure their clients not to display them. > >> > >> To expand on the flag's meaning, it would make the most > >> sense to have it mean more precisely "this element is not > >> truly a participant, but is providing some service related > >> to the conference." In other words, I would want it to > >> cover e.g. human transcribers, human translators, etc., > >> in addition to automata. > >> > >> As Eric points out, I think people are getting hung up on > >> the name without thinking the issue through completely. > >> I've updated the subject line accordingly. > >> > >> /a > >> > >>> -----Original Message----- > >>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > >>> Sent: Wednesday, March 10, 2004 20:50 > >>> To: Eric Burger; xcon@ietf.org > >>> Subject: RE: [XCON] Open Issue: Hidden Participants > >>> > >>> > >>> I agree that automatons are processing resources and could be > >>> considered as > >>> logical parts of the conference fabric, for example an IVR > >>> could monitor the > >>> conference and provide a trigger in response to a phrase > >> that could be > >>> consumed elsewhere. Similarly a device that announces > >>> participants, etc.. > >>> However, IMHO a conference recorder does not fall into this > >>> category and > >>> should probably be a visible resource maybe with an > >> indicator to show > >>> whether it is or is not active. Similarly - a player > resources which > >>> delivers content or information to the conference should also > >>> be visible - > >>> it seems desirable to know where such content is coming from. > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Eric Burger [mailto:eburger@snowshore.com] > >>> Sent: Tuesday, March 09, 2004 1:28 PM > >>> To: Kozdon, Peter; xcon@ietf.org > >>> Subject: RE: [XCON] Open Issue: Hidden Participants > >>> > >>> I think we got caught up on the name. > >>> > >>> There are two needs. > >>> > >>> The first, which I think we may have consensus on, is the > >>> need for anonymous > >>> participants. That is, participants that are present in the > >>> conference, but > >>> do not have their identities revealed. > >>> > >>> The second, which is more blurry, is the need for > >>> participants that are > >>> truly hidden. Some want to use hidden participants for > >>> automatons, e.g., > >>> IVR systems or conference recorders. (IMHO, bad idea, but > >>> that is really > >>> just MHO, not strictly black-and-white.) > >>> > >>> We do have consensus that Lawful Intercept is entirely > orthogonal to > >>> conference participants. However, the logic of the above > >>> follows. Just as > >>> IVR systems or conference recorders are not really > >>> participants, neither is > >>> LI hardware. If we say that the approach for IVR is to plumb > >>> in as a hidden > >>> participant, then LI would have the same approach. If we say > >>> that IVR is > >>> something different, e.g., just a part of the conference > >>> mixer, then it is > >>> truly "not there". Likewise, I would expect LI to be > "not there" -- > >>> something outside the XCON framework entirely. > >>> > >>>> -----Original Message----- > >>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > >>>> Sent: Monday, March 08, 2004 6:28 PM > >>>> To: 'xcon@ietf.org' > >>>> Subject: RE: [XCON] Open Issue: Hidden Participants > >>>> > >>>> > >>>> Hidden listeners operation is probably illegal in many US > >> states as > >>>> well as in many countries - when you make a call there is a > >>>> requirement in California the all parties are aware of the > >>> presence of > >>>> a 3rd party or recording device, note- that party may be > >> anonymous, > >>>> etc.. > >>>> (Exception -- > >>>> legal intercept.) > >>>> > >>>> We should follow the similar logic for XCON - provide an > >>> indication of > >>>> a recording device and/or anonymous participant's) > >>>> > >>>> Peter Kozdon > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On > >> Behalf Of > >>>> Adam Roach > >>>> Sent: Monday, March 08, 2004 12:04 PM > >>>> To: 'xcon@ietf.org' > >>>> Subject: [XCON] Open Issue: Hidden Participants > >>>> > >>>> [as chair] > >>>> > >>>> At the XCON meeting, there was a rather lively discussion that > >>>> continued the "Hidden Participants" discussion that had > >>> started on the > >>>> list. It was agreed that the topic was worth discussion, > >>> but that we > >>>> did not have enough time to pursue it in the meeting. > >>>> > >>>> I'm calling on everyone, especially those involved in the meeting > >>>> discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to > >> continue this > >>>> discussion so we can close this issue in the near future. > >>> Alan and I > >>>> would like to be able to last-call this document shortly, > >>> and this is > >>>> the key issue that needs to be resolved before a new > >>> revision of the > >>>> draft can be produced. > >>>> > >>>> /a > >>>> > >>>> _______________________________________________ > >>>> XCON mailing list > >>>> XCON@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>> > >>>> _______________________________________________ > >>>> XCON mailing list > >>>> XCON@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> XCON mailing list > >>> XCON@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/xcon > >>> > >> > >> _______________________________________________ > >> XCON mailing list > >> XCON@ietf.org > >> https://www1.ietf.org/mailman/listinfo/xcon > >> > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 11 16:08:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26192 for ; Thu, 11 Mar 2004 16:08:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XPe-0002DO-6x for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 16:08:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BL8G6x008497 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 16:08:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XPZ-0002Cb-Nf for xcon-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 16:08: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 QAA26043 for ; Thu, 11 Mar 2004 16:08:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1XPX-0003wD-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 16:08:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1XNF-0003MD-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 16:05:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1XLH-0002tE-04 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 16:03:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XE2-0008Ec-A7; Thu, 11 Mar 2004 15:56:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XDa-0007yG-7U for xcon@optimus.ietf.org; Thu, 11 Mar 2004 15:55: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 PAA24728 for ; Thu, 11 Mar 2004 15:55:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1XDY-0001nw-00 for xcon@ietf.org; Thu, 11 Mar 2004 15:55:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1XCc-0001hk-00 for xcon@ietf.org; Thu, 11 Mar 2004 15:54:51 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1B1XC9-0001Zc-00 for xcon@ietf.org; Thu, 11 Mar 2004 15:54:21 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i2BKrTaZ023098; Thu, 11 Mar 2004 15:53:29 -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 PAA07603; Thu, 11 Mar 2004 15:53:28 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Mar 2004 15:53:28 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B64E4@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Rohan Mahy'" Cc: xcon@ietf.org, Eric Burger , "'Kozdon, Peter'" , "'Adam Roach'" Subject: RE: [XCON] Open Issue: Hideable Participants Date: Thu, 11 Mar 2004 15:53:27 -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.1 required=5.0 tests=AWL autolearn=no version=2.60 What attributes does an IVR box have besides automaton? How about a caption service? If we create a caps for each service, all orthogonal, is that you think makes sense? These are all roles, they are not attributes. Brian > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Thursday, March 11, 2004 3:47 PM > To: Rosen, Brian > Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam > Roach' > Subject: Re: [XCON] Open Issue: Hideable Participants > > > Hi, > > I'd like to apologize to the group that some of > these ideas > are SIP-specific or very SIP influenced > > Here are the binary or ternary attributes that already exist from > draft-ietf-sip-callee-caps: > > automaton/human > personal/business > mobile/fixed > duplex/send-only/receive-only > > these are 100% orthogonal with respect to each other > > Various folks have proposed that we need the following additional > attributes in various parts of conferencing and/or signaling: > > interactive/noninteractive > anonymous/identified > > (again, these are 100% orthogonal with respect to each other and the > other attributes) > > finally I am proposing this new attribute we have been > describing here. > I believe this is still highly orthogonal to the other attributes. > > I believe this new attribute is more appropriate than an enumerations > for two main reasons: > > 1) you can code behavior based on the presence of the attribute > directly rather than checking for a bunch different roles and then > making sure there are not conditions attached to those roles. > 2) it allows a new thing/role to exist which we haven't > thought of yet > that can still unambiguously provide its attributes. existing code > will work quite well with this new thing if it describes itself using > (in part) a number of existing attributes. > > thanks, > -rohan > > > On Mar 11, 2004, at 11:29 AM, Rosen, Brian wrote: > > > Rohan > > > > I'm not sure I agree. I clearly do want to provide > information across > > the wire unambiguously, but I don't think a lot of binary attributes > > is a good way to do that. I think we are talking about a > role, rather > > than an attribute. A single automaton, like a single > human, is capable > > of multiple roles, so you need a list in both cases. > > > > Brian > > > >> -----Original Message----- > >> From: Rohan Mahy [mailto:rohan@cisco.com] > >> Sent: Thursday, March 11, 2004 2:24 PM > >> To: Rosen, Brian > >> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam > >> Roach' > >> Subject: Re: [XCON] Open Issue: Hideable Participants > >> > >> > >> Brian, > >> > >> There are many different orthogonal attributes we should be > >> able to get > >> access to. This "non-interesting" participant or "facilitator" > >> attribute is orthogonal to your status as an automaton or human. I > >> don't think an enumeration here is a good substitute for this > >> attribute. It may be that indicating a recorder is a good > >> value to add > >> to the "actor" media feature tag, which currently has a msg-taker > >> value, or that we can reuse the msg-taker value for the > >> recorder. The > >> goal is maximum orthogonality. We probably can't achieve complete > >> orthogonality but I think we can get very close. > >> > >> thanks, > >> -rohan > >> > >> > >> On Mar 11, 2004, at 6:14 AM, Rosen, Brian wrote: > >> > >>> Seems to me that you are on the right track, but we need to > >> go farther. > >>> We have to classify these participants so that the UI, if > >> it wanted to, > >>> could render an appropriate indication. The example of > the recorder > >>> is pretty compelling. Just knowing that there is an automaton out > >>> there > >>> is one thing. Knowing its a recorder is another. So, really you > >>> don't want a flag, you want an enunumeration. It may actually be > >>> a list, because a single automaton could have multiple functions. > >>> > >>> Brian > >>> > >>>> -----Original Message----- > >>>> From: Adam Roach [mailto:adam@dynamicsoft.com] > >>>> Sent: Thursday, March 11, 2004 12:27 AM > >>>> To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org > >>>> Subject: RE: [XCON] Open Issue: Hideable Participants > >>>> > >>>> > >>>> [not as chair] > >>>> > >>>> I don't think anyone is currently arguing whether indication > >>>> of such automata should be available to the users. Most > >>>> of what I've heard people say on this list -- after Korea, > >>>> at least -- seems to agree that such elements *should* > >>>> be indicated in the protocol. Note that this is not the > >>>> same thing as saying that they must be forcibly rendered > >>>> to users regardless of the users want, which is what you > >>>> seem to be arguing for. > >>>> > >>>> What I've heard -- and I agree with this viewpoint -- is > >>>> that there should be some flag that indicates "this element > >>>> is a facilitator, not a participant," so that users who don't > >>>> *care* about seeing such elements (existence proof: me) > >>>> could configure their clients not to display them. > >>>> > >>>> To expand on the flag's meaning, it would make the most > >>>> sense to have it mean more precisely "this element is not > >>>> truly a participant, but is providing some service related > >>>> to the conference." In other words, I would want it to > >>>> cover e.g. human transcribers, human translators, etc., > >>>> in addition to automata. > >>>> > >>>> As Eric points out, I think people are getting hung up on > >>>> the name without thinking the issue through completely. > >>>> I've updated the subject line accordingly. > >>>> > >>>> /a > >>>> > >>>>> -----Original Message----- > >>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > >>>>> Sent: Wednesday, March 10, 2004 20:50 > >>>>> To: Eric Burger; xcon@ietf.org > >>>>> Subject: RE: [XCON] Open Issue: Hidden Participants > >>>>> > >>>>> > >>>>> I agree that automatons are processing resources and could be > >>>>> considered as > >>>>> logical parts of the conference fabric, for example an IVR > >>>>> could monitor the > >>>>> conference and provide a trigger in response to a phrase > >>>> that could be > >>>>> consumed elsewhere. Similarly a device that announces > >>>>> participants, etc.. > >>>>> However, IMHO a conference recorder does not fall into this > >>>>> category and > >>>>> should probably be a visible resource maybe with an > >>>> indicator to show > >>>>> whether it is or is not active. Similarly - a player > >> resources which > >>>>> delivers content or information to the conference should also > >>>>> be visible - > >>>>> it seems desirable to know where such content is coming from. > >>>>> > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Eric Burger [mailto:eburger@snowshore.com] > >>>>> Sent: Tuesday, March 09, 2004 1:28 PM > >>>>> To: Kozdon, Peter; xcon@ietf.org > >>>>> Subject: RE: [XCON] Open Issue: Hidden Participants > >>>>> > >>>>> I think we got caught up on the name. > >>>>> > >>>>> There are two needs. > >>>>> > >>>>> The first, which I think we may have consensus on, is the > >>>>> need for anonymous > >>>>> participants. That is, participants that are present in the > >>>>> conference, but > >>>>> do not have their identities revealed. > >>>>> > >>>>> The second, which is more blurry, is the need for > >>>>> participants that are > >>>>> truly hidden. Some want to use hidden participants for > >>>>> automatons, e.g., > >>>>> IVR systems or conference recorders. (IMHO, bad idea, but > >>>>> that is really > >>>>> just MHO, not strictly black-and-white.) > >>>>> > >>>>> We do have consensus that Lawful Intercept is entirely > >> orthogonal to > >>>>> conference participants. However, the logic of the above > >>>>> follows. Just as > >>>>> IVR systems or conference recorders are not really > >>>>> participants, neither is > >>>>> LI hardware. If we say that the approach for IVR is to plumb > >>>>> in as a hidden > >>>>> participant, then LI would have the same approach. If we say > >>>>> that IVR is > >>>>> something different, e.g., just a part of the conference > >>>>> mixer, then it is > >>>>> truly "not there". Likewise, I would expect LI to be > >> "not there" -- > >>>>> something outside the XCON framework entirely. > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > >>>>>> Sent: Monday, March 08, 2004 6:28 PM > >>>>>> To: 'xcon@ietf.org' > >>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants > >>>>>> > >>>>>> > >>>>>> Hidden listeners operation is probably illegal in many US > >>>> states as > >>>>>> well as in many countries - when you make a call there is a > >>>>>> requirement in California the all parties are aware of the > >>>>> presence of > >>>>>> a 3rd party or recording device, note- that party may be > >>>> anonymous, > >>>>>> etc.. > >>>>>> (Exception -- > >>>>>> legal intercept.) > >>>>>> > >>>>>> We should follow the similar logic for XCON - provide an > >>>>> indication of > >>>>>> a recording device and/or anonymous participant's) > >>>>>> > >>>>>> Peter Kozdon > >>>>>> > >>>>>> > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On > >>>> Behalf Of > >>>>>> Adam Roach > >>>>>> Sent: Monday, March 08, 2004 12:04 PM > >>>>>> To: 'xcon@ietf.org' > >>>>>> Subject: [XCON] Open Issue: Hidden Participants > >>>>>> > >>>>>> [as chair] > >>>>>> > >>>>>> At the XCON meeting, there was a rather lively discussion that > >>>>>> continued the "Hidden Participants" discussion that had > >>>>> started on the > >>>>>> list. It was agreed that the topic was worth discussion, > >>>>> but that we > >>>>>> did not have enough time to pursue it in the meeting. > >>>>>> > >>>>>> I'm calling on everyone, especially those involved in > the meeting > >>>>>> discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to > >>>> continue this > >>>>>> discussion so we can close this issue in the near future. > >>>>> Alan and I > >>>>>> would like to be able to last-call this document shortly, > >>>>> and this is > >>>>>> the key issue that needs to be resolved before a new > >>>>> revision of the > >>>>>> draft can be produced. > >>>>>> > >>>>>> /a > >>>>>> > >>>>>> _______________________________________________ > >>>>>> XCON mailing list > >>>>>> XCON@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>>>> > >>>>>> _______________________________________________ > >>>>>> XCON mailing list > >>>>>> XCON@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>>>> > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> XCON mailing list > >>>>> XCON@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>>> > >>>> > >>>> _______________________________________________ > >>>> XCON mailing list > >>>> XCON@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>> > >>> > >>> _______________________________________________ > >>> XCON mailing list > >>> XCON@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/xcon > >> > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 11 16:08:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26260 for ; Thu, 11 Mar 2004 16:08: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 1B1XPn-0002FE-6I for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 16:08:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BL8QaC008609 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 16:08:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XPj-0002Dq-VV for xcon-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 16:08: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 QAA26103 for ; Thu, 11 Mar 2004 16:08:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1XPi-0003y0-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 16:08:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1XNw-0003SB-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 16:06:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1XLI-0002w3-01 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 16:03:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XE0-0008DQ-FZ; Thu, 11 Mar 2004 15:56:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1X9X-0007Vy-57 for xcon@optimus.ietf.org; Thu, 11 Mar 2004 15:51: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 PAA23782 for ; Thu, 11 Mar 2004 15:51:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1X9V-0000wa-00 for xcon@ietf.org; Thu, 11 Mar 2004 15:51:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1X7C-0000Ho-00 for xcon@ietf.org; Thu, 11 Mar 2004 15:49:17 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B1X4a-0007DJ-00 for xcon@ietf.org; Thu, 11 Mar 2004 15:46:32 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 11 Mar 2004 12:48:36 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2BKjxK2011574; Thu, 11 Mar 2004 12:46:00 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARC28232; Thu, 11 Mar 2004 12:45:58 -0800 (PST) In-Reply-To: <313680C9A886D511A06000204840E1CF070B64E1@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B64E1@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <402FA81B-739D-11D8-8BC0-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: xcon@ietf.org, Eric Burger , Rohan Mahy , "'Kozdon, Peter'" , "'Adam Roach'" From: Rohan Mahy Subject: Re: [XCON] Open Issue: Hideable Participants Date: Thu, 11 Mar 2004 12:47:03 -0800 To: "Rosen, Brian" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I'd like to apologize to the group that some of these ideas are SIP-specific or very SIP influenced Here are the binary or ternary attributes that already exist from draft-ietf-sip-callee-caps: automaton/human personal/business mobile/fixed duplex/send-only/receive-only these are 100% orthogonal with respect to each other Various folks have proposed that we need the following additional attributes in various parts of conferencing and/or signaling: interactive/noninteractive anonymous/identified (again, these are 100% orthogonal with respect to each other and the other attributes) finally I am proposing this new attribute we have been describing here. I believe this is still highly orthogonal to the other attributes. I believe this new attribute is more appropriate than an enumerations for two main reasons: 1) you can code behavior based on the presence of the attribute directly rather than checking for a bunch different roles and then making sure there are not conditions attached to those roles. 2) it allows a new thing/role to exist which we haven't thought of yet that can still unambiguously provide its attributes. existing code will work quite well with this new thing if it describes itself using (in part) a number of existing attributes. thanks, -rohan On Mar 11, 2004, at 11:29 AM, Rosen, Brian wrote: > Rohan > > I'm not sure I agree. I clearly do want to provide information across > the wire unambiguously, but I don't think a lot of binary attributes > is a good way to do that. I think we are talking about a role, rather > than an attribute. A single automaton, like a single human, is capable > of multiple roles, so you need a list in both cases. > > Brian > >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan@cisco.com] >> Sent: Thursday, March 11, 2004 2:24 PM >> To: Rosen, Brian >> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam >> Roach' >> Subject: Re: [XCON] Open Issue: Hideable Participants >> >> >> Brian, >> >> There are many different orthogonal attributes we should be >> able to get >> access to. This "non-interesting" participant or "facilitator" >> attribute is orthogonal to your status as an automaton or human. I >> don't think an enumeration here is a good substitute for this >> attribute. It may be that indicating a recorder is a good >> value to add >> to the "actor" media feature tag, which currently has a msg-taker >> value, or that we can reuse the msg-taker value for the >> recorder. The >> goal is maximum orthogonality. We probably can't achieve complete >> orthogonality but I think we can get very close. >> >> thanks, >> -rohan >> >> >> On Mar 11, 2004, at 6:14 AM, Rosen, Brian wrote: >> >>> Seems to me that you are on the right track, but we need to >> go farther. >>> We have to classify these participants so that the UI, if >> it wanted to, >>> could render an appropriate indication. The example of the recorder >>> is pretty compelling. Just knowing that there is an automaton out >>> there >>> is one thing. Knowing its a recorder is another. So, really you >>> don't want a flag, you want an enunumeration. It may actually be >>> a list, because a single automaton could have multiple functions. >>> >>> Brian >>> >>>> -----Original Message----- >>>> From: Adam Roach [mailto:adam@dynamicsoft.com] >>>> Sent: Thursday, March 11, 2004 12:27 AM >>>> To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org >>>> Subject: RE: [XCON] Open Issue: Hideable Participants >>>> >>>> >>>> [not as chair] >>>> >>>> I don't think anyone is currently arguing whether indication >>>> of such automata should be available to the users. Most >>>> of what I've heard people say on this list -- after Korea, >>>> at least -- seems to agree that such elements *should* >>>> be indicated in the protocol. Note that this is not the >>>> same thing as saying that they must be forcibly rendered >>>> to users regardless of the users want, which is what you >>>> seem to be arguing for. >>>> >>>> What I've heard -- and I agree with this viewpoint -- is >>>> that there should be some flag that indicates "this element >>>> is a facilitator, not a participant," so that users who don't >>>> *care* about seeing such elements (existence proof: me) >>>> could configure their clients not to display them. >>>> >>>> To expand on the flag's meaning, it would make the most >>>> sense to have it mean more precisely "this element is not >>>> truly a participant, but is providing some service related >>>> to the conference." In other words, I would want it to >>>> cover e.g. human transcribers, human translators, etc., >>>> in addition to automata. >>>> >>>> As Eric points out, I think people are getting hung up on >>>> the name without thinking the issue through completely. >>>> I've updated the subject line accordingly. >>>> >>>> /a >>>> >>>>> -----Original Message----- >>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>>> Sent: Wednesday, March 10, 2004 20:50 >>>>> To: Eric Burger; xcon@ietf.org >>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>> >>>>> >>>>> I agree that automatons are processing resources and could be >>>>> considered as >>>>> logical parts of the conference fabric, for example an IVR >>>>> could monitor the >>>>> conference and provide a trigger in response to a phrase >>>> that could be >>>>> consumed elsewhere. Similarly a device that announces >>>>> participants, etc.. >>>>> However, IMHO a conference recorder does not fall into this >>>>> category and >>>>> should probably be a visible resource maybe with an >>>> indicator to show >>>>> whether it is or is not active. Similarly - a player >> resources which >>>>> delivers content or information to the conference should also >>>>> be visible - >>>>> it seems desirable to know where such content is coming from. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Eric Burger [mailto:eburger@snowshore.com] >>>>> Sent: Tuesday, March 09, 2004 1:28 PM >>>>> To: Kozdon, Peter; xcon@ietf.org >>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>> >>>>> I think we got caught up on the name. >>>>> >>>>> There are two needs. >>>>> >>>>> The first, which I think we may have consensus on, is the >>>>> need for anonymous >>>>> participants. That is, participants that are present in the >>>>> conference, but >>>>> do not have their identities revealed. >>>>> >>>>> The second, which is more blurry, is the need for >>>>> participants that are >>>>> truly hidden. Some want to use hidden participants for >>>>> automatons, e.g., >>>>> IVR systems or conference recorders. (IMHO, bad idea, but >>>>> that is really >>>>> just MHO, not strictly black-and-white.) >>>>> >>>>> We do have consensus that Lawful Intercept is entirely >> orthogonal to >>>>> conference participants. However, the logic of the above >>>>> follows. Just as >>>>> IVR systems or conference recorders are not really >>>>> participants, neither is >>>>> LI hardware. If we say that the approach for IVR is to plumb >>>>> in as a hidden >>>>> participant, then LI would have the same approach. If we say >>>>> that IVR is >>>>> something different, e.g., just a part of the conference >>>>> mixer, then it is >>>>> truly "not there". Likewise, I would expect LI to be >> "not there" -- >>>>> something outside the XCON framework entirely. >>>>> >>>>>> -----Original Message----- >>>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>>>> Sent: Monday, March 08, 2004 6:28 PM >>>>>> To: 'xcon@ietf.org' >>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>> >>>>>> >>>>>> Hidden listeners operation is probably illegal in many US >>>> states as >>>>>> well as in many countries - when you make a call there is a >>>>>> requirement in California the all parties are aware of the >>>>> presence of >>>>>> a 3rd party or recording device, note- that party may be >>>> anonymous, >>>>>> etc.. >>>>>> (Exception -- >>>>>> legal intercept.) >>>>>> >>>>>> We should follow the similar logic for XCON - provide an >>>>> indication of >>>>>> a recording device and/or anonymous participant's) >>>>>> >>>>>> Peter Kozdon >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On >>>> Behalf Of >>>>>> Adam Roach >>>>>> Sent: Monday, March 08, 2004 12:04 PM >>>>>> To: 'xcon@ietf.org' >>>>>> Subject: [XCON] Open Issue: Hidden Participants >>>>>> >>>>>> [as chair] >>>>>> >>>>>> At the XCON meeting, there was a rather lively discussion that >>>>>> continued the "Hidden Participants" discussion that had >>>>> started on the >>>>>> list. It was agreed that the topic was worth discussion, >>>>> but that we >>>>>> did not have enough time to pursue it in the meeting. >>>>>> >>>>>> I'm calling on everyone, especially those involved in the meeting >>>>>> discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to >>>> continue this >>>>>> discussion so we can close this issue in the near future. >>>>> Alan and I >>>>>> would like to be able to last-call this document shortly, >>>>> and this is >>>>>> the key issue that needs to be resolved before a new >>>>> revision of the >>>>>> draft can be produced. >>>>>> >>>>>> /a >>>>>> >>>>>> _______________________________________________ >>>>>> XCON mailing list >>>>>> XCON@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>> >>>>>> _______________________________________________ >>>>>> XCON mailing list >>>>>> XCON@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> XCON mailing list >>>>> XCON@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>> >>>> >>>> _______________________________________________ >>>> XCON mailing list >>>> XCON@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/xcon >>>> >>> >>> _______________________________________________ >>> XCON mailing list >>> XCON@ietf.org >>> https://www1.ietf.org/mailman/listinfo/xcon >> _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 11 19:52:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07170 for ; Thu, 11 Mar 2004 19:52: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 1B1atz-0004BF-GE for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 19:51:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C0ppfv016063 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 19:51:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1atz-0004B0-5i for xcon-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 19:51: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 TAA07004 for ; Thu, 11 Mar 2004 19:51:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1atx-0003ts-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:51:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1apX-0002lY-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:47:16 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1aoc-0002ax-01 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:46:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1afL-0005Xn-UV for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:36:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ab7-0001if-PW; Thu, 11 Mar 2004 19:32:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Y7o-00052O-R9 for xcon@optimus.ietf.org; Thu, 11 Mar 2004 16:53: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 QAA29106 for ; Thu, 11 Mar 2004 16:53:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Y7m-0003EP-00 for xcon@ietf.org; Thu, 11 Mar 2004 16:53:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Y6o-00036e-00 for xcon@ietf.org; Thu, 11 Mar 2004 16:52:56 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B1Y6B-0002sr-00 for xcon@ietf.org; Thu, 11 Mar 2004 16:52:15 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 11 Mar 2004 13:54:19 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2BLpgaD024098; Thu, 11 Mar 2004 13:51:43 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARC34386; Thu, 11 Mar 2004 13:51:41 -0800 (PST) In-Reply-To: <313680C9A886D511A06000204840E1CF070B64E6@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B64E6@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6E65D12D-73A6-11D8-8BC0-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: xcon@ietf.org, Eric Burger , Rohan Mahy , "'Kozdon, Peter'" , "'Adam Roach'" From: Rohan Mahy Subject: Re: [XCON] Open Issue: Hideable Participants Date: Thu, 11 Mar 2004 13:52:46 -0800 To: "Rosen, Brian" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mar 11, 2004, at 1:36 PM, Rosen, Brian wrote: > So, this is a discussion of "do you want the characteristics of > a participant, or a description of it". > > Seems to me that since this is not a protocol mechanism, it's a > UI issue, that you want a description and not a set of characteristics. > It's pretty easy to figure out what an IVR box does, but its pretty > hard to figure out that it is an IVR box from a set of caps. > Infer that it's a donkey from a description of the parts > vs infer what parts are available knowing it's a donkey. if its really relevant to know that its a donkey, then use a description/role/whatever. However, *STAYING ON TOPIC*, we are trying to tell if you should show the donkey or not in the roster, and you clearly can't do that if some asses are interesting and others are not. thx, -r > Since I can always arrange a UI to display characteristics if > I know what role, but can't go the other way, I think role is > best. > > Brian > >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan@cisco.com] >> Sent: Thursday, March 11, 2004 4:23 PM >> To: Rosen, Brian >> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam >> Roach' >> Subject: Re: [XCON] Open Issue: Hideable Participants >> >> >> >> On Mar 11, 2004, at 12:53 PM, Rosen, Brian wrote: >>> What attributes does an IVR box have besides automaton? >>> How about a caption service? >>> >>> If we create a caps for each service, all orthogonal, is that >>> you think makes sense? >> >> no, i'm not proposing a cap for each service. it is this >> "facilitator" >> attribute that all of these roles *share* that causes my UI to hide >> them in the roster. I don't want to have to update my UI (which hid >> IVRs, announcers, human scribes, and recording services) so >> that I will >> hide the caption service you just added. >> >> if you feel you need to add roles for these services, go >> right ahead. >> I don't object to having names roles, but I want my UI to refer to >> attributes where I think attributes are appropriate. [The mere fact >> that all these services I just listed have something in >> common which is >> orthogonal to all the other attributes we have should be a >> strong clue >> that this "facilitator" property should be an attribute.] >> >> thanks, >> -rohan >> >>> These are all roles, they are not attributes. >>> >>> Brian >>> >>>> -----Original Message----- >>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>> Sent: Thursday, March 11, 2004 3:47 PM >>>> To: Rosen, Brian >>>> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam >>>> Roach' >>>> Subject: Re: [XCON] Open Issue: Hideable Participants >>>> >>>> >>>> Hi, >>>> >>>> I'd like to apologize to the group that some of >>>> these ideas >>>> are SIP-specific or very SIP influenced >>>> >>>> Here are the binary or ternary attributes that already exist from >>>> draft-ietf-sip-callee-caps: >>>> >>>> automaton/human >>>> personal/business >>>> mobile/fixed >>>> duplex/send-only/receive-only >>>> >>>> these are 100% orthogonal with respect to each other >>>> >>>> Various folks have proposed that we need the following additional >>>> attributes in various parts of conferencing and/or signaling: >>>> >>>> interactive/noninteractive >>>> anonymous/identified >>>> >>>> (again, these are 100% orthogonal with respect to each >> other and the >>>> other attributes) >>>> >>>> finally I am proposing this new attribute we have been >>>> describing here. >>>> I believe this is still highly orthogonal to the other >> attributes. >>>> >>>> I believe this new attribute is more appropriate than an >> enumerations >>>> for two main reasons: >>>> >>>> 1) you can code behavior based on the presence of the attribute >>>> directly rather than checking for a bunch different roles and then >>>> making sure there are not conditions attached to those roles. >>>> 2) it allows a new thing/role to exist which we haven't >>>> thought of yet >>>> that can still unambiguously provide its attributes. existing code >>>> will work quite well with this new thing if it describes >> itself using >>>> (in part) a number of existing attributes. >>>> >>>> thanks, >>>> -rohan >>>> >>>> >>>> On Mar 11, 2004, at 11:29 AM, Rosen, Brian wrote: >>>> >>>>> Rohan >>>>> >>>>> I'm not sure I agree. I clearly do want to provide >>>> information across >>>>> the wire unambiguously, but I don't think a lot of binary >> attributes >>>>> is a good way to do that. I think we are talking about a >>>> role, rather >>>>> than an attribute. A single automaton, like a single >>>> human, is capable >>>>> of multiple roles, so you need a list in both cases. >>>>> >>>>> Brian >>>>> >>>>>> -----Original Message----- >>>>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>>>> Sent: Thursday, March 11, 2004 2:24 PM >>>>>> To: Rosen, Brian >>>>>> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, >> Peter'; 'Adam >>>>>> Roach' >>>>>> Subject: Re: [XCON] Open Issue: Hideable Participants >>>>>> >>>>>> >>>>>> Brian, >>>>>> >>>>>> There are many different orthogonal attributes we should be >>>>>> able to get >>>>>> access to. This "non-interesting" participant or "facilitator" >>>>>> attribute is orthogonal to your status as an automaton >> or human. I >>>>>> don't think an enumeration here is a good substitute for this >>>>>> attribute. It may be that indicating a recorder is a good >>>>>> value to add >>>>>> to the "actor" media feature tag, which currently has a msg-taker >>>>>> value, or that we can reuse the msg-taker value for the >>>>>> recorder. The >>>>>> goal is maximum orthogonality. We probably can't >> achieve complete >>>>>> orthogonality but I think we can get very close. >>>>>> >>>>>> thanks, >>>>>> -rohan >>>>>> >>>>>> >>>>>> On Mar 11, 2004, at 6:14 AM, Rosen, Brian wrote: >>>>>> >>>>>>> Seems to me that you are on the right track, but we need to >>>>>> go farther. >>>>>>> We have to classify these participants so that the UI, if >>>>>> it wanted to, >>>>>>> could render an appropriate indication. The example of >>>> the recorder >>>>>>> is pretty compelling. Just knowing that there is an >> automaton out >>>>>>> there >>>>>>> is one thing. Knowing its a recorder is another. So, >> really you >>>>>>> don't want a flag, you want an enunumeration. It may >> actually be >>>>>>> a list, because a single automaton could have multiple >> functions. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Adam Roach [mailto:adam@dynamicsoft.com] >>>>>>>> Sent: Thursday, March 11, 2004 12:27 AM >>>>>>>> To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org >>>>>>>> Subject: RE: [XCON] Open Issue: Hideable Participants >>>>>>>> >>>>>>>> >>>>>>>> [not as chair] >>>>>>>> >>>>>>>> I don't think anyone is currently arguing whether indication >>>>>>>> of such automata should be available to the users. Most >>>>>>>> of what I've heard people say on this list -- after Korea, >>>>>>>> at least -- seems to agree that such elements *should* >>>>>>>> be indicated in the protocol. Note that this is not the >>>>>>>> same thing as saying that they must be forcibly rendered >>>>>>>> to users regardless of the users want, which is what you >>>>>>>> seem to be arguing for. >>>>>>>> >>>>>>>> What I've heard -- and I agree with this viewpoint -- is >>>>>>>> that there should be some flag that indicates "this element >>>>>>>> is a facilitator, not a participant," so that users who don't >>>>>>>> *care* about seeing such elements (existence proof: me) >>>>>>>> could configure their clients not to display them. >>>>>>>> >>>>>>>> To expand on the flag's meaning, it would make the most >>>>>>>> sense to have it mean more precisely "this element is not >>>>>>>> truly a participant, but is providing some service related >>>>>>>> to the conference." In other words, I would want it to >>>>>>>> cover e.g. human transcribers, human translators, etc., >>>>>>>> in addition to automata. >>>>>>>> >>>>>>>> As Eric points out, I think people are getting hung up on >>>>>>>> the name without thinking the issue through completely. >>>>>>>> I've updated the subject line accordingly. >>>>>>>> >>>>>>>> /a >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>>>>>>> Sent: Wednesday, March 10, 2004 20:50 >>>>>>>>> To: Eric Burger; xcon@ietf.org >>>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>>>> >>>>>>>>> >>>>>>>>> I agree that automatons are processing resources and could be >>>>>>>>> considered as >>>>>>>>> logical parts of the conference fabric, for example an IVR >>>>>>>>> could monitor the >>>>>>>>> conference and provide a trigger in response to a phrase >>>>>>>> that could be >>>>>>>>> consumed elsewhere. Similarly a device that announces >>>>>>>>> participants, etc.. >>>>>>>>> However, IMHO a conference recorder does not fall into this >>>>>>>>> category and >>>>>>>>> should probably be a visible resource maybe with an >>>>>>>> indicator to show >>>>>>>>> whether it is or is not active. Similarly - a player >>>>>> resources which >>>>>>>>> delivers content or information to the conference should also >>>>>>>>> be visible - >>>>>>>>> it seems desirable to know where such content is coming from. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Eric Burger [mailto:eburger@snowshore.com] >>>>>>>>> Sent: Tuesday, March 09, 2004 1:28 PM >>>>>>>>> To: Kozdon, Peter; xcon@ietf.org >>>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>>>> >>>>>>>>> I think we got caught up on the name. >>>>>>>>> >>>>>>>>> There are two needs. >>>>>>>>> >>>>>>>>> The first, which I think we may have consensus on, is the >>>>>>>>> need for anonymous >>>>>>>>> participants. That is, participants that are present in the >>>>>>>>> conference, but >>>>>>>>> do not have their identities revealed. >>>>>>>>> >>>>>>>>> The second, which is more blurry, is the need for >>>>>>>>> participants that are >>>>>>>>> truly hidden. Some want to use hidden participants for >>>>>>>>> automatons, e.g., >>>>>>>>> IVR systems or conference recorders. (IMHO, bad idea, but >>>>>>>>> that is really >>>>>>>>> just MHO, not strictly black-and-white.) >>>>>>>>> >>>>>>>>> We do have consensus that Lawful Intercept is entirely >>>>>> orthogonal to >>>>>>>>> conference participants. However, the logic of the above >>>>>>>>> follows. Just as >>>>>>>>> IVR systems or conference recorders are not really >>>>>>>>> participants, neither is >>>>>>>>> LI hardware. If we say that the approach for IVR is to plumb >>>>>>>>> in as a hidden >>>>>>>>> participant, then LI would have the same approach. If we say >>>>>>>>> that IVR is >>>>>>>>> something different, e.g., just a part of the conference >>>>>>>>> mixer, then it is >>>>>>>>> truly "not there". Likewise, I would expect LI to be >>>>>> "not there" -- >>>>>>>>> something outside the XCON framework entirely. >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>>>>>>>> Sent: Monday, March 08, 2004 6:28 PM >>>>>>>>>> To: 'xcon@ietf.org' >>>>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hidden listeners operation is probably illegal in many US >>>>>>>> states as >>>>>>>>>> well as in many countries - when you make a call there is a >>>>>>>>>> requirement in California the all parties are aware of the >>>>>>>>> presence of >>>>>>>>>> a 3rd party or recording device, note- that party may be >>>>>>>> anonymous, >>>>>>>>>> etc.. >>>>>>>>>> (Exception -- >>>>>>>>>> legal intercept.) >>>>>>>>>> >>>>>>>>>> We should follow the similar logic for XCON - provide an >>>>>>>>> indication of >>>>>>>>>> a recording device and/or anonymous participant's) >>>>>>>>>> >>>>>>>>>> Peter Kozdon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On >>>>>>>> Behalf Of >>>>>>>>>> Adam Roach >>>>>>>>>> Sent: Monday, March 08, 2004 12:04 PM >>>>>>>>>> To: 'xcon@ietf.org' >>>>>>>>>> Subject: [XCON] Open Issue: Hidden Participants >>>>>>>>>> >>>>>>>>>> [as chair] >>>>>>>>>> >>>>>>>>>> At the XCON meeting, there was a rather lively >> discussion that >>>>>>>>>> continued the "Hidden Participants" discussion that had >>>>>>>>> started on the >>>>>>>>>> list. It was agreed that the topic was worth discussion, >>>>>>>>> but that we >>>>>>>>>> did not have enough time to pursue it in the meeting. >>>>>>>>>> >>>>>>>>>> I'm calling on everyone, especially those involved in >>>> the meeting >>>>>>>>>> discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to >>>>>>>> continue this >>>>>>>>>> discussion so we can close this issue in the near future. >>>>>>>>> Alan and I >>>>>>>>>> would like to be able to last-call this document shortly, >>>>>>>>> and this is >>>>>>>>>> the key issue that needs to be resolved before a new >>>>>>>>> revision of the >>>>>>>>>> draft can be produced. >>>>>>>>>> >>>>>>>>>> /a >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> XCON mailing list >>>>>>>>>> XCON@ietf.org >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> XCON mailing list >>>>>>>>>> XCON@ietf.org >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> XCON mailing list >>>>>>>>> XCON@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> XCON mailing list >>>>>>>> XCON@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> XCON mailing list >>>>>>> XCON@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>> >>>> >> _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 11 19:52:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07205 for ; Thu, 11 Mar 2004 19:52:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1au2-0004Bu-2m for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 19:51:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C0psQn016104 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 19:51:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1au1-0004Bf-Um for xcon-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 19:51: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 TAA07011 for ; Thu, 11 Mar 2004 19:51:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1au0-0003uU-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:51:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1api-0002m5-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:47:27 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1aoc-0002b9-02 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:46:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1afK-0005Xk-P7 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:36:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1abd-00020r-KQ; Thu, 11 Mar 2004 19:32:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ZIO-0000ad-Gl for xcon@optimus.ietf.org; Thu, 11 Mar 2004 18:08: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 SAA02164 for ; Thu, 11 Mar 2004 18:08:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ZIL-0005Vm-00 for xcon@ietf.org; Thu, 11 Mar 2004 18:08:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1ZHQ-0005OY-00 for xcon@ietf.org; Thu, 11 Mar 2004 18:07:58 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1B1ZGn-0005Ar-00 for xcon@ietf.org; Thu, 11 Mar 2004 18:07:17 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i2BN6lX7005339; Thu, 11 Mar 2004 17:06:47 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Mar 2004 17:06:47 -0600 Message-ID: <9ACE0CEE075B494096C86C23878BF85906A3AC@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Rosen, Brian'" Cc: xcon@ietf.org Subject: RE: [XCON] Open Issue: Hideable Participants Date: Thu, 11 Mar 2004 17:06:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 [not as chair] I think it's perfectly fine to mark it as a donkey (role) *and* as a hooved creature (attribute). The same applies to human scribe (role) and facilitator (attribute). To drive home the point that Rohan is making (using your analogy), let's say that I'm not interested in displaying animals with hooves in my roster. My user interface knows about donkeys, cows, sheep, pigs, and horses. It also knows about a variety of non-hooved animals. Then someone comes along and announces that a particular participant is a gir -- and that another one is a loris. Which one gets rendered? /a > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, March 11, 2004 15:36 > To: 'Rohan Mahy' > Cc: xcon@ietf.org; Eric Burger; 'Kozdon, Peter'; 'Adam Roach' > Subject: RE: [XCON] Open Issue: Hideable Participants > > > So, this is a discussion of "do you want the characteristics of > a participant, or a description of it". > > Seems to me that since this is not a protocol mechanism, it's a > UI issue, that you want a description and not a set of > characteristics. > It's pretty easy to figure out what an IVR box does, but its pretty > hard to figure out that it is an IVR box from a set of caps. > Infer that it's a donkey from a description of the parts > vs infer what parts are available knowing it's a donkey. > Since I can always arrange a UI to display characteristics if > I know what role, but can't go the other way, I think role is > best. > > Brian > > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan@cisco.com] > > Sent: Thursday, March 11, 2004 4:23 PM > > To: Rosen, Brian > > Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam > > Roach' > > Subject: Re: [XCON] Open Issue: Hideable Participants > > > > > > > > On Mar 11, 2004, at 12:53 PM, Rosen, Brian wrote: > > > What attributes does an IVR box have besides automaton? > > > How about a caption service? > > > > > > If we create a caps for each service, all orthogonal, is that > > > you think makes sense? > > > > no, i'm not proposing a cap for each service. it is this > > "facilitator" > > attribute that all of these roles *share* that causes my UI to hide > > them in the roster. I don't want to have to update my UI > (which hid > > IVRs, announcers, human scribes, and recording services) so > > that I will > > hide the caption service you just added. > > > > if you feel you need to add roles for these services, go > > right ahead. > > I don't object to having names roles, but I want my UI to refer to > > attributes where I think attributes are appropriate. [The > mere fact > > that all these services I just listed have something in > > common which is > > orthogonal to all the other attributes we have should be a > > strong clue > > that this "facilitator" property should be an attribute.] > > > > thanks, > > -rohan > > > > > These are all roles, they are not attributes. > > > > > > Brian > > > > > >> -----Original Message----- > > >> From: Rohan Mahy [mailto:rohan@cisco.com] > > >> Sent: Thursday, March 11, 2004 3:47 PM > > >> To: Rosen, Brian > > >> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, > Peter'; 'Adam > > >> Roach' > > >> Subject: Re: [XCON] Open Issue: Hideable Participants > > >> > > >> > > >> Hi, > > >> > > >> I'd like to apologize to the group that some of > > >> these ideas > > >> are SIP-specific or very SIP influenced > > >> > > >> Here are the binary or ternary attributes that already exist from > > >> draft-ietf-sip-callee-caps: > > >> > > >> automaton/human > > >> personal/business > > >> mobile/fixed > > >> duplex/send-only/receive-only > > >> > > >> these are 100% orthogonal with respect to each other > > >> > > >> Various folks have proposed that we need the following additional > > >> attributes in various parts of conferencing and/or signaling: > > >> > > >> interactive/noninteractive > > >> anonymous/identified > > >> > > >> (again, these are 100% orthogonal with respect to each > > other and the > > >> other attributes) > > >> > > >> finally I am proposing this new attribute we have been > > >> describing here. > > >> I believe this is still highly orthogonal to the other > > attributes. > > >> > > >> I believe this new attribute is more appropriate than an > > enumerations > > >> for two main reasons: > > >> > > >> 1) you can code behavior based on the presence of the attribute > > >> directly rather than checking for a bunch different > roles and then > > >> making sure there are not conditions attached to those roles. > > >> 2) it allows a new thing/role to exist which we haven't > > >> thought of yet > > >> that can still unambiguously provide its attributes. > existing code > > >> will work quite well with this new thing if it describes > > itself using > > >> (in part) a number of existing attributes. > > >> > > >> thanks, > > >> -rohan > > >> > > >> > > >> On Mar 11, 2004, at 11:29 AM, Rosen, Brian wrote: > > >> > > >>> Rohan > > >>> > > >>> I'm not sure I agree. I clearly do want to provide > > >> information across > > >>> the wire unambiguously, but I don't think a lot of binary > > attributes > > >>> is a good way to do that. I think we are talking about a > > >> role, rather > > >>> than an attribute. A single automaton, like a single > > >> human, is capable > > >>> of multiple roles, so you need a list in both cases. > > >>> > > >>> Brian > > >>> > > >>>> -----Original Message----- > > >>>> From: Rohan Mahy [mailto:rohan@cisco.com] > > >>>> Sent: Thursday, March 11, 2004 2:24 PM > > >>>> To: Rosen, Brian > > >>>> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, > > Peter'; 'Adam > > >>>> Roach' > > >>>> Subject: Re: [XCON] Open Issue: Hideable Participants > > >>>> > > >>>> > > >>>> Brian, > > >>>> > > >>>> There are many different orthogonal attributes we should be > > >>>> able to get > > >>>> access to. This "non-interesting" participant or "facilitator" > > >>>> attribute is orthogonal to your status as an automaton > > or human. I > > >>>> don't think an enumeration here is a good substitute for this > > >>>> attribute. It may be that indicating a recorder is a good > > >>>> value to add > > >>>> to the "actor" media feature tag, which currently has > a msg-taker > > >>>> value, or that we can reuse the msg-taker value for the > > >>>> recorder. The > > >>>> goal is maximum orthogonality. We probably can't > > achieve complete > > >>>> orthogonality but I think we can get very close. > > >>>> > > >>>> thanks, > > >>>> -rohan > > >>>> > > >>>> > > >>>> On Mar 11, 2004, at 6:14 AM, Rosen, Brian wrote: > > >>>> > > >>>>> Seems to me that you are on the right track, but we need to > > >>>> go farther. > > >>>>> We have to classify these participants so that the UI, if > > >>>> it wanted to, > > >>>>> could render an appropriate indication. The example of > > >> the recorder > > >>>>> is pretty compelling. Just knowing that there is an > > automaton out > > >>>>> there > > >>>>> is one thing. Knowing its a recorder is another. So, > > really you > > >>>>> don't want a flag, you want an enunumeration. It may > > actually be > > >>>>> a list, because a single automaton could have multiple > > functions. > > >>>>> > > >>>>> Brian > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Adam Roach [mailto:adam@dynamicsoft.com] > > >>>>>> Sent: Thursday, March 11, 2004 12:27 AM > > >>>>>> To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org > > >>>>>> Subject: RE: [XCON] Open Issue: Hideable Participants > > >>>>>> > > >>>>>> > > >>>>>> [not as chair] > > >>>>>> > > >>>>>> I don't think anyone is currently arguing whether indication > > >>>>>> of such automata should be available to the users. Most > > >>>>>> of what I've heard people say on this list -- after Korea, > > >>>>>> at least -- seems to agree that such elements *should* > > >>>>>> be indicated in the protocol. Note that this is not the > > >>>>>> same thing as saying that they must be forcibly rendered > > >>>>>> to users regardless of the users want, which is what you > > >>>>>> seem to be arguing for. > > >>>>>> > > >>>>>> What I've heard -- and I agree with this viewpoint -- is > > >>>>>> that there should be some flag that indicates "this element > > >>>>>> is a facilitator, not a participant," so that users who don't > > >>>>>> *care* about seeing such elements (existence proof: me) > > >>>>>> could configure their clients not to display them. > > >>>>>> > > >>>>>> To expand on the flag's meaning, it would make the most > > >>>>>> sense to have it mean more precisely "this element is not > > >>>>>> truly a participant, but is providing some service related > > >>>>>> to the conference." In other words, I would want it to > > >>>>>> cover e.g. human transcribers, human translators, etc., > > >>>>>> in addition to automata. > > >>>>>> > > >>>>>> As Eric points out, I think people are getting hung up on > > >>>>>> the name without thinking the issue through completely. > > >>>>>> I've updated the subject line accordingly. > > >>>>>> > > >>>>>> /a > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > > >>>>>>> Sent: Wednesday, March 10, 2004 20:50 > > >>>>>>> To: Eric Burger; xcon@ietf.org > > >>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants > > >>>>>>> > > >>>>>>> > > >>>>>>> I agree that automatons are processing resources > and could be > > >>>>>>> considered as > > >>>>>>> logical parts of the conference fabric, for example an IVR > > >>>>>>> could monitor the > > >>>>>>> conference and provide a trigger in response to a phrase > > >>>>>> that could be > > >>>>>>> consumed elsewhere. Similarly a device that announces > > >>>>>>> participants, etc.. > > >>>>>>> However, IMHO a conference recorder does not fall into this > > >>>>>>> category and > > >>>>>>> should probably be a visible resource maybe with an > > >>>>>> indicator to show > > >>>>>>> whether it is or is not active. Similarly - a player > > >>>> resources which > > >>>>>>> delivers content or information to the conference > should also > > >>>>>>> be visible - > > >>>>>>> it seems desirable to know where such content is > coming from. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Eric Burger [mailto:eburger@snowshore.com] > > >>>>>>> Sent: Tuesday, March 09, 2004 1:28 PM > > >>>>>>> To: Kozdon, Peter; xcon@ietf.org > > >>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants > > >>>>>>> > > >>>>>>> I think we got caught up on the name. > > >>>>>>> > > >>>>>>> There are two needs. > > >>>>>>> > > >>>>>>> The first, which I think we may have consensus on, is the > > >>>>>>> need for anonymous > > >>>>>>> participants. That is, participants that are present in the > > >>>>>>> conference, but > > >>>>>>> do not have their identities revealed. > > >>>>>>> > > >>>>>>> The second, which is more blurry, is the need for > > >>>>>>> participants that are > > >>>>>>> truly hidden. Some want to use hidden participants for > > >>>>>>> automatons, e.g., > > >>>>>>> IVR systems or conference recorders. (IMHO, bad idea, but > > >>>>>>> that is really > > >>>>>>> just MHO, not strictly black-and-white.) > > >>>>>>> > > >>>>>>> We do have consensus that Lawful Intercept is entirely > > >>>> orthogonal to > > >>>>>>> conference participants. However, the logic of the above > > >>>>>>> follows. Just as > > >>>>>>> IVR systems or conference recorders are not really > > >>>>>>> participants, neither is > > >>>>>>> LI hardware. If we say that the approach for IVR > is to plumb > > >>>>>>> in as a hidden > > >>>>>>> participant, then LI would have the same approach. > If we say > > >>>>>>> that IVR is > > >>>>>>> something different, e.g., just a part of the conference > > >>>>>>> mixer, then it is > > >>>>>>> truly "not there". Likewise, I would expect LI to be > > >>>> "not there" -- > > >>>>>>> something outside the XCON framework entirely. > > >>>>>>> > > >>>>>>>> -----Original Message----- > > >>>>>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > > >>>>>>>> Sent: Monday, March 08, 2004 6:28 PM > > >>>>>>>> To: 'xcon@ietf.org' > > >>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> Hidden listeners operation is probably illegal in many US > > >>>>>> states as > > >>>>>>>> well as in many countries - when you make a call there is a > > >>>>>>>> requirement in California the all parties are aware of the > > >>>>>>> presence of > > >>>>>>>> a 3rd party or recording device, note- that party may be > > >>>>>> anonymous, > > >>>>>>>> etc.. > > >>>>>>>> (Exception -- > > >>>>>>>> legal intercept.) > > >>>>>>>> > > >>>>>>>> We should follow the similar logic for XCON - provide an > > >>>>>>> indication of > > >>>>>>>> a recording device and/or anonymous participant's) > > >>>>>>>> > > >>>>>>>> Peter Kozdon > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> -----Original Message----- > > >>>>>>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On > > >>>>>> Behalf Of > > >>>>>>>> Adam Roach > > >>>>>>>> Sent: Monday, March 08, 2004 12:04 PM > > >>>>>>>> To: 'xcon@ietf.org' > > >>>>>>>> Subject: [XCON] Open Issue: Hidden Participants > > >>>>>>>> > > >>>>>>>> [as chair] > > >>>>>>>> > > >>>>>>>> At the XCON meeting, there was a rather lively > > discussion that > > >>>>>>>> continued the "Hidden Participants" discussion that had > > >>>>>>> started on the > > >>>>>>>> list. It was agreed that the topic was worth discussion, > > >>>>>>> but that we > > >>>>>>>> did not have enough time to pursue it in the meeting. > > >>>>>>>> > > >>>>>>>> I'm calling on everyone, especially those involved in > > >> the meeting > > >>>>>>>> discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to > > >>>>>> continue this > > >>>>>>>> discussion so we can close this issue in the near future. > > >>>>>>> Alan and I > > >>>>>>>> would like to be able to last-call this document shortly, > > >>>>>>> and this is > > >>>>>>>> the key issue that needs to be resolved before a new > > >>>>>>> revision of the > > >>>>>>>> draft can be produced. > > >>>>>>>> > > >>>>>>>> /a > > >>>>>>>> > > >>>>>>>> _______________________________________________ > > >>>>>>>> XCON mailing list > > >>>>>>>> XCON@ietf.org > > >>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon > > >>>>>>>> > > >>>>>>>> _______________________________________________ > > >>>>>>>> XCON mailing list > > >>>>>>>> XCON@ietf.org > > >>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon > > >>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>>>> _______________________________________________ > > >>>>>>> XCON mailing list > > >>>>>>> XCON@ietf.org > > >>>>>>> https://www1.ietf.org/mailman/listinfo/xcon > > >>>>>>> > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> XCON mailing list > > >>>>>> XCON@ietf.org > > >>>>>> https://www1.ietf.org/mailman/listinfo/xcon > > >>>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> XCON mailing list > > >>>>> XCON@ietf.org > > >>>>> https://www1.ietf.org/mailman/listinfo/xcon > > >>>> > > >> > > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 11 19:52:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07284 for ; Thu, 11 Mar 2004 19:52: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 1B1auG-0004Ew-3g for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 19:52:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C0q8G9016288 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 19:52:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1auF-0004EX-Qf for xcon-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 19:52: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 TAA07068 for ; Thu, 11 Mar 2004 19:52:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1auD-0003z0-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:52:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1apz-0002ok-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:47:45 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1aof-0002ax-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:46:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1adc-0005SR-FK for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:34:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1abL-0001qK-3Q; Thu, 11 Mar 2004 19:32:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Yfs-0006jn-4r for xcon@optimus.ietf.org; Thu, 11 Mar 2004 17: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 RAA00382 for ; Thu, 11 Mar 2004 17:29:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Yfp-0007nF-00 for xcon@ietf.org; Thu, 11 Mar 2004 17:29:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Yer-0007f0-00 for xcon@ietf.org; Thu, 11 Mar 2004 17:28:07 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1B1YeP-0007Wm-00 for xcon@ietf.org; Thu, 11 Mar 2004 17:27:37 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i2BMQkaZ025291; Thu, 11 Mar 2004 17:26:46 -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 RAA24508; Thu, 11 Mar 2004 17:26:45 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Mar 2004 17:26:45 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B64EB@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Rohan Mahy'" Cc: xcon@ietf.org, Eric Burger , "'Kozdon, Peter'" , "'Adam Roach'" Subject: RE: [XCON] Open Issue: Hideable Participants Date: Thu, 11 Mar 2004 17:26:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Somehow, you think there are fewer attributes than roles. I think there are fewer roles than attributes. Reiterating - i think its easier to infer attributes knowing roles than it is to infer roles knowing attributes. I don't see much utility in delivering both. The fact that it's an ass is the important part; i don't think that we can provide information figure out which ones are interesting and which ones are not. Brian -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Thursday, March 11, 2004 5:16 PM To: Rosen, Brian Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam = Roach' Subject: Re: [XCON] Open Issue: Hideable Participants OK,=20 We had a semantic problem with the word "roster". Let me try once more = using your sense of the word roster:=20 we are trying to tell if your UI should show the donkey or not *from* = the roster, and you=20 clearly can=92t do that if some asses are interesting and others are = not.=20 using the example of the human scribe, this is clearly impossible to = decide why your UI shouldn't display the human scribe unless you define a new attribute, *or* define a gigantic explosion of roles, conditional = roles, and subroles.=20 thanks,=20 -rohan=20 On Mar 11, 2004, at 1:59 PM, Rosen, Brian wrote:=20 Huh? I thought we already agreed, all participants go in the roster.=20 We're talking about what information you supply about the participants=20 so that an entity recieving the roster can do interesting things with=20 it; we observe that which participants are rendered, and how they=20 are rendered, is a local decision, but that decision needs information. = I'm mostly interested in things like icons representing services in the = conference. While the caps identified might be useful, they aren't=20 enough, and I don't want to solve the problem by inventing a bunch more = caps. I'd go so far as to suggest that we remove the recorder = mechanism,=20 and just make it a role.=20 -----Original Message-----=20 From: Rohan Mahy [mailto:rohan@cisco.com]=20 Sent: Thursday, March 11, 2004 4:53 PM=20 To: Rosen, Brian=20 Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam=20 Roach'=20 Subject: Re: [XCON] Open Issue: Hideable Participants=20 On Mar 11, 2004, at 1:36 PM, Rosen, Brian wrote:=20 So, this is a discussion of "do you want the characteristics of=20 a participant, or a description of it".=20 Seems to me that since this is not a protocol mechanism, it's a=20 UI issue, that you want a description and not a set of=20 characteristics.=20 It's pretty easy to figure out what an IVR box does, but its pretty=20 hard to figure out that it is an IVR box from a set of caps.=20 Infer that it's a donkey from a description of the parts=20 vs infer what parts are available knowing it's a donkey.=20 if its really relevant to know that its a donkey, then use a=20 description/role/whatever. However, *STAYING ON TOPIC*, we=20 are trying=20 to tell if you should show the donkey or not in the roster, and you=20 clearly can't do that if some asses are interesting and=20 others are not.=20 thx,=20 -r=20 Since I can always arrange a UI to display characteristics if=20 I know what role, but can't go the other way, I think role is=20 best.=20 Brian=20 -----Original Message-----=20 From: Rohan Mahy [mailto:rohan@cisco.com]=20 Sent: Thursday, March 11, 2004 4:23 PM=20 To: Rosen, Brian=20 Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam=20 Roach'=20 Subject: Re: [XCON] Open Issue: Hideable Participants=20 On Mar 11, 2004, at 12:53 PM, Rosen, Brian wrote:=20 What attributes does an IVR box have besides automaton?=20 How about a caption service?=20 If we create a caps for each service, all orthogonal, is that=20 you think makes sense?=20 no, i'm not proposing a cap for each service. it is this=20 "facilitator"=20 attribute that all of these roles *share* that causes my UI to hide=20 them in the roster. I don't want to have to update my UI=20 (which hid=20 IVRs, announcers, human scribes, and recording services) so=20 that I will=20 hide the caption service you just added.=20 if you feel you need to add roles for these services, go=20 right ahead.=20 I don't object to having names roles, but I want my UI to refer to=20 attributes where I think attributes are appropriate. [The=20 mere fact=20 that all these services I just listed have something in=20 common which is=20 orthogonal to all the other attributes we have should be a=20 strong clue=20 that this "facilitator" property should be an attribute.]=20 thanks,=20 -rohan=20 These are all roles, they are not attributes.=20 Brian=20 -----Original Message-----=20 From: Rohan Mahy [mailto:rohan@cisco.com]=20 Sent: Thursday, March 11, 2004 3:47 PM=20 To: Rosen, Brian=20 Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon,=20 Peter'; 'Adam=20 Roach'=20 Subject: Re: [XCON] Open Issue: Hideable Participants=20 Hi,=20 I'd like to apologize to the group that some of=20 these ideas=20 are SIP-specific or very SIP influenced=20 Here are the binary or ternary attributes that already exist from=20 draft-ietf-sip-callee-caps:=20 automaton/human=20 personal/business=20 mobile/fixed=20 duplex/send-only/receive-only=20 these are 100% orthogonal with respect to each other=20 Various folks have proposed that we need the following additional=20 attributes in various parts of conferencing and/or signaling:=20 interactive/noninteractive=20 anonymous/identified=20 (again, these are 100% orthogonal with respect to each=20 other and the=20 other attributes)=20 finally I am proposing this new attribute we have been=20 describing here.=20 I believe this is still highly orthogonal to the other=20 attributes.=20 I believe this new attribute is more appropriate than an=20 enumerations=20 for two main reasons:=20 1) you can code behavior based on the presence of the attribute=20 directly rather than checking for a bunch different=20 roles and then=20 making sure there are not conditions attached to those roles.=20 2) it allows a new thing/role to exist which we haven't=20 thought of yet=20 that can still unambiguously provide its attributes.=20 existing code=20 will work quite well with this new thing if it describes=20 itself using=20 (in part) a number of existing attributes.=20 thanks,=20 -rohan=20 On Mar 11, 2004, at 11:29 AM, Rosen, Brian wrote:=20 Rohan=20 I'm not sure I agree. I clearly do want to provide=20 information across=20 the wire unambiguously, but I don't think a lot of binary=20 attributes=20 is a good way to do that. I think we are talking about a=20 role, rather=20 than an attribute. A single automaton, like a single=20 human, is capable=20 of multiple roles, so you need a list in both cases.=20 Brian=20 -----Original Message-----=20 From: Rohan Mahy [mailto:rohan@cisco.com]=20 Sent: Thursday, March 11, 2004 2:24 PM=20 To: Rosen, Brian=20 Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon,=20 Peter'; 'Adam=20 Roach'=20 Subject: Re: [XCON] Open Issue: Hideable Participants=20 Brian,=20 There are many different orthogonal attributes we should be=20 able to get=20 access to. This "non-interesting" participant or "facilitator"=20 attribute is orthogonal to your status as an automaton=20 or human. I=20 don't think an enumeration here is a good substitute for this=20 attribute. It may be that indicating a recorder is a good=20 value to add=20 to the "actor" media feature tag, which currently has=20 a msg-taker=20 value, or that we can reuse the msg-taker value for the=20 recorder. The=20 goal is maximum orthogonality. We probably can't=20 achieve complete=20 orthogonality but I think we can get very close.=20 thanks,=20 -rohan=20 On Mar 11, 2004, at 6:14 AM, Rosen, Brian wrote:=20 Seems to me that you are on the right track, but we need to=20 go farther.=20 We have to classify these participants so that the UI, if=20 it wanted to,=20 could render an appropriate indication. The example of=20 the recorder=20 is pretty compelling. Just knowing that there is an=20 automaton out=20 there=20 is one thing. Knowing its a recorder is another. So,=20 really you=20 don't want a flag, you want an enunumeration. It may=20 actually be=20 a list, because a single automaton could have multiple=20 functions.=20 Brian=20 -----Original Message-----=20 From: Adam Roach [mailto:adam@dynamicsoft.com]=20 Sent: Thursday, March 11, 2004 12:27 AM=20 To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org=20 Subject: RE: [XCON] Open Issue: Hideable Participants=20 [not as chair]=20 I don't think anyone is currently arguing whether indication=20 of such automata should be available to the users. Most=20 of what I've heard people say on this list -- after Korea,=20 at least -- seems to agree that such elements *should*=20 be indicated in the protocol. Note that this is not the=20 same thing as saying that they must be forcibly rendered=20 to users regardless of the users want, which is what you=20 seem to be arguing for.=20 What I've heard -- and I agree with this viewpoint -- is=20 that there should be some flag that indicates "this element=20 is a facilitator, not a participant," so that users who don't=20 *care* about seeing such elements (existence proof: me)=20 could configure their clients not to display them.=20 To expand on the flag's meaning, it would make the most=20 sense to have it mean more precisely "this element is not=20 truly a participant, but is providing some service related=20 to the conference." In other words, I would want it to=20 cover e.g. human transcribers, human translators, etc.,=20 in addition to automata.=20 As Eric points out, I think people are getting hung up on=20 the name without thinking the issue through completely.=20 I've updated the subject line accordingly.=20 /a=20 -----Original Message-----=20 From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com]=20 Sent: Wednesday, March 10, 2004 20:50=20 To: Eric Burger; xcon@ietf.org=20 Subject: RE: [XCON] Open Issue: Hidden Participants=20 I agree that automatons are processing resources=20 and could be=20 considered as=20 logical parts of the conference fabric, for example an IVR=20 could monitor the=20 conference and provide a trigger in response to a phrase=20 that could be=20 consumed elsewhere. Similarly a device that announces=20 participants, etc..=20 However, IMHO a conference recorder does not fall into this=20 category and=20 should probably be a visible resource maybe with an=20 indicator to show=20 whether it is or is not active. Similarly - a player=20 resources which=20 delivers content or information to the conference=20 should also=20 be visible -=20 it seems desirable to know where such content is=20 coming from.=20 -----Original Message-----=20 From: Eric Burger [mailto:eburger@snowshore.com]=20 Sent: Tuesday, March 09, 2004 1:28 PM=20 To: Kozdon, Peter; xcon@ietf.org=20 Subject: RE: [XCON] Open Issue: Hidden Participants=20 I think we got caught up on the name.=20 There are two needs.=20 The first, which I think we may have consensus on, is the=20 need for anonymous=20 participants. That is, participants that are present in the=20 conference, but=20 do not have their identities revealed.=20 The second, which is more blurry, is the need for=20 participants that are=20 truly hidden. Some want to use hidden participants for=20 automatons, e.g.,=20 IVR systems or conference recorders. (IMHO, bad idea, but=20 that is really=20 just MHO, not strictly black-and-white.)=20 We do have consensus that Lawful Intercept is entirely=20 orthogonal to=20 conference participants. However, the logic of the above=20 follows. Just as=20 IVR systems or conference recorders are not really=20 participants, neither is=20 LI hardware. If we say that the approach for IVR=20 is to plumb=20 in as a hidden=20 participant, then LI would have the same approach.=20 If we say=20 that IVR is=20 something different, e.g., just a part of the conference=20 mixer, then it is=20 truly "not there". Likewise, I would expect LI to be=20 "not there" --=20 something outside the XCON framework entirely.=20 -----Original Message-----=20 From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com]=20 Sent: Monday, March 08, 2004 6:28 PM=20 To: 'xcon@ietf.org'=20 Subject: RE: [XCON] Open Issue: Hidden Participants=20 Hidden listeners operation is probably illegal in many US=20 states as=20 well as in many countries - when you make a call there is a=20 requirement in California the all parties are aware of the=20 presence of=20 a 3rd party or recording device, note- that party may be=20 anonymous,=20 etc..=20 (Exception --=20 legal intercept.)=20 We should follow the similar logic for XCON - provide an=20 indication of=20 a recording device and/or anonymous participant's)=20 Peter Kozdon=20 -----Original Message-----=20 From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On=20 Behalf Of=20 Adam Roach=20 Sent: Monday, March 08, 2004 12:04 PM=20 To: 'xcon@ietf.org'=20 Subject: [XCON] Open Issue: Hidden Participants=20 [as chair]=20 At the XCON meeting, there was a rather lively=20 discussion that=20 continued the "Hidden Participants" discussion that had=20 started on the=20 list. It was agreed that the topic was worth discussion,=20 but that we=20 did not have enough time to pursue it in the meeting.=20 I'm calling on everyone, especially those involved in=20 the meeting=20 discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to=20 continue this=20 discussion so we can close this issue in the near future.=20 Alan and I=20 would like to be able to last-call this document shortly,=20 and this is=20 the key issue that needs to be resolved before a new=20 revision of the=20 draft can be produced.=20 /a=20 _______________________________________________=20 XCON mailing list=20 XCON@ietf.org=20 https://www1.ietf.org/mailman/listinfo/xcon=20 _______________________________________________=20 XCON mailing list=20 XCON@ietf.org=20 https://www1.ietf.org/mailman/listinfo/xcon=20 _______________________________________________=20 XCON mailing list=20 XCON@ietf.org=20 https://www1.ietf.org/mailman/listinfo/xcon=20 _______________________________________________=20 XCON mailing list=20 XCON@ietf.org=20 https://www1.ietf.org/mailman/listinfo/xcon=20 _______________________________________________=20 XCON mailing list=20 XCON@ietf.org=20 https://www1.ietf.org/mailman/listinfo/xcon=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 11 19:53:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07487 for ; Thu, 11 Mar 2004 19:53: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 1B1aud-0004JB-9H for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 19:52:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C0qVPZ016555 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 19:52:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1aud-0004Iw-2b for xcon-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 19:52: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 TAA07268 for ; Thu, 11 Mar 2004 19:52:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1aub-00046v-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:52:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1aqT-0002wZ-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:48:15 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1aoh-0002b9-04 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:46:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1acl-0005Je-6X for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:34:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1abG-0001nD-IJ; Thu, 11 Mar 2004 19:32:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1YG2-0005Sf-Nh for xcon@optimus.ietf.org; Thu, 11 Mar 2004 17:02: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 RAA29536 for ; Thu, 11 Mar 2004 17:02:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1YG0-0004U6-00 for xcon@ietf.org; Thu, 11 Mar 2004 17:02:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1YFM-0004J6-00 for xcon@ietf.org; Thu, 11 Mar 2004 17:01:45 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1B1YEF-00046E-00 for xcon@ietf.org; Thu, 11 Mar 2004 17:00:35 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i2BLxNaZ024752; Thu, 11 Mar 2004 16:59:27 -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 QAA19056; Thu, 11 Mar 2004 16:59:22 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Mar 2004 16:59:22 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B64E7@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Rohan Mahy'" Cc: xcon@ietf.org, Eric Burger , "'Kozdon, Peter'" , "'Adam Roach'" Subject: RE: [XCON] Open Issue: Hideable Participants Date: Thu, 11 Mar 2004 16:59:19 -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.1 required=5.0 tests=AWL autolearn=no version=2.60 Huh? I thought we already agreed, all participants go in the roster. We're talking about what information you supply about the participants so that an entity recieving the roster can do interesting things with it; we observe that which participants are rendered, and how they are rendered, is a local decision, but that decision needs information. I'm mostly interested in things like icons representing services in the conference. While the caps identified might be useful, they aren't enough, and I don't want to solve the problem by inventing a bunch more caps. I'd go so far as to suggest that we remove the recorder mechanism, and just make it a role. > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Thursday, March 11, 2004 4:53 PM > To: Rosen, Brian > Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam > Roach' > Subject: Re: [XCON] Open Issue: Hideable Participants > > > > On Mar 11, 2004, at 1:36 PM, Rosen, Brian wrote: > > > So, this is a discussion of "do you want the characteristics of > > a participant, or a description of it". > > > > Seems to me that since this is not a protocol mechanism, it's a > > UI issue, that you want a description and not a set of > characteristics. > > It's pretty easy to figure out what an IVR box does, but its pretty > > hard to figure out that it is an IVR box from a set of caps. > > Infer that it's a donkey from a description of the parts > > vs infer what parts are available knowing it's a donkey. > > if its really relevant to know that its a donkey, then use a > description/role/whatever. However, *STAYING ON TOPIC*, we > are trying > to tell if you should show the donkey or not in the roster, and you > clearly can't do that if some asses are interesting and > others are not. > > thx, > -r > > > Since I can always arrange a UI to display characteristics if > > I know what role, but can't go the other way, I think role is > > best. > > > > Brian > > > >> -----Original Message----- > >> From: Rohan Mahy [mailto:rohan@cisco.com] > >> Sent: Thursday, March 11, 2004 4:23 PM > >> To: Rosen, Brian > >> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam > >> Roach' > >> Subject: Re: [XCON] Open Issue: Hideable Participants > >> > >> > >> > >> On Mar 11, 2004, at 12:53 PM, Rosen, Brian wrote: > >>> What attributes does an IVR box have besides automaton? > >>> How about a caption service? > >>> > >>> If we create a caps for each service, all orthogonal, is that > >>> you think makes sense? > >> > >> no, i'm not proposing a cap for each service. it is this > >> "facilitator" > >> attribute that all of these roles *share* that causes my UI to hide > >> them in the roster. I don't want to have to update my UI > (which hid > >> IVRs, announcers, human scribes, and recording services) so > >> that I will > >> hide the caption service you just added. > >> > >> if you feel you need to add roles for these services, go > >> right ahead. > >> I don't object to having names roles, but I want my UI to refer to > >> attributes where I think attributes are appropriate. [The > mere fact > >> that all these services I just listed have something in > >> common which is > >> orthogonal to all the other attributes we have should be a > >> strong clue > >> that this "facilitator" property should be an attribute.] > >> > >> thanks, > >> -rohan > >> > >>> These are all roles, they are not attributes. > >>> > >>> Brian > >>> > >>>> -----Original Message----- > >>>> From: Rohan Mahy [mailto:rohan@cisco.com] > >>>> Sent: Thursday, March 11, 2004 3:47 PM > >>>> To: Rosen, Brian > >>>> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, > Peter'; 'Adam > >>>> Roach' > >>>> Subject: Re: [XCON] Open Issue: Hideable Participants > >>>> > >>>> > >>>> Hi, > >>>> > >>>> I'd like to apologize to the group that some of > >>>> these ideas > >>>> are SIP-specific or very SIP influenced > >>>> > >>>> Here are the binary or ternary attributes that already exist from > >>>> draft-ietf-sip-callee-caps: > >>>> > >>>> automaton/human > >>>> personal/business > >>>> mobile/fixed > >>>> duplex/send-only/receive-only > >>>> > >>>> these are 100% orthogonal with respect to each other > >>>> > >>>> Various folks have proposed that we need the following additional > >>>> attributes in various parts of conferencing and/or signaling: > >>>> > >>>> interactive/noninteractive > >>>> anonymous/identified > >>>> > >>>> (again, these are 100% orthogonal with respect to each > >> other and the > >>>> other attributes) > >>>> > >>>> finally I am proposing this new attribute we have been > >>>> describing here. > >>>> I believe this is still highly orthogonal to the other > >> attributes. > >>>> > >>>> I believe this new attribute is more appropriate than an > >> enumerations > >>>> for two main reasons: > >>>> > >>>> 1) you can code behavior based on the presence of the attribute > >>>> directly rather than checking for a bunch different > roles and then > >>>> making sure there are not conditions attached to those roles. > >>>> 2) it allows a new thing/role to exist which we haven't > >>>> thought of yet > >>>> that can still unambiguously provide its attributes. > existing code > >>>> will work quite well with this new thing if it describes > >> itself using > >>>> (in part) a number of existing attributes. > >>>> > >>>> thanks, > >>>> -rohan > >>>> > >>>> > >>>> On Mar 11, 2004, at 11:29 AM, Rosen, Brian wrote: > >>>> > >>>>> Rohan > >>>>> > >>>>> I'm not sure I agree. I clearly do want to provide > >>>> information across > >>>>> the wire unambiguously, but I don't think a lot of binary > >> attributes > >>>>> is a good way to do that. I think we are talking about a > >>>> role, rather > >>>>> than an attribute. A single automaton, like a single > >>>> human, is capable > >>>>> of multiple roles, so you need a list in both cases. > >>>>> > >>>>> Brian > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Rohan Mahy [mailto:rohan@cisco.com] > >>>>>> Sent: Thursday, March 11, 2004 2:24 PM > >>>>>> To: Rosen, Brian > >>>>>> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, > >> Peter'; 'Adam > >>>>>> Roach' > >>>>>> Subject: Re: [XCON] Open Issue: Hideable Participants > >>>>>> > >>>>>> > >>>>>> Brian, > >>>>>> > >>>>>> There are many different orthogonal attributes we should be > >>>>>> able to get > >>>>>> access to. This "non-interesting" participant or "facilitator" > >>>>>> attribute is orthogonal to your status as an automaton > >> or human. I > >>>>>> don't think an enumeration here is a good substitute for this > >>>>>> attribute. It may be that indicating a recorder is a good > >>>>>> value to add > >>>>>> to the "actor" media feature tag, which currently has > a msg-taker > >>>>>> value, or that we can reuse the msg-taker value for the > >>>>>> recorder. The > >>>>>> goal is maximum orthogonality. We probably can't > >> achieve complete > >>>>>> orthogonality but I think we can get very close. > >>>>>> > >>>>>> thanks, > >>>>>> -rohan > >>>>>> > >>>>>> > >>>>>> On Mar 11, 2004, at 6:14 AM, Rosen, Brian wrote: > >>>>>> > >>>>>>> Seems to me that you are on the right track, but we need to > >>>>>> go farther. > >>>>>>> We have to classify these participants so that the UI, if > >>>>>> it wanted to, > >>>>>>> could render an appropriate indication. The example of > >>>> the recorder > >>>>>>> is pretty compelling. Just knowing that there is an > >> automaton out > >>>>>>> there > >>>>>>> is one thing. Knowing its a recorder is another. So, > >> really you > >>>>>>> don't want a flag, you want an enunumeration. It may > >> actually be > >>>>>>> a list, because a single automaton could have multiple > >> functions. > >>>>>>> > >>>>>>> Brian > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Adam Roach [mailto:adam@dynamicsoft.com] > >>>>>>>> Sent: Thursday, March 11, 2004 12:27 AM > >>>>>>>> To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org > >>>>>>>> Subject: RE: [XCON] Open Issue: Hideable Participants > >>>>>>>> > >>>>>>>> > >>>>>>>> [not as chair] > >>>>>>>> > >>>>>>>> I don't think anyone is currently arguing whether indication > >>>>>>>> of such automata should be available to the users. Most > >>>>>>>> of what I've heard people say on this list -- after Korea, > >>>>>>>> at least -- seems to agree that such elements *should* > >>>>>>>> be indicated in the protocol. Note that this is not the > >>>>>>>> same thing as saying that they must be forcibly rendered > >>>>>>>> to users regardless of the users want, which is what you > >>>>>>>> seem to be arguing for. > >>>>>>>> > >>>>>>>> What I've heard -- and I agree with this viewpoint -- is > >>>>>>>> that there should be some flag that indicates "this element > >>>>>>>> is a facilitator, not a participant," so that users who don't > >>>>>>>> *care* about seeing such elements (existence proof: me) > >>>>>>>> could configure their clients not to display them. > >>>>>>>> > >>>>>>>> To expand on the flag's meaning, it would make the most > >>>>>>>> sense to have it mean more precisely "this element is not > >>>>>>>> truly a participant, but is providing some service related > >>>>>>>> to the conference." In other words, I would want it to > >>>>>>>> cover e.g. human transcribers, human translators, etc., > >>>>>>>> in addition to automata. > >>>>>>>> > >>>>>>>> As Eric points out, I think people are getting hung up on > >>>>>>>> the name without thinking the issue through completely. > >>>>>>>> I've updated the subject line accordingly. > >>>>>>>> > >>>>>>>> /a > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > >>>>>>>>> Sent: Wednesday, March 10, 2004 20:50 > >>>>>>>>> To: Eric Burger; xcon@ietf.org > >>>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I agree that automatons are processing resources > and could be > >>>>>>>>> considered as > >>>>>>>>> logical parts of the conference fabric, for example an IVR > >>>>>>>>> could monitor the > >>>>>>>>> conference and provide a trigger in response to a phrase > >>>>>>>> that could be > >>>>>>>>> consumed elsewhere. Similarly a device that announces > >>>>>>>>> participants, etc.. > >>>>>>>>> However, IMHO a conference recorder does not fall into this > >>>>>>>>> category and > >>>>>>>>> should probably be a visible resource maybe with an > >>>>>>>> indicator to show > >>>>>>>>> whether it is or is not active. Similarly - a player > >>>>>> resources which > >>>>>>>>> delivers content or information to the conference > should also > >>>>>>>>> be visible - > >>>>>>>>> it seems desirable to know where such content is > coming from. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Eric Burger [mailto:eburger@snowshore.com] > >>>>>>>>> Sent: Tuesday, March 09, 2004 1:28 PM > >>>>>>>>> To: Kozdon, Peter; xcon@ietf.org > >>>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants > >>>>>>>>> > >>>>>>>>> I think we got caught up on the name. > >>>>>>>>> > >>>>>>>>> There are two needs. > >>>>>>>>> > >>>>>>>>> The first, which I think we may have consensus on, is the > >>>>>>>>> need for anonymous > >>>>>>>>> participants. That is, participants that are present in the > >>>>>>>>> conference, but > >>>>>>>>> do not have their identities revealed. > >>>>>>>>> > >>>>>>>>> The second, which is more blurry, is the need for > >>>>>>>>> participants that are > >>>>>>>>> truly hidden. Some want to use hidden participants for > >>>>>>>>> automatons, e.g., > >>>>>>>>> IVR systems or conference recorders. (IMHO, bad idea, but > >>>>>>>>> that is really > >>>>>>>>> just MHO, not strictly black-and-white.) > >>>>>>>>> > >>>>>>>>> We do have consensus that Lawful Intercept is entirely > >>>>>> orthogonal to > >>>>>>>>> conference participants. However, the logic of the above > >>>>>>>>> follows. Just as > >>>>>>>>> IVR systems or conference recorders are not really > >>>>>>>>> participants, neither is > >>>>>>>>> LI hardware. If we say that the approach for IVR > is to plumb > >>>>>>>>> in as a hidden > >>>>>>>>> participant, then LI would have the same approach. > If we say > >>>>>>>>> that IVR is > >>>>>>>>> something different, e.g., just a part of the conference > >>>>>>>>> mixer, then it is > >>>>>>>>> truly "not there". Likewise, I would expect LI to be > >>>>>> "not there" -- > >>>>>>>>> something outside the XCON framework entirely. > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > >>>>>>>>>> Sent: Monday, March 08, 2004 6:28 PM > >>>>>>>>>> To: 'xcon@ietf.org' > >>>>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Hidden listeners operation is probably illegal in many US > >>>>>>>> states as > >>>>>>>>>> well as in many countries - when you make a call there is a > >>>>>>>>>> requirement in California the all parties are aware of the > >>>>>>>>> presence of > >>>>>>>>>> a 3rd party or recording device, note- that party may be > >>>>>>>> anonymous, > >>>>>>>>>> etc.. > >>>>>>>>>> (Exception -- > >>>>>>>>>> legal intercept.) > >>>>>>>>>> > >>>>>>>>>> We should follow the similar logic for XCON - provide an > >>>>>>>>> indication of > >>>>>>>>>> a recording device and/or anonymous participant's) > >>>>>>>>>> > >>>>>>>>>> Peter Kozdon > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On > >>>>>>>> Behalf Of > >>>>>>>>>> Adam Roach > >>>>>>>>>> Sent: Monday, March 08, 2004 12:04 PM > >>>>>>>>>> To: 'xcon@ietf.org' > >>>>>>>>>> Subject: [XCON] Open Issue: Hidden Participants > >>>>>>>>>> > >>>>>>>>>> [as chair] > >>>>>>>>>> > >>>>>>>>>> At the XCON meeting, there was a rather lively > >> discussion that > >>>>>>>>>> continued the "Hidden Participants" discussion that had > >>>>>>>>> started on the > >>>>>>>>>> list. It was agreed that the topic was worth discussion, > >>>>>>>>> but that we > >>>>>>>>>> did not have enough time to pursue it in the meeting. > >>>>>>>>>> > >>>>>>>>>> I'm calling on everyone, especially those involved in > >>>> the meeting > >>>>>>>>>> discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to > >>>>>>>> continue this > >>>>>>>>>> discussion so we can close this issue in the near future. > >>>>>>>>> Alan and I > >>>>>>>>>> would like to be able to last-call this document shortly, > >>>>>>>>> and this is > >>>>>>>>>> the key issue that needs to be resolved before a new > >>>>>>>>> revision of the > >>>>>>>>>> draft can be produced. > >>>>>>>>>> > >>>>>>>>>> /a > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> XCON mailing list > >>>>>>>>>> XCON@ietf.org > >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> XCON mailing list > >>>>>>>>>> XCON@ietf.org > >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> XCON mailing list > >>>>>>>>> XCON@ietf.org > >>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> XCON mailing list > >>>>>>>> XCON@ietf.org > >>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> XCON mailing list > >>>>>>> XCON@ietf.org > >>>>>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>>>> > >>>> > >> > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 11 19:53:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07678 for ; Thu, 11 Mar 2004 19:53: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 1B1av3-0004NF-Dp for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 19:52:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C0qvMu016802 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 19:52:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1av2-0004Mu-Vf for xcon-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 19:52: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 TAA07449 for ; Thu, 11 Mar 2004 19:52:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1av0-0004EH-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:52:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1aqx-00034m-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:48:47 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1aoj-0002bd-01 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:46:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1abJ-0005Jo-79 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:32:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1abH-0001oB-RY; Thu, 11 Mar 2004 19:32:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1YV0-0006QK-9o for xcon@optimus.ietf.org; Thu, 11 Mar 2004 17:17: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 RAA29984 for ; Thu, 11 Mar 2004 17:17:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1YUx-0006QD-00 for xcon@ietf.org; Thu, 11 Mar 2004 17:17:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1YU1-0006JI-00 for xcon@ietf.org; Thu, 11 Mar 2004 17:16:57 -0500 Received: from ind-iport-1-sec.cisco.com ([64.104.129.9] helo=ind-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B1YT5-00066e-00 for xcon@ietf.org; Thu, 11 Mar 2004 17:15:55 -0500 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 12 Mar 2004 09:23:55 +0530 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2BMExEi001261; Thu, 11 Mar 2004 14:15:04 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARC36779; Thu, 11 Mar 2004 14:15:10 -0800 (PST) In-Reply-To: <313680C9A886D511A06000204840E1CF070B64E7@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B64E7@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: multipart/alternative; boundary=Apple-Mail-6--195556393 Message-Id: Cc: xcon@ietf.org, Eric Burger , Rohan Mahy , "'Kozdon, Peter'" , "'Adam Roach'" From: Rohan Mahy Subject: Re: [XCON] Open Issue: Hideable Participants Date: Thu, 11 Mar 2004 14:16:14 -0800 To: "Rosen, Brian" X-Mailer: Apple Mail (2.612) Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 --Apple-Mail-6--195556393 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable OK, We had a semantic problem with the word "roster". Let me try once more=20= using your sense of the word roster: we are trying to tell if your UI should show the donkey or not *from*=20 the roster, and you clearly can=92t do that if some asses are interesting and others are = not. using the example of the human scribe, this is clearly impossible to=20 decide why your UI shouldn't display the human scribe unless you define=20= a new attribute, *or* define a gigantic explosion of roles, conditional=20= roles, and subroles. thanks, -rohan On Mar 11, 2004, at 1:59 PM, Rosen, Brian wrote: > Huh? I thought we already agreed, all participants go in the roster. > We're talking about what information you supply about the participants > so that an entity recieving the roster can do interesting things with > it; we observe that which participants are rendered, and how they > are rendered, is a local decision, but that decision needs = information. > I'm mostly interested in things like icons representing services in = the > conference. While the caps identified might be useful, they aren't > enough, and I don't want to solve the problem by inventing a bunch = more > caps. I'd go so far as to suggest that we remove the recorder=20 > mechanism, > and just make it a role. > >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan@cisco.com] >> Sent: Thursday, March 11, 2004 4:53 PM >> To: Rosen, Brian >> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam >> Roach' >> Subject: Re: [XCON] Open Issue: Hideable Participants >> >> >> >> On Mar 11, 2004, at 1:36 PM, Rosen, Brian wrote: >> >>> So, this is a discussion of "do you want the characteristics of >>> a participant, or a description of it". >>> >>> Seems to me that since this is not a protocol mechanism, it's a >>> UI issue, that you want a description and not a set of >> characteristics. >>> It's pretty easy to figure out what an IVR box does, but its pretty >>> hard to figure out that it is an IVR box from a set of caps. >>> Infer that it's a donkey from a description of the parts >>> vs infer what parts are available knowing it's a donkey. >> >> if its really relevant to know that its a donkey, then use a >> description/role/whatever. However, *STAYING ON TOPIC*, we >> are trying >> to tell if you should show the donkey or not in the roster, and you >> clearly can't do that if some asses are interesting and >> others are not. >> >> thx, >> -r >> >>> Since I can always arrange a UI to display characteristics if >>> I know what role, but can't go the other way, I think role is >>> best. >>> >>> Brian >>> >>>> -----Original Message----- >>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>> Sent: Thursday, March 11, 2004 4:23 PM >>>> To: Rosen, Brian >>>> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam >>>> Roach' >>>> Subject: Re: [XCON] Open Issue: Hideable Participants >>>> >>>> >>>> >>>> On Mar 11, 2004, at 12:53 PM, Rosen, Brian wrote: >>>>> What attributes does an IVR box have besides automaton? >>>>> How about a caption service? >>>>> >>>>> If we create a caps for each service, all orthogonal, is that >>>>> you think makes sense? >>>> >>>> no, i'm not proposing a cap for each service. it is this >>>> "facilitator" >>>> attribute that all of these roles *share* that causes my UI to hide >>>> them in the roster. I don't want to have to update my UI >> (which hid >>>> IVRs, announcers, human scribes, and recording services) so >>>> that I will >>>> hide the caption service you just added. >>>> >>>> if you feel you need to add roles for these services, go >>>> right ahead. >>>> I don't object to having names roles, but I want my UI to refer to >>>> attributes where I think attributes are appropriate. [The >> mere fact >>>> that all these services I just listed have something in >>>> common which is >>>> orthogonal to all the other attributes we have should be a >>>> strong clue >>>> that this "facilitator" property should be an attribute.] >>>> >>>> thanks, >>>> -rohan >>>> >>>>> These are all roles, they are not attributes. >>>>> >>>>> Brian >>>>> >>>>>> -----Original Message----- >>>>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>>>> Sent: Thursday, March 11, 2004 3:47 PM >>>>>> To: Rosen, Brian >>>>>> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, >> Peter'; 'Adam >>>>>> Roach' >>>>>> Subject: Re: [XCON] Open Issue: Hideable Participants >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I'd like to apologize to the group that some of >>>>>> these ideas >>>>>> are SIP-specific or very SIP influenced >>>>>> >>>>>> Here are the binary or ternary attributes that already exist from >>>>>> draft-ietf-sip-callee-caps: >>>>>> >>>>>> automaton/human >>>>>> personal/business >>>>>> mobile/fixed >>>>>> duplex/send-only/receive-only >>>>>> >>>>>> these are 100% orthogonal with respect to each other >>>>>> >>>>>> Various folks have proposed that we need the following additional >>>>>> attributes in various parts of conferencing and/or signaling: >>>>>> >>>>>> interactive/noninteractive >>>>>> anonymous/identified >>>>>> >>>>>> (again, these are 100% orthogonal with respect to each >>>> other and the >>>>>> other attributes) >>>>>> >>>>>> finally I am proposing this new attribute we have been >>>>>> describing here. >>>>>> I believe this is still highly orthogonal to the other >>>> attributes. >>>>>> >>>>>> I believe this new attribute is more appropriate than an >>>> enumerations >>>>>> for two main reasons: >>>>>> >>>>>> 1) you can code behavior based on the presence of the attribute >>>>>> directly rather than checking for a bunch different >> roles and then >>>>>> making sure there are not conditions attached to those roles. >>>>>> 2) it allows a new thing/role to exist which we haven't >>>>>> thought of yet >>>>>> that can still unambiguously provide its attributes. >> existing code >>>>>> will work quite well with this new thing if it describes >>>> itself using >>>>>> (in part) a number of existing attributes. >>>>>> >>>>>> thanks, >>>>>> -rohan >>>>>> >>>>>> >>>>>> On Mar 11, 2004, at 11:29 AM, Rosen, Brian wrote: >>>>>> >>>>>>> Rohan >>>>>>> >>>>>>> I'm not sure I agree. I clearly do want to provide >>>>>> information across >>>>>>> the wire unambiguously, but I don't think a lot of binary >>>> attributes >>>>>>> is a good way to do that. I think we are talking about a >>>>>> role, rather >>>>>>> than an attribute. A single automaton, like a single >>>>>> human, is capable >>>>>>> of multiple roles, so you need a list in both cases. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>>>>>> Sent: Thursday, March 11, 2004 2:24 PM >>>>>>>> To: Rosen, Brian >>>>>>>> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, >>>> Peter'; 'Adam >>>>>>>> Roach' >>>>>>>> Subject: Re: [XCON] Open Issue: Hideable Participants >>>>>>>> >>>>>>>> >>>>>>>> Brian, >>>>>>>> >>>>>>>> There are many different orthogonal attributes we should be >>>>>>>> able to get >>>>>>>> access to. This "non-interesting" participant or "facilitator" >>>>>>>> attribute is orthogonal to your status as an automaton >>>> or human. I >>>>>>>> don't think an enumeration here is a good substitute for this >>>>>>>> attribute. It may be that indicating a recorder is a good >>>>>>>> value to add >>>>>>>> to the "actor" media feature tag, which currently has >> a msg-taker >>>>>>>> value, or that we can reuse the msg-taker value for the >>>>>>>> recorder. The >>>>>>>> goal is maximum orthogonality. We probably can't >>>> achieve complete >>>>>>>> orthogonality but I think we can get very close. >>>>>>>> >>>>>>>> thanks, >>>>>>>> -rohan >>>>>>>> >>>>>>>> >>>>>>>> On Mar 11, 2004, at 6:14 AM, Rosen, Brian wrote: >>>>>>>> >>>>>>>>> Seems to me that you are on the right track, but we need to >>>>>>>> go farther. >>>>>>>>> We have to classify these participants so that the UI, if >>>>>>>> it wanted to, >>>>>>>>> could render an appropriate indication. The example of >>>>>> the recorder >>>>>>>>> is pretty compelling. Just knowing that there is an >>>> automaton out >>>>>>>>> there >>>>>>>>> is one thing. Knowing its a recorder is another. So, >>>> really you >>>>>>>>> don't want a flag, you want an enunumeration. It may >>>> actually be >>>>>>>>> a list, because a single automaton could have multiple >>>> functions. >>>>>>>>> >>>>>>>>> Brian >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Adam Roach [mailto:adam@dynamicsoft.com] >>>>>>>>>> Sent: Thursday, March 11, 2004 12:27 AM >>>>>>>>>> To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org >>>>>>>>>> Subject: RE: [XCON] Open Issue: Hideable Participants >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [not as chair] >>>>>>>>>> >>>>>>>>>> I don't think anyone is currently arguing whether indication >>>>>>>>>> of such automata should be available to the users. Most >>>>>>>>>> of what I've heard people say on this list -- after Korea, >>>>>>>>>> at least -- seems to agree that such elements *should* >>>>>>>>>> be indicated in the protocol. Note that this is not the >>>>>>>>>> same thing as saying that they must be forcibly rendered >>>>>>>>>> to users regardless of the users want, which is what you >>>>>>>>>> seem to be arguing for. >>>>>>>>>> >>>>>>>>>> What I've heard -- and I agree with this viewpoint -- is >>>>>>>>>> that there should be some flag that indicates "this element >>>>>>>>>> is a facilitator, not a participant," so that users who don't >>>>>>>>>> *care* about seeing such elements (existence proof: me) >>>>>>>>>> could configure their clients not to display them. >>>>>>>>>> >>>>>>>>>> To expand on the flag's meaning, it would make the most >>>>>>>>>> sense to have it mean more precisely "this element is not >>>>>>>>>> truly a participant, but is providing some service related >>>>>>>>>> to the conference." In other words, I would want it to >>>>>>>>>> cover e.g. human transcribers, human translators, etc., >>>>>>>>>> in addition to automata. >>>>>>>>>> >>>>>>>>>> As Eric points out, I think people are getting hung up on >>>>>>>>>> the name without thinking the issue through completely. >>>>>>>>>> I've updated the subject line accordingly. >>>>>>>>>> >>>>>>>>>> /a >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>>>>>>>>> Sent: Wednesday, March 10, 2004 20:50 >>>>>>>>>>> To: Eric Burger; xcon@ietf.org >>>>>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I agree that automatons are processing resources >> and could be >>>>>>>>>>> considered as >>>>>>>>>>> logical parts of the conference fabric, for example an IVR >>>>>>>>>>> could monitor the >>>>>>>>>>> conference and provide a trigger in response to a phrase >>>>>>>>>> that could be >>>>>>>>>>> consumed elsewhere. Similarly a device that announces >>>>>>>>>>> participants, etc.. >>>>>>>>>>> However, IMHO a conference recorder does not fall into this >>>>>>>>>>> category and >>>>>>>>>>> should probably be a visible resource maybe with an >>>>>>>>>> indicator to show >>>>>>>>>>> whether it is or is not active. Similarly - a player >>>>>>>> resources which >>>>>>>>>>> delivers content or information to the conference >> should also >>>>>>>>>>> be visible - >>>>>>>>>>> it seems desirable to know where such content is >> coming from. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Eric Burger [mailto:eburger@snowshore.com] >>>>>>>>>>> Sent: Tuesday, March 09, 2004 1:28 PM >>>>>>>>>>> To: Kozdon, Peter; xcon@ietf.org >>>>>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>>>>>> >>>>>>>>>>> I think we got caught up on the name. >>>>>>>>>>> >>>>>>>>>>> There are two needs. >>>>>>>>>>> >>>>>>>>>>> The first, which I think we may have consensus on, is the >>>>>>>>>>> need for anonymous >>>>>>>>>>> participants. That is, participants that are present in the >>>>>>>>>>> conference, but >>>>>>>>>>> do not have their identities revealed. >>>>>>>>>>> >>>>>>>>>>> The second, which is more blurry, is the need for >>>>>>>>>>> participants that are >>>>>>>>>>> truly hidden. Some want to use hidden participants for >>>>>>>>>>> automatons, e.g., >>>>>>>>>>> IVR systems or conference recorders. (IMHO, bad idea, but >>>>>>>>>>> that is really >>>>>>>>>>> just MHO, not strictly black-and-white.) >>>>>>>>>>> >>>>>>>>>>> We do have consensus that Lawful Intercept is entirely >>>>>>>> orthogonal to >>>>>>>>>>> conference participants. However, the logic of the above >>>>>>>>>>> follows. Just as >>>>>>>>>>> IVR systems or conference recorders are not really >>>>>>>>>>> participants, neither is >>>>>>>>>>> LI hardware. If we say that the approach for IVR >> is to plumb >>>>>>>>>>> in as a hidden >>>>>>>>>>> participant, then LI would have the same approach. >> If we say >>>>>>>>>>> that IVR is >>>>>>>>>>> something different, e.g., just a part of the conference >>>>>>>>>>> mixer, then it is >>>>>>>>>>> truly "not there". Likewise, I would expect LI to be >>>>>>>> "not there" -- >>>>>>>>>>> something outside the XCON framework entirely. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>>>>>>>>>> Sent: Monday, March 08, 2004 6:28 PM >>>>>>>>>>>> To: 'xcon@ietf.org' >>>>>>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hidden listeners operation is probably illegal in many US >>>>>>>>>> states as >>>>>>>>>>>> well as in many countries - when you make a call there is a >>>>>>>>>>>> requirement in California the all parties are aware of the >>>>>>>>>>> presence of >>>>>>>>>>>> a 3rd party or recording device, note- that party may be >>>>>>>>>> anonymous, >>>>>>>>>>>> etc.. >>>>>>>>>>>> (Exception -- >>>>>>>>>>>> legal intercept.) >>>>>>>>>>>> >>>>>>>>>>>> We should follow the similar logic for XCON - provide an >>>>>>>>>>> indication of >>>>>>>>>>>> a recording device and/or anonymous participant's) >>>>>>>>>>>> >>>>>>>>>>>> Peter Kozdon >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On >>>>>>>>>> Behalf Of >>>>>>>>>>>> Adam Roach >>>>>>>>>>>> Sent: Monday, March 08, 2004 12:04 PM >>>>>>>>>>>> To: 'xcon@ietf.org' >>>>>>>>>>>> Subject: [XCON] Open Issue: Hidden Participants >>>>>>>>>>>> >>>>>>>>>>>> [as chair] >>>>>>>>>>>> >>>>>>>>>>>> At the XCON meeting, there was a rather lively >>>> discussion that >>>>>>>>>>>> continued the "Hidden Participants" discussion that had >>>>>>>>>>> started on the >>>>>>>>>>>> list. It was agreed that the topic was worth discussion, >>>>>>>>>>> but that we >>>>>>>>>>>> did not have enough time to pursue it in the meeting. >>>>>>>>>>>> >>>>>>>>>>>> I'm calling on everyone, especially those involved in >>>>>> the meeting >>>>>>>>>>>> discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to >>>>>>>>>> continue this >>>>>>>>>>>> discussion so we can close this issue in the near future. >>>>>>>>>>> Alan and I >>>>>>>>>>>> would like to be able to last-call this document shortly, >>>>>>>>>>> and this is >>>>>>>>>>>> the key issue that needs to be resolved before a new >>>>>>>>>>> revision of the >>>>>>>>>>>> draft can be produced. >>>>>>>>>>>> >>>>>>>>>>>> /a >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> XCON mailing list >>>>>>>>>>>> XCON@ietf.org >>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> XCON mailing list >>>>>>>>>>>> XCON@ietf.org >>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> XCON mailing list >>>>>>>>>>> XCON@ietf.org >>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> XCON mailing list >>>>>>>>>> XCON@ietf.org >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> XCON mailing list >>>>>>>>> XCON@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>> >>>>>> >>>> >> --Apple-Mail-6--195556393 Content-Type: text/enriched; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable OK, We had a semantic problem with the word "roster". Let me try once more using your sense of the word roster: 0000,0000,DDDDwe are trying to tell if your UI should show the donkey or not *from* the roster, and you clearly can=92t do that if some asses are interesting and others are = not. using the example of the human scribe, this is clearly impossible to decide why your UI shouldn't display the human scribe unless you define a new attribute, *or* define a gigantic explosion of roles, conditional roles, and subroles. thanks, -rohan On Mar 11, 2004, at 1:59 PM, Rosen, Brian wrote: Huh? I thought we already agreed, all participants go in the roster. We're talking about what information you supply about the participants so that an entity recieving the roster can do interesting things with=20 it; we observe that which participants are rendered, and how they are rendered, is a local decision, but that decision needs information. I'm mostly interested in things like icons representing services in the conference. While the caps identified might be useful, they aren't enough, and I don't want to solve the problem by inventing a bunch more caps. I'd go so far as to suggest that we remove the recorder mechanism, and just make it a role. -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Thursday, March 11, 2004 4:53 PM To: Rosen, Brian Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam Roach' Subject: Re: [XCON] Open Issue: Hideable Participants On Mar 11, 2004, at 1:36 PM, Rosen, Brian wrote: So, this is a discussion of "do you want the characteristics of a participant, or a description of it". Seems to me that since this is not a protocol mechanism, it's a UI issue, that you want a description and not a set of=20 characteristics. It's pretty easy to figure out what an IVR box does, but its pretty hard to figure out that it is an IVR box from a set of caps. Infer that it's a donkey from a description of the parts vs infer what parts are available knowing it's a donkey. if its really relevant to know that its a donkey, then use a=20 description/role/whatever. However, *STAYING ON TOPIC*, we=20 are trying=20 to tell if you should show the donkey or not in the roster, and you=20 clearly can't do that if some asses are interesting and=20 others are not. thx, -r Since I can always arrange a UI to display characteristics if I know what role, but can't go the other way, I think role is best. Brian -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Thursday, March 11, 2004 4:23 PM To: Rosen, Brian Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam Roach' Subject: Re: [XCON] Open Issue: Hideable Participants On Mar 11, 2004, at 12:53 PM, Rosen, Brian wrote: What attributes does an IVR box have besides automaton? How about a caption service? If we create a caps for each service, all orthogonal, is that you think makes sense? no, i'm not proposing a cap for each service. it is this "facilitator" attribute that all of these roles *share* that causes my UI to hide them in the roster. I don't want to have to update my UI=20 (which hid IVRs, announcers, human scribes, and recording services) so that I will hide the caption service you just added. if you feel you need to add roles for these services, go right ahead. I don't object to having names roles, but I want my UI to refer to attributes where I think attributes are appropriate. [The=20 mere fact that all these services I just listed have something in common which is orthogonal to all the other attributes we have should be a strong clue that this "facilitator" property should be an attribute.] thanks, -rohan These are all roles, they are not attributes. Brian -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Thursday, March 11, 2004 3:47 PM To: Rosen, Brian Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon,=20 Peter'; 'Adam Roach' Subject: Re: [XCON] Open Issue: Hideable Participants Hi, <I'd like to apologize to the group that some of these ideas are SIP-specific or very SIP influenced< Here are the binary or ternary attributes that already exist from draft-ietf-sip-callee-caps: automaton/human personal/business mobile/fixed duplex/send-only/receive-only these are 100% orthogonal with respect to each other Various folks have proposed that we need the following additional attributes in various parts of conferencing and/or signaling: interactive/noninteractive anonymous/identified (again, these are 100% orthogonal with respect to each other and the other attributes) finally I am proposing this new attribute we have been describing here. I believe this is still highly orthogonal to the other attributes. I believe this new attribute is more appropriate than an enumerations for two main reasons: 1) you can code behavior based on the presence of the attribute directly rather than checking for a bunch different=20 roles and then making sure there are not conditions attached to those roles. 2) it allows a new thing/role to exist which we haven't thought of yet that can still unambiguously provide its attributes. =20 existing code will work quite well with this new thing if it describes itself using (in part) a number of existing attributes. thanks, -rohan On Mar 11, 2004, at 11:29 AM, Rosen, Brian wrote: Rohan I'm not sure I agree. I clearly do want to provide information across the wire unambiguously, but I don't think a lot of binary attributes is a good way to do that. I think we are talking about a role, rather than an attribute. A single automaton, like a single human, is capable of multiple roles, so you need a list in both cases. Brian -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Thursday, March 11, 2004 2:24 PM To: Rosen, Brian Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam Roach' Subject: Re: [XCON] Open Issue: Hideable Participants Brian, There are many different orthogonal attributes we should be able to get access to. This "non-interesting" participant or "facilitator" attribute is orthogonal to your status as an automaton or human. I don't think an enumeration here is a good substitute for this attribute. It may be that indicating a recorder is a good value to add to the "actor" media feature tag, which currently has=20 a msg-taker value, or that we can reuse the msg-taker value for the recorder. The goal is maximum orthogonality. We probably can't achieve complete orthogonality but I think we can get very close. thanks, -rohan On Mar 11, 2004, at 6:14 AM, Rosen, Brian wrote: Seems to me that you are on the right track, but we need to go farther. We have to classify these participants so that the UI, if it wanted to, could render an appropriate indication. The example of the recorder is pretty compelling. Just knowing that there is an automaton out there is one thing. Knowing its a recorder is another. So, really you don't want a flag, you want an enunumeration. It may actually be a list, because a single automaton could have multiple functions. Brian -----Original Message----- From: Adam Roach [mailto:adam@dynamicsoft.com] Sent: Thursday, March 11, 2004 12:27 AM To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org Subject: RE: [XCON] Open Issue: Hideable Participants [not as chair] I don't think anyone is currently arguing whether indication of such automata should be available to the users. Most of what I've heard people say on this list -- after Korea, at least -- seems to agree that such elements *should* be indicated in the protocol. Note that this is not the same thing as saying that they must be forcibly rendered to users regardless of the users want, which is what you seem to be arguing for. What I've heard -- and I agree with this viewpoint -- is that there should be some flag that indicates "this element is a facilitator, not a participant," so that users who don't *care* about seeing such elements (existence proof: me) could configure their clients not to display them. To expand on the flag's meaning, it would make the most sense to have it mean more precisely "this element is not truly a participant, but is providing some service related to the conference." In other words, I would want it to cover e.g. human transcribers, human translators, etc., in addition to automata. As Eric points out, I think people are getting hung up on the name without thinking the issue through completely. I've updated the subject line accordingly. /a -----Original Message----- From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] Sent: Wednesday, March 10, 2004 20:50 To: Eric Burger; xcon@ietf.org Subject: RE: [XCON] Open Issue: Hidden Participants I agree that automatons are processing resources=20 = and could be = considered as logical parts of the conference fabric, for example an IVR could monitor the conference and provide a trigger in response to a phrase that could be consumed elsewhere. Similarly a device that announces participants, etc.. However, IMHO a conference recorder does not fall into this category and should probably be a visible resource maybe with an indicator to show whether it is or is not active. Similarly - a player resources which delivers content or information to the conference=20 = should also = be visible - it seems desirable to know where such content is=20 = coming from. = -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Tuesday, March 09, 2004 1:28 PM To: Kozdon, Peter; xcon@ietf.org Subject: RE: [XCON] Open Issue: Hidden Participants I think we got caught up on the name. There are two needs. The first, which I think we may have consensus on, is the need for anonymous participants. That is, participants that are present in the conference, but do not have their identities revealed. The second, which is more blurry, is the need for participants that are truly hidden. Some want to use hidden participants for automatons, e.g., IVR systems or conference recorders. (IMHO, bad idea, but that is really just MHO, not strictly black-and-white.) We do have consensus that Lawful Intercept is entirely orthogonal to conference participants. However, the logic of the above follows. Just as IVR systems or conference recorders are not really participants, neither is LI hardware. If we say that the approach for IVR=20 = is to plumb = in as a hidden participant, then LI would have the same approach. =20 = If we say = that IVR is something different, e.g., just a part of the conference mixer, then it is truly "not there". Likewise, I would expect LI to be "not there" -- something outside the XCON framework entirely. -----Original Message----- From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] Sent: Monday, March 08, 2004 6:28 PM To: 'xcon@ietf.org' Subject: RE: [XCON] Open Issue: Hidden Participants Hidden listeners operation is probably illegal in many US states as well as in many countries - when you make a call there is a requirement in California the all parties are aware of the presence of a 3rd party or recording device, note- that party may be anonymous, etc.. (Exception -- legal intercept.) We should follow the similar logic for XCON - provide an indication of a recording device and/or anonymous participant's) Peter Kozdon -----Original Message----- From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of Adam Roach Sent: Monday, March 08, 2004 12:04 PM To: 'xcon@ietf.org' Subject: [XCON] Open Issue: Hidden Participants [as chair] At the XCON meeting, there was a rather lively = discussion that = co= ntinued the "Hidden Participants" discussion that had started on the list. It was agreed that the topic was worth discussion, but that we did not have enough time to pursue it in the meeting. I'm calling on everyone, especially those involved in the meeting discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to continue this discussion so we can close this issue in the near future. Alan and I would like to be able to last-call this document shortly, and this is the key issue that needs to be resolved before a new revision of the draft can be produced. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon = --Apple-Mail-6--195556393-- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 11 19:53:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07712 for ; Thu, 11 Mar 2004 19:53:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1av9-0004Qf-W3 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 19:53:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C0r3YY017015 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 19:53:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1av9-0004Pq-3q for xcon-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 19:53: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 TAA07511 for ; Thu, 11 Mar 2004 19:53:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1av7-0004Gw-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:53:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1arC-00038l-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:49:02 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1aok-0002bR-04 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:46:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1abb-0005IN-NW for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:33:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1aax-0001cl-0V; Thu, 11 Mar 2004 19:32:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XYx-00032L-PL for xcon@optimus.ietf.org; Thu, 11 Mar 2004 16:17: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 QAA27122 for ; Thu, 11 Mar 2004 16:17:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1XYv-00062C-00 for xcon@ietf.org; Thu, 11 Mar 2004 16:17:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1XXH-0005dB-00 for xcon@ietf.org; Thu, 11 Mar 2004 16:16:14 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1B1XVm-00057d-00 for xcon@ietf.org; Thu, 11 Mar 2004 16:14:38 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 11 Mar 2004 13:12:04 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2BLE5U7027839; Thu, 11 Mar 2004 16:14:05 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGS33832; Thu, 11 Mar 2004 16:14:04 -0500 (EST) Message-ID: <4050D69C.10502@cisco.com> Date: Thu, 11 Mar 2004 16:14:04 -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: "Rosen, Brian" CC: "'Rohan Mahy'" , xcon@ietf.org, Eric Burger , "'Kozdon, Peter'" , "'Adam Roach'" Subject: Re: [XCON] Open Issue: Hideable Participants References: <313680C9A886D511A06000204840E1CF070B64E4@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Lets not get hung up on whether we call it a role or an attribute. Many of the callee-caps things can be considered to be roles. Regarding Rohan saying there is another new attribute - I don't know what that is. Are you talking about a "hideable" attribute? I don't think that makes much sense. It puts the responsibility on the focus to decide what should be hideable. I think it is better for clients to each decide what they do/don't want to see. I may want to hide automata and attendants except that I want to see recorders. You may just decide to hide automata. Regarding how to denote a recorder, I think the existing message-taker feature tag is probably close enough for the purpose. I think what we are talking about can be achieved by exposing the contact parameters from each participant in CPCP. Paul Rosen, Brian wrote: > What attributes does an IVR box have besides automaton? > How about a caption service? > > If we create a caps for each service, all orthogonal, is that > you think makes sense? > > These are all roles, they are not attributes. > > Brian > > >>-----Original Message----- >>From: Rohan Mahy [mailto:rohan@cisco.com] >>Sent: Thursday, March 11, 2004 3:47 PM >>To: Rosen, Brian >>Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam >>Roach' >>Subject: Re: [XCON] Open Issue: Hideable Participants >> >> >>Hi, >> >>I'd like to apologize to the group that some of >>these ideas >>are SIP-specific or very SIP influenced >> >>Here are the binary or ternary attributes that already exist from >>draft-ietf-sip-callee-caps: >> >>automaton/human >>personal/business >>mobile/fixed >>duplex/send-only/receive-only >> >>these are 100% orthogonal with respect to each other >> >>Various folks have proposed that we need the following additional >>attributes in various parts of conferencing and/or signaling: >> >>interactive/noninteractive >>anonymous/identified >> >>(again, these are 100% orthogonal with respect to each other and the >>other attributes) >> >>finally I am proposing this new attribute we have been >>describing here. >> I believe this is still highly orthogonal to the other attributes. >> >>I believe this new attribute is more appropriate than an enumerations >>for two main reasons: >> >>1) you can code behavior based on the presence of the attribute >>directly rather than checking for a bunch different roles and then >>making sure there are not conditions attached to those roles. >>2) it allows a new thing/role to exist which we haven't >>thought of yet >>that can still unambiguously provide its attributes. existing code >>will work quite well with this new thing if it describes itself using >>(in part) a number of existing attributes. >> >>thanks, >>-rohan >> >> >>On Mar 11, 2004, at 11:29 AM, Rosen, Brian wrote: >> >> >>>Rohan >>> >>>I'm not sure I agree. I clearly do want to provide >> >>information across >> >>>the wire unambiguously, but I don't think a lot of binary attributes >>>is a good way to do that. I think we are talking about a >> >>role, rather >> >>>than an attribute. A single automaton, like a single >> >>human, is capable >> >>>of multiple roles, so you need a list in both cases. >>> >>>Brian >>> >>> >>>>-----Original Message----- >>>>From: Rohan Mahy [mailto:rohan@cisco.com] >>>>Sent: Thursday, March 11, 2004 2:24 PM >>>>To: Rosen, Brian >>>>Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam >>>>Roach' >>>>Subject: Re: [XCON] Open Issue: Hideable Participants >>>> >>>> >>>>Brian, >>>> >>>>There are many different orthogonal attributes we should be >>>>able to get >>>>access to. This "non-interesting" participant or "facilitator" >>>>attribute is orthogonal to your status as an automaton or human. I >>>>don't think an enumeration here is a good substitute for this >>>>attribute. It may be that indicating a recorder is a good >>>>value to add >>>>to the "actor" media feature tag, which currently has a msg-taker >>>>value, or that we can reuse the msg-taker value for the >>>>recorder. The >>>>goal is maximum orthogonality. We probably can't achieve complete >>>>orthogonality but I think we can get very close. >>>> >>>>thanks, >>>>-rohan >>>> >>>> >>>>On Mar 11, 2004, at 6:14 AM, Rosen, Brian wrote: >>>> >>>> >>>>>Seems to me that you are on the right track, but we need to >>>> >>>>go farther. >>>> >>>>>We have to classify these participants so that the UI, if >>>> >>>>it wanted to, >>>> >>>>>could render an appropriate indication. The example of >>>> >>the recorder >> >>>>>is pretty compelling. Just knowing that there is an automaton out >>>>>there >>>>>is one thing. Knowing its a recorder is another. So, really you >>>>>don't want a flag, you want an enunumeration. It may actually be >>>>>a list, because a single automaton could have multiple functions. >>>>> >>>>>Brian >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Adam Roach [mailto:adam@dynamicsoft.com] >>>>>>Sent: Thursday, March 11, 2004 12:27 AM >>>>>>To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org >>>>>>Subject: RE: [XCON] Open Issue: Hideable Participants >>>>>> >>>>>> >>>>>>[not as chair] >>>>>> >>>>>>I don't think anyone is currently arguing whether indication >>>>>>of such automata should be available to the users. Most >>>>>>of what I've heard people say on this list -- after Korea, >>>>>>at least -- seems to agree that such elements *should* >>>>>>be indicated in the protocol. Note that this is not the >>>>>>same thing as saying that they must be forcibly rendered >>>>>>to users regardless of the users want, which is what you >>>>>>seem to be arguing for. >>>>>> >>>>>>What I've heard -- and I agree with this viewpoint -- is >>>>>>that there should be some flag that indicates "this element >>>>>>is a facilitator, not a participant," so that users who don't >>>>>>*care* about seeing such elements (existence proof: me) >>>>>>could configure their clients not to display them. >>>>>> >>>>>>To expand on the flag's meaning, it would make the most >>>>>>sense to have it mean more precisely "this element is not >>>>>>truly a participant, but is providing some service related >>>>>>to the conference." In other words, I would want it to >>>>>>cover e.g. human transcribers, human translators, etc., >>>>>>in addition to automata. >>>>>> >>>>>>As Eric points out, I think people are getting hung up on >>>>>>the name without thinking the issue through completely. >>>>>>I've updated the subject line accordingly. >>>>>> >>>>>>/a >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>>>>>Sent: Wednesday, March 10, 2004 20:50 >>>>>>>To: Eric Burger; xcon@ietf.org >>>>>>>Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>> >>>>>>> >>>>>>>I agree that automatons are processing resources and could be >>>>>>>considered as >>>>>>>logical parts of the conference fabric, for example an IVR >>>>>>>could monitor the >>>>>>>conference and provide a trigger in response to a phrase >>>>>> >>>>>>that could be >>>>>> >>>>>>>consumed elsewhere. Similarly a device that announces >>>>>>>participants, etc.. >>>>>>>However, IMHO a conference recorder does not fall into this >>>>>>>category and >>>>>>>should probably be a visible resource maybe with an >>>>>> >>>>>>indicator to show >>>>>> >>>>>>>whether it is or is not active. Similarly - a player >>>>>> >>>>resources which >>>> >>>>>>>delivers content or information to the conference should also >>>>>>>be visible - >>>>>>>it seems desirable to know where such content is coming from. >>>>>>> >>>>>>> >>>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Eric Burger [mailto:eburger@snowshore.com] >>>>>>>Sent: Tuesday, March 09, 2004 1:28 PM >>>>>>>To: Kozdon, Peter; xcon@ietf.org >>>>>>>Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>> >>>>>>>I think we got caught up on the name. >>>>>>> >>>>>>>There are two needs. >>>>>>> >>>>>>>The first, which I think we may have consensus on, is the >>>>>>>need for anonymous >>>>>>>participants. That is, participants that are present in the >>>>>>>conference, but >>>>>>>do not have their identities revealed. >>>>>>> >>>>>>>The second, which is more blurry, is the need for >>>>>>>participants that are >>>>>>>truly hidden. Some want to use hidden participants for >>>>>>>automatons, e.g., >>>>>>>IVR systems or conference recorders. (IMHO, bad idea, but >>>>>>>that is really >>>>>>>just MHO, not strictly black-and-white.) >>>>>>> >>>>>>>We do have consensus that Lawful Intercept is entirely >>>>>> >>>>orthogonal to >>>> >>>>>>>conference participants. However, the logic of the above >>>>>>>follows. Just as >>>>>>>IVR systems or conference recorders are not really >>>>>>>participants, neither is >>>>>>>LI hardware. If we say that the approach for IVR is to plumb >>>>>>>in as a hidden >>>>>>>participant, then LI would have the same approach. If we say >>>>>>>that IVR is >>>>>>>something different, e.g., just a part of the conference >>>>>>>mixer, then it is >>>>>>>truly "not there". Likewise, I would expect LI to be >>>>>> >>>>"not there" -- >>>> >>>>>>>something outside the XCON framework entirely. >>>>>>> >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>>>>>>Sent: Monday, March 08, 2004 6:28 PM >>>>>>>>To: 'xcon@ietf.org' >>>>>>>>Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>>> >>>>>>>> >>>>>>>>Hidden listeners operation is probably illegal in many US >>>>>>> >>>>>>states as >>>>>> >>>>>>>>well as in many countries - when you make a call there is a >>>>>>>>requirement in California the all parties are aware of the >>>>>>> >>>>>>>presence of >>>>>>> >>>>>>>>a 3rd party or recording device, note- that party may be >>>>>>> >>>>>>anonymous, >>>>>> >>>>>>>>etc.. >>>>>>>>(Exception -- >>>>>>>>legal intercept.) >>>>>>>> >>>>>>>>We should follow the similar logic for XCON - provide an >>>>>>> >>>>>>>indication of >>>>>>> >>>>>>>>a recording device and/or anonymous participant's) >>>>>>>> >>>>>>>>Peter Kozdon >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On >>>>>>> >>>>>>Behalf Of >>>>>> >>>>>>>>Adam Roach >>>>>>>>Sent: Monday, March 08, 2004 12:04 PM >>>>>>>>To: 'xcon@ietf.org' >>>>>>>>Subject: [XCON] Open Issue: Hidden Participants >>>>>>>> >>>>>>>>[as chair] >>>>>>>> >>>>>>>>At the XCON meeting, there was a rather lively discussion that >>>>>>>>continued the "Hidden Participants" discussion that had >>>>>>> >>>>>>>started on the >>>>>>> >>>>>>>>list. It was agreed that the topic was worth discussion, >>>>>>> >>>>>>>but that we >>>>>>> >>>>>>>>did not have enough time to pursue it in the meeting. >>>>>>>> >>>>>>>>I'm calling on everyone, especially those involved in >>>>>>> >>the meeting >> >>>>>>>>discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to >>>>>>> >>>>>>continue this >>>>>> >>>>>>>>discussion so we can close this issue in the near future. >>>>>>> >>>>>>>Alan and I >>>>>>> >>>>>>>>would like to be able to last-call this document shortly, >>>>>>> >>>>>>>and this is >>>>>>> >>>>>>>>the key issue that needs to be resolved before a new >>>>>>> >>>>>>>revision of the >>>>>>> >>>>>>>>draft can be produced. >>>>>>>> >>>>>>>>/a >>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>XCON mailing list >>>>>>>>XCON@ietf.org >>>>>>>>https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>XCON mailing list >>>>>>>>XCON@ietf.org >>>>>>>>https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>> >>>>>>>> >>>>>>> >>>>>>>_______________________________________________ >>>>>>>XCON mailing list >>>>>>>XCON@ietf.org >>>>>>>https://www1.ietf.org/mailman/listinfo/xcon >>>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>XCON mailing list >>>>>>XCON@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/xcon >>>>>> >>>>> >>>>>_______________________________________________ >>>>>XCON mailing list >>>>>XCON@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/xcon >>>> > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 11 19:54:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07998 for ; Thu, 11 Mar 2004 19:54:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1avn-0004aA-J9 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 19:53:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C0rhTN017608 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 19:53:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1avn-0004Zv-Dh for xcon-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 19:53: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 TAA07774 for ; Thu, 11 Mar 2004 19:53:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1avl-0004UO-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:53:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1as4-0003Ns-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:49:55 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1aoo-0002ax-02 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:46:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1ab2-0005IS-7e for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:32:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ab0-0001dp-Pg; Thu, 11 Mar 2004 19:32:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Xf0-0003AJ-6n for xcon@optimus.ietf.org; Thu, 11 Mar 2004 16:24: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 QAA27909 for ; Thu, 11 Mar 2004 16:24:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Xey-0007JP-00 for xcon@ietf.org; Thu, 11 Mar 2004 16:24:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Xe1-0007A1-00 for xcon@ietf.org; Thu, 11 Mar 2004 16:23:10 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B1XdN-0006yh-00 for xcon@ietf.org; Thu, 11 Mar 2004 16:22:29 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2BLLsM7026562; Thu, 11 Mar 2004 13:21:55 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARC31487; Thu, 11 Mar 2004 13:21:53 -0800 (PST) In-Reply-To: <313680C9A886D511A06000204840E1CF070B64E4@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B64E4@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <44D4F32D-73A2-11D8-8BC0-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: xcon@ietf.org, Eric Burger , Rohan Mahy , "'Kozdon, Peter'" , "'Adam Roach'" From: Rohan Mahy Subject: Re: [XCON] Open Issue: Hideable Participants Date: Thu, 11 Mar 2004 13:22:58 -0800 To: "Rosen, Brian" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mar 11, 2004, at 12:53 PM, Rosen, Brian wrote: > What attributes does an IVR box have besides automaton? > How about a caption service? > > If we create a caps for each service, all orthogonal, is that > you think makes sense? no, i'm not proposing a cap for each service. it is this "facilitator" attribute that all of these roles *share* that causes my UI to hide them in the roster. I don't want to have to update my UI (which hid IVRs, announcers, human scribes, and recording services) so that I will hide the caption service you just added. if you feel you need to add roles for these services, go right ahead. I don't object to having names roles, but I want my UI to refer to attributes where I think attributes are appropriate. [The mere fact that all these services I just listed have something in common which is orthogonal to all the other attributes we have should be a strong clue that this "facilitator" property should be an attribute.] thanks, -rohan > These are all roles, they are not attributes. > > Brian > >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan@cisco.com] >> Sent: Thursday, March 11, 2004 3:47 PM >> To: Rosen, Brian >> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam >> Roach' >> Subject: Re: [XCON] Open Issue: Hideable Participants >> >> >> Hi, >> >> I'd like to apologize to the group that some of >> these ideas >> are SIP-specific or very SIP influenced >> >> Here are the binary or ternary attributes that already exist from >> draft-ietf-sip-callee-caps: >> >> automaton/human >> personal/business >> mobile/fixed >> duplex/send-only/receive-only >> >> these are 100% orthogonal with respect to each other >> >> Various folks have proposed that we need the following additional >> attributes in various parts of conferencing and/or signaling: >> >> interactive/noninteractive >> anonymous/identified >> >> (again, these are 100% orthogonal with respect to each other and the >> other attributes) >> >> finally I am proposing this new attribute we have been >> describing here. >> I believe this is still highly orthogonal to the other attributes. >> >> I believe this new attribute is more appropriate than an enumerations >> for two main reasons: >> >> 1) you can code behavior based on the presence of the attribute >> directly rather than checking for a bunch different roles and then >> making sure there are not conditions attached to those roles. >> 2) it allows a new thing/role to exist which we haven't >> thought of yet >> that can still unambiguously provide its attributes. existing code >> will work quite well with this new thing if it describes itself using >> (in part) a number of existing attributes. >> >> thanks, >> -rohan >> >> >> On Mar 11, 2004, at 11:29 AM, Rosen, Brian wrote: >> >>> Rohan >>> >>> I'm not sure I agree. I clearly do want to provide >> information across >>> the wire unambiguously, but I don't think a lot of binary attributes >>> is a good way to do that. I think we are talking about a >> role, rather >>> than an attribute. A single automaton, like a single >> human, is capable >>> of multiple roles, so you need a list in both cases. >>> >>> Brian >>> >>>> -----Original Message----- >>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>> Sent: Thursday, March 11, 2004 2:24 PM >>>> To: Rosen, Brian >>>> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam >>>> Roach' >>>> Subject: Re: [XCON] Open Issue: Hideable Participants >>>> >>>> >>>> Brian, >>>> >>>> There are many different orthogonal attributes we should be >>>> able to get >>>> access to. This "non-interesting" participant or "facilitator" >>>> attribute is orthogonal to your status as an automaton or human. I >>>> don't think an enumeration here is a good substitute for this >>>> attribute. It may be that indicating a recorder is a good >>>> value to add >>>> to the "actor" media feature tag, which currently has a msg-taker >>>> value, or that we can reuse the msg-taker value for the >>>> recorder. The >>>> goal is maximum orthogonality. We probably can't achieve complete >>>> orthogonality but I think we can get very close. >>>> >>>> thanks, >>>> -rohan >>>> >>>> >>>> On Mar 11, 2004, at 6:14 AM, Rosen, Brian wrote: >>>> >>>>> Seems to me that you are on the right track, but we need to >>>> go farther. >>>>> We have to classify these participants so that the UI, if >>>> it wanted to, >>>>> could render an appropriate indication. The example of >> the recorder >>>>> is pretty compelling. Just knowing that there is an automaton out >>>>> there >>>>> is one thing. Knowing its a recorder is another. So, really you >>>>> don't want a flag, you want an enunumeration. It may actually be >>>>> a list, because a single automaton could have multiple functions. >>>>> >>>>> Brian >>>>> >>>>>> -----Original Message----- >>>>>> From: Adam Roach [mailto:adam@dynamicsoft.com] >>>>>> Sent: Thursday, March 11, 2004 12:27 AM >>>>>> To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org >>>>>> Subject: RE: [XCON] Open Issue: Hideable Participants >>>>>> >>>>>> >>>>>> [not as chair] >>>>>> >>>>>> I don't think anyone is currently arguing whether indication >>>>>> of such automata should be available to the users. Most >>>>>> of what I've heard people say on this list -- after Korea, >>>>>> at least -- seems to agree that such elements *should* >>>>>> be indicated in the protocol. Note that this is not the >>>>>> same thing as saying that they must be forcibly rendered >>>>>> to users regardless of the users want, which is what you >>>>>> seem to be arguing for. >>>>>> >>>>>> What I've heard -- and I agree with this viewpoint -- is >>>>>> that there should be some flag that indicates "this element >>>>>> is a facilitator, not a participant," so that users who don't >>>>>> *care* about seeing such elements (existence proof: me) >>>>>> could configure their clients not to display them. >>>>>> >>>>>> To expand on the flag's meaning, it would make the most >>>>>> sense to have it mean more precisely "this element is not >>>>>> truly a participant, but is providing some service related >>>>>> to the conference." In other words, I would want it to >>>>>> cover e.g. human transcribers, human translators, etc., >>>>>> in addition to automata. >>>>>> >>>>>> As Eric points out, I think people are getting hung up on >>>>>> the name without thinking the issue through completely. >>>>>> I've updated the subject line accordingly. >>>>>> >>>>>> /a >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>>>>> Sent: Wednesday, March 10, 2004 20:50 >>>>>>> To: Eric Burger; xcon@ietf.org >>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>> >>>>>>> >>>>>>> I agree that automatons are processing resources and could be >>>>>>> considered as >>>>>>> logical parts of the conference fabric, for example an IVR >>>>>>> could monitor the >>>>>>> conference and provide a trigger in response to a phrase >>>>>> that could be >>>>>>> consumed elsewhere. Similarly a device that announces >>>>>>> participants, etc.. >>>>>>> However, IMHO a conference recorder does not fall into this >>>>>>> category and >>>>>>> should probably be a visible resource maybe with an >>>>>> indicator to show >>>>>>> whether it is or is not active. Similarly - a player >>>> resources which >>>>>>> delivers content or information to the conference should also >>>>>>> be visible - >>>>>>> it seems desirable to know where such content is coming from. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Eric Burger [mailto:eburger@snowshore.com] >>>>>>> Sent: Tuesday, March 09, 2004 1:28 PM >>>>>>> To: Kozdon, Peter; xcon@ietf.org >>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>> >>>>>>> I think we got caught up on the name. >>>>>>> >>>>>>> There are two needs. >>>>>>> >>>>>>> The first, which I think we may have consensus on, is the >>>>>>> need for anonymous >>>>>>> participants. That is, participants that are present in the >>>>>>> conference, but >>>>>>> do not have their identities revealed. >>>>>>> >>>>>>> The second, which is more blurry, is the need for >>>>>>> participants that are >>>>>>> truly hidden. Some want to use hidden participants for >>>>>>> automatons, e.g., >>>>>>> IVR systems or conference recorders. (IMHO, bad idea, but >>>>>>> that is really >>>>>>> just MHO, not strictly black-and-white.) >>>>>>> >>>>>>> We do have consensus that Lawful Intercept is entirely >>>> orthogonal to >>>>>>> conference participants. However, the logic of the above >>>>>>> follows. Just as >>>>>>> IVR systems or conference recorders are not really >>>>>>> participants, neither is >>>>>>> LI hardware. If we say that the approach for IVR is to plumb >>>>>>> in as a hidden >>>>>>> participant, then LI would have the same approach. If we say >>>>>>> that IVR is >>>>>>> something different, e.g., just a part of the conference >>>>>>> mixer, then it is >>>>>>> truly "not there". Likewise, I would expect LI to be >>>> "not there" -- >>>>>>> something outside the XCON framework entirely. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>>>>>> Sent: Monday, March 08, 2004 6:28 PM >>>>>>>> To: 'xcon@ietf.org' >>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>>> >>>>>>>> >>>>>>>> Hidden listeners operation is probably illegal in many US >>>>>> states as >>>>>>>> well as in many countries - when you make a call there is a >>>>>>>> requirement in California the all parties are aware of the >>>>>>> presence of >>>>>>>> a 3rd party or recording device, note- that party may be >>>>>> anonymous, >>>>>>>> etc.. >>>>>>>> (Exception -- >>>>>>>> legal intercept.) >>>>>>>> >>>>>>>> We should follow the similar logic for XCON - provide an >>>>>>> indication of >>>>>>>> a recording device and/or anonymous participant's) >>>>>>>> >>>>>>>> Peter Kozdon >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On >>>>>> Behalf Of >>>>>>>> Adam Roach >>>>>>>> Sent: Monday, March 08, 2004 12:04 PM >>>>>>>> To: 'xcon@ietf.org' >>>>>>>> Subject: [XCON] Open Issue: Hidden Participants >>>>>>>> >>>>>>>> [as chair] >>>>>>>> >>>>>>>> At the XCON meeting, there was a rather lively discussion that >>>>>>>> continued the "Hidden Participants" discussion that had >>>>>>> started on the >>>>>>>> list. It was agreed that the topic was worth discussion, >>>>>>> but that we >>>>>>>> did not have enough time to pursue it in the meeting. >>>>>>>> >>>>>>>> I'm calling on everyone, especially those involved in >> the meeting >>>>>>>> discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to >>>>>> continue this >>>>>>>> discussion so we can close this issue in the near future. >>>>>>> Alan and I >>>>>>>> would like to be able to last-call this document shortly, >>>>>>> and this is >>>>>>>> the key issue that needs to be resolved before a new >>>>>>> revision of the >>>>>>>> draft can be produced. >>>>>>>> >>>>>>>> /a >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> XCON mailing list >>>>>>>> XCON@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> XCON mailing list >>>>>>>> XCON@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> XCON mailing list >>>>>>> XCON@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> XCON mailing list >>>>>> XCON@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>> >>>>> >>>>> _______________________________________________ >>>>> XCON mailing list >>>>> XCON@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>> >> _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 11 19:54:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08031 for ; Thu, 11 Mar 2004 19:54:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1avq-0004as-8B for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 19:53:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C0rk1R017652 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 19:53:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1avq-0004ab-2b for xcon-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 19:53:46 -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 TAA07785 for ; Thu, 11 Mar 2004 19:53:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1avo-0004V0-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:53:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1as7-0003Ot-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:49:59 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1aoo-0002bR-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:46:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1ab8-0005Ih-Fp for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:32:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ab4-0001fV-Ap; Thu, 11 Mar 2004 19:32:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XtG-00042o-8t for xcon@optimus.ietf.org; Thu, 11 Mar 2004 16:38: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 QAA28717 for ; Thu, 11 Mar 2004 16:38:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1XtE-0001MJ-00 for xcon@ietf.org; Thu, 11 Mar 2004 16:38:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1XsN-0001FN-00 for xcon@ietf.org; Thu, 11 Mar 2004 16:38:00 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1B1XrZ-0000zk-00 for xcon@ietf.org; Thu, 11 Mar 2004 16:37:14 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i2BLaIaZ024240; Thu, 11 Mar 2004 16:36:18 -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 QAA14413; Thu, 11 Mar 2004 16:36:18 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Mar 2004 16:36:18 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B64E6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Rohan Mahy'" Cc: xcon@ietf.org, Eric Burger , "'Kozdon, Peter'" , "'Adam Roach'" Subject: RE: [XCON] Open Issue: Hideable Participants Date: Thu, 11 Mar 2004 16:36:17 -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.1 required=5.0 tests=AWL autolearn=no version=2.60 So, this is a discussion of "do you want the characteristics of a participant, or a description of it". Seems to me that since this is not a protocol mechanism, it's a UI issue, that you want a description and not a set of characteristics. It's pretty easy to figure out what an IVR box does, but its pretty hard to figure out that it is an IVR box from a set of caps. Infer that it's a donkey from a description of the parts vs infer what parts are available knowing it's a donkey. Since I can always arrange a UI to display characteristics if I know what role, but can't go the other way, I think role is best. Brian > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Thursday, March 11, 2004 4:23 PM > To: Rosen, Brian > Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam > Roach' > Subject: Re: [XCON] Open Issue: Hideable Participants > > > > On Mar 11, 2004, at 12:53 PM, Rosen, Brian wrote: > > What attributes does an IVR box have besides automaton? > > How about a caption service? > > > > If we create a caps for each service, all orthogonal, is that > > you think makes sense? > > no, i'm not proposing a cap for each service. it is this > "facilitator" > attribute that all of these roles *share* that causes my UI to hide > them in the roster. I don't want to have to update my UI (which hid > IVRs, announcers, human scribes, and recording services) so > that I will > hide the caption service you just added. > > if you feel you need to add roles for these services, go > right ahead. > I don't object to having names roles, but I want my UI to refer to > attributes where I think attributes are appropriate. [The mere fact > that all these services I just listed have something in > common which is > orthogonal to all the other attributes we have should be a > strong clue > that this "facilitator" property should be an attribute.] > > thanks, > -rohan > > > These are all roles, they are not attributes. > > > > Brian > > > >> -----Original Message----- > >> From: Rohan Mahy [mailto:rohan@cisco.com] > >> Sent: Thursday, March 11, 2004 3:47 PM > >> To: Rosen, Brian > >> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam > >> Roach' > >> Subject: Re: [XCON] Open Issue: Hideable Participants > >> > >> > >> Hi, > >> > >> I'd like to apologize to the group that some of > >> these ideas > >> are SIP-specific or very SIP influenced > >> > >> Here are the binary or ternary attributes that already exist from > >> draft-ietf-sip-callee-caps: > >> > >> automaton/human > >> personal/business > >> mobile/fixed > >> duplex/send-only/receive-only > >> > >> these are 100% orthogonal with respect to each other > >> > >> Various folks have proposed that we need the following additional > >> attributes in various parts of conferencing and/or signaling: > >> > >> interactive/noninteractive > >> anonymous/identified > >> > >> (again, these are 100% orthogonal with respect to each > other and the > >> other attributes) > >> > >> finally I am proposing this new attribute we have been > >> describing here. > >> I believe this is still highly orthogonal to the other > attributes. > >> > >> I believe this new attribute is more appropriate than an > enumerations > >> for two main reasons: > >> > >> 1) you can code behavior based on the presence of the attribute > >> directly rather than checking for a bunch different roles and then > >> making sure there are not conditions attached to those roles. > >> 2) it allows a new thing/role to exist which we haven't > >> thought of yet > >> that can still unambiguously provide its attributes. existing code > >> will work quite well with this new thing if it describes > itself using > >> (in part) a number of existing attributes. > >> > >> thanks, > >> -rohan > >> > >> > >> On Mar 11, 2004, at 11:29 AM, Rosen, Brian wrote: > >> > >>> Rohan > >>> > >>> I'm not sure I agree. I clearly do want to provide > >> information across > >>> the wire unambiguously, but I don't think a lot of binary > attributes > >>> is a good way to do that. I think we are talking about a > >> role, rather > >>> than an attribute. A single automaton, like a single > >> human, is capable > >>> of multiple roles, so you need a list in both cases. > >>> > >>> Brian > >>> > >>>> -----Original Message----- > >>>> From: Rohan Mahy [mailto:rohan@cisco.com] > >>>> Sent: Thursday, March 11, 2004 2:24 PM > >>>> To: Rosen, Brian > >>>> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, > Peter'; 'Adam > >>>> Roach' > >>>> Subject: Re: [XCON] Open Issue: Hideable Participants > >>>> > >>>> > >>>> Brian, > >>>> > >>>> There are many different orthogonal attributes we should be > >>>> able to get > >>>> access to. This "non-interesting" participant or "facilitator" > >>>> attribute is orthogonal to your status as an automaton > or human. I > >>>> don't think an enumeration here is a good substitute for this > >>>> attribute. It may be that indicating a recorder is a good > >>>> value to add > >>>> to the "actor" media feature tag, which currently has a msg-taker > >>>> value, or that we can reuse the msg-taker value for the > >>>> recorder. The > >>>> goal is maximum orthogonality. We probably can't > achieve complete > >>>> orthogonality but I think we can get very close. > >>>> > >>>> thanks, > >>>> -rohan > >>>> > >>>> > >>>> On Mar 11, 2004, at 6:14 AM, Rosen, Brian wrote: > >>>> > >>>>> Seems to me that you are on the right track, but we need to > >>>> go farther. > >>>>> We have to classify these participants so that the UI, if > >>>> it wanted to, > >>>>> could render an appropriate indication. The example of > >> the recorder > >>>>> is pretty compelling. Just knowing that there is an > automaton out > >>>>> there > >>>>> is one thing. Knowing its a recorder is another. So, > really you > >>>>> don't want a flag, you want an enunumeration. It may > actually be > >>>>> a list, because a single automaton could have multiple > functions. > >>>>> > >>>>> Brian > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Adam Roach [mailto:adam@dynamicsoft.com] > >>>>>> Sent: Thursday, March 11, 2004 12:27 AM > >>>>>> To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org > >>>>>> Subject: RE: [XCON] Open Issue: Hideable Participants > >>>>>> > >>>>>> > >>>>>> [not as chair] > >>>>>> > >>>>>> I don't think anyone is currently arguing whether indication > >>>>>> of such automata should be available to the users. Most > >>>>>> of what I've heard people say on this list -- after Korea, > >>>>>> at least -- seems to agree that such elements *should* > >>>>>> be indicated in the protocol. Note that this is not the > >>>>>> same thing as saying that they must be forcibly rendered > >>>>>> to users regardless of the users want, which is what you > >>>>>> seem to be arguing for. > >>>>>> > >>>>>> What I've heard -- and I agree with this viewpoint -- is > >>>>>> that there should be some flag that indicates "this element > >>>>>> is a facilitator, not a participant," so that users who don't > >>>>>> *care* about seeing such elements (existence proof: me) > >>>>>> could configure their clients not to display them. > >>>>>> > >>>>>> To expand on the flag's meaning, it would make the most > >>>>>> sense to have it mean more precisely "this element is not > >>>>>> truly a participant, but is providing some service related > >>>>>> to the conference." In other words, I would want it to > >>>>>> cover e.g. human transcribers, human translators, etc., > >>>>>> in addition to automata. > >>>>>> > >>>>>> As Eric points out, I think people are getting hung up on > >>>>>> the name without thinking the issue through completely. > >>>>>> I've updated the subject line accordingly. > >>>>>> > >>>>>> /a > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > >>>>>>> Sent: Wednesday, March 10, 2004 20:50 > >>>>>>> To: Eric Burger; xcon@ietf.org > >>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants > >>>>>>> > >>>>>>> > >>>>>>> I agree that automatons are processing resources and could be > >>>>>>> considered as > >>>>>>> logical parts of the conference fabric, for example an IVR > >>>>>>> could monitor the > >>>>>>> conference and provide a trigger in response to a phrase > >>>>>> that could be > >>>>>>> consumed elsewhere. Similarly a device that announces > >>>>>>> participants, etc.. > >>>>>>> However, IMHO a conference recorder does not fall into this > >>>>>>> category and > >>>>>>> should probably be a visible resource maybe with an > >>>>>> indicator to show > >>>>>>> whether it is or is not active. Similarly - a player > >>>> resources which > >>>>>>> delivers content or information to the conference should also > >>>>>>> be visible - > >>>>>>> it seems desirable to know where such content is coming from. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Eric Burger [mailto:eburger@snowshore.com] > >>>>>>> Sent: Tuesday, March 09, 2004 1:28 PM > >>>>>>> To: Kozdon, Peter; xcon@ietf.org > >>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants > >>>>>>> > >>>>>>> I think we got caught up on the name. > >>>>>>> > >>>>>>> There are two needs. > >>>>>>> > >>>>>>> The first, which I think we may have consensus on, is the > >>>>>>> need for anonymous > >>>>>>> participants. That is, participants that are present in the > >>>>>>> conference, but > >>>>>>> do not have their identities revealed. > >>>>>>> > >>>>>>> The second, which is more blurry, is the need for > >>>>>>> participants that are > >>>>>>> truly hidden. Some want to use hidden participants for > >>>>>>> automatons, e.g., > >>>>>>> IVR systems or conference recorders. (IMHO, bad idea, but > >>>>>>> that is really > >>>>>>> just MHO, not strictly black-and-white.) > >>>>>>> > >>>>>>> We do have consensus that Lawful Intercept is entirely > >>>> orthogonal to > >>>>>>> conference participants. However, the logic of the above > >>>>>>> follows. Just as > >>>>>>> IVR systems or conference recorders are not really > >>>>>>> participants, neither is > >>>>>>> LI hardware. If we say that the approach for IVR is to plumb > >>>>>>> in as a hidden > >>>>>>> participant, then LI would have the same approach. If we say > >>>>>>> that IVR is > >>>>>>> something different, e.g., just a part of the conference > >>>>>>> mixer, then it is > >>>>>>> truly "not there". Likewise, I would expect LI to be > >>>> "not there" -- > >>>>>>> something outside the XCON framework entirely. > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > >>>>>>>> Sent: Monday, March 08, 2004 6:28 PM > >>>>>>>> To: 'xcon@ietf.org' > >>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants > >>>>>>>> > >>>>>>>> > >>>>>>>> Hidden listeners operation is probably illegal in many US > >>>>>> states as > >>>>>>>> well as in many countries - when you make a call there is a > >>>>>>>> requirement in California the all parties are aware of the > >>>>>>> presence of > >>>>>>>> a 3rd party or recording device, note- that party may be > >>>>>> anonymous, > >>>>>>>> etc.. > >>>>>>>> (Exception -- > >>>>>>>> legal intercept.) > >>>>>>>> > >>>>>>>> We should follow the similar logic for XCON - provide an > >>>>>>> indication of > >>>>>>>> a recording device and/or anonymous participant's) > >>>>>>>> > >>>>>>>> Peter Kozdon > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On > >>>>>> Behalf Of > >>>>>>>> Adam Roach > >>>>>>>> Sent: Monday, March 08, 2004 12:04 PM > >>>>>>>> To: 'xcon@ietf.org' > >>>>>>>> Subject: [XCON] Open Issue: Hidden Participants > >>>>>>>> > >>>>>>>> [as chair] > >>>>>>>> > >>>>>>>> At the XCON meeting, there was a rather lively > discussion that > >>>>>>>> continued the "Hidden Participants" discussion that had > >>>>>>> started on the > >>>>>>>> list. It was agreed that the topic was worth discussion, > >>>>>>> but that we > >>>>>>>> did not have enough time to pursue it in the meeting. > >>>>>>>> > >>>>>>>> I'm calling on everyone, especially those involved in > >> the meeting > >>>>>>>> discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to > >>>>>> continue this > >>>>>>>> discussion so we can close this issue in the near future. > >>>>>>> Alan and I > >>>>>>>> would like to be able to last-call this document shortly, > >>>>>>> and this is > >>>>>>>> the key issue that needs to be resolved before a new > >>>>>>> revision of the > >>>>>>>> draft can be produced. > >>>>>>>> > >>>>>>>> /a > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> XCON mailing list > >>>>>>>> XCON@ietf.org > >>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> XCON mailing list > >>>>>>>> XCON@ietf.org > >>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> XCON mailing list > >>>>>>> XCON@ietf.org > >>>>>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> XCON mailing list > >>>>>> XCON@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> XCON mailing list > >>>>> XCON@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/xcon > >>>> > >> > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 11 19:55:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08238 for ; Thu, 11 Mar 2004 19:55:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1awf-0004nj-09 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 19:54:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C0sa3X018449 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 19:54:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1awe-0004nU-Qi for xcon-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 19:54: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 TAA08141 for ; Thu, 11 Mar 2004 19:54:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1awd-0004og-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:54:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1atV-0003mb-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:51:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1apK-0002iU-0E for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 19:47:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1abX-0001xH-2M; Thu, 11 Mar 2004 19:32:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1YtU-0007ZX-Ju for xcon@optimus.ietf.org; Thu, 11 Mar 2004 17:43: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 RAA01121 for ; Thu, 11 Mar 2004 17:43:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1YtS-00020J-00 for xcon@ietf.org; Thu, 11 Mar 2004 17:43:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Ysn-0001rS-00 for xcon@ietf.org; Thu, 11 Mar 2004 17:42:29 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B1Ys6-0001dn-00 for xcon@ietf.org; Thu, 11 Mar 2004 17:41:46 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2BMfEK2025495; Thu, 11 Mar 2004 14:41:14 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARC39237; Thu, 11 Mar 2004 14:41:12 -0800 (PST) In-Reply-To: <313680C9A886D511A06000204840E1CF070B64E4@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B64E4@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <59674866-73AD-11D8-8BC0-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: xcon@ietf.org, Eric Burger , Rohan Mahy , "'Kozdon, Peter'" , "'Adam Roach'" From: Rohan Mahy Subject: Re: [XCON] Open Issue: Hideable Participants Date: Thu, 11 Mar 2004 14:42:17 -0800 To: "Rosen, Brian" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I was so busy trying to get back to the original purpose of this thread that forgot to answer Brian question directly. On Mar 11, 2004, at 12:53 PM, Rosen, Brian wrote: > What attributes does an IVR box have besides automaton? business (typically) fixed (typically) automaton interactive full duplex its supported media (audio, video, text) > How about a caption service? this is really 2 participants. the listener/watcher and the captions themselves. note that a caption service probably does not assume a class (biz/personal). listener: automaton (sometimes, more typically a human) fixed (almost certainly) non-interactive receive-only audio and/or video captioner: automaton (sometimes, more typically a human) fixed (almost certainly) non-interactive send-only text thanks, -rohan _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 11 20:02:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08594 for ; Thu, 11 Mar 2004 20:02:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1b3p-0005FR-6U for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 20:02:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C121O9020169 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 20:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1b3o-0005FE-TO for xcon-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 20:02:00 -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 UAA08576 for ; Thu, 11 Mar 2004 20:01:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1b3n-00069o-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 20:01:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1b2p-00060Y-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 20:01:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1b1w-0005rY-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 20:00:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1b1x-00057e-2Q; Thu, 11 Mar 2004 20:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1b14-00054k-Tp for xcon@optimus.ietf.org; Thu, 11 Mar 2004 19:59: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 TAA08476 for ; Thu, 11 Mar 2004 19:59:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1b13-0005jA-00 for xcon@ietf.org; Thu, 11 Mar 2004 19:59:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1b05-0005ZN-00 for xcon@ietf.org; Thu, 11 Mar 2004 19:58:11 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B1az3-0005GS-00 for xcon@ietf.org; Thu, 11 Mar 2004 19:57:06 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2C0uSM7015778; Thu, 11 Mar 2004 16:56:28 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARC51593; Thu, 11 Mar 2004 16:56:27 -0800 (PST) In-Reply-To: <313680C9A886D511A06000204840E1CF070B64EB@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B64EB@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <3E46F027-73C0-11D8-8BC0-0003938AF740@cisco.com> Content-Transfer-Encoding: quoted-printable Cc: xcon@ietf.org, Eric Burger , Rohan Mahy , "'Kozdon, Peter'" , "'Adam Roach'" From: Rohan Mahy Subject: Re: [XCON] Open Issue: Hideable Participants Date: Thu, 11 Mar 2004 16:57:32 -0800 To: "Rosen, Brian" X-Mailer: Apple Mail (2.612) 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On Mar 11, 2004, at 2:26 PM, Rosen, Brian wrote: > Somehow, you think there are fewer attributes than roles. > I think there are fewer roles than attributes. > Reiterating - i think its easier to infer attributes knowing roles > than it is to infer roles knowing attributes. I don't > see much utility in delivering both. > > The fact that it's an ass is the important part; i don't think that we > can provide information figure out which ones are interesting and > which ones are not. You need to demonstrate this assertion then. What would you do with=20 the knowledge of a role. I already showed how based on the "hide-able"=20= attribute I can do something useful for a variety of roles. The burden=20= of proof is on you to show how I can do anything useful with roles=20 without needed an explosion of them. thanks, -rohan > Brian > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Thursday, March 11, 2004 5:16 PM > To: Rosen, Brian > Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam=20 > Roach' > Subject: Re: [XCON] Open Issue: Hideable Participants > > > OK, > > > We had a semantic problem with the word "roster". Let me try once more=20= > using > your sense of the word roster: > > > we are trying to tell if your UI should show the donkey or not *from*=20= > the > roster, and you > clearly can=92t do that if some asses are interesting and others are = not. > > > using the example of the human scribe, this is clearly impossible to=20= > decide > why your UI shouldn't display the human scribe unless you define a new > attribute, *or* define a gigantic explosion of roles, conditional=20 > roles, and > subroles. > > > thanks, > -rohan > > > > On Mar 11, 2004, at 1:59 PM, Rosen, Brian wrote: > > > Huh? I thought we already agreed, all participants go in the roster. > We're talking about what information you supply about the participants > so that an entity recieving the roster can do interesting things with > it; we observe that which participants are rendered, and how they > are rendered, is a local decision, but that decision needs = information. > I'm mostly interested in things like icons representing services in = the > conference. While the caps identified might be useful, they aren't > enough, and I don't want to solve the problem by inventing a bunch = more > caps. I'd go so far as to suggest that we remove the recorder=20 > mechanism, > and just make it a role. > > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Thursday, March 11, 2004 4:53 PM > To: Rosen, Brian > Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam > Roach' > Subject: Re: [XCON] Open Issue: Hideable Participants > > > > > On Mar 11, 2004, at 1:36 PM, Rosen, Brian wrote: > > > So, this is a discussion of "do you want the characteristics of > a participant, or a description of it". > > > Seems to me that since this is not a protocol mechanism, it's a > UI issue, that you want a description and not a set of > characteristics. > It's pretty easy to figure out what an IVR box does, but its pretty > hard to figure out that it is an IVR box from a set of caps. > Infer that it's a donkey from a description of the parts > vs infer what parts are available knowing it's a donkey. > > > if its really relevant to know that its a donkey, then use a > description/role/whatever. However, *STAYING ON TOPIC*, we > are trying > to tell if you should show the donkey or not in the roster, and you > clearly can't do that if some asses are interesting and > others are not. > > > thx, > -r > > > Since I can always arrange a UI to display characteristics if > I know what role, but can't go the other way, I think role is > best. > > > Brian > > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Thursday, March 11, 2004 4:23 PM > To: Rosen, Brian > Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam > Roach' > Subject: Re: [XCON] Open Issue: Hideable Participants > > > > > On Mar 11, 2004, at 12:53 PM, Rosen, Brian wrote: > What attributes does an IVR box have besides automaton? > How about a caption service? > > > If we create a caps for each service, all orthogonal, is that > you think makes sense? > > > no, i'm not proposing a cap for each service. it is this > "facilitator" > attribute that all of these roles *share* that causes my UI to hide > them in the roster. I don't want to have to update my UI > (which hid > IVRs, announcers, human scribes, and recording services) so > that I will > hide the caption service you just added. > > > if you feel you need to add roles for these services, go > right ahead. > I don't object to having names roles, but I want my UI to refer to > attributes where I think attributes are appropriate. [The > mere fact > that all these services I just listed have something in > common which is > orthogonal to all the other attributes we have should be a > strong clue > that this "facilitator" property should be an attribute.] > > > thanks, > -rohan > > > These are all roles, they are not attributes. > > > Brian > > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Thursday, March 11, 2004 3:47 PM > To: Rosen, Brian > Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, > Peter'; 'Adam > Roach' > Subject: Re: [XCON] Open Issue: Hideable Participants > > > > Hi, > > > I'd like to apologize to the group that some of > these ideas > are SIP-specific or very SIP influenced > > > Here are the binary or ternary attributes that already exist from > draft-ietf-sip-callee-caps: > > > automaton/human > personal/business > mobile/fixed > duplex/send-only/receive-only > > > these are 100% orthogonal with respect to each other > > > Various folks have proposed that we need the following additional > attributes in various parts of conferencing and/or signaling: > > > interactive/noninteractive > anonymous/identified > > > (again, these are 100% orthogonal with respect to each > other and the > other attributes) > > > finally I am proposing this new attribute we have been > describing here. > I believe this is still highly orthogonal to the other > attributes. > > > I believe this new attribute is more appropriate than an > enumerations > for two main reasons: > > > 1) you can code behavior based on the presence of the attribute > directly rather than checking for a bunch different > roles and then > making sure there are not conditions attached to those roles. > 2) it allows a new thing/role to exist which we haven't > thought of yet > that can still unambiguously provide its attributes. > existing code > will work quite well with this new thing if it describes > itself using > (in part) a number of existing attributes. > > > thanks, > -rohan > > > > On Mar 11, 2004, at 11:29 AM, Rosen, Brian wrote: > > > Rohan > > > I'm not sure I agree. I clearly do want to provide > information across > the wire unambiguously, but I don't think a lot of binary > attributes > is a good way to do that. I think we are talking about a > role, rather > than an attribute. A single automaton, like a single > human, is capable > of multiple roles, so you need a list in both cases. > > > Brian > > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Thursday, March 11, 2004 2:24 PM > To: Rosen, Brian > Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, > Peter'; 'Adam > Roach' > Subject: Re: [XCON] Open Issue: Hideable Participants > > > > Brian, > > > There are many different orthogonal attributes we should be > able to get > access to. This "non-interesting" participant or "facilitator" > attribute is orthogonal to your status as an automaton > or human. I > don't think an enumeration here is a good substitute for this > attribute. It may be that indicating a recorder is a good > value to add > to the "actor" media feature tag, which currently has > a msg-taker > value, or that we can reuse the msg-taker value for the > recorder. The > goal is maximum orthogonality. We probably can't > achieve complete > orthogonality but I think we can get very close. > > > thanks, > -rohan > > > > On Mar 11, 2004, at 6:14 AM, Rosen, Brian wrote: > > > Seems to me that you are on the right track, but we need to > go farther. > We have to classify these participants so that the UI, if > it wanted to, > could render an appropriate indication. The example of > the recorder > is pretty compelling. Just knowing that there is an > automaton out > there > is one thing. Knowing its a recorder is another. So, > really you > don't want a flag, you want an enunumeration. It may > actually be > a list, because a single automaton could have multiple > functions. > > > Brian > > > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Thursday, March 11, 2004 12:27 AM > To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org > Subject: RE: [XCON] Open Issue: Hideable Participants > > > > [not as chair] > > > I don't think anyone is currently arguing whether indication > of such automata should be available to the users. Most > of what I've heard people say on this list -- after Korea, > at least -- seems to agree that such elements *should* > be indicated in the protocol. Note that this is not the > same thing as saying that they must be forcibly rendered > to users regardless of the users want, which is what you > seem to be arguing for. > > > What I've heard -- and I agree with this viewpoint -- is > that there should be some flag that indicates "this element > is a facilitator, not a participant," so that users who don't > *care* about seeing such elements (existence proof: me) > could configure their clients not to display them. > > > To expand on the flag's meaning, it would make the most > sense to have it mean more precisely "this element is not > truly a participant, but is providing some service related > to the conference." In other words, I would want it to > cover e.g. human transcribers, human translators, etc., > in addition to automata. > > > As Eric points out, I think people are getting hung up on > the name without thinking the issue through completely. > I've updated the subject line accordingly. > > > /a > > > -----Original Message----- > From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > Sent: Wednesday, March 10, 2004 20:50 > To: Eric Burger; xcon@ietf.org > Subject: RE: [XCON] Open Issue: Hidden Participants > > > > I agree that automatons are processing resources > and could be > considered as > logical parts of the conference fabric, for example an IVR > could monitor the > conference and provide a trigger in response to a phrase > that could be > consumed elsewhere. Similarly a device that announces > participants, etc.. > However, IMHO a conference recorder does not fall into this > category and > should probably be a visible resource maybe with an > indicator to show > whether it is or is not active. Similarly - a player > resources which > delivers content or information to the conference > should also > be visible - > it seems desirable to know where such content is > coming from. > > > > > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Tuesday, March 09, 2004 1:28 PM > To: Kozdon, Peter; xcon@ietf.org > Subject: RE: [XCON] Open Issue: Hidden Participants > > > I think we got caught up on the name. > > > There are two needs. > > > The first, which I think we may have consensus on, is the > need for anonymous > participants. That is, participants that are present in the > conference, but > do not have their identities revealed. > > > The second, which is more blurry, is the need for > participants that are > truly hidden. Some want to use hidden participants for > automatons, e.g., > IVR systems or conference recorders. (IMHO, bad idea, but > that is really > just MHO, not strictly black-and-white.) > > > We do have consensus that Lawful Intercept is entirely > orthogonal to > conference participants. However, the logic of the above > follows. Just as > IVR systems or conference recorders are not really > participants, neither is > LI hardware. If we say that the approach for IVR > is to plumb > in as a hidden > participant, then LI would have the same approach. > If we say > that IVR is > something different, e.g., just a part of the conference > mixer, then it is > truly "not there". Likewise, I would expect LI to be > "not there" -- > something outside the XCON framework entirely. > > > -----Original Message----- > From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] > Sent: Monday, March 08, 2004 6:28 PM > To: 'xcon@ietf.org' > Subject: RE: [XCON] Open Issue: Hidden Participants > > > > Hidden listeners operation is probably illegal in many US > states as > well as in many countries - when you make a call there is a > requirement in California the all parties are aware of the > presence of > a 3rd party or recording device, note- that party may be > anonymous, > etc.. > (Exception -- > legal intercept.) > > > We should follow the similar logic for XCON - provide an > indication of > a recording device and/or anonymous participant's) > > > Peter Kozdon > > > > > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On > Behalf Of > Adam Roach > Sent: Monday, March 08, 2004 12:04 PM > To: 'xcon@ietf.org' > Subject: [XCON] Open Issue: Hidden Participants > > > [as chair] > > > At the XCON meeting, there was a rather lively > discussion that > continued the "Hidden Participants" discussion that had > started on the > list. It was agreed that the topic was worth discussion, > but that we > did not have enough time to pursue it in the meeting. > > > I'm calling on everyone, especially those involved in > the meeting > discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to > continue this > discussion so we can close this issue in the near future. > Alan and I > would like to be able to last-call this document shortly, > and this is > the key issue that needs to be resolved before a new > revision of the > draft can be produced. > > > /a > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 11 20:04:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08694 for ; Thu, 11 Mar 2004 20:04: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 1B1b5k-0005OG-1P for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 20:04:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C140vZ020714 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 20:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1b5j-0005O1-Rx for xcon-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 20:03: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 UAA08653 for ; Thu, 11 Mar 2004 20:03:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1b5h-0006Tx-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 20:03:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1b4l-0006KH-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 20:03:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1b3o-0006A6-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 20:02:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1b3p-0005Fm-QD; Thu, 11 Mar 2004 20:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1b37-0005ER-Al for xcon@optimus.ietf.org; Thu, 11 Mar 2004 20:01: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 UAA08570 for ; Thu, 11 Mar 2004 20:01:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1b35-00062l-00 for xcon@ietf.org; Thu, 11 Mar 2004 20:01:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1b2D-0005ty-00 for xcon@ietf.org; Thu, 11 Mar 2004 20:00:22 -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 1B1b1P-0005ht-00 for xcon@ietf.org; Thu, 11 Mar 2004 19:59:32 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 11 Mar 2004 17:02:47 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2C0wxK2010211; Thu, 11 Mar 2004 16:59:00 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARC51835; Thu, 11 Mar 2004 16:58:58 -0800 (PST) In-Reply-To: <313680C9A886D511A06000204840E1CF070B64E6@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B64E6@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <986F33DA-73C0-11D8-8BC0-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: xcon@ietf.org, Eric Burger , Rohan Mahy , "'Kozdon, Peter'" , "'Adam Roach'" From: Rohan Mahy Subject: Re: [XCON] Open Issue: Hideable Participants Date: Thu, 11 Mar 2004 17:00:03 -0800 To: "Rosen, Brian" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian, WHO CARES that its an IVR. I believe that there is NOTHING USEFUL that you can do with that knowledge. However, I can do useful stuff with nearly all of the attributes, without knowing (or caring) what the role/description is. thanks, -rohan On Mar 11, 2004, at 1:36 PM, Rosen, Brian wrote: > So, this is a discussion of "do you want the characteristics of > a participant, or a description of it". > > Seems to me that since this is not a protocol mechanism, it's a > UI issue, that you want a description and not a set of characteristics. > It's pretty easy to figure out what an IVR box does, but its pretty > hard to figure out that it is an IVR box from a set of caps. > Infer that it's a donkey from a description of the parts > vs infer what parts are available knowing it's a donkey. > Since I can always arrange a UI to display characteristics if > I know what role, but can't go the other way, I think role is > best. > > Brian > >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan@cisco.com] >> Sent: Thursday, March 11, 2004 4:23 PM >> To: Rosen, Brian >> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam >> Roach' >> Subject: Re: [XCON] Open Issue: Hideable Participants >> >> >> >> On Mar 11, 2004, at 12:53 PM, Rosen, Brian wrote: >>> What attributes does an IVR box have besides automaton? >>> How about a caption service? >>> >>> If we create a caps for each service, all orthogonal, is that >>> you think makes sense? >> >> no, i'm not proposing a cap for each service. it is this >> "facilitator" >> attribute that all of these roles *share* that causes my UI to hide >> them in the roster. I don't want to have to update my UI (which hid >> IVRs, announcers, human scribes, and recording services) so >> that I will >> hide the caption service you just added. >> >> if you feel you need to add roles for these services, go >> right ahead. >> I don't object to having names roles, but I want my UI to refer to >> attributes where I think attributes are appropriate. [The mere fact >> that all these services I just listed have something in >> common which is >> orthogonal to all the other attributes we have should be a >> strong clue >> that this "facilitator" property should be an attribute.] >> >> thanks, >> -rohan >> >>> These are all roles, they are not attributes. >>> >>> Brian >>> >>>> -----Original Message----- >>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>> Sent: Thursday, March 11, 2004 3:47 PM >>>> To: Rosen, Brian >>>> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam >>>> Roach' >>>> Subject: Re: [XCON] Open Issue: Hideable Participants >>>> >>>> >>>> Hi, >>>> >>>> I'd like to apologize to the group that some of >>>> these ideas >>>> are SIP-specific or very SIP influenced >>>> >>>> Here are the binary or ternary attributes that already exist from >>>> draft-ietf-sip-callee-caps: >>>> >>>> automaton/human >>>> personal/business >>>> mobile/fixed >>>> duplex/send-only/receive-only >>>> >>>> these are 100% orthogonal with respect to each other >>>> >>>> Various folks have proposed that we need the following additional >>>> attributes in various parts of conferencing and/or signaling: >>>> >>>> interactive/noninteractive >>>> anonymous/identified >>>> >>>> (again, these are 100% orthogonal with respect to each >> other and the >>>> other attributes) >>>> >>>> finally I am proposing this new attribute we have been >>>> describing here. >>>> I believe this is still highly orthogonal to the other >> attributes. >>>> >>>> I believe this new attribute is more appropriate than an >> enumerations >>>> for two main reasons: >>>> >>>> 1) you can code behavior based on the presence of the attribute >>>> directly rather than checking for a bunch different roles and then >>>> making sure there are not conditions attached to those roles. >>>> 2) it allows a new thing/role to exist which we haven't >>>> thought of yet >>>> that can still unambiguously provide its attributes. existing code >>>> will work quite well with this new thing if it describes >> itself using >>>> (in part) a number of existing attributes. >>>> >>>> thanks, >>>> -rohan >>>> >>>> >>>> On Mar 11, 2004, at 11:29 AM, Rosen, Brian wrote: >>>> >>>>> Rohan >>>>> >>>>> I'm not sure I agree. I clearly do want to provide >>>> information across >>>>> the wire unambiguously, but I don't think a lot of binary >> attributes >>>>> is a good way to do that. I think we are talking about a >>>> role, rather >>>>> than an attribute. A single automaton, like a single >>>> human, is capable >>>>> of multiple roles, so you need a list in both cases. >>>>> >>>>> Brian >>>>> >>>>>> -----Original Message----- >>>>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>>>> Sent: Thursday, March 11, 2004 2:24 PM >>>>>> To: Rosen, Brian >>>>>> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, >> Peter'; 'Adam >>>>>> Roach' >>>>>> Subject: Re: [XCON] Open Issue: Hideable Participants >>>>>> >>>>>> >>>>>> Brian, >>>>>> >>>>>> There are many different orthogonal attributes we should be >>>>>> able to get >>>>>> access to. This "non-interesting" participant or "facilitator" >>>>>> attribute is orthogonal to your status as an automaton >> or human. I >>>>>> don't think an enumeration here is a good substitute for this >>>>>> attribute. It may be that indicating a recorder is a good >>>>>> value to add >>>>>> to the "actor" media feature tag, which currently has a msg-taker >>>>>> value, or that we can reuse the msg-taker value for the >>>>>> recorder. The >>>>>> goal is maximum orthogonality. We probably can't >> achieve complete >>>>>> orthogonality but I think we can get very close. >>>>>> >>>>>> thanks, >>>>>> -rohan >>>>>> >>>>>> >>>>>> On Mar 11, 2004, at 6:14 AM, Rosen, Brian wrote: >>>>>> >>>>>>> Seems to me that you are on the right track, but we need to >>>>>> go farther. >>>>>>> We have to classify these participants so that the UI, if >>>>>> it wanted to, >>>>>>> could render an appropriate indication. The example of >>>> the recorder >>>>>>> is pretty compelling. Just knowing that there is an >> automaton out >>>>>>> there >>>>>>> is one thing. Knowing its a recorder is another. So, >> really you >>>>>>> don't want a flag, you want an enunumeration. It may >> actually be >>>>>>> a list, because a single automaton could have multiple >> functions. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Adam Roach [mailto:adam@dynamicsoft.com] >>>>>>>> Sent: Thursday, March 11, 2004 12:27 AM >>>>>>>> To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org >>>>>>>> Subject: RE: [XCON] Open Issue: Hideable Participants >>>>>>>> >>>>>>>> >>>>>>>> [not as chair] >>>>>>>> >>>>>>>> I don't think anyone is currently arguing whether indication >>>>>>>> of such automata should be available to the users. Most >>>>>>>> of what I've heard people say on this list -- after Korea, >>>>>>>> at least -- seems to agree that such elements *should* >>>>>>>> be indicated in the protocol. Note that this is not the >>>>>>>> same thing as saying that they must be forcibly rendered >>>>>>>> to users regardless of the users want, which is what you >>>>>>>> seem to be arguing for. >>>>>>>> >>>>>>>> What I've heard -- and I agree with this viewpoint -- is >>>>>>>> that there should be some flag that indicates "this element >>>>>>>> is a facilitator, not a participant," so that users who don't >>>>>>>> *care* about seeing such elements (existence proof: me) >>>>>>>> could configure their clients not to display them. >>>>>>>> >>>>>>>> To expand on the flag's meaning, it would make the most >>>>>>>> sense to have it mean more precisely "this element is not >>>>>>>> truly a participant, but is providing some service related >>>>>>>> to the conference." In other words, I would want it to >>>>>>>> cover e.g. human transcribers, human translators, etc., >>>>>>>> in addition to automata. >>>>>>>> >>>>>>>> As Eric points out, I think people are getting hung up on >>>>>>>> the name without thinking the issue through completely. >>>>>>>> I've updated the subject line accordingly. >>>>>>>> >>>>>>>> /a >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>>>>>>> Sent: Wednesday, March 10, 2004 20:50 >>>>>>>>> To: Eric Burger; xcon@ietf.org >>>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>>>> >>>>>>>>> >>>>>>>>> I agree that automatons are processing resources and could be >>>>>>>>> considered as >>>>>>>>> logical parts of the conference fabric, for example an IVR >>>>>>>>> could monitor the >>>>>>>>> conference and provide a trigger in response to a phrase >>>>>>>> that could be >>>>>>>>> consumed elsewhere. Similarly a device that announces >>>>>>>>> participants, etc.. >>>>>>>>> However, IMHO a conference recorder does not fall into this >>>>>>>>> category and >>>>>>>>> should probably be a visible resource maybe with an >>>>>>>> indicator to show >>>>>>>>> whether it is or is not active. Similarly - a player >>>>>> resources which >>>>>>>>> delivers content or information to the conference should also >>>>>>>>> be visible - >>>>>>>>> it seems desirable to know where such content is coming from. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Eric Burger [mailto:eburger@snowshore.com] >>>>>>>>> Sent: Tuesday, March 09, 2004 1:28 PM >>>>>>>>> To: Kozdon, Peter; xcon@ietf.org >>>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>>>> >>>>>>>>> I think we got caught up on the name. >>>>>>>>> >>>>>>>>> There are two needs. >>>>>>>>> >>>>>>>>> The first, which I think we may have consensus on, is the >>>>>>>>> need for anonymous >>>>>>>>> participants. That is, participants that are present in the >>>>>>>>> conference, but >>>>>>>>> do not have their identities revealed. >>>>>>>>> >>>>>>>>> The second, which is more blurry, is the need for >>>>>>>>> participants that are >>>>>>>>> truly hidden. Some want to use hidden participants for >>>>>>>>> automatons, e.g., >>>>>>>>> IVR systems or conference recorders. (IMHO, bad idea, but >>>>>>>>> that is really >>>>>>>>> just MHO, not strictly black-and-white.) >>>>>>>>> >>>>>>>>> We do have consensus that Lawful Intercept is entirely >>>>>> orthogonal to >>>>>>>>> conference participants. However, the logic of the above >>>>>>>>> follows. Just as >>>>>>>>> IVR systems or conference recorders are not really >>>>>>>>> participants, neither is >>>>>>>>> LI hardware. If we say that the approach for IVR is to plumb >>>>>>>>> in as a hidden >>>>>>>>> participant, then LI would have the same approach. If we say >>>>>>>>> that IVR is >>>>>>>>> something different, e.g., just a part of the conference >>>>>>>>> mixer, then it is >>>>>>>>> truly "not there". Likewise, I would expect LI to be >>>>>> "not there" -- >>>>>>>>> something outside the XCON framework entirely. >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>>>>>>>> Sent: Monday, March 08, 2004 6:28 PM >>>>>>>>>> To: 'xcon@ietf.org' >>>>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hidden listeners operation is probably illegal in many US >>>>>>>> states as >>>>>>>>>> well as in many countries - when you make a call there is a >>>>>>>>>> requirement in California the all parties are aware of the >>>>>>>>> presence of >>>>>>>>>> a 3rd party or recording device, note- that party may be >>>>>>>> anonymous, >>>>>>>>>> etc.. >>>>>>>>>> (Exception -- >>>>>>>>>> legal intercept.) >>>>>>>>>> >>>>>>>>>> We should follow the similar logic for XCON - provide an >>>>>>>>> indication of >>>>>>>>>> a recording device and/or anonymous participant's) >>>>>>>>>> >>>>>>>>>> Peter Kozdon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On >>>>>>>> Behalf Of >>>>>>>>>> Adam Roach >>>>>>>>>> Sent: Monday, March 08, 2004 12:04 PM >>>>>>>>>> To: 'xcon@ietf.org' >>>>>>>>>> Subject: [XCON] Open Issue: Hidden Participants >>>>>>>>>> >>>>>>>>>> [as chair] >>>>>>>>>> >>>>>>>>>> At the XCON meeting, there was a rather lively >> discussion that >>>>>>>>>> continued the "Hidden Participants" discussion that had >>>>>>>>> started on the >>>>>>>>>> list. It was agreed that the topic was worth discussion, >>>>>>>>> but that we >>>>>>>>>> did not have enough time to pursue it in the meeting. >>>>>>>>>> >>>>>>>>>> I'm calling on everyone, especially those involved in >>>> the meeting >>>>>>>>>> discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to >>>>>>>> continue this >>>>>>>>>> discussion so we can close this issue in the near future. >>>>>>>>> Alan and I >>>>>>>>>> would like to be able to last-call this document shortly, >>>>>>>>> and this is >>>>>>>>>> the key issue that needs to be resolved before a new >>>>>>>>> revision of the >>>>>>>>>> draft can be produced. >>>>>>>>>> >>>>>>>>>> /a >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> XCON mailing list >>>>>>>>>> XCON@ietf.org >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> XCON mailing list >>>>>>>>>> XCON@ietf.org >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> XCON mailing list >>>>>>>>> XCON@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> XCON mailing list >>>>>>>> XCON@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> XCON mailing list >>>>>>> XCON@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>> >>>> >> > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 11 20:11:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08951 for ; Thu, 11 Mar 2004 20:11:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1bCY-000699-Fm for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 20:11:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C1B22q023621 for xcon-archive@odin.ietf.org; Thu, 11 Mar 2004 20:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1bCY-00068u-7q for xcon-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 20:11: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 UAA08924 for ; Thu, 11 Mar 2004 20:11:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1bCW-0007SG-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 20:11:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1bBa-0007Jj-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 20:10:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1bAa-0007Am-00 for xcon-web-archive@ietf.org; Thu, 11 Mar 2004 20: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 1B1bAb-00062w-8j; Thu, 11 Mar 2004 20: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 1B1b9m-0005vZ-5p for xcon@optimus.ietf.org; Thu, 11 Mar 2004 20:08: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 UAA08842 for ; Thu, 11 Mar 2004 20:08:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1b9k-00073J-00 for xcon@ietf.org; Thu, 11 Mar 2004 20:08:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1b8v-0006vG-00 for xcon@ietf.org; Thu, 11 Mar 2004 20:07:19 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B1b8B-0006l4-00 for xcon@ietf.org; Thu, 11 Mar 2004 20:06:31 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 11 Mar 2004 17:08:38 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2C15naD010281; Thu, 11 Mar 2004 17:05:49 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARC52356; Thu, 11 Mar 2004 17:05:48 -0800 (PST) In-Reply-To: <4050D69C.10502@cisco.com> References: <313680C9A886D511A06000204840E1CF070B64E4@whq-msgusr-02.pit.comms.marconi.com> <4050D69C.10502@cisco.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8CC600C8-73C1-11D8-8BC0-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Cc: xcon@ietf.org, Eric Burger , "Rosen, Brian" , Rohan Mahy , "'Kozdon, Peter'" , "'Adam Roach'" From: Rohan Mahy Subject: Re: [XCON] Open Issue: Hideable Participants Date: Thu, 11 Mar 2004 17:06:53 -0800 To: Paul Kyzivat X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul, On Mar 11, 2004, at 1:14 PM, Paul Kyzivat wrote: > Lets not get hung up on whether we call it a role or an attribute. > Many of the callee-caps things can be considered to be roles. > > Regarding Rohan saying there is another new attribute - I don't know > what that is. Are you talking about a "hideable" attribute? I don't > think that makes much sense. It puts the responsibility on the focus > to decide what should be hideable. yes. It makes the focus responsible for setting and believing this attribute. I think this is an excellent thing. IMO, the focus is the only entity that can do a reasonable job of this. > I think it is better for clients to each decide what they do/don't > want to see. I may want to hide automata and attendants except that I > want to see recorders. You may just decide to hide automata. feel free to do that, but you may not like the results. what if the predominantly interesting thing in the conference is an automaton with VCR-style controls that the humans in the group are annotating? What if the automata is providing other useful information as a participant (rendering a summary of last months sales figures for example). I think the "ignore automatons" approach. It also doesn't allow you to ignore the "tea lady" participant or the "human scribe" participant. > Regarding how to denote a recorder, I think the existing message-taker > feature tag is probably close enough for the purpose. this may be reasonable, but there are slightly different routing semantics if I want my call routed to someone/something who can take a message for me, and something that just records what I said. > I think what we are talking about can be achieved by exposing the > contact parameters from each participant in CPCP. sometimes. thanks, -r > Paul > > Rosen, Brian wrote: >> What attributes does an IVR box have besides automaton? >> How about a caption service? >> If we create a caps for each service, all orthogonal, is that >> you think makes sense? >> These are all roles, they are not attributes. >> Brian >>> -----Original Message----- >>> From: Rohan Mahy [mailto:rohan@cisco.com] >>> Sent: Thursday, March 11, 2004 3:47 PM >>> To: Rosen, Brian >>> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam >>> Roach' >>> Subject: Re: [XCON] Open Issue: Hideable Participants >>> >>> >>> Hi, >>> >>> I'd like to apologize to the group that some of these >>> ideas are SIP-specific or very SIP influenced >>> >>> Here are the binary or ternary attributes that already exist from >>> draft-ietf-sip-callee-caps: >>> >>> automaton/human >>> personal/business >>> mobile/fixed >>> duplex/send-only/receive-only >>> >>> these are 100% orthogonal with respect to each other >>> >>> Various folks have proposed that we need the following additional >>> attributes in various parts of conferencing and/or signaling: >>> >>> interactive/noninteractive >>> anonymous/identified >>> >>> (again, these are 100% orthogonal with respect to each other and the >>> other attributes) >>> >>> finally I am proposing this new attribute we have been describing >>> here. I believe this is still highly orthogonal to the other >>> attributes. >>> >>> I believe this new attribute is more appropriate than an >>> enumerations for two main reasons: >>> >>> 1) you can code behavior based on the presence of the attribute >>> directly rather than checking for a bunch different roles and then >>> making sure there are not conditions attached to those roles. >>> 2) it allows a new thing/role to exist which we haven't thought of >>> yet that can still unambiguously provide its attributes. existing >>> code will work quite well with this new thing if it describes itself >>> using (in part) a number of existing attributes. >>> >>> thanks, >>> -rohan >>> >>> >>> On Mar 11, 2004, at 11:29 AM, Rosen, Brian wrote: >>> >>> >>>> Rohan >>>> >>>> I'm not sure I agree. I clearly do want to provide >>> >>> information across >>> >>>> the wire unambiguously, but I don't think a lot of binary attributes >>>> is a good way to do that. I think we are talking about a >>> >>> role, rather >>> >>>> than an attribute. A single automaton, like a single >>> >>> human, is capable >>> >>>> of multiple roles, so you need a list in both cases. >>>> >>>> Brian >>>> >>>> >>>>> -----Original Message----- >>>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>>> Sent: Thursday, March 11, 2004 2:24 PM >>>>> To: Rosen, Brian >>>>> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam >>>>> Roach' >>>>> Subject: Re: [XCON] Open Issue: Hideable Participants >>>>> >>>>> >>>>> Brian, >>>>> >>>>> There are many different orthogonal attributes we should be >>>>> able to get >>>>> access to. This "non-interesting" participant or "facilitator" >>>>> attribute is orthogonal to your status as an automaton or human. I >>>>> don't think an enumeration here is a good substitute for this >>>>> attribute. It may be that indicating a recorder is a good >>>>> value to add >>>>> to the "actor" media feature tag, which currently has a msg-taker >>>>> value, or that we can reuse the msg-taker value for the >>>>> recorder. The >>>>> goal is maximum orthogonality. We probably can't achieve complete >>>>> orthogonality but I think we can get very close. >>>>> >>>>> thanks, >>>>> -rohan >>>>> >>>>> >>>>> On Mar 11, 2004, at 6:14 AM, Rosen, Brian wrote: >>>>> >>>>> >>>>>> Seems to me that you are on the right track, but we need to >>>>> >>>>> go farther. >>>>> >>>>>> We have to classify these participants so that the UI, if >>>>> >>>>> it wanted to, >>>>> >>>>>> could render an appropriate indication. The example of >>>>> >>> the recorder >>> >>>>>> is pretty compelling. Just knowing that there is an automaton out >>>>>> there >>>>>> is one thing. Knowing its a recorder is another. So, really you >>>>>> don't want a flag, you want an enunumeration. It may actually be >>>>>> a list, because a single automaton could have multiple functions. >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Adam Roach [mailto:adam@dynamicsoft.com] >>>>>>> Sent: Thursday, March 11, 2004 12:27 AM >>>>>>> To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org >>>>>>> Subject: RE: [XCON] Open Issue: Hideable Participants >>>>>>> >>>>>>> >>>>>>> [not as chair] >>>>>>> >>>>>>> I don't think anyone is currently arguing whether indication >>>>>>> of such automata should be available to the users. Most >>>>>>> of what I've heard people say on this list -- after Korea, >>>>>>> at least -- seems to agree that such elements *should* >>>>>>> be indicated in the protocol. Note that this is not the >>>>>>> same thing as saying that they must be forcibly rendered >>>>>>> to users regardless of the users want, which is what you >>>>>>> seem to be arguing for. >>>>>>> >>>>>>> What I've heard -- and I agree with this viewpoint -- is >>>>>>> that there should be some flag that indicates "this element >>>>>>> is a facilitator, not a participant," so that users who don't >>>>>>> *care* about seeing such elements (existence proof: me) >>>>>>> could configure their clients not to display them. >>>>>>> >>>>>>> To expand on the flag's meaning, it would make the most >>>>>>> sense to have it mean more precisely "this element is not >>>>>>> truly a participant, but is providing some service related >>>>>>> to the conference." In other words, I would want it to >>>>>>> cover e.g. human transcribers, human translators, etc., >>>>>>> in addition to automata. >>>>>>> >>>>>>> As Eric points out, I think people are getting hung up on >>>>>>> the name without thinking the issue through completely. >>>>>>> I've updated the subject line accordingly. >>>>>>> >>>>>>> /a >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>>>>>> Sent: Wednesday, March 10, 2004 20:50 >>>>>>>> To: Eric Burger; xcon@ietf.org >>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>>> >>>>>>>> >>>>>>>> I agree that automatons are processing resources and could be >>>>>>>> considered as >>>>>>>> logical parts of the conference fabric, for example an IVR >>>>>>>> could monitor the >>>>>>>> conference and provide a trigger in response to a phrase >>>>>>> >>>>>>> that could be >>>>>>> >>>>>>>> consumed elsewhere. Similarly a device that announces >>>>>>>> participants, etc.. >>>>>>>> However, IMHO a conference recorder does not fall into this >>>>>>>> category and >>>>>>>> should probably be a visible resource maybe with an >>>>>>> >>>>>>> indicator to show >>>>>>> >>>>>>>> whether it is or is not active. Similarly - a player >>>>>>> >>>>> resources which >>>>> >>>>>>>> delivers content or information to the conference should also >>>>>>>> be visible - >>>>>>>> it seems desirable to know where such content is coming from. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Eric Burger [mailto:eburger@snowshore.com] >>>>>>>> Sent: Tuesday, March 09, 2004 1:28 PM >>>>>>>> To: Kozdon, Peter; xcon@ietf.org >>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>>> >>>>>>>> I think we got caught up on the name. >>>>>>>> >>>>>>>> There are two needs. >>>>>>>> >>>>>>>> The first, which I think we may have consensus on, is the >>>>>>>> need for anonymous >>>>>>>> participants. That is, participants that are present in the >>>>>>>> conference, but >>>>>>>> do not have their identities revealed. >>>>>>>> >>>>>>>> The second, which is more blurry, is the need for >>>>>>>> participants that are >>>>>>>> truly hidden. Some want to use hidden participants for >>>>>>>> automatons, e.g., >>>>>>>> IVR systems or conference recorders. (IMHO, bad idea, but >>>>>>>> that is really >>>>>>>> just MHO, not strictly black-and-white.) >>>>>>>> >>>>>>>> We do have consensus that Lawful Intercept is entirely >>>>>>> >>>>> orthogonal to >>>>> >>>>>>>> conference participants. However, the logic of the above >>>>>>>> follows. Just as >>>>>>>> IVR systems or conference recorders are not really >>>>>>>> participants, neither is >>>>>>>> LI hardware. If we say that the approach for IVR is to plumb >>>>>>>> in as a hidden >>>>>>>> participant, then LI would have the same approach. If we say >>>>>>>> that IVR is >>>>>>>> something different, e.g., just a part of the conference >>>>>>>> mixer, then it is >>>>>>>> truly "not there". Likewise, I would expect LI to be >>>>>>> >>>>> "not there" -- >>>>> >>>>>>>> something outside the XCON framework entirely. >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>>>>>>> Sent: Monday, March 08, 2004 6:28 PM >>>>>>>>> To: 'xcon@ietf.org' >>>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>>>> >>>>>>>>> >>>>>>>>> Hidden listeners operation is probably illegal in many US >>>>>>>> >>>>>>> states as >>>>>>> >>>>>>>>> well as in many countries - when you make a call there is a >>>>>>>>> requirement in California the all parties are aware of the >>>>>>>> >>>>>>>> presence of >>>>>>>> >>>>>>>>> a 3rd party or recording device, note- that party may be >>>>>>>> >>>>>>> anonymous, >>>>>>> >>>>>>>>> etc.. >>>>>>>>> (Exception -- >>>>>>>>> legal intercept.) >>>>>>>>> >>>>>>>>> We should follow the similar logic for XCON - provide an >>>>>>>> >>>>>>>> indication of >>>>>>>> >>>>>>>>> a recording device and/or anonymous participant's) >>>>>>>>> >>>>>>>>> Peter Kozdon >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On >>>>>>>> >>>>>>> Behalf Of >>>>>>> >>>>>>>>> Adam Roach >>>>>>>>> Sent: Monday, March 08, 2004 12:04 PM >>>>>>>>> To: 'xcon@ietf.org' >>>>>>>>> Subject: [XCON] Open Issue: Hidden Participants >>>>>>>>> >>>>>>>>> [as chair] >>>>>>>>> >>>>>>>>> At the XCON meeting, there was a rather lively discussion that >>>>>>>>> continued the "Hidden Participants" discussion that had >>>>>>>> >>>>>>>> started on the >>>>>>>> >>>>>>>>> list. It was agreed that the topic was worth discussion, >>>>>>>> >>>>>>>> but that we >>>>>>>> >>>>>>>>> did not have enough time to pursue it in the meeting. >>>>>>>>> >>>>>>>>> I'm calling on everyone, especially those involved in >>>>>>>> >>> the meeting >>> >>>>>>>>> discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to >>>>>>>> >>>>>>> continue this >>>>>>> >>>>>>>>> discussion so we can close this issue in the near future. >>>>>>>> >>>>>>>> Alan and I >>>>>>>> >>>>>>>>> would like to be able to last-call this document shortly, >>>>>>>> >>>>>>>> and this is >>>>>>>> >>>>>>>>> the key issue that needs to be resolved before a new >>>>>>>> >>>>>>>> revision of the >>>>>>>> >>>>>>>>> draft can be produced. >>>>>>>>> >>>>>>>>> /a >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> XCON mailing list >>>>>>>>> XCON@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> XCON mailing list >>>>>>>>> XCON@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> XCON mailing list >>>>>>>> XCON@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> XCON mailing list >>>>>>> XCON@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> XCON mailing list >>>>>> XCON@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>> >> _______________________________________________ >> XCON mailing list >> XCON@ietf.org >> https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Sat Mar 13 17:32:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04236 for ; Sat, 13 Mar 2004 17:32: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 1B2HfP-00066q-Hy for xcon-archive@odin.ietf.org; Sat, 13 Mar 2004 17:31:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2DMVdoX023483 for xcon-archive@odin.ietf.org; Sat, 13 Mar 2004 17:31:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2HfP-00066g-9c for xcon-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 17:31: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 RAA04232 for ; Sat, 13 Mar 2004 17:31:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2HfM-0002nP-00 for xcon-web-archive@ietf.org; Sat, 13 Mar 2004 17:31:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2HeP-0002jZ-00 for xcon-web-archive@ietf.org; Sat, 13 Mar 2004 17:30:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2Hdt-0002fT-00 for xcon-web-archive@ietf.org; Sat, 13 Mar 2004 17: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 1B2Hdt-00063a-RY; Sat, 13 Mar 2004 17:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2HdM-00062A-I6 for xcon@optimus.ietf.org; Sat, 13 Mar 2004 17:29: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 RAA04201 for ; Sat, 13 Mar 2004 17:29:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2HdK-0002ei-00 for xcon@ietf.org; Sat, 13 Mar 2004 17:29:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2HcP-0002b8-00 for xcon@ietf.org; Sat, 13 Mar 2004 17:28:34 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B2HbY-0002TS-00 for xcon@ietf.org; Sat, 13 Mar 2004 17:27:40 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 13 Mar 2004 14:32:58 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2DMR7Uk001495; Sat, 13 Mar 2004 17:27:08 -0500 (EST) Received: from cisco.com (che-vpn-cluster-2-164.cisco.com [10.86.242.164]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGT50635; Sat, 13 Mar 2004 17:27:05 -0500 (EST) Message-ID: <40538AB9.9050405@cisco.com> Date: Sat, 13 Mar 2004 17:27:05 -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: Rohan Mahy CC: xcon@ietf.org, Eric Burger , "Rosen, Brian" , "'Kozdon, Peter'" , "'Adam Roach'" Subject: Re: [XCON] Open Issue: Hideable Participants References: <313680C9A886D511A06000204840E1CF070B64E4@whq-msgusr-02.pit.comms.marconi.com> <4050D69C.10502@cisco.com> <8CC600C8-73C1-11D8-8BC0-0003938AF740@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Replying to this whole thread, not just to Rohan... It seems to me that this discussion is replicating that which took place around presence, in how to define "services". I have the impression that what Brian is calling "role" here is similar to what others have called "service" there. In the presence case we could find no useful unique way to define a service, and decided it was largely in the eye of the beholder. So we decided that we should just describe the features of a presentity, and let the watchers interpret certain collections of features as a service. The same should work here, although the application is a bit simpler. It is simply a matter of a client deciding what combination of features constitue a participant that is/isn't interesting to that client. Whether "hideable" is a distinct feature is a separate question. I am inclined to think it is not, because whether something is hideable is a subjective decision, and not everyone will want to make the same decision. Paul Rohan Mahy wrote: > Paul, > > On Mar 11, 2004, at 1:14 PM, Paul Kyzivat wrote: > >> Lets not get hung up on whether we call it a role or an attribute. >> Many of the callee-caps things can be considered to be roles. >> >> Regarding Rohan saying there is another new attribute - I don't know >> what that is. Are you talking about a "hideable" attribute? I don't >> think that makes much sense. It puts the responsibility on the focus >> to decide what should be hideable. > > > yes. It makes the focus responsible for setting and believing this > attribute. I think this is an excellent thing. IMO, the focus is the > only entity that can do a reasonable job of this. > >> I think it is better for clients to each decide what they do/don't >> want to see. I may want to hide automata and attendants except that I >> want to see recorders. You may just decide to hide automata. > > > feel free to do that, but you may not like the results. what if the > predominantly interesting thing in the conference is an automaton with > VCR-style controls that the humans in the group are annotating? What if > the automata is providing other useful information as a participant > (rendering a summary of last months sales figures for example). I think > the "ignore automatons" approach. It also doesn't allow you to ignore > the "tea lady" participant or the "human scribe" participant. > >> Regarding how to denote a recorder, I think the existing message-taker >> feature tag is probably close enough for the purpose. > > > this may be reasonable, but there are slightly different routing > semantics if I want my call routed to someone/something who can take a > message for me, and something that just records what I said. > >> I think what we are talking about can be achieved by exposing the >> contact parameters from each participant in CPCP. > > > sometimes. > > thanks, > -r > >> Paul >> >> Rosen, Brian wrote: >> >>> What attributes does an IVR box have besides automaton? >>> How about a caption service? >>> If we create a caps for each service, all orthogonal, is that >>> you think makes sense? >>> These are all roles, they are not attributes. >>> Brian >>> >>>> -----Original Message----- >>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>> Sent: Thursday, March 11, 2004 3:47 PM >>>> To: Rosen, Brian >>>> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam >>>> Roach' >>>> Subject: Re: [XCON] Open Issue: Hideable Participants >>>> >>>> >>>> Hi, >>>> >>>> I'd like to apologize to the group that some of these >>>> ideas are SIP-specific or very SIP influenced >>>> >>>> Here are the binary or ternary attributes that already exist from >>>> draft-ietf-sip-callee-caps: >>>> >>>> automaton/human >>>> personal/business >>>> mobile/fixed >>>> duplex/send-only/receive-only >>>> >>>> these are 100% orthogonal with respect to each other >>>> >>>> Various folks have proposed that we need the following additional >>>> attributes in various parts of conferencing and/or signaling: >>>> >>>> interactive/noninteractive >>>> anonymous/identified >>>> >>>> (again, these are 100% orthogonal with respect to each other and the >>>> other attributes) >>>> >>>> finally I am proposing this new attribute we have been describing >>>> here. I believe this is still highly orthogonal to the other >>>> attributes. >>>> >>>> I believe this new attribute is more appropriate than an >>>> enumerations for two main reasons: >>>> >>>> 1) you can code behavior based on the presence of the attribute >>>> directly rather than checking for a bunch different roles and then >>>> making sure there are not conditions attached to those roles. >>>> 2) it allows a new thing/role to exist which we haven't thought of >>>> yet that can still unambiguously provide its attributes. existing >>>> code will work quite well with this new thing if it describes itself >>>> using (in part) a number of existing attributes. >>>> >>>> thanks, >>>> -rohan >>>> >>>> >>>> On Mar 11, 2004, at 11:29 AM, Rosen, Brian wrote: >>>> >>>> >>>>> Rohan >>>>> >>>>> I'm not sure I agree. I clearly do want to provide >>>> >>>> >>>> information across >>>> >>>>> the wire unambiguously, but I don't think a lot of binary attributes >>>>> is a good way to do that. I think we are talking about a >>>> >>>> >>>> role, rather >>>> >>>>> than an attribute. A single automaton, like a single >>>> >>>> >>>> human, is capable >>>> >>>>> of multiple roles, so you need a list in both cases. >>>>> >>>>> Brian >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>>>> Sent: Thursday, March 11, 2004 2:24 PM >>>>>> To: Rosen, Brian >>>>>> Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam >>>>>> Roach' >>>>>> Subject: Re: [XCON] Open Issue: Hideable Participants >>>>>> >>>>>> >>>>>> Brian, >>>>>> >>>>>> There are many different orthogonal attributes we should be >>>>>> able to get >>>>>> access to. This "non-interesting" participant or "facilitator" >>>>>> attribute is orthogonal to your status as an automaton or human. I >>>>>> don't think an enumeration here is a good substitute for this >>>>>> attribute. It may be that indicating a recorder is a good >>>>>> value to add >>>>>> to the "actor" media feature tag, which currently has a msg-taker >>>>>> value, or that we can reuse the msg-taker value for the >>>>>> recorder. The >>>>>> goal is maximum orthogonality. We probably can't achieve complete >>>>>> orthogonality but I think we can get very close. >>>>>> >>>>>> thanks, >>>>>> -rohan >>>>>> >>>>>> >>>>>> On Mar 11, 2004, at 6:14 AM, Rosen, Brian wrote: >>>>>> >>>>>> >>>>>>> Seems to me that you are on the right track, but we need to >>>>>> >>>>>> >>>>>> go farther. >>>>>> >>>>>>> We have to classify these participants so that the UI, if >>>>>> >>>>>> >>>>>> it wanted to, >>>>>> >>>>>>> could render an appropriate indication. The example of >>>>>> >>>>>> >>>> the recorder >>>> >>>>>>> is pretty compelling. Just knowing that there is an automaton out >>>>>>> there >>>>>>> is one thing. Knowing its a recorder is another. So, really you >>>>>>> don't want a flag, you want an enunumeration. It may actually be >>>>>>> a list, because a single automaton could have multiple functions. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Adam Roach [mailto:adam@dynamicsoft.com] >>>>>>>> Sent: Thursday, March 11, 2004 12:27 AM >>>>>>>> To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org >>>>>>>> Subject: RE: [XCON] Open Issue: Hideable Participants >>>>>>>> >>>>>>>> >>>>>>>> [not as chair] >>>>>>>> >>>>>>>> I don't think anyone is currently arguing whether indication >>>>>>>> of such automata should be available to the users. Most >>>>>>>> of what I've heard people say on this list -- after Korea, >>>>>>>> at least -- seems to agree that such elements *should* >>>>>>>> be indicated in the protocol. Note that this is not the >>>>>>>> same thing as saying that they must be forcibly rendered >>>>>>>> to users regardless of the users want, which is what you >>>>>>>> seem to be arguing for. >>>>>>>> >>>>>>>> What I've heard -- and I agree with this viewpoint -- is >>>>>>>> that there should be some flag that indicates "this element >>>>>>>> is a facilitator, not a participant," so that users who don't >>>>>>>> *care* about seeing such elements (existence proof: me) >>>>>>>> could configure their clients not to display them. >>>>>>>> >>>>>>>> To expand on the flag's meaning, it would make the most >>>>>>>> sense to have it mean more precisely "this element is not >>>>>>>> truly a participant, but is providing some service related >>>>>>>> to the conference." In other words, I would want it to >>>>>>>> cover e.g. human transcribers, human translators, etc., >>>>>>>> in addition to automata. >>>>>>>> >>>>>>>> As Eric points out, I think people are getting hung up on >>>>>>>> the name without thinking the issue through completely. >>>>>>>> I've updated the subject line accordingly. >>>>>>>> >>>>>>>> /a >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>>>>>>> Sent: Wednesday, March 10, 2004 20:50 >>>>>>>>> To: Eric Burger; xcon@ietf.org >>>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>>>> >>>>>>>>> >>>>>>>>> I agree that automatons are processing resources and could be >>>>>>>>> considered as >>>>>>>>> logical parts of the conference fabric, for example an IVR >>>>>>>>> could monitor the >>>>>>>>> conference and provide a trigger in response to a phrase >>>>>>>> >>>>>>>> >>>>>>>> that could be >>>>>>>> >>>>>>>>> consumed elsewhere. Similarly a device that announces >>>>>>>>> participants, etc.. >>>>>>>>> However, IMHO a conference recorder does not fall into this >>>>>>>>> category and >>>>>>>>> should probably be a visible resource maybe with an >>>>>>>> >>>>>>>> >>>>>>>> indicator to show >>>>>>>> >>>>>>>>> whether it is or is not active. Similarly - a player >>>>>>>> >>>>>>>> >>>>>> resources which >>>>>> >>>>>>>>> delivers content or information to the conference should also >>>>>>>>> be visible - >>>>>>>>> it seems desirable to know where such content is coming from. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Eric Burger [mailto:eburger@snowshore.com] >>>>>>>>> Sent: Tuesday, March 09, 2004 1:28 PM >>>>>>>>> To: Kozdon, Peter; xcon@ietf.org >>>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>>>> >>>>>>>>> I think we got caught up on the name. >>>>>>>>> >>>>>>>>> There are two needs. >>>>>>>>> >>>>>>>>> The first, which I think we may have consensus on, is the >>>>>>>>> need for anonymous >>>>>>>>> participants. That is, participants that are present in the >>>>>>>>> conference, but >>>>>>>>> do not have their identities revealed. >>>>>>>>> >>>>>>>>> The second, which is more blurry, is the need for >>>>>>>>> participants that are >>>>>>>>> truly hidden. Some want to use hidden participants for >>>>>>>>> automatons, e.g., >>>>>>>>> IVR systems or conference recorders. (IMHO, bad idea, but >>>>>>>>> that is really >>>>>>>>> just MHO, not strictly black-and-white.) >>>>>>>>> >>>>>>>>> We do have consensus that Lawful Intercept is entirely >>>>>>>> >>>>>>>> >>>>>> orthogonal to >>>>>> >>>>>>>>> conference participants. However, the logic of the above >>>>>>>>> follows. Just as >>>>>>>>> IVR systems or conference recorders are not really >>>>>>>>> participants, neither is >>>>>>>>> LI hardware. If we say that the approach for IVR is to plumb >>>>>>>>> in as a hidden >>>>>>>>> participant, then LI would have the same approach. If we say >>>>>>>>> that IVR is >>>>>>>>> something different, e.g., just a part of the conference >>>>>>>>> mixer, then it is >>>>>>>>> truly "not there". Likewise, I would expect LI to be >>>>>>>> >>>>>>>> >>>>>> "not there" -- >>>>>> >>>>>>>>> something outside the XCON framework entirely. >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>>>>>>>> Sent: Monday, March 08, 2004 6:28 PM >>>>>>>>>> To: 'xcon@ietf.org' >>>>>>>>>> Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hidden listeners operation is probably illegal in many US >>>>>>>>> >>>>>>>>> >>>>>>>> states as >>>>>>>> >>>>>>>>>> well as in many countries - when you make a call there is a >>>>>>>>>> requirement in California the all parties are aware of the >>>>>>>>> >>>>>>>>> >>>>>>>>> presence of >>>>>>>>> >>>>>>>>>> a 3rd party or recording device, note- that party may be >>>>>>>>> >>>>>>>>> >>>>>>>> anonymous, >>>>>>>> >>>>>>>>>> etc.. >>>>>>>>>> (Exception -- >>>>>>>>>> legal intercept.) >>>>>>>>>> >>>>>>>>>> We should follow the similar logic for XCON - provide an >>>>>>>>> >>>>>>>>> >>>>>>>>> indication of >>>>>>>>> >>>>>>>>>> a recording device and/or anonymous participant's) >>>>>>>>>> >>>>>>>>>> Peter Kozdon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On >>>>>>>>> >>>>>>>>> >>>>>>>> Behalf Of >>>>>>>> >>>>>>>>>> Adam Roach >>>>>>>>>> Sent: Monday, March 08, 2004 12:04 PM >>>>>>>>>> To: 'xcon@ietf.org' >>>>>>>>>> Subject: [XCON] Open Issue: Hidden Participants >>>>>>>>>> >>>>>>>>>> [as chair] >>>>>>>>>> >>>>>>>>>> At the XCON meeting, there was a rather lively discussion that >>>>>>>>>> continued the "Hidden Participants" discussion that had >>>>>>>>> >>>>>>>>> >>>>>>>>> started on the >>>>>>>>> >>>>>>>>>> list. It was agreed that the topic was worth discussion, >>>>>>>>> >>>>>>>>> >>>>>>>>> but that we >>>>>>>>> >>>>>>>>>> did not have enough time to pursue it in the meeting. >>>>>>>>>> >>>>>>>>>> I'm calling on everyone, especially those involved in >>>>>>>>> >>>>>>>>> >>>> the meeting >>>> >>>>>>>>>> discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to >>>>>>>>> >>>>>>>>> >>>>>>>> continue this >>>>>>>> >>>>>>>>>> discussion so we can close this issue in the near future. >>>>>>>>> >>>>>>>>> >>>>>>>>> Alan and I >>>>>>>>> >>>>>>>>>> would like to be able to last-call this document shortly, >>>>>>>>> >>>>>>>>> >>>>>>>>> and this is >>>>>>>>> >>>>>>>>>> the key issue that needs to be resolved before a new >>>>>>>>> >>>>>>>>> >>>>>>>>> revision of the >>>>>>>>> >>>>>>>>>> draft can be produced. >>>>>>>>>> >>>>>>>>>> /a >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> XCON mailing list >>>>>>>>>> XCON@ietf.org >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> XCON mailing list >>>>>>>>>> XCON@ietf.org >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> XCON mailing list >>>>>>>>> XCON@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> XCON mailing list >>>>>>>> XCON@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> XCON mailing list >>>>>>> XCON@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/xcon >>>>>> >>>>>> >>> _______________________________________________ >>> XCON mailing list >>> XCON@ietf.org >>> https://www1.ietf.org/mailman/listinfo/xcon >> >> > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Mar 15 14:08:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16692 for ; Mon, 15 Mar 2004 14:08:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xRU-000227-S5 for xcon-archive@odin.ietf.org; Mon, 15 Mar 2004 14:08:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FJ845M007793 for xcon-archive@odin.ietf.org; Mon, 15 Mar 2004 14: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 1B2xRT-00021T-La for xcon-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 14: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 OAA16642 for ; Mon, 15 Mar 2004 14:08:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2xRR-0004kB-00 for xcon-web-archive@ietf.org; Mon, 15 Mar 2004 14:08:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2xQP-0004du-00 for xcon-web-archive@ietf.org; Mon, 15 Mar 2004 14:06:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2xPT-0004Zr-00 for xcon-web-archive@ietf.org; Mon, 15 Mar 2004 14:05:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xPV-0001fr-0r; Mon, 15 Mar 2004 14:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xOf-0001cW-5k for xcon@optimus.ietf.org; Mon, 15 Mar 2004 14:05: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 OAA16470 for ; Mon, 15 Mar 2004 14:05:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2xOc-0004X5-00 for xcon@ietf.org; Mon, 15 Mar 2004 14:05:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2xNe-0004UT-00 for xcon@ietf.org; Mon, 15 Mar 2004 14:04:07 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1B2xNG-0004SU-00 for xcon@ietf.org; Mon, 15 Mar 2004 14:03:42 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i2FJ30uJ008365 for ; Mon, 15 Mar 2004 13:03:09 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Mar 2004 13:02:54 -0600 Message-ID: <9ACE0CEE075B494096C86C23878BF85906A3B7@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'xcon@ietf.org'" Date: Mon, 15 Mar 2004 13:02:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [XCON] WGLC for Floor Control Reqs 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 Today begins a three-week working-group last call period for the Floor Control Requirements document, . The chairs plan to submit the document to the IESG for consideration within next several weeks unless substantial open issues are discovered. This last call ends on April 5th. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 18 16:18:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09220 for ; Thu, 18 Mar 2004 16:18: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 1B44th-0005tf-W7 for xcon-archive@odin.ietf.org; Thu, 18 Mar 2004 16:17:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ILHnXA022663 for xcon-archive@odin.ietf.org; Thu, 18 Mar 2004 16:17:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B44th-0005tS-Rj for xcon-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 16:17:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09199 for ; Thu, 18 Mar 2004 16:17:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B44tg-00050d-00 for xcon-web-archive@ietf.org; Thu, 18 Mar 2004 16:17:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B44si-0004wE-00 for xcon-web-archive@ietf.org; Thu, 18 Mar 2004 16:16:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B44rx-0004sa-00 for xcon-web-archive@ietf.org; Thu, 18 Mar 2004 16:16:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B44rx-0005oq-RG; Thu, 18 Mar 2004 16:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B44ri-0005nu-De for xcon@optimus.ietf.org; Thu, 18 Mar 2004 16:15:46 -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 QAA09147 for ; Thu, 18 Mar 2004 16:15:43 -0500 (EST) From: petri.koskelainen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B44rg-0004rm-00 for xcon@ietf.org; Thu, 18 Mar 2004 16:15:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B44qn-0004oT-00 for xcon@ietf.org; Thu, 18 Mar 2004 16:14:50 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B44q4-0004kY-00 for xcon@ietf.org; Thu, 18 Mar 2004 16:14:04 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2ILE3p24273 for ; Thu, 18 Mar 2004 23:14:03 +0200 (EET) X-Scanned: Thu, 18 Mar 2004 23:13:58 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2ILDwXG005700 for ; Thu, 18 Mar 2004 23:13:58 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 005DBq97; Thu, 18 Mar 2004 23:13:56 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2ILDuF19024 for ; Thu, 18 Mar 2004 23:13:56 +0200 (EET) Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 18 Mar 2004 23:13:55 +0200 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 18 Mar 2004 23:13: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 Date: Thu, 18 Mar 2004 23:13:54 +0200 Message-ID: <481D6FFB3BD60E4CB590F39C59098400023E0D56@trebe004.europe.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Hidden Participants Thread-Index: AcP8G53wGoxUPWGVQRiKeQQtE1H1FwRD7/sw To: X-OriginalArrivalTime: 18 Mar 2004 21:13:55.0889 (UTC) FILETIME=[EC17D210:01C40D2D] Content-Transfer-Encoding: quoted-printable Subject: [XCON] CPCP Requirements: hidden users 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 need to close this open issue asap so we can move forward.=20 Support for this was removed from cpcp-reqs-02 draft=20 but no concensus has so far been reached in the list. However, the discussion has lately been focusing on callee capabilities and whether (and how) hidden or hideable users are shown in the user = interface and in the conference package. Callee capabilities can indeed be extended to include such roles or = attributes=20 (in addition to attendant, msg-taker etc), but it seems that this issue = has=20 nothing to do with CPCP. Only issue which might be linked to=20 CPCP is that the conference policy can define whether hidden or hideable = users are=20 allowed in a conference (but it opens yet another rathole).=20 If a user wants to remain anonymous that is supported already. I propose that we close this open issue as it has nothing to do with = CPCP requirements. Extending callee-caps (and conf package) is another issue and should be = discussed in a separate thread. -- Petri _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Thu Mar 18 16:30:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09782 for ; Thu, 18 Mar 2004 16:30: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 1B455D-0006uL-Ij for xcon-archive@odin.ietf.org; Thu, 18 Mar 2004 16:29:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ILThFP026547 for xcon-archive@odin.ietf.org; Thu, 18 Mar 2004 16:29:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B455D-0006u6-Dn for xcon-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 16:29: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 QAA09749 for ; Thu, 18 Mar 2004 16:29:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B455B-00061V-00 for xcon-web-archive@ietf.org; Thu, 18 Mar 2004 16:29:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B454G-0005z2-00 for xcon-web-archive@ietf.org; Thu, 18 Mar 2004 16:28:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B453X-0005wP-00 for xcon-web-archive@ietf.org; Thu, 18 Mar 2004 16:27:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B453Y-0006ky-KQ; Thu, 18 Mar 2004 16:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B453D-0006jU-JB for xcon@optimus.ietf.org; Thu, 18 Mar 2004 16:27: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 QAA09691 for ; Thu, 18 Mar 2004 16:27:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B453B-0005uv-00 for xcon@ietf.org; Thu, 18 Mar 2004 16:27:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B452N-0005sq-00 for xcon@ietf.org; Thu, 18 Mar 2004 16:26:48 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1B451t-0005nN-00 for xcon@ietf.org; Thu, 18 Mar 2004 16:26:17 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 13:25:46 -0800 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 18 Mar 2004 13:25:18 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 13:25:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.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 Requirements: hidden users Date: Thu, 18 Mar 2004 13:26:02 -0800 Message-ID: Thread-Topic: [XCON] CPCP Requirements: hidden users Thread-Index: AcP8G53wGoxUPWGVQRiKeQQtE1H1FwRD7/swAADKNyA= From: "Orit Levin" To: , X-OriginalArrivalTime: 18 Mar 2004 21:25:41.0444 (UTC) FILETIME=[90A2F840:01C40D2F] 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I agree with this proposal. I would like to mention that the current conference package is "the basic conference package" which covers SIPPING conferencing requirements. I suggest keeping it as is and declare it as done on the SIPPING list. The XML schema is extensible and extensions to the package will need to be separately defined based on the XCON work. Would we agree to this? Orit. -----Original Message----- From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of petri.koskelainen@nokia.com Sent: Thursday, March 18, 2004 1:14 PM To: xcon@ietf.org Subject: [XCON] CPCP Requirements: hidden users We need to close this open issue asap so we can move forward.=20 Support for this was removed from cpcp-reqs-02 draft but no concensus has so far been reached in the list. However, the discussion has lately been focusing on callee capabilities and whether (and how) hidden or hideable users are shown in the user interface and in the conference package. Callee capabilities can indeed be extended to include such roles or attributes (in addition to attendant, msg-taker etc), but it seems that this issue has nothing to do with CPCP. Only issue which might be linked to CPCP is that the conference policy can define whether hidden or hideable users are allowed in a conference (but it opens yet another rathole).=20 If a user wants to remain anonymous that is supported already. I propose that we close this open issue as it has nothing to do with CPCP requirements. Extending callee-caps (and conf package) is another issue and should be discussed in a separate thread. -- Petri _______________________________________________ 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 Mar 19 14:31:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17345 for ; Fri, 19 Mar 2004 14:31: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 1B4PiJ-0008S5-Ar for xcon-archive@odin.ietf.org; Fri, 19 Mar 2004 14:31:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JJVRvi032483 for xcon-archive@odin.ietf.org; Fri, 19 Mar 2004 14:31:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4PiI-0008Rq-Mg for xcon-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 14:31: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 OAA17342 for ; Fri, 19 Mar 2004 14:31:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4PiG-0000Re-00 for xcon-web-archive@ietf.org; Fri, 19 Mar 2004 14:31:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4PhK-0000Mv-00 for xcon-web-archive@ietf.org; Fri, 19 Mar 2004 14:30:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4Pgz-0000I5-00 for xcon-web-archive@ietf.org; Fri, 19 Mar 2004 14: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 1B4Pgx-0008MQ-PP; Fri, 19 Mar 2004 14: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 1B4OmA-0004ku-DO for xcon@optimus.ietf.org; Fri, 19 Mar 2004 13:31: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 NAA14282 for ; Fri, 19 Mar 2004 13:31:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Om8-0002QE-00 for xcon@ietf.org; Fri, 19 Mar 2004 13:31:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4OlD-0002M1-00 for xcon@ietf.org; Fri, 19 Mar 2004 13:30:24 -0500 Received: from omzesmtp03.mci.com ([199.249.17.11]) by ietf-mx with esmtp (Exim 4.12) id 1B4OkH-0002DS-00; Fri, 19 Mar 2004 13:29:25 -0500 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HUU0004X5NM2Y@firewall.mci.com>; Fri, 19 Mar 2004 18:21:22 +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 <0HUU000015NLN4@pmismtp02.mcilink.com>; Fri, 19 Mar 2004 18:21:21 +0000 (GMT) Received: from XS578V7033521.mci.com ([166.50.113.70]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HUU0000Y5NJKT@pmismtp02.mcilink.com>; Fri, 19 Mar 2004 18:21:21 +0000 (GMT) Date: Fri, 19 Mar 2004 12:21:18 -0600 From: Alan Johnston X-Sender: Alan.Johnston@pop.mcit.com To: "Rosen, Brian" , "'Paul Kyzivat'" , "Niemi Aki (Nokia-M/Espoo)" Message-id: <5.2.1.1.0.20040319121725.02eb0ad0@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Subject: [XCON] RE: Chat sessions Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 As a result of this thread, in Korea, a group of us (roughly myself, Brian, Hisham, Aki, Paul, Markus - apologies to others who I might have forgotten) met to discuss "chat rooms" and text conferencing. Here is what the consensus of the participants was: There is a need to document aspects of "chat rooms" or text conferencing. There seems to be a need to have a request/response kind of subset of conferencing (sidebar) AS WELL AS an immediate no request/response subset of conferencing (private message / whisper). This need is not specific to media, although the exact mechanism to establish it might be media dependent. Media Policy is a media independent mechanism, but others may be more appropriate, especially for IM. This work will at least begin in XCON. In addition, the absence of an ability to express a nickname in SIP was identified as an area for future SIP work. Thanks, Alan Johnston MCI sip:alan@sipstation.com At 08:07 PM 3/2/2004 -0500, Rosen, Brian wrote: >How are we going to resolve this? > >Most of us are here. Can we get together? > >Brian > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Tuesday, March 02, 2004 6:44 PM > > To: Niemi Aki (Nokia-M/Espoo) > > Cc: ext Rosen, Brian; ext Jonathan Rosenberg; > > Markus.Isomaki@nokia.com; > > hisham.khartabil@nokia.com; Miguel.An.Garcia@nokia.com; > > simple@ietf.org > > Subject: Re: [Simple] Chat sessions > > > > > > > > > > Niemi Aki (Nokia-M/Espoo) wrote: > > > > > >>> Of course you can't do private messages with voice. Voice > > and IM are > > >>> inherently different. You can't send private voice > > packets to another > > >>> participant of a conference, simply because there isn't a way to > > >>> single out a participant in a conference by directly addressing > > >>> packets there. It also makes mixing really complicated, because a > > >>> private voice stream might overlap with the rest of the > > conference. > > >>> These don't present a problem for IM; the sender can > > single out the > > >>> recipient using the cpim To header field and the recipient UA can > > >>> simply mark a message as private and render it to the > > same UI as the > > >>> rest of the IMs in that conference. > > >> > > >> I protest. There is no logical difference. There is no protocol > > >> difference. In most cases, there is no practical difference. You > > >> send media to some address, you get media from some address. You > > >> render it. IM or voice or video is all just media, and its handled > > >> the same way. You might have "centralized" or > > "distributed" mixers. > > >> Most IM systems, as implemented, are centralized mixers. You send > > >> all media to the mixer, it sends media to you. There is nothing > > >> special with IM. You need some signaling for a private message. > > >> You can use the same signaling for a sidebar or a whisper. > > > > > > Hmm.. which systems are these? The ones I've used have both private > > > messages *and* sidebars. > > > > It seems that in principle the difference between sidebars > > and private > > messages is simply one of UI design. A particular client > > could support > > one or the other, or both. > > > > But you also seem to require that the initiator be able to > > choose which > > user experience the recipients will have. That turns it into > > a protocol > > issue. In general I would consider this a bad idea. But it is > > largely a > > human factors issue, and I don't feel qualified to comment on > > it except > > from the perspective of personal preference. But it seems that whole > > discussion hinges on whether there is a valid requirement for giving > > senders that degree of control over recipients. > > > > Paul > > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Fri Mar 19 16:28:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24707 for ; Fri, 19 Mar 2004 16:28:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RX5-0001UD-DR for xcon-archive@odin.ietf.org; Fri, 19 Mar 2004 16:28:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JLRxDg005709 for xcon-archive@odin.ietf.org; Fri, 19 Mar 2004 16:27:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RX5-0001U0-5Z for xcon-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 16:27: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 QAA24581 for ; Fri, 19 Mar 2004 16:27:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4RX3-0004bZ-00 for xcon-web-archive@ietf.org; Fri, 19 Mar 2004 16:27:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4RVg-0004K1-00 for xcon-web-archive@ietf.org; Fri, 19 Mar 2004 16:26:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4RUG-0003yZ-00 for xcon-web-archive@ietf.org; Fri, 19 Mar 2004 16:25:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RUF-0000pK-I9; Fri, 19 Mar 2004 16:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RTx-0000oc-Sb for xcon@optimus.ietf.org; Fri, 19 Mar 2004 16:24: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 QAA23981 for ; Fri, 19 Mar 2004 16:24:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4RTv-0003uz-00 for xcon@ietf.org; Fri, 19 Mar 2004 16:24:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4RSO-0003YK-00 for xcon@ietf.org; Fri, 19 Mar 2004 16:23:10 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1B4RQk-00034e-00 for xcon@ietf.org; Fri, 19 Mar 2004 16:21:26 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 19 Mar 2004 13:19:40 -0800 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2JLKpUk002514; Fri, 19 Mar 2004 16:20:52 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-128.cisco.com [64.100.229.128]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AXW00724; Fri, 19 Mar 2004 13:20:50 -0800 (PST) Message-Id: <4.3.2.7.2.20040319160917.00ba3da0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 19 Mar 2004 16:20:50 -0500 To: Paul Kyzivat From: Michael Hammer Subject: Re: [XCON] Open Issue: Hideable Participants Cc: Rohan Mahy , xcon@ietf.org, Eric Burger , "Rosen, Brian" , "'Kozdon, Peter'" , "'Adam Roach'" In-Reply-To: <40538AB9.9050405@cisco.com> References: <313680C9A886D511A06000204840E1CF070B64E4@whq-msgusr-02.pit.comms.marconi.com> <4050D69C.10502@cisco.com> <8CC600C8-73C1-11D8-8BC0-0003938AF740@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Likewise to the whole thread. (Apologies for the late comment.) A user may not care whether an indicator is a primitive (attribute?) or a constructor (role?), but when I read the list of values suggested in this list thus far it is not clear to me which ones other than perhaps message-taker (a little vague as to what that means -- verbatim or summary) or recorder will result in someone playing my words back to me and making me eat them. For legal purposes, any participant that records the conversation (probably audio or video) will need to have an unambiguous indication to each participant. Facilitator and automaton do not tell me much of anything. Also, I would suggest (to keep clear of lawful intercept stuff) to describe this as "Displayable Participants". As Paul notes, this is really a UI issue, based on useful indications in the protocol. Mike At 05:27 PM 3/13/2004 -0500, Paul Kyzivat wrote: >Replying to this whole thread, not just to Rohan... > >It seems to me that this discussion is replicating that which took place >around presence, in how to define "services". I have the impression that >what Brian is calling "role" here is similar to what others have called >"service" there. > >In the presence case we could find no useful unique way to define a >service, and decided it was largely in the eye of the beholder. So we >decided that we should just describe the features of a presentity, and let >the watchers interpret certain collections of features as a service. > >The same should work here, although the application is a bit simpler. It >is simply a matter of a client deciding what combination of features >constitue a participant that is/isn't interesting to that client. > >Whether "hideable" is a distinct feature is a separate question. I am >inclined to think it is not, because whether something is hideable is a >subjective decision, and not everyone will want to make the same decision. > > Paul > >Rohan Mahy wrote: >>Paul, >>On Mar 11, 2004, at 1:14 PM, Paul Kyzivat wrote: >> >>>Lets not get hung up on whether we call it a role or an attribute. Many >>>of the callee-caps things can be considered to be roles. >>> >>>Regarding Rohan saying there is another new attribute - I don't know >>>what that is. Are you talking about a "hideable" attribute? I don't >>>think that makes much sense. It puts the responsibility on the focus to >>>decide what should be hideable. >> >>yes. It makes the focus responsible for setting and believing this >>attribute. I think this is an excellent thing. IMO, the focus is the >>only entity that can do a reasonable job of this. >> >>>I think it is better for clients to each decide what they do/don't want >>>to see. I may want to hide automata and attendants except that I want to >>>see recorders. You may just decide to hide automata. >> >>feel free to do that, but you may not like the results. what if the >>predominantly interesting thing in the conference is an automaton with >>VCR-style controls that the humans in the group are annotating? What if >>the automata is providing other useful information as a participant >>(rendering a summary of last months sales figures for example). I think >>the "ignore automatons" approach. It also doesn't allow you to ignore >>the "tea lady" participant or the "human scribe" participant. >> >>>Regarding how to denote a recorder, I think the existing message-taker >>>feature tag is probably close enough for the purpose. >> >>this may be reasonable, but there are slightly different routing >>semantics if I want my call routed to someone/something who can take a >>message for me, and something that just records what I said. >> >>>I think what we are talking about can be achieved by exposing the >>>contact parameters from each participant in CPCP. >> >>sometimes. >>thanks, >>-r >> >>> Paul >>> >>>Rosen, Brian wrote: >>> >>>>What attributes does an IVR box have besides automaton? >>>>How about a caption service? >>>>If we create a caps for each service, all orthogonal, is that >>>>you think makes sense? >>>>These are all roles, they are not attributes. >>>>Brian >>>> >>>>>-----Original Message----- >>>>>From: Rohan Mahy [mailto:rohan@cisco.com] >>>>>Sent: Thursday, March 11, 2004 3:47 PM >>>>>To: Rosen, Brian >>>>>Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam >>>>>Roach' >>>>>Subject: Re: [XCON] Open Issue: Hideable Participants >>>>> >>>>> >>>>>Hi, >>>>> >>>>>I'd like to apologize to the group that some of these >>>>>ideas are SIP-specific or very SIP influenced >>>>> >>>>>Here are the binary or ternary attributes that already exist from >>>>>draft-ietf-sip-callee-caps: >>>>> >>>>>automaton/human >>>>>personal/business >>>>>mobile/fixed >>>>>duplex/send-only/receive-only >>>>> >>>>>these are 100% orthogonal with respect to each other >>>>> >>>>>Various folks have proposed that we need the following additional >>>>>attributes in various parts of conferencing and/or signaling: >>>>> >>>>>interactive/noninteractive >>>>>anonymous/identified >>>>> >>>>>(again, these are 100% orthogonal with respect to each other and the >>>>>other attributes) >>>>> >>>>>finally I am proposing this new attribute we have been describing >>>>>here. I believe this is still highly orthogonal to the other attributes. >>>>> >>>>>I believe this new attribute is more appropriate than an enumerations >>>>>for two main reasons: >>>>> >>>>>1) you can code behavior based on the presence of the attribute >>>>>directly rather than checking for a bunch different roles and then >>>>>making sure there are not conditions attached to those roles. >>>>>2) it allows a new thing/role to exist which we haven't thought of yet >>>>>that can still unambiguously provide its attributes. existing code >>>>>will work quite well with this new thing if it describes itself using >>>>>(in part) a number of existing attributes. >>>>> >>>>>thanks, >>>>>-rohan >>>>> >>>>> >>>>>On Mar 11, 2004, at 11:29 AM, Rosen, Brian wrote: >>>>> >>>>> >>>>>>Rohan >>>>>> >>>>>>I'm not sure I agree. I clearly do want to provide >>>>> >>>>> >>>>>information across >>>>> >>>>>>the wire unambiguously, but I don't think a lot of binary attributes >>>>>>is a good way to do that. I think we are talking about a >>>>> >>>>> >>>>>role, rather >>>>> >>>>>>than an attribute. A single automaton, like a single >>>>> >>>>> >>>>>human, is capable >>>>> >>>>>>of multiple roles, so you need a list in both cases. >>>>>> >>>>>>Brian >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Rohan Mahy [mailto:rohan@cisco.com] >>>>>>>Sent: Thursday, March 11, 2004 2:24 PM >>>>>>>To: Rosen, Brian >>>>>>>Cc: xcon@ietf.org; Eric Burger; Rohan Mahy; 'Kozdon, Peter'; 'Adam >>>>>>>Roach' >>>>>>>Subject: Re: [XCON] Open Issue: Hideable Participants >>>>>>> >>>>>>> >>>>>>>Brian, >>>>>>> >>>>>>>There are many different orthogonal attributes we should be >>>>>>>able to get >>>>>>>access to. This "non-interesting" participant or "facilitator" >>>>>>>attribute is orthogonal to your status as an automaton or human. I >>>>>>>don't think an enumeration here is a good substitute for this >>>>>>>attribute. It may be that indicating a recorder is a good >>>>>>>value to add >>>>>>>to the "actor" media feature tag, which currently has a msg-taker >>>>>>>value, or that we can reuse the msg-taker value for the >>>>>>>recorder. The >>>>>>>goal is maximum orthogonality. We probably can't achieve complete >>>>>>>orthogonality but I think we can get very close. >>>>>>> >>>>>>>thanks, >>>>>>>-rohan >>>>>>> >>>>>>> >>>>>>>On Mar 11, 2004, at 6:14 AM, Rosen, Brian wrote: >>>>>>> >>>>>>> >>>>>>>>Seems to me that you are on the right track, but we need to >>>>>>> >>>>>>> >>>>>>>go farther. >>>>>>> >>>>>>>>We have to classify these participants so that the UI, if >>>>>>> >>>>>>> >>>>>>>it wanted to, >>>>>>> >>>>>>>>could render an appropriate indication. The example of >>>>>>> >>>>>the recorder >>>>> >>>>>>>>is pretty compelling. Just knowing that there is an automaton out >>>>>>>>there >>>>>>>>is one thing. Knowing its a recorder is another. So, really you >>>>>>>>don't want a flag, you want an enunumeration. It may actually be >>>>>>>>a list, because a single automaton could have multiple functions. >>>>>>>> >>>>>>>>Brian >>>>>>>> >>>>>>>> >>>>>>>>>-----Original Message----- >>>>>>>>>From: Adam Roach [mailto:adam@dynamicsoft.com] >>>>>>>>>Sent: Thursday, March 11, 2004 12:27 AM >>>>>>>>>To: 'Kozdon, Peter'; Eric Burger; xcon@ietf.org >>>>>>>>>Subject: RE: [XCON] Open Issue: Hideable Participants >>>>>>>>> >>>>>>>>> >>>>>>>>>[not as chair] >>>>>>>>> >>>>>>>>>I don't think anyone is currently arguing whether indication >>>>>>>>>of such automata should be available to the users. Most >>>>>>>>>of what I've heard people say on this list -- after Korea, >>>>>>>>>at least -- seems to agree that such elements *should* >>>>>>>>>be indicated in the protocol. Note that this is not the >>>>>>>>>same thing as saying that they must be forcibly rendered >>>>>>>>>to users regardless of the users want, which is what you >>>>>>>>>seem to be arguing for. >>>>>>>>> >>>>>>>>>What I've heard -- and I agree with this viewpoint -- is >>>>>>>>>that there should be some flag that indicates "this element >>>>>>>>>is a facilitator, not a participant," so that users who don't >>>>>>>>>*care* about seeing such elements (existence proof: me) >>>>>>>>>could configure their clients not to display them. >>>>>>>>> >>>>>>>>>To expand on the flag's meaning, it would make the most >>>>>>>>>sense to have it mean more precisely "this element is not >>>>>>>>>truly a participant, but is providing some service related >>>>>>>>>to the conference." In other words, I would want it to >>>>>>>>>cover e.g. human transcribers, human translators, etc., >>>>>>>>>in addition to automata. >>>>>>>>> >>>>>>>>>As Eric points out, I think people are getting hung up on >>>>>>>>>the name without thinking the issue through completely. >>>>>>>>>I've updated the subject line accordingly. >>>>>>>>> >>>>>>>>>/a >>>>>>>>> >>>>>>>>> >>>>>>>>>>-----Original Message----- >>>>>>>>>>From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>>>>>>>>Sent: Wednesday, March 10, 2004 20:50 >>>>>>>>>>To: Eric Burger; xcon@ietf.org >>>>>>>>>>Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>I agree that automatons are processing resources and could be >>>>>>>>>>considered as >>>>>>>>>>logical parts of the conference fabric, for example an IVR >>>>>>>>>>could monitor the >>>>>>>>>>conference and provide a trigger in response to a phrase >>>>>>>>> >>>>>>>>> >>>>>>>>>that could be >>>>>>>>> >>>>>>>>>>consumed elsewhere. Similarly a device that announces >>>>>>>>>>participants, etc.. >>>>>>>>>>However, IMHO a conference recorder does not fall into this >>>>>>>>>>category and >>>>>>>>>>should probably be a visible resource maybe with an >>>>>>>>> >>>>>>>>> >>>>>>>>>indicator to show >>>>>>>>> >>>>>>>>>>whether it is or is not active. Similarly - a player >>>>>>>>> >>>>>>>resources which >>>>>>> >>>>>>>>>>delivers content or information to the conference should also >>>>>>>>>>be visible - >>>>>>>>>>it seems desirable to know where such content is coming from. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>-----Original Message----- >>>>>>>>>>From: Eric Burger [mailto:eburger@snowshore.com] >>>>>>>>>>Sent: Tuesday, March 09, 2004 1:28 PM >>>>>>>>>>To: Kozdon, Peter; xcon@ietf.org >>>>>>>>>>Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>>>>> >>>>>>>>>>I think we got caught up on the name. >>>>>>>>>> >>>>>>>>>>There are two needs. >>>>>>>>>> >>>>>>>>>>The first, which I think we may have consensus on, is the >>>>>>>>>>need for anonymous >>>>>>>>>>participants. That is, participants that are present in the >>>>>>>>>>conference, but >>>>>>>>>>do not have their identities revealed. >>>>>>>>>> >>>>>>>>>>The second, which is more blurry, is the need for >>>>>>>>>>participants that are >>>>>>>>>>truly hidden. Some want to use hidden participants for >>>>>>>>>>automatons, e.g., >>>>>>>>>>IVR systems or conference recorders. (IMHO, bad idea, but >>>>>>>>>>that is really >>>>>>>>>>just MHO, not strictly black-and-white.) >>>>>>>>>> >>>>>>>>>>We do have consensus that Lawful Intercept is entirely >>>>>>>>> >>>>>>>orthogonal to >>>>>>> >>>>>>>>>>conference participants. However, the logic of the above >>>>>>>>>>follows. Just as >>>>>>>>>>IVR systems or conference recorders are not really >>>>>>>>>>participants, neither is >>>>>>>>>>LI hardware. If we say that the approach for IVR is to plumb >>>>>>>>>>in as a hidden >>>>>>>>>>participant, then LI would have the same approach. If we say >>>>>>>>>>that IVR is >>>>>>>>>>something different, e.g., just a part of the conference >>>>>>>>>>mixer, then it is >>>>>>>>>>truly "not there". Likewise, I would expect LI to be >>>>>>>>> >>>>>>>"not there" -- >>>>>>> >>>>>>>>>>something outside the XCON framework entirely. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>-----Original Message----- >>>>>>>>>>>From: Kozdon, Peter [mailto:Peter.Kozdon@icn.siemens.com] >>>>>>>>>>>Sent: Monday, March 08, 2004 6:28 PM >>>>>>>>>>>To: 'xcon@ietf.org' >>>>>>>>>>>Subject: RE: [XCON] Open Issue: Hidden Participants >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>Hidden listeners operation is probably illegal in many US >>>>>>>>>> >>>>>>>>>states as >>>>>>>>> >>>>>>>>>>>well as in many countries - when you make a call there is a >>>>>>>>>>>requirement in California the all parties are aware of the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>presence of >>>>>>>>>> >>>>>>>>>>>a 3rd party or recording device, note- that party may be >>>>>>>>>> >>>>>>>>>anonymous, >>>>>>>>> >>>>>>>>>>>etc.. >>>>>>>>>>>(Exception -- >>>>>>>>>>>legal intercept.) >>>>>>>>>>> >>>>>>>>>>>We should follow the similar logic for XCON - provide an >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>indication of >>>>>>>>>> >>>>>>>>>>>a recording device and/or anonymous participant's) >>>>>>>>>>> >>>>>>>>>>>Peter Kozdon >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>-----Original Message----- >>>>>>>>>>>From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On >>>>>>>>>> >>>>>>>>>Behalf Of >>>>>>>>> >>>>>>>>>>>Adam Roach >>>>>>>>>>>Sent: Monday, March 08, 2004 12:04 PM >>>>>>>>>>>To: 'xcon@ietf.org' >>>>>>>>>>>Subject: [XCON] Open Issue: Hidden Participants >>>>>>>>>>> >>>>>>>>>>>[as chair] >>>>>>>>>>> >>>>>>>>>>>At the XCON meeting, there was a rather lively discussion that >>>>>>>>>>>continued the "Hidden Participants" discussion that had >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>started on the >>>>>>>>>> >>>>>>>>>>>list. It was agreed that the topic was worth discussion, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>but that we >>>>>>>>>> >>>>>>>>>>>did not have enough time to pursue it in the meeting. >>>>>>>>>>> >>>>>>>>>>>I'm calling on everyone, especially those involved in >>>>>>>>>> >>>>>the meeting >>>>> >>>>>>>>>>>discussion (Rohan, Alan, Eric, Roni, Hisham, Dave) to >>>>>>>>>> >>>>>>>>>continue this >>>>>>>>> >>>>>>>>>>>discussion so we can close this issue in the near future. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>Alan and I >>>>>>>>>> >>>>>>>>>>>would like to be able to last-call this document shortly, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>and this is >>>>>>>>>> >>>>>>>>>>>the key issue that needs to be resolved before a new >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>revision of the >>>>>>>>>> >>>>>>>>>>>draft can be produced. >>>>>>>>>>> >>>>>>>>>>>/a >>>>>>>>>>> >>>>>>>>>>>_______________________________________________ >>>>>>>>>>>XCON mailing list >>>>>>>>>>>XCON@ietf.org >>>>>>>>>>>https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>>>>> >>>>>>>>>>>_______________________________________________ >>>>>>>>>>>XCON mailing list >>>>>>>>>>>XCON@ietf.org >>>>>>>>>>>https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>_______________________________________________ >>>>>>>>>>XCON mailing list >>>>>>>>>>XCON@ietf.org >>>>>>>>>>https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>>> >>>>>>>>>_______________________________________________ >>>>>>>>>XCON mailing list >>>>>>>>>XCON@ietf.org >>>>>>>>>https://www1.ietf.org/mailman/listinfo/xcon >>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>XCON mailing list >>>>>>>>XCON@ietf.org >>>>>>>>https://www1.ietf.org/mailman/listinfo/xcon >>>>>>> >>>>_______________________________________________ >>>>XCON mailing list >>>>XCON@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/xcon >>> > > >_______________________________________________ >XCON mailing list >XCON@ietf.org >https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Mar 22 13:11:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09692 for ; Mon, 22 Mar 2004 13:11: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 1B5Tt3-0000Hs-Pu for xcon-archive@odin.ietf.org; Mon, 22 Mar 2004 13:10:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MIAvso001097 for xcon-archive@odin.ietf.org; Mon, 22 Mar 2004 13:10:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Tt3-0000Hb-Iz for xcon-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 13:10: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 NAA09658 for ; Mon, 22 Mar 2004 13:10:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Tt1-0005Dz-00 for xcon-web-archive@ietf.org; Mon, 22 Mar 2004 13:10:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Ts6-00055O-00 for xcon-web-archive@ietf.org; Mon, 22 Mar 2004 13:09:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5TrP-0004x0-00 for xcon-web-archive@ietf.org; Mon, 22 Mar 2004 13:09:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Tr1-0008RK-Sl; Mon, 22 Mar 2004 13:08:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Tp8-0008D2-OK for xcon@optimus.ietf.org; Mon, 22 Mar 2004 13:06: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 NAA09467 for ; Mon, 22 Mar 2004 13:06:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Tp6-0004f4-00 for xcon@ietf.org; Mon, 22 Mar 2004 13:06:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5ToD-0004Xr-00 for xcon@ietf.org; Mon, 22 Mar 2004 13:05:57 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1B5Tni-0004O5-00 for xcon@ietf.org; Mon, 22 Mar 2004 13:05:26 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i2MI4mTY005149 for ; Mon, 22 Mar 2004 12:04:48 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Mar 2004 12:04:48 -0600 Message-ID: <9ACE0CEE075B494096C86C23878BF85906A3DB@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'xcon@ietf.org'" Date: Mon, 22 Mar 2004 12:04:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [XCON] Reminder: FC Reqs last call Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 As a reminder, we are currently conducting a last call for the Floor Control Requirements document. This last call period has two weeks remaining. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Mar 22 16:46:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26784 for ; Mon, 22 Mar 2004 16:46:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5XF5-0004va-Np for xcon-archive@odin.ietf.org; Mon, 22 Mar 2004 16:45:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MLjtpq018936 for xcon-archive@odin.ietf.org; Mon, 22 Mar 2004 16:45:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5XF5-0004vL-DM for xcon-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 16:45: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 QAA26771 for ; Mon, 22 Mar 2004 16:45:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5XF3-0003LU-00 for xcon-web-archive@ietf.org; Mon, 22 Mar 2004 16:45:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5XE5-0003Cm-00 for xcon-web-archive@ietf.org; Mon, 22 Mar 2004 16:44:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5XDD-00033Q-00 for xcon-web-archive@ietf.org; Mon, 22 Mar 2004 16:43:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5XDE-0004qe-8V; Mon, 22 Mar 2004 16:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5X5c-0003iu-IA for xcon@optimus.ietf.org; Mon, 22 Mar 2004 16:36: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 QAA25877 for ; Mon, 22 Mar 2004 16:36:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5X5a-0001fs-00 for xcon@ietf.org; Mon, 22 Mar 2004 16:36:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5X4K-0001Wm-00 for xcon@ietf.org; Mon, 22 Mar 2004 16:34:49 -0500 Received: from [195.7.64.137] (helo=mail3.pi.se ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B5X3o-0001R7-00; Mon, 22 Mar 2004 16:34:17 -0500 Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) (authenticated (0 bits)) by mail3.pi.se (8.12.10/8.11.2) with ESMTP id i2MLVfLX029511; Mon, 22 Mar 2004 22:31:43 +0100 (CET) From: "Gunnar Hellstrom" To: "XCON" , "SIMPLE" , "Alan Johnston" , "Rosen, Brian" , "'Paul Kyzivat'" , "Niemi Aki \(Nokia-M/Espoo\)" Date: Mon, 22 Mar 2004 22:34:09 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5.2.1.1.0.20040319121725.02eb0ad0@pop.mcit.com> Importance: Normal Content-Transfer-Encoding: 7bit Subject: [XCON] RE: [Simple] RE: Chat sessions Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Text conferencing does not need to be a sidebar. I see text usage in a conference setting divided mainly in two variants. 1. Real time text in the main conference. ------------------------------------------- There is a valid use of real time text as part of the main conference. That is for all kinds of real time "subtitling" of a conference. The reason may be that the audience is of mixed language background, and need a typed translation while the main voice medium is left as it is. Another reason may be that there are participants who cannot hear the voice, and need to see it typed. This type of text conferencing need to be real time, character by character ( or close to that ). Since it should flow together with other media in real time, I think it is most natural to implement it with the text transmitted as a streaming media in RTP, as specified by RFC2793 and RFC2793bis, and initiated with the other real time media audio and video with SDP at session initiation time. It is the extension of the real time point to point call into the multipoint world. The three natural media are video, text and audio. One natural way to display it, if video is also included, is to display text under the video image of the person sending the text, or the person being text-interpreted. 2. Text Chat messaging in Chat rooms and sidebars --------------------------------------------------- For the sidebar text Chat rooms, I would expect that the users often are more happy to see the discussion message wise. They can then concentrate on the main conference and occationally look at the sidebar if there are new messages there. That would be the SIMPLE traditional IM view of text. Would it be OK to use the term "text conferencing" for no 1, and "Chat rooms" for no 2 ? I expect XCON to mainly concentrate on no 1, and SIMPLE on no. 2. Therefore I post this to both groups. Regards Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > Alan Johnston > Sent: Friday, March 19, 2004 7:21 PM > To: Rosen, Brian; 'Paul Kyzivat'; Niemi Aki (Nokia-M/Espoo) > Subject: [Simple] RE: Chat sessions > > > As a result of this thread, in Korea, a group of us (roughly > myself, Brian, > Hisham, Aki, Paul, Markus - apologies to others who I might have > forgotten) > met to discuss "chat rooms" and text conferencing. > > Here is what the consensus of the participants was: > > There is a need to document aspects of "chat rooms" or text > conferencing. > > There seems to be a need to have a request/response kind of > subset of conferencing (sidebar) AS WELL AS an immediate > no request/response subset of conferencing (private message / > whisper). This need is not specific to media, although the > exact mechanism to establish it might be media dependent. > Media Policy is a media independent mechanism, but others > may be more appropriate, especially for IM. This work > will at least begin in XCON. > > In addition, the absence of an ability to express a nickname > in SIP was identified as an area for future SIP work. > > Thanks, > Alan Johnston > MCI > sip:alan@sipstation.com > > At 08:07 PM 3/2/2004 -0500, Rosen, Brian wrote: > >How are we going to resolve this? > > > >Most of us are here. Can we get together? > > > >Brian > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Tuesday, March 02, 2004 6:44 PM > > > To: Niemi Aki (Nokia-M/Espoo) > > > Cc: ext Rosen, Brian; ext Jonathan Rosenberg; > > > Markus.Isomaki@nokia.com; > > > hisham.khartabil@nokia.com; Miguel.An.Garcia@nokia.com; > > > simple@ietf.org > > > Subject: Re: [Simple] Chat sessions > > > > > > > > > > > > > > > Niemi Aki (Nokia-M/Espoo) wrote: > > > > > > > >>> Of course you can't do private messages with voice. Voice > > > and IM are > > > >>> inherently different. You can't send private voice > > > packets to another > > > >>> participant of a conference, simply because there isn't a way to > > > >>> single out a participant in a conference by directly addressing > > > >>> packets there. It also makes mixing really complicated, because a > > > >>> private voice stream might overlap with the rest of the > > > conference. > > > >>> These don't present a problem for IM; the sender can > > > single out the > > > >>> recipient using the cpim To header field and the recipient UA can > > > >>> simply mark a message as private and render it to the > > > same UI as the > > > >>> rest of the IMs in that conference. > > > >> > > > >> I protest. There is no logical difference. There is no protocol > > > >> difference. In most cases, there is no practical difference. You > > > >> send media to some address, you get media from some address. You > > > >> render it. IM or voice or video is all just media, and > its handled > > > >> the same way. You might have "centralized" or > > > "distributed" mixers. > > > >> Most IM systems, as implemented, are centralized mixers. You send > > > >> all media to the mixer, it sends media to you. There is nothing > > > >> special with IM. You need some signaling for a private message. > > > >> You can use the same signaling for a sidebar or a whisper. > > > > > > > > Hmm.. which systems are these? The ones I've used have both private > > > > messages *and* sidebars. > > > > > > It seems that in principle the difference between sidebars > > > and private > > > messages is simply one of UI design. A particular client > > > could support > > > one or the other, or both. > > > > > > But you also seem to require that the initiator be able to > > > choose which > > > user experience the recipients will have. That turns it into > > > a protocol > > > issue. In general I would consider this a bad idea. But it is > > > largely a > > > human factors issue, and I don't feel qualified to comment on > > > it except > > > from the perspective of personal preference. But it seems that whole > > > discussion hinges on whether there is a valid requirement for giving > > > senders that degree of control over recipients. > > > > > > Paul > > > > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Mar 22 17:19:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28842 for ; Mon, 22 Mar 2004 17:19: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 1B5Xkb-0006yt-Ff for xcon-archive@odin.ietf.org; Mon, 22 Mar 2004 17:18:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MMIJiw026788 for xcon-archive@odin.ietf.org; Mon, 22 Mar 2004 17:18:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5XkR-0006xe-4s for xcon-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 17:18: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 RAA28510 for ; Mon, 22 Mar 2004 17:18:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5XkI-00075b-00 for xcon-web-archive@ietf.org; Mon, 22 Mar 2004 17:18:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Xj1-0006ps-00 for xcon-web-archive@ietf.org; Mon, 22 Mar 2004 17:16:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5XiF-0006jl-00 for xcon-web-archive@ietf.org; Mon, 22 Mar 2004 17:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5XiE-0006by-7t; Mon, 22 Mar 2004 17:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Xi6-0006au-H9 for xcon@optimus.ietf.org; Mon, 22 Mar 2004 17:15: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 RAA28393 for ; Mon, 22 Mar 2004 17:15:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Xi4-0006jG-00 for xcon@ietf.org; Mon, 22 Mar 2004 17:15:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Xh7-0006dH-00 for xcon@ietf.org; Mon, 22 Mar 2004 17:14:54 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1B5Xgm-0006X7-00; Mon, 22 Mar 2004 17:14:32 -0500 Received: from softarmor.com (www.softarmor.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id i2MMGopF027788; Mon, 22 Mar 2004 16:16:50 -0600 Message-ID: <405F65D1.8010605@softarmor.com> Date: Mon, 22 Mar 2004 16:16:49 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xcon@ietf.org CC: sipping@ietf.org;, Glenn Parsons , sip@ietf.org, simple@ietf.org References: <405E7C1D.1080301@softarmor.com> In-Reply-To: <405E7C1D.1080301@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [XCON] Oops, XCON Too! -- Was: Proposed dates for SIPish interim meetings Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Your sentience challenged scribe (that's me) forot to include XCON in the original list. It's not because I think they're not important. It's because I forgot. This MIGHT have something to do with having spent the weekend scraping old vinyl flooring loose from the concrete slab of my house, as my water heater ruptured while we were in Korea and much sogginess ensued. Or I might not have an excuse. Anyhow, topics addressed in the interim meeting will include SIP, SIPPING, SIMPLE, and XCON (where I REALLY want progress on floor control, especially after last weekend's labors!). And maybe LEMONADE, although the current drift in responses is that there is little need for co-location here. Follow-ups to SIPPING, please. -- Dean Dean Willis wrote: > Please reply to the SIPPING list -- other lists copied to make sure we > hit everybody. > > We probably need to have at least three days of interim meetings between > now and IETF 60, covering topics in SIP, SIPPING, and SIMPLE. > > We've had a number of venue suggestions in the USA, and it has been > suggested that a Tuesday-Thursday schedule would provide the best > opportunities for travelers from more distant points. > > There has also been some discussion of co-locating with the Lemonade > working group, if the venue allows. We're not sure whether this would > mean adding another day fore-or-aft, or simply running another room in > parallel. > > For the record, historically we've had anywhere from 30 to 60 attendees > at interim meetings. > > As I understand it, the leading candidate for venue is the Boulderama in > Boulder, Colorado. Rohan's current proposal is to ask each attendee to > contribute $50 toward meeting fees (princiaplly, renting the room). Of > course, if somebody wants to sponsor the meeting and pick up the > > These dates have been proposed: > > May 4-6 (May conflict with T1-S1) > May 25-27 (conflicts with OMA POC interim) > June 1-3 (no conflicts I know of) > > For planning purposes, it would help to know: > > 1) Who and how many would be able and willing to attend May 4-6? > 2) Who and how many would be able and willing to to attend May 25-27? > 3) Who and how many would be able and willing to to attend June 1-3? > 4) Who would be conflicted if LEMONADE and SIP-related sessions occurred > simultaneously? > 5) Who just doesn't want to go the the US because of travel > restrictions and annoying border delays? > 6) Anyody willing to sponsor or cosponsor the meeting? > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Mar 22 17:39:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29957 for ; Mon, 22 Mar 2004 17:39:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Y4N-00011t-Dm for xcon-archive@odin.ietf.org; Mon, 22 Mar 2004 17:38:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MMctDP003944 for xcon-archive@odin.ietf.org; Mon, 22 Mar 2004 17:38:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Y4M-00011P-Qj for xcon-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 17:38: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 RAA29903 for ; Mon, 22 Mar 2004 17:38:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Y4K-0001uQ-00 for xcon-web-archive@ietf.org; Mon, 22 Mar 2004 17:38:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Y3J-0001oE-00 for xcon-web-archive@ietf.org; Mon, 22 Mar 2004 17:37:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5Y2W-0001iI-00 for xcon-web-archive@ietf.org; Mon, 22 Mar 2004 17:37:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Y2X-0000a4-IY; Mon, 22 Mar 2004 17: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 1B5Y2Q-0000Yp-Eo for xcon@optimus.ietf.org; Mon, 22 Mar 2004 17:36: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 RAA29834 for ; Mon, 22 Mar 2004 17:36:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Y2N-0001hT-00 for xcon@ietf.org; Mon, 22 Mar 2004 17:36:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Y1X-0001bX-00 for xcon@ietf.org; Mon, 22 Mar 2004 17:36:00 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5Y0j-0001Q1-00; Mon, 22 Mar 2004 17:35:09 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Mar 2004 14:39:24 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2MMYaaD010726; Mon, 22 Mar 2004 14:34:37 -0800 (PST) Received: from cisco.com ([161.44.79.74]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGZ74946; Mon, 22 Mar 2004 17:34:35 -0500 (EST) Message-ID: <405F69FA.3040404@cisco.com> Date: Mon, 22 Mar 2004 17:34:34 -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: Gunnar Hellstrom CC: XCON , SIMPLE , Alan Johnston , "Rosen, Brian" , "Niemi Aki (Nokia-M/Espoo)" References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [XCON] Re: [Simple] RE: Chat sessions Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gunnar Hellstrom wrote: > Text conferencing does not need to be a sidebar. > I see text usage in a conference setting divided mainly in two variants. > > 1. Real time text in the main conference. > ------------------------------------------- > There is a valid use of real time text as part of the main conference. That > is for all kinds of real time "subtitling" of a conference. > > The reason may be that the audience is of mixed language background, and > need a typed translation while the main voice medium is left as it is. > > Another reason may be that there are participants who cannot hear the > voice, and need to see it typed. > > This type of text conferencing need to be real time, character by character > ( or close to that ). Since it should flow together with other media in > real time, I think it is most natural to implement it with the text > transmitted as a streaming media in RTP, as specified by RFC2793 and > RFC2793bis, and initiated with the other real time media audio and video > with SDP at session initiation time. > It is the extension of the real time point to point call into the > multipoint world. The three natural media are video, text and audio. > One natural way to display it, if video is also included, is to display > text under the video image of the person sending the text, or the person > being text-interpreted. > > 2. Text Chat messaging in Chat rooms and sidebars > --------------------------------------------------- > For the sidebar text Chat rooms, I would expect that the users often are > more happy to see the discussion message wise. They can then concentrate on > the main conference and occationally look at the sidebar if there are new > messages there. That would be the SIMPLE traditional IM view of text. I think the above are some excellent use cases. (But they aren't the only use cases involving IM and/or Instant Text. > Would it be OK to use the term "text conferencing" for no 1, and "Chat > rooms" for no 2 ? > I expect XCON to mainly concentrate on no 1, and SIMPLE on no. 2. Therefore > I post this to both groups. I think this is too narrow a view. People use IM (message based) chat rooms every day, and this application also must be addressed by XCON. I also see cases where some of the participants don't have the capability to handle all the media in use in the conference. All of audio, video, message based IM, real time text may be in use in the conference. Some participants may have only audio, others only audio/video, others only video and real time text, and perhaps some only IM. Those that don't have all the media may just miss some content, but they may also get some via transcoding. Pretty much every combination has some relevance. And there seems no need to exclude any medium from sidebars, though as you point out, the value proposition for media in sidebars may be different than it is in the main conference. Paul _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Mar 23 03:18:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10869 for ; Tue, 23 Mar 2004 03:18:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5h6u-00022t-4j for xcon-archive@odin.ietf.org; Tue, 23 Mar 2004 03:18:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2N8I8tS007838 for xcon-archive@odin.ietf.org; Tue, 23 Mar 2004 03:18:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5h6s-00022K-Io for xcon-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 03:18: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 DAA10851 for ; Tue, 23 Mar 2004 03:18:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5h6q-0001Yk-00 for xcon-web-archive@ietf.org; Tue, 23 Mar 2004 03:18:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5h5s-0001S8-00 for xcon-web-archive@ietf.org; Tue, 23 Mar 2004 03:17:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5h4t-0001Ld-00 for xcon-web-archive@ietf.org; Tue, 23 Mar 2004 03:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5h4t-0001rl-Ea; Tue, 23 Mar 2004 03:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5h3y-0001pE-TC for xcon@optimus.ietf.org; Tue, 23 Mar 2004 03:15: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 DAA10780 for ; Tue, 23 Mar 2004 03:15:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5h3w-0001Fb-00 for xcon@ietf.org; Tue, 23 Mar 2004 03:15:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5h30-00019e-00 for xcon@ietf.org; Tue, 23 Mar 2004 03:14:07 -0500 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 1B5h2I-000140-00; Tue, 23 Mar 2004 03:13:22 -0500 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id JAA57693; Tue, 23 Mar 2004 09:17:48 +0100 (CET) Received: by ns.ivd.nl (TUNIX txp2/smap) id sma057448; Tue, 23 Mar 04 09:16:59 +0100 Received: from IVD-Message_Server by mailserver.viataal.nl with Novell_GroupWise; Tue, 23 Mar 2004 09:12:43 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Tue, 23 Mar 2004 09:12:26 +0100 From: "A vWijk" To: , , , , , , Subject: Betr.: [XCON] RE: [Simple] RE: Chat sessions Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I fully agree. greetz Arnoud Drs. Arnoud A. T. van Wijk Viataal Research & Development Afdeling RDS Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands. Mobile: +31651921948 International text telephone: +31735588408 >>> "Gunnar Hellstrom" 22-03-04 22:34 >>> Text conferencing does not need to be a sidebar. I see text usage in a conference setting divided mainly in two variants. 1. Real time text in the main conference. ------------------------------------------- There is a valid use of real time text as part of the main conference. = That is for all kinds of real time "subtitling" of a conference. The reason may be that the audience is of mixed language background, and need a typed translation while the main voice medium is left as it is. Another reason may be that there are participants who cannot hear the voice, and need to see it typed. This type of text conferencing need to be real time, character by = character ( or close to that ). Since it should flow together with other media in real time, I think it is most natural to implement it with the text transmitted as a streaming media in RTP, as specified by RFC2793 and RFC2793bis, and initiated with the other real time media audio and video with SDP at session initiation time. It is the extension of the real time point to point call into the multipoint world. The three natural media are video, text and audio. One natural way to display it, if video is also included, is to display text under the video image of the person sending the text, or the person being text-interpreted. 2. Text Chat messaging in Chat rooms and sidebars --------------------------------------------------- For the sidebar text Chat rooms, I would expect that the users often are more happy to see the discussion message wise. They can then concentrate = on the main conference and occationally look at the sidebar if there are new messages there. That would be the SIMPLE traditional IM view of text. Would it be OK to use the term "text conferencing" for no 1, and "Chat rooms" for no 2 ? I expect XCON to mainly concentrate on no 1, and SIMPLE on no. 2. = Therefore I post this to both groups. Regards Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se=20 Gunnar.Hellstrom@Omnitor.se=20 -------------------------------------------- > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > Alan Johnston > Sent: Friday, March 19, 2004 7:21 PM > To: Rosen, Brian; 'Paul Kyzivat'; Niemi Aki (Nokia-M/Espoo) > Subject: [Simple] RE: Chat sessions > > > As a result of this thread, in Korea, a group of us (roughly > myself, Brian, > Hisham, Aki, Paul, Markus - apologies to others who I might have > forgotten) > met to discuss "chat rooms" and text conferencing. > > Here is what the consensus of the participants was: > > There is a need to document aspects of "chat rooms" or text > conferencing. > > There seems to be a need to have a request/response kind of > subset of conferencing (sidebar) AS WELL AS an immediate > no request/response subset of conferencing (private message / > whisper). This need is not specific to media, although the > exact mechanism to establish it might be media dependent. > Media Policy is a media independent mechanism, but others > may be more appropriate, especially for IM. This work > will at least begin in XCON. > > In addition, the absence of an ability to express a nickname > in SIP was identified as an area for future SIP work. > > Thanks, > Alan Johnston > MCI > sip:alan@sipstation.com=20 > > At 08:07 PM 3/2/2004 -0500, Rosen, Brian wrote: > >How are we going to resolve this? > > > >Most of us are here. Can we get together? > > > >Brian > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > > > Sent: Tuesday, March 02, 2004 6:44 PM > > > To: Niemi Aki (Nokia-M/Espoo) > > > Cc: ext Rosen, Brian; ext Jonathan Rosenberg; > > > Markus.Isomaki@nokia.com; > > > hisham.khartabil@nokia.com; Miguel.An.Garcia@nokia.com; > > > simple@ietf.org=20 > > > Subject: Re: [Simple] Chat sessions > > > > > > > > > > > > > > > Niemi Aki (Nokia-M/Espoo) wrote: > > > > > > > >>> Of course you can't do private messages with voice. Voice > > > and IM are > > > >>> inherently different. You can't send private voice > > > packets to another > > > >>> participant of a conference, simply because there isn't a way to > > > >>> single out a participant in a conference by directly addressing > > > >>> packets there. It also makes mixing really complicated, because = a > > > >>> private voice stream might overlap with the rest of the > > > conference. > > > >>> These don't present a problem for IM; the sender can > > > single out the > > > >>> recipient using the cpim To header field and the recipient UA = can > > > >>> simply mark a message as private and render it to the > > > same UI as the > > > >>> rest of the IMs in that conference. > > > >> > > > >> I protest. There is no logical difference. There is no protocol > > > >> difference. In most cases, there is no practical difference. = You > > > >> send media to some address, you get media from some address. You > > > >> render it. IM or voice or video is all just media, and > its handled > > > >> the same way. You might have "centralized" or > > > "distributed" mixers. > > > >> Most IM systems, as implemented, are centralized mixers. You = send > > > >> all media to the mixer, it sends media to you. There is nothing > > > >> special with IM. You need some signaling for a private message. > > > >> You can use the same signaling for a sidebar or a whisper. > > > > > > > > Hmm.. which systems are these? The ones I've used have both = private > > > > messages *and* sidebars. > > > > > > It seems that in principle the difference between sidebars > > > and private > > > messages is simply one of UI design. A particular client > > > could support > > > one or the other, or both. > > > > > > But you also seem to require that the initiator be able to > > > choose which > > > user experience the recipients will have. That turns it into > > > a protocol > > > issue. In general I would consider this a bad idea. But it is > > > largely a > > > human factors issue, and I don't feel qualified to comment on > > > it except > > > from the perspective of personal preference. But it seems that whole > > > discussion hinges on whether there is a valid requirement for giving > > > senders that degree of control over recipients. > > > > > > Paul > > > > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org=20 > >https://www1.ietf.org/mailman/listinfo/simple=20 > > > _______________________________________________ > Simple mailing list > Simple@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/simple=20 > _______________________________________________ XCON mailing list XCON@ietf.org=20 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 Mar 23 18:27:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11559 for ; Tue, 23 Mar 2004 18:27:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vI9-0002Pz-HH for xcon-archive@odin.ietf.org; Tue, 23 Mar 2004 18:26:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NNQfaQ009294 for xcon-archive@odin.ietf.org; Tue, 23 Mar 2004 18:26:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vI8-0002Pp-W6 for xcon-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 18:26: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 SAA11497 for ; Tue, 23 Mar 2004 18:26:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5vI6-0000d0-00 for xcon-web-archive@ietf.org; Tue, 23 Mar 2004 18:26:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5vHB-0000XZ-00 for xcon-web-archive@ietf.org; Tue, 23 Mar 2004 18:25:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5vGX-0000TJ-00 for xcon-web-archive@ietf.org; Tue, 23 Mar 2004 18:25:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vGZ-0001z2-4m; Tue, 23 Mar 2004 18:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vGD-0001xh-Fe for xcon@optimus.ietf.org; Tue, 23 Mar 2004 18:24: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 SAA11407 for ; Tue, 23 Mar 2004 18:24:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5vGA-0000S1-00 for xcon@ietf.org; Tue, 23 Mar 2004 18:24:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5vFP-0000Mk-00 for xcon@ietf.org; Tue, 23 Mar 2004 18:23:52 -0500 Received: from mail3.pi.se ([195.7.64.137] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B5vES-0000Di-00; Tue, 23 Mar 2004 18:22:53 -0500 Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) (authenticated (0 bits)) by mail3.pi.se (8.12.10/8.11.2) with ESMTP id i2NNK771013503; Wed, 24 Mar 2004 00:20:08 +0100 (CET) From: "Gunnar Hellstrom" To: "Paul Kyzivat" Cc: "XCON" , "SIMPLE" , "Alan Johnston" , "Rosen, Brian" , "Niemi Aki \(Nokia-M/Espoo\)" Date: Wed, 24 Mar 2004 00:22:36 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <405F69FA.3040404@cisco.com> Content-Transfer-Encoding: 7bit Subject: [XCON] RE: [Simple] RE: Chat sessions Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul, OK, I have no problem to widen my view to include your proposed scenarios. They sound plausible. Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, March 22, 2004 11:35 PM > To: Gunnar Hellstrom > Cc: XCON; SIMPLE; Alan Johnston; Rosen, Brian; Niemi Aki (Nokia-M/Espoo) > Subject: Re: [Simple] RE: Chat sessions > > > > > Gunnar Hellstrom wrote: > > Text conferencing does not need to be a sidebar. > > I see text usage in a conference setting divided mainly in two > variants. > > > > 1. Real time text in the main conference. > > ------------------------------------------- > > There is a valid use of real time text as part of the main > conference. That > > is for all kinds of real time "subtitling" of a conference. > > > > The reason may be that the audience is of mixed language > background, and > > need a typed translation while the main voice medium is left as it is. > > > > Another reason may be that there are participants who cannot hear the > > voice, and need to see it typed. > > > > This type of text conferencing need to be real time, character > by character > > ( or close to that ). Since it should flow together with other media in > > real time, I think it is most natural to implement it with the text > > transmitted as a streaming media in RTP, as specified by RFC2793 and > > RFC2793bis, and initiated with the other real time media audio > and video > > with SDP at session initiation time. > > It is the extension of the real time point to point call into the > > multipoint world. The three natural media are video, text and audio. > > One natural way to display it, if video is also included, is to display > > text under the video image of the person sending the text, or > the person > > being text-interpreted. > > > > 2. Text Chat messaging in Chat rooms and sidebars > > --------------------------------------------------- > > For the sidebar text Chat rooms, I would expect that the users > often are > > more happy to see the discussion message wise. They can then > concentrate on > > the main conference and occationally look at the sidebar if > there are new > > messages there. That would be the SIMPLE traditional IM view of text. > > I think the above are some excellent use cases. (But they aren't the > only use cases involving IM and/or Instant Text. > > > Would it be OK to use the term "text conferencing" for no 1, and "Chat > > rooms" for no 2 ? > > I expect XCON to mainly concentrate on no 1, and SIMPLE on no. > 2. Therefore > > I post this to both groups. > > I think this is too narrow a view. People use IM (message based) chat > rooms every day, and this application also must be addressed by XCON. > > I also see cases where some of the participants don't have the > capability to handle all the media in use in the conference. All of > audio, video, message based IM, real time text may be in use in the > conference. Some participants may have only audio, others only > audio/video, others only video and real time text, and perhaps some only > IM. Those that don't have all the media may just miss some content, but > they may also get some via transcoding. Pretty much every combination > has some relevance. > > And there seems no need to exclude any medium from sidebars, though as > you point out, the value proposition for media in sidebars may be > different than it is in the main conference. > > Paul > > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Mon Mar 29 00:37:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25820 for ; Mon, 29 Mar 2004 00:37: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 1B7pSQ-00028p-5J for xcon-archive@odin.ietf.org; Mon, 29 Mar 2004 00:37:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T5bAx1008225 for xcon-archive@odin.ietf.org; Mon, 29 Mar 2004 00:37:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7pSP-00028S-Va for xcon-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 00:37: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 AAA25746 for ; Mon, 29 Mar 2004 00:37:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7pSN-0002rw-00 for xcon-web-archive@ietf.org; Mon, 29 Mar 2004 00:37:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7pRL-0002ff-00 for xcon-web-archive@ietf.org; Mon, 29 Mar 2004 00:36:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7pQK-0002Vc-00 for xcon-web-archive@ietf.org; Mon, 29 Mar 2004 00:35:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7pQM-0001y7-6B; Mon, 29 Mar 2004 00:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7pPW-0001vw-S9 for xcon@optimus.ietf.org; Mon, 29 Mar 2004 00:34: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 AAA25607 for ; Mon, 29 Mar 2004 00:34:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7pPU-0002PH-00 for xcon@ietf.org; Mon, 29 Mar 2004 00:34:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7pOc-0002Iu-00 for xcon@ietf.org; Mon, 29 Mar 2004 00:33:15 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1B7pOI-0002Bt-00 for xcon@ietf.org; Mon, 29 Mar 2004 00:32:54 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i2T5WPT9002566 for ; Sun, 28 Mar 2004 23:32:25 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sun, 28 Mar 2004 23:32:25 -0600 Message-ID: <9ACE0CEE075B494096C86C23878BF85906A404@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'xcon@ietf.org'" Subject: [XCON] Reminder: FC Reqs last call Date: Sun, 28 Mar 2004 23:32:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 As a reminder, we are currently conducting a last call for the Floor Control Requirements document. This last call period ends in one week. Lacking any comments, the chairs will request publication as an RFC at that time. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Mar 30 17:41:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18979 for ; Tue, 30 Mar 2004 17:41: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 1B8Rjk-0006Xa-HH for xcon-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i239RbBp008162 for xcon-archive@odin.ietf.org; Wed, 3 Mar 2004 04:27:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AySen-0001sf-Eo for xcon-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 04:27: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 EAA13524 for ; Wed, 3 Mar 2004 04:26:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AySeU-000736-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 04:26:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AySdN-0006mU-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 04:25:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyScO-0006ZN-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 04:24:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyScQ-00018J-Tp; Wed, 03 Mar 2004 04:24:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRnl-0004is-OM for xcon@optimus.ietf.org; Wed, 03 Mar 2004 03:32: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 DAA10904 for ; Wed, 3 Mar 2004 03:32:04 -0500 (EST) From: petri.koskelainen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRnP-0005Ow-00 for xcon@ietf.org; Wed, 03 Mar 2004 03:32:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRlr-0005FD-00 for xcon@ietf.org; Wed, 03 Mar 2004 03:30:27 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1AyRkx-00056M-00 for xcon@ietf.org; Wed, 03 Mar 2004 03:29:31 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i238TUS19431; Wed, 3 Mar 2004 10:29:30 +0200 (EET) X-Scanned: Wed, 3 Mar 2004 10:28:55 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i238Stmu006461; Wed, 3 Mar 2004 10:28:55 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00wjUFZe; Wed, 03 Mar 2004 10:28:54 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i238Sr701028; Wed, 3 Mar 2004 10:28:53 +0200 (EET) Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Mar 2004 10:28:44 +0200 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Mar 2004 10:28:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Meeting re IM Private Messages Date: Wed, 3 Mar 2004 10:28:43 +0200 Message-ID: <481D6FFB3BD60E4CB590F39C59098400023E0D1B@trebe004.europe.nokia.com> Thread-Topic: [XCON] Meeting re IM Private Messages Thread-Index: AcQA3saP371bk+zpT7yxBYIvmhZlywAGlygQ To: , , X-OriginalArrivalTime: 03 Mar 2004 08:28:44.0210 (UTC) FILETIME=[8A675120:01C400F9] 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, > This, plus today's discussion of nicknames in sipping made me=20 > realize that we seem to have lost a CPCP requirement that a = participant=20 > be able to request identify anonymity with respect to the other=20 > participants in the conference. =20 > I know the design team talked about this long ago. This=20 > information would then be used to override the normal=20 > information provided in the sipping conference package. Current draft says the following: REQ-A6: It MUST be possible to anonymously participate in a conference. -- Petri _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Mar 30 17:54:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21382 for ; Tue, 30 Mar 2004 17:54: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 1B8Rje-0006YH-CD for xcon-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S000g4026587 for xcon-archive@odin.ietf.org; Tue, 27 Jan 2004 19:00:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ald7N-0006jz-BS for xcon-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 18:59: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 SAA01243 for ; Tue, 27 Jan 2004 18:59:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ald7K-0004Fd-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 18:59:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ald5u-0003xN-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 18:58:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ald4s-0003pi-00 for xcon-web-archive@ietf.org; Tue, 27 Jan 2004 18:57:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ald4r-0005A8-C3; Tue, 27 Jan 2004 18:57:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al7qI-0005vw-NE for xcon@optimus.ietf.org; Mon, 26 Jan 2004 09:35: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 JAA07028 for ; Mon, 26 Jan 2004 09:35:56 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al7qG-0000cs-00 for xcon@ietf.org; Mon, 26 Jan 2004 09:35:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al7pP-0000bB-00 for xcon@ietf.org; Mon, 26 Jan 2004 09:35:05 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Al7oT-0000Yj-00 for xcon@ietf.org; Mon, 26 Jan 2004 09:34:06 -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 i0QEXhV19310 for ; Mon, 26 Jan 2004 16:33:43 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 26 Jan 2004 16:33:42 +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 16:33:41 +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 16:33:41 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B186@esebe019.ntc.nokia.com> Thread-Topic: [XCON] CPCP Requirement: Repeat times Thread-Index: AcPkCiwg9yPfTyRES/SIjdRtVeO4hgADmaUg To: , , X-OriginalArrivalTime: 26 Jan 2004 14:33:41.0910 (UTC) FILETIME=[652A6B60:01C3E419] 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 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;=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 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 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Mar 30 18:03:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23819 for ; Tue, 30 Mar 2004 18:03:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjZ-0006Xa-W1 for xcon-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AAEm3q023859 for xcon-archive@odin.ietf.org; Tue, 10 Feb 2004 05:14:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqUuk-0006CR-RL for xcon-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 05:14:46 -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 FAA10059 for ; Tue, 10 Feb 2004 05:14:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqUuh-0004GU-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 05:14:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqUtn-0004Bu-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 05:13:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqUt3-00046s-00 for xcon-web-archive@ietf.org; Tue, 10 Feb 2004 05:13:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqUt5-0005y3-Ai; Tue, 10 Feb 2004 05:13:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqUsr-0005xf-Hi for xcon@optimus.ietf.org; Tue, 10 Feb 2004 05:12:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10000 for ; Tue, 10 Feb 2004 05:12:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqUso-00045y-00 for xcon@ietf.org; Tue, 10 Feb 2004 05:12:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqUrr-00041N-00 for xcon@ietf.org; Tue, 10 Feb 2004 05:11:48 -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 1AqUrE-0003tS-00 for xcon@ietf.org; Tue, 10 Feb 2004 05:11:09 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Feb 2004 02:18:40 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1AAAbu5022407; Tue, 10 Feb 2004 02:10:38 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQD43022; Tue, 10 Feb 2004 02:10:32 -0800 (PST) Date: Tue, 10 Feb 2004 10:45:42 +0100 Subject: Re: [XCON] CPCP Requirement: Hidden Participants Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: , To: From: Rohan Mahy In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797721@esebe019.ntc.nokia.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 7bit Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Well, (hidden) announcement servers are already invited to basic conferences today, so clearly this is not a wacky future requirement. I don't really see what the big deal is in terms of complexity of implementation/specification, but perhaps you can fill me in sometime at SIPit. thx, -r On Tuesday, February 10, 2004, at 09:00 AM, wrote: > We are all creative here and can come up with many use cases and > features, but there is a line that we have to draw in order to get > something finished. We're aiming at basic conferencing first. > > /Hisham > >> -----Original Message----- >> From: ext Rohan Mahy [mailto:rohan@cisco.com] >> Sent: 10.February.2004 02:20 >> To: Eric Burger >> Cc: Khartabil Hisham (Nokia-TP/Helsinki); xcon@ietf.org >> Subject: Re: [XCON] CPCP Requirement: Hidden Participants >> >> >> Hi, >> >> I believe there are plenty of uses for hidden participants. A robot >> that announces folks when they enter or whispers things to you in a >> sidebar via IM should be hidden. They detract from my view of who is >> there. This is very different from anonymous. >> >> thx, >> -rohan >> >> >>>> -----Original Message----- >>>> From: hisham.khartabil@nokia.com >> [mailto:hisham.khartabil@nokia.com] >>>> Sent: Wednesday, February 04, 2004 5:33 AM >>>> To: drage@lucent.com; fluffy@cisco.com; Eric Burger; xcon@ietf.org >>>> Subject: RE: [XCON] CPCP Requirement: Hidden Participants >>>> >>>> I agree with Keith. That's why we removed hidden participants >>>> and are content with anonymous. Legal interception can be >>>> local implementation and policy. >>>> >>>> /Hisham >>>> >>>>> -----Original Message----- >>>>> From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On >>>> Behalf Of ext >>>>> Drage, Keith (Keith) >>>>> Sent: 04.February.2004 11:47 >>>>> To: Cullen Jennings; Eric Burger; XCON-IETF >>>>> Subject: RE: [XCON] CPCP Requirement: Hidden Participants >>>>> >>>>> >>>>> In the current mechanisms I know of for supporting legal >>>>> intercept (in 3GPP), the interceptor would not even be a >>>>> participant, therefore I am not convinced that this is >>>>> relevant to the issue of hidden participants anyway. >>> [snip] >>> >>> >>> _______________________________________________ >>> 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 Mar 30 18:10:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25791 for ; Tue, 30 Mar 2004 18:10: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 1B8RjW-0006a4-Dh for xcon-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB38w3xE006033 for xcon-archive@odin.ietf.org; Wed, 3 Dec 2003 03:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSpf-0001Z7-7X for xcon-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 03:58:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06690 for ; Wed, 3 Dec 2003 03:57:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARSpc-0004hQ-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 03:58:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARSpb-0004hJ-00 for xcon-web-archive@ietf.org; Wed, 03 Dec 2003 03:57:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSpd-0001YL-Jz; Wed, 03 Dec 2003 03:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSos-0001WF-0t for xcon@optimus.ietf.org; Wed, 03 Dec 2003 03:57: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 DAA06640 for ; Wed, 3 Dec 2003 03:56:58 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARSop-0004g0-00 for xcon@ietf.org; Wed, 03 Dec 2003 03:57:11 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ARSoo-0004fx-00 for xcon@ietf.org; Wed, 03 Dec 2003 03:57:10 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB38vAQ19818 for ; Wed, 3 Dec 2003 10:57:10 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Dec 2003 10:57:10 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 3 Dec 2003 10:57:10 +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] Chicken and Egg - Can CPCP create a conference Date: Wed, 3 Dec 2003 10:57:04 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797479@esebe019.ntc.nokia.com> Thread-Topic: [XCON] Chicken and Egg - Can CPCP create a conference Thread-Index: AcO48UzMD2ve4y0ATUy7LcwhKSe1MgAib0yg To: , , , Cc: , , X-OriginalArrivalTime: 03 Dec 2003 08:57:10.0441 (UTC) FILETIME=[6FCE4190:01C3B97B] Content-Transfer-Encoding: quoted-printable Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 02.December.2003 18:28 > To: 'Alan Johnston'; Khartabil Hisham (NMP-MSW/Helsinki); > rohan@cisco.com; pkyzivat@cisco.com > Cc: Mayer Georg (NMP-MSW/Helsinki); oritl@microsoft.com; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference >=20 >=20 > Agree with one nit. >=20 > Every conference starts with a default policy. You then use CPCP to > modify it. The conference service defines the default policy. It may > also enforce limits on what kinds of changes could be made to policy > with CPCP, but that is beyond the scope of our work. The=20 > default policy > for an ad-hoc conference may or may not be different from the default > policy for a pre-scheduled conference; that's an implementation issue. >=20 > If you create a conference ID, connect to the conference policy server > and request it's current conference policy, you should get a coherent > answer. I see it as you connect to conference policy server, create a conference = policy and a conference ID (or get a conference ID assigned to you). = There is no need for a default policy to exist for non ad-hoc = conferences. /Hisham >=20 > > -----Original Message----- > > From: Alan Johnston [mailto:alan.johnston@mci.com] > > Sent: Tuesday, December 02, 2003 10:52 AM > > To: hisham.khartabil@nokia.com; Brian.Rosen@marconi.com; > > rohan@cisco.com; pkyzivat@cisco.com > > Cc: georg.mayer@nokia.com; oritl@microsoft.com; xcon@ietf.org > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > >=20 > >=20 > > At 05:26 PM 12/2/2003 +0200, hisham.khartabil@nokia.com wrote: > >=20 > >=20 > > > > -----Original Message----- > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: 02.December.2003 16:52 > > > > To: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com; > > > > pkyzivat@cisco.com > > > > Cc: alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); > > > > oritl@microsoft.com; xcon@ietf.org > > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a=20 > conference > > > > > > > > > > > > So, two fundamental differences: > > > > 1. You think CPCP has some separate namespace=20 > independent of a URI > > > > (of which a SIP uri is a good, but not exclusive example). > > > > I am opposed to that. A conferenceID is a uri. I can imagine a > > > > specific instance of a conference service that could=20 > have multiple > > > > IDs for the same conference, for example, an H.323 URI=20 > > and a SIP URI > > > > that resolves to the same conference. That's fine, and it's > > > > not subject > > > > to standardization. However, I think that the ID you=20 > use with the > > > > focus is always the ID you use with CPCP for the same=20 > conference. > > > > > >I don't understand why the ID for the conference needs to be=20 > > the same as=20 > > >the ID for the conference policy. > >=20 > > I agree with Brian here. The conference identifier is the=20 > > URI. It is the=20 > > means by which a participant joins the conference and=20 > depends on the=20 > > signaling protocol (SIP, H.323, PSTN, etc.). It can't just=20 > > be some random=20 > > string. This is a fundamental idea in the framework. > >=20 > > >If you look at XCAP list usage for example, you will see=20 > > that the list-URI=20 > > >used when sending SIP SUBSCRIBE requests to the list is not=20 > > the same as=20 > > >the URI used to manipulate the list using XCAP. They=20 > > certainly need to be=20 > > >linked, but not necessarily the same. > >=20 > > I don't understand what you are saying. The policy URI and=20 > > the conference=20 > > URI can not be the same since they are different protocols, right? > >=20 > >=20 > > >Depending on the protocol we chose, a SIP URI can or cannot=20 > > be used to=20 > > >identify a conference policy. > >=20 > > Knowing only the conference URI, it must be possible to=20 > determine the=20 > > conference policy URI. > >=20 > >=20 > > > > > > > > 2. You think ad-hoc conferences don't have policy. I am > > > > fundamentally > > > > opposed to that. Ad-hoc conferences should have all of the > > > > functionality of a pre-established conference and I can't=20 > > imagine any > > > > reason why we can't provide that. > > > > > >If we replicate everything that a scheduled conference can=20 > > have to ad-hoc=20 > > >conferences, then we don't need scheduled conferences at=20 > > all. Perhaps we=20 > > >need to define the scope of an ad-hoc conference. To me an=20 > > ad-hoc is just=20 > > >that; a conference created instantaneously for discussing an=20 > > urgent matter=20 > > >or whatever. You REFER other participants and it terminated=20 > > as soon as the=20 > > >last participant leaves. There are no start and stop times,=20 > > there are no=20 > > >dial-out and dial-in lists configured, there is no general=20 > > conference=20 > > >info, and there are no media policies. > >=20 > > I agree 100% with Brian. An ad-hoc conference does have=20 > > policy, but it is=20 > > a default (non-unique) policy. The creator of the conference=20 > > factory URI=20 > > sets that policy. It is possible for this policy to be=20 > > manipulated once=20 > > the conference has begun, but again this is up to the application. > >=20 > > There is no such thing as an "ad-hoc conference" or a "scheduled=20 > > conference" - however,there are "ad-hoc methods" of joining=20 > > or being added=20 > > to a conference, and scheduled means. > >=20 > > When joining a pre-established, the conference URI is=20 > typically sent=20 > > out-of-band, often in advance, to participants using say=20 > > email or IM. When=20 > > a participant is added using ad-hoc means, they often will=20 > > not know (see)=20 > > the conference URI - they will just be added in via a REFER or=20 > > transfer. Trying to come up with a strict definition for one=20 > > vs. the other=20 > > is very difficult and probably not all that productive. > >=20 > > I would encourage everyone to carefully read the SIPPING Conference=20 > > Framework document - it details many of these issues. > >=20 > > Thanks, > > Alan Johnston > > MCI > > sip:alan@sipstation.com > >=20 > > > > > > > > We also have a nit, at least I think it's a nit, about=20 > > Instantiation. > > > > I'm not sure there is any real difference between a re-usable > > > > conference ID and an instantiated conference that has no > > > > participants. > > > > Since I define instantiated as allocated mixer resources,=20 > > if I'm not > > > > using resources I don't have the conference instantiated. > > > > > >I agree about the definition of "instantiated". But if=20 > there are no=20 > > >current participants in a conference, and a server releases=20 > > resources and=20 > > >keeps the conference ID, it needs to guarantee what=20 > > resources will be=20 > > >available as soon as a participant enters. This might be not=20 > > releasing the=20 > > >resources. Perhaps all this is an implementation issue. > > > > > > > If you define instantiation differently, then you could. > > > > It would be good, I think, to have a common agreement on what > > > > instantiation means, because we use it in the documents, but I'm > > > > not sure we disagree on what can happen. We both agree you can > > > > manipulate policy, and we both agree participants can=20 > come and go. > > > > I guess I would ask you if you have some notion of a re-usable > > > > conference ID that is somehow different from an instantiated > > > > conference with no participants. > > > > > >A conference ID can exist even if a conference is not=20 > > instantiated. But=20 > > >what I was trying to say is that a conference can be=20 > > instantiated without=20 > > >any participants, unless as I said, the resources can be=20 > > guaranteed to be=20 > > >reallocated. > > > > > >Regards, > > >Hisham > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > From: hisham.khartabil@nokia.com=20 > > [mailto:hisham.khartabil@nokia.com] > > > > > Sent: Tuesday, December 02, 2003 9:26 AM > > > > > To: Brian.Rosen@marconi.com; rohan@cisco.com;=20 > pkyzivat@cisco.com > > > > > Cc: alan.johnston@mci.com; georg.mayer@nokia.com; > > > > oritl@microsoft.com; > > > > > xcon@ietf.org > > > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a=20 > > conference > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > > Sent: 02.December.2003 15:16 > > > > > > To: Khartabil Hisham (NMP-MSW/Helsinki); rohan@cisco.com; > > > > > > 'Paul Kyzivat' > > > > > > Cc: alan.johnston@mci.com; Mayer Georg (NMP-MSW/Helsinki); > > > > > > oritl@microsoft.com; xcon@ietf.org > > > > > > Subject: RE: [XCON] Chicken and Egg - Can CPCP create=20 > > a conference > > > > > > > > > > > > > > > > > > Well it's clear that my view is different from you-all. > > > > > > Not an unfamiliar situation :( > > > > > > Let me keep trying a while, but I'll cave if I'm out here > > > > > > by myself for too long. > > > > > > > > > > > > Several points to make. In my view: > > > > > > 1. "Instantiating" a conference is a concept that is getting > > > > > > confusing. > > > > > > It's all in what you mean. I think it's when the=20 > > mixer resources > > > > > > are actually allocated (as opposed to reserved). =20 > > That starts when > > > > > > the first participant creates a dialog with the=20 > > focus, and ends > > > > > > when the last dialog terminates. Getting a=20 > > conference ID doesn't > > > > > > instantiate a conference, creating a dialog with it does. > > > > > > > > > > Some chat type conferences can exist without any > > > > > participants. Participants come and go as they please. Why is > > > > > there a requirement that at least one participant is needed > > > > > for the conference to ever exist? > > > > > > > > > > > > > > > > > You can have a policy on whether the conference ID=20 > > expires when > > > > > > the last dialog terminates. If it does, once the conference > > > > > > instantiation terminates, it cannot be re-instantiated. > > > > > > If it doesn't, then it can be re-instantiated. An=20 > > example of the > > > > > > latter is a weekly sales meeting or a "meet-me" number. > > > > > > An example of the latter could be a 4-way call=20 > > created by a CONF > > > > > > button. > > > > > > > > > > > > 2. You can manipulate policy before you instantiate a=20 > > conference. > > > > > > As soon as a conference ID is created, policy is=20 > > available to be > > > > > > manipulated on it. > > > > > > > > > > Agreed on the part, but I don't think you need the conferece > > > > > ID (that is the SIP URI for the conference) in order to > > > > > manipulate the policy. CPCP can provide its own conference > > > > > policy ID that is somehow mapped to a conference ID. This > > > > > depends on the protocol chosen for CPCP. > > > > > > > > > > > > > > > > > 3. There is almost no difference between a pre-established > > > > > > conference and an ad-hoc conference. Try and think=20 > > of something > > > > > > that matters: > > > > > > Time between creation of conference ID and instantiation? > > > > > > Nope; you can pre-establish a conference=20 > and use it > > > > > > immediately, and there can be an arbitrary > > > > > > delay between > > > > > > requesting an ad-hoc conference and the=20 > first dialog > > > > > > with it. And even if there was, who cares? > > > > > > > > > > You are asking to redefine the whole concept of ah-hoc > > > > > conferencing using SIP. The INVITE creates a conference, and > > > > > creates a dialog. > > > > > > > > > > > DialIn/DialOut > > > > > > Nope - both can do both, or a mixture of either > > > > > > > > > > How can you limit the dail-in list in an ad-hoc conference. > > > > > Let me remind you that an ad-hoc conference does not=20 > > have a policy. > > > > > > > > > > For dial-out list, it is true that you can send REFER > > > > > requests for the focus, but again, you cannot predefine that > > > > > list. Also, you have to send a REFER to the focus for each > > > > > potential participant, creating x number of dialogs, one for > > > > > each REFER request. > > > > > > > > > > > > > > > > "Long running conference/chat" Nope; length of time of a > > > > > > conference/chat is not relevant, you=20 > could start one > > > > > > ad-hoc and leave it run for years. > > > > > > > > > > again, with ad-hoc conferences, there is no policy to dictate > > > > > this. I think I will stop commenting now until someone agrues > > > > > that I am wrong and an ah-hoc conference also needs a policy > > > > > (where my reply would be: why is it called ah-hoc then?). > > > > > > > > > > Regards, > > > > > Hisham > > > > > > > > > > > Therefore, I think you can't use CPCP for pre-established > > > > > > conferences and SIP for ad-hoc conferences. Pick one. > > > > There is no > > > > > > justification for two mechanisms to do the same=20 > > thing. I have a > > > > > > problem with policy creating a conference, and I think SIP > > > > > > signalling is a more appropriate way to create a=20 > > conference, but > > > > > > I care more about having one and only one way to do it. > > > > > > > > > > > > 4. My view of the conference factory was that you=20 > didn't get a > > > > > > conference instantiation from it, you only got a=20 > > conference ID. > > > > > > Either end would immediately terminate the conference > > > > > factory dialog, > > > > > > either by an actual BYE or a REFER. If you wanted to=20 > > immediately > > > > > > instantiate the conference after getting the=20 > > conferenceID, fine, > > > > > > but you don't have to; you can just get the=20 > conference ID and > > > > > > instantiate later. Later could be milliseconds or,=20 > if policy > > > > > > allowed, years. > > > > > > > > > > > > 5. I agree that non-SIP signalling mechanisms could be > > > > standardized > > > > > > to create conferences (H.323, iCal) if there is a SIP way > > > > > to do it. > > > > > > There wouldn't be any interoperability issues with that > > > > like there > > > > > > would if both CPCP and SIP can do it. Even a single device > > > > > that had, > > > > > > say, both SIP and iCAL mechanisms would have no=20 > > interoperability > > > > > > issues with devices that were, say, SIP-only. On the=20 > > other hand, > > > > > > if you standardize on CPCP to do it, then you would=20 > > not expect to > > > > > > see any other standardized mechanism. > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Mar 30 18:17:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27830 for ; Tue, 30 Mar 2004 18:17: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 1B8RjS-0006ZK-DD for xcon-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T1QcYZ025459 for xcon-archive@odin.ietf.org; Sat, 28 Feb 2004 20:26:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFj4-0006cK-Jx for xcon-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 20:26: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 UAA14439 for ; Sat, 28 Feb 2004 20:26:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxFj2-0004aZ-00 for xcon-web-archive@ietf.org; Sat, 28 Feb 2004 20:26:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxFhu-0004LK-00 for xcon-web-archive@ietf.org; Sat, 28 Feb 2004 20:25:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxFgv-00045a-00 for xcon-web-archive@ietf.org; Sat, 28 Feb 2004 20:24:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFgw-0005lX-9o; Sat, 28 Feb 2004 20:24:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFOp-0004Na-Ac for xcon@optimus.ietf.org; Sat, 28 Feb 2004 20:05: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 UAA13827 for ; Sat, 28 Feb 2004 20:05:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxFOn-0002JX-00 for xcon@ietf.org; Sat, 28 Feb 2004 20:05:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxFNn-0002Cw-00 for xcon@ietf.org; Sat, 28 Feb 2004 20:04:40 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AxFNU-00026b-00 for xcon@ietf.org; Sat, 28 Feb 2004 20:04:20 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1T13jr16330 for ; Sat, 28 Feb 2004 19:03:47 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <17CK11GH>; Sun, 29 Feb 2004 01:03:44 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00B3EF7B3@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Adam Roach'" , "'Eric Burger'" , "'xcon@ietf.org'" Subject: RE: [XCON] CPCP Requirement: Hidden Participants Date: Sun, 29 Feb 2004 01:03:43 -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=AWL autolearn=no version=2.60 It would have been better that you replied to one of the later messages in this thread. Your comments make it look like my own comments below refer to legal intercept, when they do not. We have already agreed that hidden participants are nothing to do with legal intercept. regards Keith > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: 26 February 2004 03:46 > To: Eric Burger; 'xcon@ietf.org' > Subject: RE: [XCON] CPCP Requirement: Hidden Participants > > > I know this issue has been settled, but just as a general > announcement for any work in any working group: the IAB > and IESG have stated positions on the topic of legal > intercept that are (to my understanding) binding on all > IETF protocols. > > These positions are detailed in RFC 2804, and are > summarized as follows: "The IETF has decided not to consider > requirements for wiretapping as part of the process for > creating and maintaining IETF standards." > > /a > > > -----Original Message----- > > From: Eric Burger [mailto:eburger@snowshore.com] > > Sent: Tuesday, January 20, 2004 10:01 > > To: xcon@ietf.org > > Subject: RE: [XCON] CPCP Requirement: Hidden Participants > > > > > > 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 > > > > > > > > > I believe hidden users are appropriate. > > > > > > I do not believe that this adds complexity to the > > > specifications (particularly to the specification of CPCP), > > > so I see no need to make it a DEFER as far as the > > > specifications are concerned. It may add complexity to the > > > implementation, so I am quite happy to see it a MAY in the > > > requirements, so that it is optional to implement. > > > > > > As regards the legal implications of hidden users, then yes, > > > there may be priveleged users that are able to request the > > > identity of hidden users (along with an indication that they > > > are hidden). This of course requires the enabling of such a > > > privileged user in the first place. > > > > > > Secondly, it may not be necessary to identify hidden users, > > > but merely that there are hidden users in the conference (in > > > addition to any that may have made themselves visible). Some > > > countries require some form of tone or announcement on voice > > > conferences when someone else is listening in. They also > > > require an announcement or other indication in the call is > > > being recorded. > > > > > > regards > > > > > > Keith > > > > > > Keith Drage > > > Lucent Technologies > > > drage@lucent.com > > > tel: +44 1793 776249 > > > > > > > > > > -----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 > > > > > > > > > > > > > > > > > > > > > -----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 > > > > > > > > > > > > > > > Related to this is there a requirement that, while not > > > > revealing the > > > > > identity of a hidden user, the conference policy contains > > > > > state indication > > > > > about either the presence of hidden users, or the > > > > > possibility/preclusion > > > > > that such hidden users may be present? > > > > > > > > > > I am anticipating that: > > > > > 1) Laws may exist that require notification of such. > > > > > > > > That's a good point. This might require changes to the > > > > conference event package to indicate if there are hidden > > > > participants or not, and if so, how many. > > > > > > > > The question remain: is there a need for such a feature (to > > > > hide users?)? > > > > > > > > Regards, > > > > Hisham > > > > > > > > > 2) In some conferences, participants may want technical > > > > > assurance that > > > > > hidden users are not possible before they speak. > > > > > > > > > > Mike > > > > > > > > > > > > > > > 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 > > > > > > > > > >http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt > > > > > > > > REQ-A7: It SHOULD be possible to participate in a > > conference as a > > > > hidden user. Hidden user is present in a conference, but > > > his presence > > > > is not revealed. > > > > > > > > REQ-E10: It MUST be possible to allow and disallow > > > hidden membership > > > > in a conference. > > > > > > > >Should a conference policy, using CPCP, specify if a user > > > can be hidden? > > > >This means that the conference state package does not report the > > > >participation on the hidden user. CPCP is used to identify > > > which users are > > > >hidden. The list of hidden users is only manipulated by a > > > privileged user > > > >such as the moderator. > > > > > > > >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 Mar 30 18:25:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29937 for ; Tue, 30 Mar 2004 18:25:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006a4-H9 for xcon-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i239R25N007152 for xcon-archive@odin.ietf.org; Wed, 3 Mar 2004 04:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AySeR-0001no-Ei for xcon-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 04:26: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 EAA13420 for ; Wed, 3 Mar 2004 04:26:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AySe5-0006yx-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 04:26:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AySd4-0006j6-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 04:25:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AySc3-0006YJ-00 for xcon-web-archive@ietf.org; Wed, 03 Mar 2004 04:24:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AySc1-00010T-0u; Wed, 03 Mar 2004 04:24:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRaU-0003ps-PN for xcon@optimus.ietf.org; Wed, 03 Mar 2004 03:18: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 DAA10074 for ; Wed, 3 Mar 2004 03:18:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRa8-0003Ai-00 for xcon@ietf.org; Wed, 03 Mar 2004 03:18:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRZ6-00032p-00 for xcon@ietf.org; Wed, 03 Mar 2004 03:17:17 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AyRYc-0002uR-00 for xcon@ietf.org; Wed, 03 Mar 2004 03:16:46 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id i238GI0p004421 for ; Wed, 3 Mar 2004 02:16:18 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <10MYQRMS>; Wed, 3 Mar 2004 02:16:17 -0600 Message-ID: <9ACE0CEE075B494096C86C23878BF85906A35F@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'xcon@ietf.org'" Date: Wed, 3 Mar 2004 02:16:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [XCON] CPCP-XCAP needs clarification on dial-out lists Sender: xcon-admin@ietf.org Errors-To: xcon-admin@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Centralized Conferencing List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,EXCUSE_3 autolearn=no version=2.60 [not as chair] "Asking the focus to invite a user into the conference is achieved by sending a HTTP PUT request to the CPS that modifies the Dial-Out List (DL) adding URIs to it. The CPS then triggers the focus to send the conference invitation, eg: SIP INVITE(s) as needed. Similarly, a user can be removed from the Dial-out list by issuing a HTTP DELETE removing the URIs." I can't find anywhere in the document what the semantics associated with removing a user from a dial-out list might be during an active conference. Does that cause the user to be removed from the conference, similar to setting their ACL list entry to "expelled"? This needs to be clearly specified. My personal preference is that removing someone from the dial-out list does *not* kick them out of the conference if they are already present -- we already have a mechanism to do that with the ACL list. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From exim@www1.ietf.org Tue Mar 30 18:35:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02525 for ; Tue, 30 Mar 2004 18:35:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjF-0006WI-Ev for xcon-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1Kc9f6001905 for xcon-archive@odin.ietf.org; Mon, 1 Dec 2003 15:38:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuo4-0000UN-Sn for xcon-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 15:38: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 PAA28061 for ; Mon, 1 Dec 2003 15:37:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQuo3-00007s-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 15:38:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQuo3-00007p-00 for xcon-web-archive@ietf.org; Mon, 01 Dec 2003 15:38:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQunz-0000Np-Ek; Mon, 01 Dec 2003 15:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQunc-0000C8-8p for xcon@optimus.ietf.org; Mon, 01 Dec 2003 15:37: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 PAA28038 for ; Mon, 1 Dec 2003 15:37:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQunP-000077-00 for xcon@ietf.org; Mon, 01 Dec 2003 15:37:27 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AQunO-00006S-00 for xcon@ietf.org; Mon, 01 Dec 2003 15:37:26 -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 PAA09860; Mon, 1 Dec 2003 15:36:53 -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 PAA10935; Mon, 1 Dec 2003 15:36:55 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Dec 2003 15:36:54 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B613F@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Orit Levin'" , xcon@ietf.org Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference Date: Mon, 1 Dec 2003 15:36:53 -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: , Orit Keeping XCON separate from SIP is useful so long as it doesn't get in the way of common sense. To me, that would mean, for example, having a different name space for a conference ID, requiring one for CPCP and another for SIP. If a conference ID in CPCP is not a uri, for which a SIP uri is an excellent, but not limiting example, I have a very large problem. I don't care if some day, someone invents a way to use CPCP without SIP, and I don't have any interest in making that difficult in any way. However, it's not a driving function, and I don't think there is any reason to have more than one standardized way to create a conference. An INVITE to a conference URI does it. A specific implementation may have some other, non standardized way. I want ONE standardized way, unless someone has a compelling reason why we need to have two. It's a broken record; when you have multiple ways to do the same thing, you facilitate incompatible implementations. If there are a million ways, you will have a lot of incompatible systems. I have no interest in fostering that kind of design. Brian > -----Original Message----- > From: Orit Levin [mailto:oritl@microsoft.com] > Sent: Monday, December 01, 2003 3:02 PM > To: Rosen, Brian; xcon@ietf.org > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference > > > Brian! > I am actually surprised by this thread. > > In reality, a single conference instance can be potentially defined / > requested by million ways. Moreover, the same conference instance can > host participants joining by very different means and media. Moreover, > the same conference can have more than a single unique identifier... > > SIP conferencing and XCON conferencing must be able to coexist in the > system and share same conference instances but apart from > that - each is > a "complete system" on its own. (SIP point-to-point CC is a different > issue - it is one of the tools available for XCON.) > > As a result, the discussion of the addressing scheme should > first apply > to the SIPPING conferencing work. (In XCON we still need to > agree on the > higher level architectural decomposition of the pieces that we managed > to introduce.) > > In particular, draft-ietf-sipping-cc-conferencing-02.txt has different > assumptions or, I should say, is less restrictive that you propose > below. BTW, it does define that "calling a Factory" results in > establishing a conference with its focus (either through the > same dialog > or by redirection to a focus - both are valid cases). If we > disagree on > this, let's start this discussion in SIPPING ASAP. > > Orit. > > -----Original Message----- > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org] On Behalf Of > Rosen, Brian > Sent: Monday, December 01, 2003 10:26 AM > To: 'xcon@ietf.org' > Subject: [XCON] Chicken and Egg - Can CPCP create a conference > > I'd like to re-open the requirement to create a conference with CPCP. > Somehow, I missed that one. > > Generally, I think it's a bad idea to have two ways to do > something, and > we > have another way to create a conference (conference factory uri). I'd > like to eliminate one of them if possible. > > Beyond that, it seems to me that there is a chicken and egg > problem with > CPCP. That is, how do you "start" sending CPCP "commands", > and to whom > do you address them? This is an issue that intertwines with the > signalling > protocol (sip). In my mind, the conference uri gave you an > address (the > host of the focus) and an identifier (the userpart of the uri). Now, > in at least the first version of all of this, do we need to have some > kind > of discovery mechanism for the conference policy server? I think not, > or at least I think you get it from the focus. I'd propose that it is > precisely the host of the focus, but I'd be okay with a query to the > focus > that returned the address of the conference policy server. > > So, if I were choosing, I would not permit CPCP to create conferences. > I would rely on the conference factory URI (as well as out of band > means). > I would make the conference policy server the same host as the > conference > uri, or at least make the focus return the address of > conference policy > server. > If you need a conference uri to get the conference policy server > address, > then you can't use CPCP without a conference URI, and thus > using CPCP to > create/discover a conference URI wouldn't work. > > Brian > > _______________________________________________ > 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