Re: [vwrap] Status and future of the VWRAP working group

Morgaine <morgaine.dinova@googlemail.com> Tue, 29 March 2011 15:35 UTC

Return-Path: <morgaine.dinova@googlemail.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 1D8123A697F for <vwrap@core3.amsl.com>; Tue, 29 Mar 2011 08:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.926
X-Spam-Level:
X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 UD62ywU1kB4s for <vwrap@core3.amsl.com>; Tue, 29 Mar 2011 08:35:51 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 18EE13A6932 for <vwrap@ietf.org>; Tue, 29 Mar 2011 08:35:51 -0700 (PDT)
Received: by qwg5 with SMTP id 5so227832qwg.31 for <vwrap@ietf.org>; Tue, 29 Mar 2011 08:37:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WYpyrk1ut33OlPn515v0WRLJf7N9ZJaBQsenDmTHQaM=; b=Qqj7fKUEbVzr77Fa0bpMZ7umqTcEUQw39ifj+C5ozr2889f1/h/5XqXQsmiKYfgQZP xFJVtp+blr+b8ADgzzsOvTMZYZPWGlSO62uwO+b6uDpEEHK4zgnDlvjB3ReuUR8YwyqQ Rgn3+zOjOJl2RTMNZgnL3djKM5sdRfhw2AYtU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MU5i3pvsEVxXgfn9qzFx71+iGT4qt+IN1GaG9CNRseTPot7JJLmsH2AM5oFiCLcdH5 aQItqJ9kg3G/lcK6ESsi4nTrK/eE/KVE6BScHieev+vOrDmaEgbjri1WL11OBarSzv0D yXT4H8slqxwK0Lj5g6Xa269hdRGPCMEwm+pt0=
MIME-Version: 1.0
Received: by 10.229.124.145 with SMTP id u17mr4643729qcr.71.1301413049023; Tue, 29 Mar 2011 08:37:29 -0700 (PDT)
Received: by 10.229.211.84 with HTTP; Tue, 29 Mar 2011 08:37:28 -0700 (PDT)
In-Reply-To: <4646639E08F58B42836FAC24C94624DD92FDE5FEC5@GVW0433EXB.americas.hpqcorp.net>
References: <AANLkTim=tpngqs8gt=sjCeOQgtUATVRXXKe11qUaNJFw@mail.gmail.com> <BLU159-ds1192252375D420BE8C7C9EDCB90@phx.gbl> <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <AANLkTimLHwMb9u5Ok-44-JgHaL_EydeSHyHUQybvNpMp@mail.gmail.com> <20110326135320.GC29908@alinoe.com> <AANLkTin=9a35pzm9QkGt6v5PgWAgsqomkYCBG8eSa4Xg@mail.gmail.com> <AANLkTinp2+skkPP0L1sWtTn1-OU=Q6_YXk_W1+QdL-8Q@mail.gmail.com> <AANLkTin25vWxk9Wd1U3ne_4DedU4Cz5JhMHTzt9gDyfA@mail.gmail.com> <AANLkTimM=ERx_WctgAzHhgm_GE_cVYM0j6FXp6xMthds@mail.gmail.com> <AANLkTi=aghMKoOusjwbC7wyh=kzZwEY7a3_VCiw93ZYB@mail.gmail.com> <4D911618.7060706@gmail.com> <AANLkTikWoUrXCNZ9QV6icHh-Zeas+xu2VAGkqD4mxwWx@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD92FDE5FEC5@GVW0433EXB.americas.hpqcorp.net>
Date: Tue, 29 Mar 2011 16:37:28 +0100
Message-ID: <AANLkTin1e=Q6NWOSkNPG+aTNpvmoDvd=OEzs4XiHtUpd@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: vwrap@ietf.org
Content-Type: multipart/alternative; boundary="000e0cd25cae7e3d77049fa0d619"
Subject: Re: [vwrap] Status and future of the VWRAP working group
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: Tue, 29 Mar 2011 15:35:53 -0000

On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software) <
mike.dickson@hp.com> wrote:

>
> Right, so we do need to standardize “Service Level Interop”.  As has been
> pointed out its concrete enough you can actually do it and it would allow
> the assembly of virtual worlds based upon it.
>


