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

"Dickson, Mike (ISS Software)" <mike.dickson@hp.com> Tue, 29 March 2011 12:54 UTC

Return-Path: <mike.dickson@hp.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 5568E3A67B6 for <vwrap@core3.amsl.com>; Tue, 29 Mar 2011 05:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Level:
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 8VfP3reC8VVF for <vwrap@core3.amsl.com>; Tue, 29 Mar 2011 05:54:12 -0700 (PDT)
Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by core3.amsl.com (Postfix) with ESMTP id 137193A6452 for <vwrap@ietf.org>; Tue, 29 Mar 2011 05:54:11 -0700 (PDT)
Received: from G5W2206G.americas.hpqcorp.net (g5w2206g.atlanta.hp.com [16.228.43.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id C558989EF; Tue, 29 Mar 2011 12:55:49 +0000 (UTC)
Received: from G4W1852.americas.hpqcorp.net (16.234.97.230) by G5W2206G.americas.hpqcorp.net (16.228.43.185) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 29 Mar 2011 12:54:39 +0000
Received: from GVW0433EXB.americas.hpqcorp.net ([16.234.32.148]) by G4W1852.americas.hpqcorp.net ([16.234.97.230]) with mapi; Tue, 29 Mar 2011 12:54:38 +0000
From: "Dickson, Mike (ISS Software)" <mike.dickson@hp.com>
To: Morgaine <morgaine.dinova@googlemail.com>, "vwrap@ietf.org" <vwrap@ietf.org>
Date: Tue, 29 Mar 2011 12:54:35 +0000
Thread-Topic: [vwrap] Status and future of the VWRAP working group
Thread-Index: AcvtpFa3mUmGgSZyRUmFUi+yEnI85QAasuTQ
Message-ID: <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>
In-Reply-To: <AANLkTikWoUrXCNZ9QV6icHh-Zeas+xu2VAGkqD4mxwWx@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_4646639E08F58B42836FAC24C94624DD92FDE5FEC5GVW0433EXBame_"
MIME-Version: 1.0
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 12:54:13 -0000

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<mailto: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<mailto: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