Re: [ogpx] VWRAP Draft Charter - 2009 09 01

Morgaine <morgaine.dinova@googlemail.com> Thu, 03 September 2009 03:29 UTC

Return-Path: <morgaine.dinova@googlemail.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 356003A69A5 for <ogpx@core3.amsl.com>; Wed, 2 Sep 2009 20:29:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.775
X-Spam-Level:
X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=0.201, 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 KSqrEeYZcy4O for <ogpx@core3.amsl.com>; Wed, 2 Sep 2009 20:29:29 -0700 (PDT)
Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 07F783A6905 for <ogpx@ietf.org>; Wed, 2 Sep 2009 20:29:28 -0700 (PDT)
Received: by ewy3 with SMTP id 3so1450458ewy.42 for <ogpx@ietf.org>; Wed, 02 Sep 2009 20:28:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=8PYO4U4la4rqaQ1jma4gKlgf1m6EN6B0VLR7spkCCRc=; b=Nz1phE6H9HC58ZZx9GPfZ41OP/jMLvju7IFE9MJnFKITqxFxijzFIHElMxHw+JY4yN k1l+Fs8erBG6373YnebpOEp7ZOcdSB4ZDwRGmpZNKU6vXCOzJqvTn3JDbTr0oG735+mw YFr67WTof7ckO2r3JeHWEj+tOaAbAyLX/bswY=
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 :content-type; b=Ch3hJQq7QrZ927myki7dlzK06rdp2migOOhwUAMj904Xl48y90oVv9yei07gEF/+dG EEsP6C5CPyo75//bNxVHodNsxUq+0wrQRJThuYKpkYnMIjpy+PknWI5VS0TH0YfmyO0A NGnAYHs6OmtTXuxzOpfwcvOOznEYbQVbdRRCI=
MIME-Version: 1.0
Received: by 10.210.3.14 with SMTP id 14mr9782418ebc.80.1251948483560; Wed, 02 Sep 2009 20:28:03 -0700 (PDT)
In-Reply-To: <20090902230338.GC6652@alinoe.com>
References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <f72742de0909011648l5bcfc98fm3aa2a80bf2f0e3c0@mail.gmail.com> <e0b04bba0909020641y7cb795b8ie167f8c4a035197e@mail.gmail.com> <20090902230338.GC6652@alinoe.com>
Date: Thu, 03 Sep 2009 04:28:03 +0100
Message-ID: <e0b04bba0909022028g68227199t86212294fe6faefc@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: ogpx@ietf.org
Content-Type: multipart/alternative; boundary="000e0ce03beea3c7920472a3f84d"
Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01
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, 03 Sep 2009 03:29:31 -0000

[This discussion should now be regarded as post charter agreement, I
believe.]

On Thu, Sep 3, 2009 at 12:03 AM, Carlo Wood <carlo@alinoe.com> wrote:


> Therefore, your (and my) view of "virtual world", namely a
> collection of regions run by a single administration, who obviously
> can decide to use any arbitrary inter-world protocol, and therefore
> which ALSO can be defined more technically by being set of regions
> that define VWRAP endpoints at it's boundary, is the same as a
> "region domain"! :)
>
>
Carlo, unfortunately that interpretation is not correct. :-))))

The problem you see is that a virtual world is much more than just a Region
Domain.  It is a complete set of services of which the Region Domain service
is just one.  Other typical services might be those of the Agent Domain
(which provides identification and authorization services and possibly
others), as well as asset and inventory services, IM and other communication
services, and maybe several more.

In our new protocol, these services may either be implemented internally
within a virtual world, or some might be implemented as external services
offered by third parties, the choice being a policy and design decision for
each world operator.  In all cases however, the virtual worlds are defined
by a *set* of services, and not just by a Region Domain.

This is easy to see by looking at a couple of archetypal examples in this
space:


   - Is Second Life a virtual world?  Undoubtedly.  Is Second Life just a
   Region Domain (assuming it were implemented using VWRAP)?  No, of course
   not, SL includes all of the services mentioned above, and others.
   - Is OSgrid a virtual world?  Undoubtedly.  Is OSgrid just a Region
   Domain (assuming it were implemented using VWRAP)?  No, of course not, it
   currently runs all the UGAIM services, which in a VWRAP context would become
   similar to those of Second Life.


So you see, the idea that has been floated which claims that "VW == RD" is
completely wrong, and misrepresents what constitutes a "virtual world"
despite the very clear examples before us.

