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

Vaughn Deluca <vaughn.deluca@gmail.com> Wed, 30 March 2011 21:05 UTC

Return-Path: <vaughn.deluca@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 AE3553A6B97; Wed, 30 Mar 2011 14:05:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, 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 77qC6DlSp6CY; Wed, 30 Mar 2011 14:05:44 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id D8A163A68F4; Wed, 30 Mar 2011 14:05:43 -0700 (PDT)
Received: by ewy19 with SMTP id 19so613462ewy.31 for <multiple recipients>; Wed, 30 Mar 2011 14:07:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=inKTtd8NwNoT4B3gFd28JO9z29RY4PZSFZsV1EbnTIk=; b=e9qKJZGcl8bAbZNJkMTTJuprSD9m19w/mOkpzd/zGnY9mrGnsC3k6kOH1jjo5hZUrB gJrcLYvnwRSzKcqCvFjZlLfwIOR8LQq2DWRLEi0GqCKuEzzGlr4orjbAGzE/grzBAOHE sCvLX5pNqVQi4GaAOkrkx2PKgT5TNSX90sVv8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JT591ctKvKL8pUzeQbTBOHGmnjWlPEQSvfI6wipO9C++3JcNETtYHHXdVOfpB9jwCI c+kYVYIv2HySBcvcudmY1KYZJVSgb3JdPBa+f/vY+4ugjXGIYD+r/pM3g8vWzF/E7+gw A4t/Zc9bHY+0BZkjmYKIWEyKeD3JuoorIE2Tg=
MIME-Version: 1.0
Received: by 10.213.104.103 with SMTP id n39mr1221494ebo.144.1301519241819; Wed, 30 Mar 2011 14:07:21 -0700 (PDT)
Received: by 10.213.17.17 with HTTP; Wed, 30 Mar 2011 14:07:21 -0700 (PDT)
In-Reply-To: <AANLkTimW_yvXG3bfnTJuQ8B3fuw5z4=+mryvKETu+6Ja@mail.gmail.com>
References: <mailman.119.1301425219.8353.vwrap@ietf.org> <AANLkTimW_yvXG3bfnTJuQ8B3fuw5z4=+mryvKETu+6Ja@mail.gmail.com>
Date: Wed, 30 Mar 2011 23:07:21 +0200
Message-ID: <AANLkTimB+8BMR9OvacF6JqnOf6MrD2_XUCjfAVyS5Vws@mail.gmail.com>
From: Vaughn Deluca <vaughn.deluca@gmail.com>
To: kmancuso@gmail.com
Content-Type: text/plain; charset="ISO-8859-1"
Cc: vwrap@ietf.org, vwrap-request@ietf.org
Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Wed, 30 Mar 2011 21:05:46 -0000

Katherine wrote:
>It seems to me that accomodating "full" interop only would reduce the
>number of possible implementers and use cases for our work

I am sure that nobody  suggested to we restrict ourselves to "full"
interop only.
"Service level interop" is clearly subset of VW interoperability. You
can't have VW interoperability without service level interoperability!
However, If i understand Morgaine right, she is worried that the VWRAP
specs will be *restricted* to service level interop only.

It has been argued (sorry, I forgot by whom) that proper
specifications of service level interop will give us virtual world
interop for free. I think we need a bit more, but i really have a hard
time envisioning how service level interop can be specified in such a
way that it *prevents* VW interop, at least not if we pay attention to
this aspect, and clearly we do. So in conclusion i do not see much of
a problem.

Izzy wrote in another tread "This whole argument between service level
interop and 'full' interop eludes me." At first it eluded me to, but
now i think that what is actually expressed in these discussions is
the question of the scope of our effort as well as design approach.
Some prefer to work bottom up, following their primary interests in
getting the low level protocols working, especially since that will
already be good enough for (all?) of their use cases . Some prefer a
more top-down approach, first sketching the high level picture of the
users perception of VW interop,  and from there working downwards,
obviously also because that approach optimises the realisation of
*their* use cases.

I think we need both, and above all, i do feel that the two approaches
are not al all incompatible and both are without any doubt square
within the current charter.
Formally splitting our effort in two working parties along the current
visible fissures and getting each to work on their own interest is a
recipe for disaster. It will only strengthen the animosity that is
already slowing us down tremendously, and will sustain the infighting.
Rather than spitting efforts off, we need to address the causes for
the current disagreement and found common ground.  In my view that is
not all all hard.

I have been reviewing the discussion we had in September and i am
actually amazed at the level of consensus that is expressed in those
email exchanges. Unfortuanately we have been very bad at consolidating
that consensus. As a result we recycle the same problems time and time
again. The archives make very depressing reading from that point of
view. We need to do more documentation for sure.

I am currently going over the September discussion and looking up the
places were we all agreed on the way forward.  Much of that is still
undocumented, and my aim is to get those points written down in the
wiki.

As i final point i want to make clear how I understand the term
"Service Level Interop". I used the term, and since the glosary entry
is still emtpy, i feel obliged to add at least my personal reading. If
somebody disagrees, please add an improved version.

Service level interoperability:
	A subset of "Virtual World Interoperability" as defined by the VWRAP
protocol. Service level interoperabity loosely describes specific
interactions between VWRAP endpoints. These inteactions form the glue
that hold a particular virtual world together, but might just as well
be used for communication between different VWRAP compatible virtual
worlds (i.e. crossing trust domains).

I intend to put this up in the glossary, but first will see how it
flies here  :)

On 3/29/11, Katherine Mancuso <kmancuso@gmail.com> wrote:
> 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
> ----------------------------------------------------------------------------------------------
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>