Re: [vmeet] timeframe
Dave Cridland <dave@cridland.net> Fri, 15 May 2009 16:04 UTC
Return-Path: <dave@cridland.net>
X-Original-To: vmeet@core3.amsl.com
Delivered-To: vmeet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBBE03A70F6 for <vmeet@core3.amsl.com>; Fri, 15 May 2009 09:04:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.594
X-Spam-Level:
X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkY3XjgHWl6v for <vmeet@core3.amsl.com>; Fri, 15 May 2009 09:04:45 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 90B5F3A70F4 for <vmeet@ietf.org>; Fri, 15 May 2009 09:04:44 -0700 (PDT)
Received: from puncture ((unknown) [217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id <Sg2S9gBNdze=@peirce.dave.cridland.net>; Fri, 15 May 2009 17:06:14 +0100
X-SMTP-Protocol-Errors: NORDNS
References: <20090507175356.GG32848@verdi> <4A08BC3C.9070302@dcrocker.net> <200905121242.n4CCgnj4013481@cichlid.raleigh.ibm.com> <20090513025653.GD14375@verdi> <4A0C5831.5060801@dcrocker.net> <20090514221220.GA70521@verdi> <4A0C9B51.2010508@dcrocker.net> <20090515000426.GC70521@verdi> <00311CF9-51CF-496A-AC6E-5C673CB274A9@gmail.com>
In-Reply-To: <00311CF9-51CF-496A-AC6E-5C673CB274A9@gmail.com>
MIME-Version: 1.0
Message-Id: <11966.1242403570.072307@puncture>
Date: Fri, 15 May 2009 17:06:10 +0100
From: Dave Cridland <dave@cridland.net>
To: Doug Otis <doug.mtview@gmail.com>, Dave CROCKER <dcrocker@bbiw.net>, IETF remote participation meeting services discussion <vmeet@ietf.org>, John Leslie <john@jlc.net>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Subject: Re: [vmeet] timeframe
X-BeenThere: vmeet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF remote participation meeting services discussion <vmeet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vmeet>, <mailto:vmeet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vmeet>
List-Post: <mailto:vmeet@ietf.org>
List-Help: <mailto:vmeet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vmeet>, <mailto:vmeet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 May 2009 16:04:46 -0000
On Fri May 15 03:27:15 2009, Doug Otis wrote: > For smaller groups, WebEx Meeting using a telephone bridge works > well, but it does not offer a Q & A window. Raising a hand icon > is only seen by the presenter. This will likely frustrate > participants who would like to make a point, but feel ignored by a > likely distracted host. A question queue seems an important > requirement to assure participants they are being given a fair > chance. Otherwise, the floor is likely to ceded to those willing > to ask for forgiveness rather than permission. The chat and > window control for remote participants does not compare favorably > to a simpler jabber client. On the other hand, the polling > feature is very nice and allows participation in "hums." FWIW, some existing XMPP clients use the MUC presence to signal voting, and they could just as easily signal a "I'd like the floor". However, the current usage of the MUC rooms as a "back channel", for side-discussions, makes actual floor control tricky - XEP-0045 does include "voice requests" and control, and the implementation the IETF uses supports these, I believe, but I'd consider removal of voice to be a problem, unless each working group had both a "presentation" MUC *and* a backchannel, which becomes unweidly quite quickly. Incidentally, my guess would be that a voting/hand-raising specification or two could be written, and implemented, by Stockholm, in cross-platform clients. If you want this to happen, please say so, and I'll be happy to drive this forward. There's scope for signalling other things through MUC, too, but anything that requires server mediation has a longer turn-around time, obviously. To get a client-client signalling mechanism going only needs, after all, one client developer to bite. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
- [vmeet] Duties of WG Chairs John Leslie
- [vmeet] Supporting interim meetings (was Re: Duti… Dave CROCKER
- Re: [vmeet] Supporting interim meetings (was Re: … Thomas Narten
- Re: [vmeet] Supporting interim meetings John Leslie
- Re: [vmeet] Supporting interim meetings (was Re: … Dave Cridland
- [vmeet] The philosophy behind the list of recomme… Dave CROCKER
- Re: [vmeet] Supporting interim meetings Dave CROCKER
- Re: [vmeet] Supporting interim meetings Brian Rosen
- Re: [vmeet] Supporting interim meetings Dave CROCKER
- Re: [vmeet] Supporting interim meetings John Leslie
- [vmeet] timeframe Dave CROCKER
- Re: [vmeet] timeframe John Leslie
- Re: [vmeet] timeframe Doug Otis
- Re: [vmeet] timeframe Dave Cridland
- Re: [vmeet] timeframe Brian Rosen
- Re: [vmeet] Supporting interim meetings Thomas Narten
- Re: [vmeet] Supporting interim meetings Doug Otis
- Re: [vmeet] Supporting interim meetings Peter Saint-Andre
- Re: [vmeet] Supporting interim meetings Doug Otis