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