[ogpx] An example to show the problems with defining an OGPX/VWRAP virtual world

"Magnus Zeisig" <magnus.zeisig@iis.se> Tue, 01 September 2009 10:17 UTC

Return-Path: <magnus.zeisig@iis.se>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3F123A69AC for <ogpx@core3.amsl.com>; Tue, 1 Sep 2009 03:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 chAetKzVh-43 for <ogpx@core3.amsl.com>; Tue, 1 Sep 2009 03:17:44 -0700 (PDT)
Received: from cleaner.prod.iis.se (cleaner.prod.iis.se [212.247.7.212]) by core3.amsl.com (Postfix) with ESMTP id C02993A698C for <ogpx@ietf.org>; Tue, 1 Sep 2009 03:17:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by cleaner.prod.iis.se (Postfix) with ESMTP id CD118A8010; Tue, 1 Sep 2009 10:17:55 +0000 (UTC)
Received: from cleaner.prod.iis.se ([127.0.0.1]) by localhost (cleaner.prod.iis.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24127-03-2; Tue, 1 Sep 2009 10:17:45 +0000 (UTC)
Received: from pgpkeys.office.nic.se (pgpkeys.office.nic.se [212.247.204.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cleaner.prod.iis.se (Postfix) with ESMTP id B6602A8014 for <ogpx@ietf.org>; Tue, 1 Sep 2009 10:17:32 +0000 (UTC)
Received: from EXCHANGE.office.nic.se ([212.247.204.6]) by pgpkeys.office.nic.se (PGP Universal service); Tue, 01 Sep 2009 12:17:32 +0200
X-PGP-Universal: processed; by pgpkeys.office.nic.se on Tue, 01 Sep 2009 12:17:32 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
MIME-Version: 1.0
x-pgp-encoding-version: 2.0.2
x-pgp-universal-saved-content-codepage: utf-8
x-pgp-mapi-encoding-version: 2.5.0
x-pgp-encoding-format: Partitioned
Date: Tue, 1 Sep 2009 12:06:31 +0200
Message-ID: <69830D4127201D4EBD146B9041199718010191FD@EXCHANGE.office.nic.se>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: An example to show the problems with defining an OGPX/VWRAP virtual world
Thread-Index: Acoq69pSwgyAJ8zIRdiYEl9r4XpumQ==
From: "Magnus Zeisig" <magnus.zeisig@iis.se>
To: <ogpx@ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Content-class: urn:content-classes:message
X-Virus-Scanned: Debian amavisd-new at cleaner.prod.iis.se
Subject: [ogpx] An example to show the problems with defining an OGPX/VWRAP virtual world
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Worlds and the Open Grid Protocol <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Sep 2009 11:02:44 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Sorry to crash in and sorry if my below rambling is useless, a misinterpretation, or, even worse, only mess up things even further. But I believe an example might clarify things a bit to at least some readers. If my below example is wrong, perhaps someone with a better understanding than me could correct it or provide another example.

I think one of the problems with the definitions of "virtual world" and related terminology on the list is that it's easy to lock it to the existing models, like Second Life or OpenSimulator, and not realizing that future models might be quite different. If I understand the intents and early definitions on this list right, a very small but still rather complex OGPX/VWRAP model might look like this:

Protocols

* Five geographically adjacent simulators/regions in a rectangular grid: "R11" (top left), "R12" (top right), "R21" (middle left), "R22" (middle right) and "R3" (bottom left and right, since no requirement for equal-sized or -shaped regions exists).
* Four avatars: "A1", "A2", "A3" and "A4".
* Three simulator/region owners/managers: "M1" handling "R11" and "R22", "M2" handling "R12" and "R3", and "M3" handling "R21".
* Three asset/inventory service providers: "S1" catering to "A2", "A3", "R11", "R22" and "R3", "S2" catering to "R12" and "R21", and "S3" catering to "A1" and "A4" (one region owner may employ more than one asset service, like "M2" does with "S1" for "R3" and "S2" for "R12").
* Two authentication service providers: "L1" catering to "A1", "A2" and "A4", and "L2" catering to "A3".

Note that some of the above entities may be the same company or site providing different services, e.g. "Virtual World Services, Ltd." managing both "M1", "S1" and "L1".

Policies

All simulator/region owner/managers, asset/inventory service providers and authentication service providers share a common domain of trust, with the following exceptions:
* "M2" doesn't trust "S1" (e.g. owing to previous experiences of malicious content).
* "S1" doesn't trust "M3" (e.g. owing to "M3"s refusal to sign an IP agreement).
* "M1" doesn't trust "L2" (e.g. owing to a too loose control when accepting new users).

Results

Seen from the avatars' points of view, this means:
* "A1" can move freely with all attachments and inventory through all the regions.
* "A2"  can move freely through all the regions but can't bring attachments and inventory to "R12" and "R3" owing to "M2"s distrust for "S1", and "R21" owing to "S1"s distrust for "M3".
* "A3" can only move to regions "R12", "R21" and "R3" owing to "M1"s distrust for "L2", and can't bring attachments and inventory to "R12" and "R3" owing to "M2"s distrust for "S1", and "R21" owing to "S1"s distrust for "M3", i.e. is not fully operational in any region. Also, the world is geographically split since "R12" and "R21" is only connected through a corner where it can't cross but require teleportation.
* "A4" can move freely with all attachments and inventory through all the regions.

So, to "A1" and "A4" this is a great virtual world with five fully functional regions, to "A2" it's a hobbled world where it's ruthed (forced to some generic appearence) in three out of five regions, and to "A3" it's a lousy, splitted world with only three regions in which it's all ruthed. But what really constitutes the geographic "virtual world" in this example? The five regions "R11", "R12", "R21", "R22", "R3", the three regions "R12", "R21", "R3" where all avatars can go, or no region since there is no region that is fully functional to all avatars?

I guess this is part of the reason why the exact definition of e.g. "virtual world" and "interop" is not made, because the aim of the working group is to provide the technical specs necessary to enable, but not force, the communication between such entities as mentioned in the example above, while policies might make up a totally different infrastructure and impression of what the "virtual world" or "virtual worlds" and "interop" are, or at least appear to be to the end-users (avatar owners).

Best regards,
Magnus

-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSpzyJ+5MlU9XyaiSAQgTyQf+MjeSs8iKdSWHKKPASzwa9KjmYtj8ojUg
+nqiaGtaB7lWC/Lq1PUGxMXdJvUd4AhCL96wvawWQzxAQmYYk7n0hjvs6RKub2cm
bhuvhHbEtn/9uD1tdBJvm0x+Q1ZFr6nqE2XV9cXEwlGx32/wl9aP0/wejAouqCZM
a9YQv5ceE5B3zJn54TdbFPXX8V6OZ7jtiUplP2erhUg0hkzOjVYkwt1f5G9NJhW8
p2YcTYibC0mnnu/ATzVojMhxMiQpwxRH7695TobDUdBCz48+ix1tZvkLdk9o2t2u
JodGIkTtd+mFdYOtUNbaScrTs02exahKfqD81gaEYCcLfO+J14XkkQ==
=FsIQ
-----END PGP SIGNATURE-----