[vmeet] The philosophy behind the list of recommendations.

Dave CROCKER <dhc@dcrocker.net> Thu, 14 May 2009 13:18 UTC

Return-Path: <dhc@dcrocker.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 4EB693A6FB0 for <vmeet@core3.amsl.com>; Thu, 14 May 2009 06:18:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.289
X-Spam-Level:
X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[AWL=-0.549, BAYES_20=-0.74]
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 FGGfRbMbFYxZ for <vmeet@core3.amsl.com>; Thu, 14 May 2009 06:18:27 -0700 (PDT)
Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id C6FD928C283 for <vmeet@ietf.org>; Thu, 14 May 2009 06:17:09 -0700 (PDT)
Received: from [127.0.0.1] (adsl-68-122-70-68.dsl.pltn13.pacbell.net [68.122.70.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n4EDIZsv021990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <vmeet@ietf.org>; Thu, 14 May 2009 06:18:41 -0700
Message-ID: <4A0C1A2B.7090904@dcrocker.net>
Date: Thu, 14 May 2009 06:18:35 -0700
From: Dave CROCKER <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: vmeet@ietf.org
References: <20090507175356.GG32848@verdi> <4A08BC3C.9070302@dcrocker.net> <200905121242.n4CCgnj4013481@cichlid.raleigh.ibm.com> <20090513025653.GD14375@verdi>
In-Reply-To: <20090513025653.GD14375@verdi>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 14 May 2009 06:18:41 -0700 (PDT)
Subject: [vmeet] The philosophy behind the list of recommendations.
X-BeenThere: vmeet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dcrocker@bbiw.net
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: Thu, 14 May 2009 13:18:28 -0000

John Leslie wrote:
>>  - audio bridge (could be VoIP, or POTS, that is a detail)
>>  - access to charts
>>  - IM capability as a side channel
> 
>    We have been running virtual meetings with that much for some time
> now, any many folks are used to it. By human nature, if we provide a
> tool that folks aren't used to, they'll gravitate back to _that_ model
> they're used to.
>
>    So, while I support Dave's call for more than that, we can't just
> make a list -- we need to explain _why_ each feature we recommend is
> a significant improvement over bare-bones.

and

Dave Cridland wrote:
 > I've been asking around for solutions to these issues which are based
 > around open standards. While I fully understand, and indeed support, the
 > need for an "out of the box" solution to this, I'd like an "out of the
 > box" solution that used a suite of open standards to achieve these goals.


Folks,

We DO need to be clear about our reasons for choosing anything different from 
what we do today and the reasons for making the choices we recommend.

On the matter of using products based on open standards, I'm frankly viewing 
that as desirable rather than mandatory.  The reason is that I am pretty sure we 
do not want to block our use if the only acceptable solution happens to be 
proprietary. Our need is too strong, I believe.

As for choosing functions that go beyond what is already in use, here is the 
reasoning driving the candidate choices I've listed:

      There is a difference between camping and staying at a 5-star hotel. In 
the range of capabilities for remote participation in an meeting, the current 
set of capabilities that we use are closer to the former than the latter.

      Remote participation is currently quite limited in number and style.  We 
are seeking much greater use.

      I believe that seriously supporting truly inclusive participation for 
long-term, regular virtual meetings, the tools need to attain a level of 
capability, integration and ease of use that is considerably better than we 
currently employ.  We need a lower barrier to use and we need better 
functionality to aid a wider range of meeting content and style.

We might not need a 5-star set of tools, but we need a lot more than a tent.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net