I think you misunderstood the point that I wrote, since you concluded the
opposite.  No, it does not follow that we need to standardize "service level
interop", because that does not give us interoperation between virtual
worlds.  It only allows us to standardize (as you correctly state) the
"assembly of virtual worlds", one world at a time, instead of standardizing
their interoperation.  We don't need to standardize how VWs are assembled,
it's not even our remit to do that because that's up to each provider.


>
> I don’t know what it mean to have virtual world interop personally.
>

Why?  It's very easy to understand, and I would guess that every VW user
today who is using two or more virtual worlds like (say) OSgrid and InWorldz
can probably describe it very eloquently.  I'll just repaste how I described
it yesterday:


> We either have interoperability between worlds, in which an inhabitant can
> travel from one world to another and take their avatar and/or possessions
> with them, or else we don't have that.  It's black and white, and no amount
> of fudging about "service level interoperability" is going to overcome the
> lack of VW interoperability as a user would understand it.



Interoperability between VWs is truly a simple concept, and users are asking
for it continually and woeing its absence daily.  Its lack is so clear and
self-evident and annoying that people even write export-import programs to
try to alleviate the user "suffering" through its absence.  Frankly,
professing not to understand what it means is very bizarre.  All I can
suggest is, I'll try to clarify it further for you if you still don't
understand what it means.


Morgaine.





===========================

On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software) <
mike.dickson@hp.com> wrote:

> *From:* vwrap-bounces@ietf.org [mailto:vwrap-bounces@ietf.org] *On Behalf
> Of *Morgaine
> *Sent:* Monday, March 28, 2011 8:01 PM
> *To:* vwrap@ietf.org
>
> *Subject:* Re: [vwrap] Status and future of the VWRAP working group
>
>
>
> Responding to two posts:
>
>
> On Tue, Mar 29, 2011 at 12:13 AM, Dzonatas Sol <dzonatas@gmail.com> wrote:
>
>
> If you want service only, I think there is code implemented already.
>
>
>
> Exactly as Dzonatas says.  We don't need to work on protocols for internal
> use by separate, isolated world services.  We have those already.  The
> ingredient that is mostly missing from the Virtual World arena is
> interoperability *between* such services, and that is the goal that has
> sparked extremely wide interest.
>
> Right, so we do need to standardize “Service Level Interop”.  As has been
> pointed out its concrete enough you can actually do it and it would allow
> the assembly of virtual worlds based upon it.   The point that some of this
> exists is a good one, there’s some existing practice and knowledge that can
> be leveraged.
>
> On Tue, Mar 29, 2011 at 12:15 AM, Boroondas Gupte <
> sllists@boroon.dasgupta.ch> wrote:
>
>
> d. interoperability between (instances of) any two virtual world systems
> conforming to the (to be defined) VWRAP standard.
>
>
> Exactly as Boroondas says.  Indeed, that is the interoperability goal
> sought by the majority of contributors here over the years, so this is
> nothing new. It's the feature that virtual worlds don't yet have, and that's
> why it's worthwhile to work on it.
>
> Again, this is sensible and it’s achieved via the “standard services”
> defined above.  I don’t know what it mean to have virtual world interop
> personally.  It’s a nice ideal but in practice differences in policy,
> technology, etc, make it practically impossible to specify given the current
> state of  affairs.    We can’t even agree on a the data description protocol
> let alone how to handle policy across VW systems.  And that extends past
> business policy into technical issues like: if an “object”  is scripted how
> does that transfer to another VW. Who allocates the script resources.  And
> of course there’s also creator’s rights vs. owner’s rights.  The list is
> extremely long and we can’t even agree on how services should talk and which
> there should be in a standard way.
>
>
>
> IMO, the effort should focus on Service Level interoperability and the
> definition of a few fundamental building block services: i.e user service,
> inventory service, asset service.  I’d leave the simulator piece off for
> now.  If we get those right you can start to share user information between
> “virtual worlds”, locate and access inventory and define an objects
> characteristics inside a simulator.  And the simulator piece can evolve
> until its ready to be standardized.
>
> Mike
>
>
>