Re: [vwrap] vwrap Digest, Vol 11, Issue 24

Katherine Mancuso <kmancuso@gmail.com> Tue, 29 March 2011 20:46 UTC

Return-Path: <kmancuso@gmail.com>
X-Original-To: vwrap@core3.amsl.com
Delivered-To: vwrap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059FD3A6A93; Tue, 29 Mar 2011 13:46:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 n+NRUxngraBo; Tue, 29 Mar 2011 13:46:36 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 905283A6981; Tue, 29 Mar 2011 13:46:36 -0700 (PDT)
Received: by iye19 with SMTP id 19so590908iye.31 for <multiple recipients>; Tue, 29 Mar 2011 13:48:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=gqMTILQOF0c6g9Q69c1eT3LwLmhrx9pROcgnE62qJj4=; b=mChttd5h6IGI3USfo4JrdA5Bd88UjK+U8xofwQRr6Sbq5mZfn/Xw8Sk1F8dmAPd77x tdjAgdmlCrlcEwT3vJHWRFrZ+FxynAvgWqtG5AFTueLlJ/M+8JQL+kqr4bgDaZEBiYrA Ok7v/MQFzOzRkKLPPrxsjDWG2iwLrD4EcJOdc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; b=j8QjhRrvWKZkrzcW2dZAyklWM+rV1/e0RpZOm/5UufePhc0VksLVYfNh8TP9LiKg+Q PAlbfBSr0HVskTLUZYN0FlcOuN9ViLqVB+mGB4sFDZLUnEjsPYxQCnL925/kLv+SJgm7 R1lge0u6LyRkKQdC1dG059tv21xDYZ3Zx4A4w=
Received: by 10.231.29.101 with SMTP id p37mr463666ibc.3.1301431694594; Tue, 29 Mar 2011 13:48:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.143.131 with HTTP; Tue, 29 Mar 2011 13:42:14 -0700 (PDT)
In-Reply-To: <mailman.119.1301425219.8353.vwrap@ietf.org>
References: <mailman.119.1301425219.8353.vwrap@ietf.org>
From: Katherine Mancuso <kmancuso@gmail.com>
Date: Tue, 29 Mar 2011 13:42:14 -0700
Message-ID: <AANLkTimW_yvXG3bfnTJuQ8B3fuw5z4=+mryvKETu+6Ja@mail.gmail.com>
To: vwrap@ietf.org
Cc: vwrap-request@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: kmancuso@gmail.com
List-Id: Virtual World Region Agent Protocol - IETF working group <vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Mar 2011 20:46:38 -0000

Hi everyone,

I want to speak up for agreeing with Meadhbh & Mike about keeping a
role for service level interop in this group.  We've made good
progress towards this goal and can continue to work on it.

Here is an alternative proposal to any which has been brought up so
far.  I'm aware this may not be fully correct in its technical
details, as I am not a software architect:

Could the partisans of "full" VW interop consider working together on
a draft specification that is something like the intro or David's
piece in scope that lays out which specific capacities would need to
be supported at a minimum to allow for "full" interop, perhaps getting
input from implementers such as the Hypergrid folks and the folks who
coordinated the teleport test at Linden?  Citing existing service
specifications (either ones developed within this WG, or outside
specifications like XML, Collada, etc) is preferred, and for
capabilities for which there are not existing service specifications
or the existing specifications don't work well enough, address that to
lay out a clear roadmap of what must be developed.

My vision here is that folks who are doing service-level work could
continue developing and implementing their individual services, and
the folks who wish to do "full" interop could define a menu of
services which must be implemented for "full" interop.  Implementers
could then choose their path based on their use cases: implement the
"full" interop specification including all the specifications called
for, or implement individual services.  I believe that both of these
concepts can exist under our existing charter or with limited
amendment to the charter and intro, which is much easier for everyone
to agree to than entirely rewriting both, and does not require
trashing years of work.

It seems to me that accomodating "full" interop only would reduce the
number of possible implementers and use cases for our work
dramatically, not to mention cut out a productive body of folks in
this group who have been contributing an awful lot of documents and
implementing.

For example, to illustrate my point:

>From my work as a SL developer focusing in education, I know there's a
substantial use case in K-12 education in the US for walled gardens,
because schools have big legal liability problems with letting minors
wander unwalled virtual worlds (most school libraries in the US have
internet filters for the same reasons) and have fairly intense
supervision requirements which require substantial moderation &
surveillance tools.  However, a shared asset server that contains a
core of "safe" content might be of interest to these folks, since
educators don't necessarily need to reinvent the wheel for their
classrooms every year.  This is a really good case for service level
interop ... implement the asset server specification only, not the
"full" one that allows you to teleport to other worlds.

On the other hand, universities have far greater interest in letting
students and professors teleport among university spaces (which
happens metaphorically in the real world all the time), and fewer
liability issues.  Sharing an asset server might be of interest to
them, but so too might "full" interop.  They'd want to implement the
"full" interop specification.

(Paging Fleep Tuque, are you here to make this case better for me?)

TL;DR - Proposal is to amend the charter & intro so that they allow
the "full" interop people to work in one community on their ideas and
the service level interop people to work in parallel on their ideas,
rather than assuming that one model has to exclusively dominate the
group.

I will be unavailable to post anything else much lengthy through 3 April, FYI.

Katherine

-- 
---------------------------------------------------------------------------------------------
Katherine Mancuso

ISIS Inc, Community Manager (http://www.isis-inc.org)
Sex::Tech Conference, Social Media Chair (http://www.sextech.org)
The Vesuvius Group: metaverse community builders
(http://www.thevesuviusgroup.com)
GimpGirl Community Liaison (http://www.gimpgirl.com)

http://twitter.com/musingvirtual
http://facebook.com/kmancuso
http://www.linkedin.com/in/kathymancuso
Second Life: Muse Carmona
----------------------------------------------------------------------------------------------