Also note that an RD cannot provide the full set of VWRAP endpoints, but
only those endpoints appropriate to the region services, proxying aside.
Instead, it is the *VW* that provides the full set of VWRAP endpoints, but
only a subset of those are contained in or provided by the RD.  VW != RD.

And this is why the VWRAP protocol as currently defined by our old reference
OGP documents cannot possibly interoperate between VWs because it defines
interoperation between one VW and one or more regions or Region Domains, and
not between one VW and another VW, nor between two RDs.  If VWs and RDs were
indeed identical then there would be no issue, but I doubt that Linden Lab
wishes to demote Second Life to the status of an RD only. ;-)

As we move into analysis of the problem space, these issues will be
disentangled and clarified and the protocols will be defined and evolve, but
from the current OGP perspective there is no symmetrical relationship
possible between VWs that could be described as "peering".  It is the
asymmetry of the VW-RD relationship that has been the crux of the "no VW
interop" issue.  For symmetrical peering, the protocol would need to mention
at least two communicating VWs.

Of course the situation could change as the protocol evolves.  For example,
once or twice we have heard mention that multiple ADs could be involved in
some way, and it seems certain that communication services from multiple VWs
will be merged because residents demand this.  This would start to take us
into VW-VW interop territory.  However, there is no such thing in VWRAP
currently, and it's not in the list of deliverables to include it, and
therefore we cannot say that VWRAP will provide VW-VW interop at all.  For
now. ;-)


Morgaine.






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

On Thu, Sep 3, 2009 at 12:03 AM, Carlo Wood <carlo@alinoe.com> wrote:

> On Wed, Sep 02, 2009 at 02:41:37PM +0100, Morgaine wrote:
> > Joshua, this draft of the charter reads a lot better than the previous
> ones,
> > the iterations are definitely helping. :-)
> >
> > Admittedly, our job has been simplified tremendously by knowing that
> VWRAP will
> > not address interop between VWs, so that we can focus on the single-world
> > building aspects of the work.  This is good.  (Not ideal but still very
> > useful.)  We could have been here already on the 20th August if my call
> for
> > clarity had been accepted.
> >
> > The following is worth noting:  because you still have not spelled out
> that the
> > protocol does not allow for more than one world to be mentioned (it never
> talks
> > to a peer world), the workgroup will probably continue to receive input
> from
> > people expecting VWRAP to be a VW interop protocol.
> [..snip..]
>
> Morgaine,
>
> I think that Meadhbh's standpoint is not that VWRAP shouldn't allow VW
> interop,
> we just failed to understand eachother.
>
> I think I now FINALLY start to understand what she's been trying to say,
> so let ME try to give you a clear explanation:
>
> The refusal to define "virtual world" is, imho, irrational and apparently
> based on the fact that the MMOX effort failed because they couldn't get
> an agreement on it's definition. Fearing that any attempt to define
> it in this group would lead to a failure again, Meadhbh dogmatically
> refused to even consider talking about it. A definition of the term
> "virtual world" is taboo. Not rational, but lets just accept that
> as a fact. After all, the solution is simple: use a different term!
>
> I've seen some people the term 'grid', but also that isn't very
> clearly defined (although not as much taboo).
> A better term however is apparently "Region Domain".
> "Region Domain" is defined within OGPX namely, and means something
> along the way of:
>
> * A collection of regions run by a single entity (in the trust model).
>
> What WE consider a "single administration", or, for example,
> the current participants like Linden Lab, or people running
> a given VW/grid using OpenSim right now is as good as synonym
> for "single entity in the trust model."
>
> Therefore, your (and my) view of "virtual world", namely a
> collection of regions run by a single administration, who obviously
> can decide to use any arbitrary inter-world protocol, and therefore
> which ALSO can be defined more technically by being set of regions
> that define VWRAP endpoints at it's boundary, is the same as a
> "region domain"! :)
>
> Hopefully this clarifies things and I propose to start using
> "region domain" instead of "virtual world", because the last term
> is not usuable in a technical context without clear definition.
>
> Most importantly, Meadhbh/Joshua et al ARE concerned with
> allowing interop between different region domains and definitely
> think that this is an important part of VWRAP.
>
> The main difference, I think, is that they are mostly interested
> (from their background with LL) in a tight trust model where
> there is no room for "stealing content" without legal consequences
> while you and me, and Cable Beach, think that the VWRAP universe
> will benefit most from a nil trust model. We'll just have to
> make sure that VWRAP will allow as much as possible with as
> little trust as possible. I think a win-win solution is definitely
> possible here.
>
> --
> Carlo Wood <carlo@alinoe.com>
>