Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision

Joshua Bell <josh@lindenlab.com> Thu, 20 August 2009 22:59 UTC

Return-Path: <josh@lindenlab.com>
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 E11743A6D9C for <ogpx@core3.amsl.com>; Thu, 20 Aug 2009 15:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.373
X-Spam-Level:
X-Spam-Status: No, score=-1.373 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 bIyv2+k+Hk+5 for <ogpx@core3.amsl.com>; Thu, 20 Aug 2009 15:59:24 -0700 (PDT)
Received: from mail-yw0-f188.google.com (mail-yw0-f188.google.com [209.85.211.188]) by core3.amsl.com (Postfix) with ESMTP id 1D3183A6DBA for <ogpx@ietf.org>; Thu, 20 Aug 2009 15:59:13 -0700 (PDT)
Received: by ywh26 with SMTP id 26so346448ywh.5 for <ogpx@ietf.org>; Thu, 20 Aug 2009 15:59:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.18.20 with SMTP id 20mr474287anr.141.1250809153280; Thu, 20 Aug 2009 15:59:13 -0700 (PDT)
In-Reply-To: <f72742de0908201125k34443566tfaf2894167d7bbdf@mail.gmail.com>
References: <f72742de0908191206m2a5b3e2fm4efcf0eaf471a758@mail.gmail.com> <20090820140733.GA28751@alinoe.com> <f72742de0908201125k34443566tfaf2894167d7bbdf@mail.gmail.com>
Date: Thu, 20 Aug 2009 15:59:13 -0700
Message-ID: <f72742de0908201559j5e91c3abmcb5c3c4c4ea7c427@mail.gmail.com>
From: Joshua Bell <josh@lindenlab.com>
To: ogpx@ietf.org
Content-Type: multipart/alternative; boundary=0016e6470bdc435b6604719ab324
Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision
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: Thu, 20 Aug 2009 22:59:26 -0000

On Thu, Aug 20, 2009 at 7:07 AM, Carlo Wood<carlo@alinoe.com> wrote:
>
> This speaks of "a virtual world", which refering back to the introduction
> seems to define that there are more than one virtual world possible,
> and hence the phrase "the virtual world" seems to refer to a single
virtual
> world like Second Life (explicitely excluding open grid virtual worlds),
> or vica versa.

Ah, here's the crux of the problem - terminology. The protocol suite
we're envisioning talks about agents and regions, not about world or
worlds.

If you think of a set of regions under the control of one
administrative domain as being a "world", then depending on the
policy, then you could see the protocol as enabling interop between
"worlds".

However, we (the folks banging on the charter) don't believe (at this
point!) that such a deployment pattern concept needs to be either
explicitly described in the charter or is implicit in the protocol
itself.

Once you have an agent domain/region domain split, the concept of
"world" is much fuzzier. If "world" is the set of all locations an
avatar can visit, then multiple region domains create the "world" and
thus it is conceivable (modulo policy) that all services that
implement OGP region services are part of one big "world".

By analogy, the set of all publicly available sites that implement
HTTP could be called "the Web" - there is only one "web" even though
parts are blocked from access by policy (site policy, user policy,
government policy, etc). That doesn't preclude intranets. The analogy
isn't perfect by any means, however. And I don't think we're trying to
say "world" is the same as "web" intentionally - it just means that at
a protocol level, "world" isn't well defined.

I believe (but I'm not an active user), that in "Grid" mode, a
collection of OpenSims under distinct administrative control play
together to form a coherent "world"; they share some services but not
others, and users have a relatively seamless experience. (Please jump
in and correct me, OpenSim peeps!)

Another wrinkle in the terminology: it's easy to imagine that a large
VW provider like Linden Lab could, purely for administrative purposes,
split the VW service across both multiple agent and region domains. I
can imagine separate region domains being used purely for scale (e.g.
limiting the number of hosts per region domain), real-world geography
(e.g. region domains don't span colos), and so forth. Similar
divisions might occur for agent domains. Policy would dictate access;
in the cases listed above, I would imagine that it would be completely
transparent to users which agent domain/region domain they associated
with or in. In this scenario, referring to the collection of multiple
region domains as multiple "worlds" would be confusing to the end
user.

So... I wouldn't get hung up on it. From a protocol level, we need to
support interop between regions under distinct administrative control,
but we don't need to be explicit about it. That said, Zha's take on
deployment patterns will be critical for making sure we're addressing
the real world scenarios.

Now that I've said all of this - does anyone have concrete suggestions
for refining the charter text?