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

Morgaine <morgaine.dinova@googlemail.com> Mon, 14 September 2009 05:42 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 DA87E3A68DB for <ogpx@core3.amsl.com>; Sun, 13 Sep 2009 22:42:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.016
X-Spam-Level:
X-Spam-Status: No, score=-0.016 tagged_above=-999 required=5 tests=[AWL=-1.696, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_FWDLOOK=1.666, SARE_UNSUB18=0.131]
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 izouIU+4BqNT for <ogpx@core3.amsl.com>; Sun, 13 Sep 2009 22:42:28 -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 646C73A6781 for <ogpx@ietf.org>; Sun, 13 Sep 2009 22:42:27 -0700 (PDT)
Received: by ewy3 with SMTP id 3so2225133ewy.42 for <ogpx@ietf.org>; Sun, 13 Sep 2009 22:43:07 -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=SsHVe6rxaiCHUb0iFaj5nPvUb/6Jc+0wwhJt8BKf/yc=; b=eqU8IkItW5NuIXWcDkj0+o/V1eRJIRe2F8up2IwOc7/3nIyiWcg6hDGXCEc0edk7ay yiEdmC6ujd91D79Joqefy7W8wkYM4O8ag2Zar6+IozTwbx/UEAzKFOfMZ5m5hL29GaDB bRohm6kWKjCj139liTHzm2CfbVcbEi2SFjQqE=
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=rBE2HjGoPiFUeXMJ9X/i/kR87jqMOJ/QXLGmotjW/c0ZiPqbrRctVjt2eJWFzjJMiv nTWxYl8j6N5oLKf+pDvsBr7jhdzKMecD1wApM3cmgfgudrnohVrcKmiasmgcXEmy9LRM 0KJdPDKrcLM3AVjEk98qwGqEmOMJc8b7BYkDw=
MIME-Version: 1.0
Received: by 10.216.90.133 with SMTP id e5mr1461930wef.23.1252906986964; Sun, 13 Sep 2009 22:43:06 -0700 (PDT)
In-Reply-To: <20090904195822.GA15341@alinoe.com>
References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <f72742de0909011648l5bcfc98fm3aa2a80bf2f0e3c0@mail.gmail.com> <e0b04bba0909020641y7cb795b8ie167f8c4a035197e@mail.gmail.com> <20090902230338.GC6652@alinoe.com> <e0b04bba0909022028g68227199t86212294fe6faefc@mail.gmail.com> <20090904195822.GA15341@alinoe.com>
Date: Mon, 14 Sep 2009 06:43:06 +0100
Message-ID: <e0b04bba0909132243r10730a3fq275f8143087807c6@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: ogpx@ietf.org
Content-Type: multipart/alternative; boundary="0016e6dab052e507d904738323b5"
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: Mon, 14 Sep 2009 05:42:33 -0000

Carlo asked for detailed comments on the below, so here goes. :-)


On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood <carlo@alinoe.com> wrote:

> On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote:
> > 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.
>
> Well... that is purely semantic. It is a way to define VW, but not one that
> I've been using :/
>

It's a rough top-level projection of the architectural model of VWRAP, once
the various services have been decoupled in the way that David Levine often
describes to us.  Nothing very contentious there, everyone likes a
services-oriented approach. :-)


>
> For simplicity, assume that only two things are needed to create a complete
> virtual world, like SL or OG: A Region Domain (RD) and an Agent Domain
> (AD).
>

I am happy to consider that simple scenario as representative.  It is quite
reasonable to equate AD with VW because the AD is the focus of almost all
the policy decisions of a VWRAP-based world.  When other decoupled services
are added to this picture, it doesn't change the fundamental architecture of
AD + RDs, only extends it by decoupling more than just the region service.
So that's fine with me.


>
> Currently, without any interop, each administrative entity (or trust
> entity)
> will need to provide both: an RD *and* an AD, otherwise they don't have a
> functional VW.
>

Correct.  The AD is the seat of most (but not all) of the policy decisions
of a VW, so it's very central to the existence of a VW.  While it's possible
to imagine policy-free VWs that temporarily  take on the policy of any other
world they hook up with, this is clearly a subset situation.  All the
currently known SL-like virtual worlds are grids of the SL kind, with their
own individual policies which they are not going to change on interop.


> Your conclusion is that a VW exist of both 1 RD and 1 AD. But I ask you to
> reconsider if that conclusion is correct, because it is based on the
> current
> situation without any interop. Now "correct" might not be the correct word
> - heh.
> Rather I should say: I ask you to reconsider if that definition is very
> useful.
>
> Lets consider the following fictive case:
>
> LL runs one RD and AD, called RD1 and AD1.
> CB (Cable Beach) runs another RD and AD, called RD2 and AD2.
> A user that authenticates with either AD1 or AD2 can travel to RD1 AND RD2,
> completely symmetrical, keeping their respective AD1- and AD2- assets etc.
> This is possible with the right policies, so for the sake of looking at
> the usefulness of the above definition of VW, assume this is the case.
>

That's not quite right because Cable Beach is not a world provider like LL.
Cable Beach is perhaps best described as a "login mediation" mechanism or
protocol, which provides a model for interaction between a "world service"
(effectively an AD), the user's client, and various decoupled services such
as simulation nodes (possibly an RD) and inventory/asset services.  Let's
assume therefore that your "CB" above means something different (another
world provider similar to LL), and then we can proceed with your example
case.



> Would you consider "RD1 + AD1" one VW, and "RD2 + AD2" to be another VW?
> Or do you think it would make most sense in THIS case to speak of a single
> VW?
>

They're two worlds because you defined them as such, as each has its own
AD.  :-)  But that aside, if they were set up separately then they have two
different sets of policies, two different sets of residents, two different
ToS's, possibly two different legal jurisdictions, two different mechanisms
for abuse control and conflict resolution, and so on and so forth.  If they
were created to be worlds that can stand alone but interoperate when
desired, then each of these is a diffferent world.  I don't see how that can
be disputed.


>
> I think this is what Infinity means when she says that "virtual world"
> cannot
> be defined, because what could be perceived as being a VW is highly
> dependend
> on the exact situation (and policies) and in certain configuration that are
> not as clear as the current situation (no interop) or the above example
> (100%
> interop).
>
> This is incorrect.  "Virtual world" is defined by each provider of a
virtual world and by nobody else, and each provider knows full well how it
is defined, what its boundaries are, and what makes it distinct.  Nobody
else can define what a virtual world is, and it's not our business to define
it either (nor to conjure up a fictitious definition).

We only need to define the protocol interactions at the endpoints presented
by those worlds, and not to define "virtual world" structurally nor any
other way.  Doing so is what has got us into this mess, by creating a
fictitious definition based on reachability and hence blocking any ability
to talk about *actual* virtual worlds.  Those worlds exist.  They won't go
away.  They want to interoperate, but they don't want to be told that they
don't exist.

The contention that we don't know what "virtual world" means is just plain
bizarre.  I don't know of any VW operator who doesn't know what their world
is.  Every single one of them could provide the necessary endpoints for
VWRAP within their world without any scratching of heads at the meaning of
"virtual world".  That repeated allegation has been a complete
misrepresentation.  It's just not true.

And possibly even worse is the *excuse*  that "virtual world" is not being
defined but is being used non-normatively, while *in practice* using the
phrase "*the* virtual world" to create a totally fictitious single virtual
world instead.  That phrase is unnecessary, it is misrepresentative of the
actual situation, it bypasses policy controls of one world by not mentioning
its AD, it prevents us from mentioning virtual worlds by blocking the normal
meaning of the term, and it provides nothing useful as a benefit in return.
Unless total confusion is a benefit. ;-)


In one of my first posts about this topic I stated that "virtual world"
> should
> be considered to be the Region Domain (although I didn't use that term at
> the
> moment) and be completely independent of the Agent Domain, based on typical
> cases of abuse and griefing etc: if anyone annoys some other user, or
> breaks
> almost any ToS, it will be region based; which is why I've always said that
> any type of abuse can and should be handled at the sim (single region)
> level:
> the estate owner and managers in SL, even, but that idea definitely extends
> to "world administrations": the people running the REGION (domain) is the
> one
> that should decide what is the local ToS and deal with abuse etc. That is
> why I strongly argue to define "virtual world" as Region Domain, and leave
> the AD out of it. Nevertheless, now I have the term "Region Domain" I don't
> need "virtual world" anymore.
>

But that's *not* how OGP is structured.  It's the AD that is the focus of
service policy choices in OGP, and it's the "world service" that is the
focus of service policy in Cable Beach.  The AD and the world service are
the source of capabilities that determine pretty much everything else, and
the region domain is very subsidiary to that.  Indeed, a region domain may
have no policy of its own at all, but merely extend an existing virtual
world by accepting the policies of that world's AD.  That's the model in the
original OGP before it gained aspirations of becoming a cross-VW interop
protocol.

If RDs determined VW policy and generated seed capabilities for everything
and ADs were merely login services then your model would apply, and RD could
be considered "VW".  But that's not how it is currently structured --- RDs
are merely the land + physical simulation components of worlds, and in SL's
case, also an elaborate system of proxies.  And that's why we need multiple
ADs to interact in VWRAP before we can consider that there is VW-VW
interop.  RDs don't handle it.


> > 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.
>

Indeed.  But access to such decoupled services is provided by the AD through
the capabilities that it delivers to authorized parties, and regions are
just one such service.  You're giving RDs credit for something that they
don't do. :-)  Perhaps the VWRAP model should be redesigned along your lines
so that RDs become the VWs and are the generators of seed caps, and then ADs
become just a subservient policy-free login mechanism. :D


> I'm afraid that is purely a matter of opinion. I agree that it is likely
> that a single 'administrative entity' that runs a RD will also run an AD
> and allow users authenticated with their AD visit their RD, but it is no
> more than *likely*. There will almost certainly be service provides that
> ONLY run an AD, and don't have a RD! And I can imagine that there will
> be some that only run a RD and do not care about running their own AD.
>
> Oh sure, there will be all combinations of services, that is to be
expected.  But it is the seat of policy that is the heart of each virtual
world, and currently the seat of policy lies in the AD.  A VW that doesn't
have an AD in the VWRAP model is just a colony without a government, ready
to be assimilated into a world that has an AD and that therefore sets
policies, instead of being a sovereign world that merely wants to interop
with that other world through VWRAP.



> Therefore, "virtual world" cannot be synonym for "the set of services
> run by a single administrative entity" as you seem to argue, and at
> the SAME time be argued to include an RD *and* AD at all times.
>
> I don't follow that.  Two worlds *that can run independently* (that's very
important) can certainly each be defined as a set of services that includes
the functions of an AD and an RD, and those worlds each continue to include
the functions of an AD and an RD even after they start interoperating
(assuming that VWRAP is extended to allow cross-VW interop).  No world is
going to give up part of its services portfolio on interop.  Interop is an *
additional*  benefit, not a loss of capability.

[It's worth noting that there may actually be a small loss of capability
occurring on interop in VWRAP, although it is rarely mentioned.  You can be
present in two worlds simultaneously with the same login credentials
pre-interop (a feature that we enjoy currently between SL and OSgrid for
example), but post-interop this may no longer be possible --- it depends on
the implementation.  No doubt we will visit this issue within VWRAP.]


> 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.
>
> Of course, LL happens to run all services that are needed to create one
> virtual world; there are no third parties they can hire from yet, so they
> have to provide it all themselves.
>
> But after SL implemented VWRAP they might decide to do away from one of
> their services and only keep their RD. Unlikely, but possible.
>

You're confusing RD functionality with AD functionality again there.  The AD
is the heart of a world because it defines its capabilities and policies.
The RD is just a pile of region hosts that could easily be farmed out to a
third party to run without them determining policy, and indeed this is
already being done.  While it is a very important pile of hosts which gives
a world its physical characterists, the RD is a subservient service to the
AD in OGP, just as the equivalent "simulation nodes" provide a subservient
service to the "world service" under Cable Beach.  The RD is well named ---
it provides region services only, not the package of internal + external
services that together create a virtual world.


>
> >   • 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.
>
> Exact same argument.
>

Exact same response because the same applies. :-)   What's more, in OSgrid
this is even easier to identify, because every person or company that adds
regions to OSgrid is subscribing to the notion that they are participants in
OSgrid --- OSgrid is their virtual world.  They are merely providing
additional land mass and simulation capacity.

Also, in this example there is no need to hypothesize region services being
farmed out to third parties, as there already are hundreds to thousands of
independent third parties involved in supplying regions.  Those regions and
clusters of regions (equivalent to RDs) together combine to create the
virtual world of OSgrid.  There is a clear distinction between R/RDs here
and the VW itself, which also includes a variety of other services as
Charles has described several times.  The R/RDs are a very important part,
but functionally they are not the VW, nor are they the VW perceptually.
They are places within the world, not the whole world.


> > 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.
>
> If you want to put it that way (including everything above that you said)
> then
> I have to side with Infinity: you cannot define a virtual world that way
> and
> use it for useful discussions regarding VWRAP.
>

I think you may have misread that.  I did not define "VW == RD".  That's the
opposite of what I said, but I agree with you on the negative conclusion.
If one defines "VW == RD" then it becomes impossible to have a meaningful
discussion about VWs in VWRAP.  It also becomes impossible to have a
meaningful discussion about VWs in VWRAP if one conjures up a fictitious
meaning of "virtual world" based on reachability.  And that's why we should
not define it in either of those two ways.

The most useful and forward-looking way of defining virtual worlds in VWRAP
is as a collection of service endpoints, regardless of who operates them.
All we should care about is the protocol between endpoints, and not conjure
up some non-existent single virtual world.


>
> In the end, one virtual world as defined by "all services together to make
> things work" will be, or can be, a mix of many RD's and many AD's with a
> complex
> web of trust/non-trust between them that makes the concept of "virtual
> world"
> rather fuzzy at best.
>

You're right but you're not being clear about what is fuzzy.  The concept of
"*single virtual world*" is not only fuzzy, it is totally *non-existent in
practice* (because there are many, not one) as well as *impossible in theory
*  because of balkanization through incompatible trust domains, as described
so magnificently by Magnus a week or two ago.  We should not go there.

In contrast, the concept of *multiple virtual worlds* is crystal clear.
Several people here in the group operate virtual worlds, but nobody would
suggest that they are unclear about what they operate.  We've been sold a
bridge on that "uncertainty".  Multiple virtual worlds presenting VWRAP
endpoints are the natural way of approaching interop between VWs, and you
don't have to define VWs structurally for that.  You only have to define the
endpoints that VWs need to present to the protocol, and avoid any notion of
"single virtual world".



> [...]
> > 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.
>
> You can about peering with just two RD's and one AD, or one RD and two
> AD's.
>

I think you're confusing RDs with VWs again --- RDs only provide regions,
nothing else.  For peering between two VWs, you would need interaction
between their two ADs because their ADs provide their policies.  If you
bypass a VW's AD then you bypass its policies, so you're not interoping with
that world.  And I don't think we're encouraging bypassing and hence
subverting a world's policies.


> > 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. ;-)
>
> I can't comment on that cause I didn't see VWRAP yet, but from the
> charter and the comments on this list I'd think that full support
> for interop between any number of RD's and AD's is intended.
>

Well you've put your finger on the problem here.  Everyone is saying what
they *think* is intended because the intention is not actually spelled out
in the documents.  Why cannot it be spelled out clearly that interop between
multiple ADs is intended?  If it were, this entire discussion could be
avoided because it's easy and reasonable to equate ADs with VWs in practice.

Notice however that even if the protocol were modified to be able to handle
two ADs at a time, use of an unadorned "the virtual world" in the documents
would continue to raise the perennial question of "Which virtual world?".
After all, there would be two of them being discussed.

It's this phraseology that stems from OGP's original goal of adding *single
regions or RDs* to an existing *single virtual world* (namely SL in the
prototype) that is creating such a problem.  That phraseology was
appropriate for that original goal.  It is not appropriate for the goal of
interoperating multiple virtual worlds --- it makes it impossible to even
talk about the goal sensibly, because "the virtual world" in the OGP sense
has no plural.

It's unfortunate, but this whole affair is just the product of legacy
wording from OGP.  That's never going to work in a multi-world setting where
we need to talk about the endpoints in different worlds.


Morgaine.

PS. If anyone else read this far other than Carlo, you have a lot of stamina
and dedication. ;-)







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

On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood <carlo@alinoe.com> wrote:

> On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote:
> > 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.
>
> Well... that is purely semantic. It is a way to define VW, but not one that
> I've been using :/
>
> For simplicity, assume that only two things are needed to create a complete
> virtual world, like SL or OG: A Region Domain (RD) and an Agent Domain
> (AD).
>
> Currently, without any interop, each administrative entity (or trust
> entity)
> will need to provide both: an RD *and* an AD, otherwise they don't have a
> functional VW.
>
> Your conclusion is that a VW exist of both 1 RD and 1 AD. But I ask you to
> reconsider if that conclusion is correct, because it is based on the
> current
> situation without any interop. Now "correct" might not be the correct word
> - heh.
> Rather I should say: I ask you to reconsider if that definition is very
> useful.
>
> Lets consider the following fictive case:
>
> LL runs one RD and AD, called RD1 and AD1.
> CB (Cable Beach) runs another RD and AD, called RD2 and AD2.
> A user that authenticates with either AD1 or AD2 can travel to RD1 AND RD2,
> completely symmetrical, keeping their respective AD1- and AD2- assets etc.
> This is possible with the right policies, so for the sake of looking at
> the usefulness of the above definition of VW, assume this is the case.
>
> Would you consider "RD1 + AD1" one VW, and "RD2 + AD2" to be another VW?
> Or do you think it would make most sense in THIS case to speak of a single
> VW?
>
> I think this is what Infinity means when she says that "virtual world"
> cannot
> be defined, because what could be perceived as being a VW is highly
> dependend
> on the exact situation (and policies) and in certain configuration that are
> not as clear as the current situation (no interop) or the above example
> (100%
> interop).
>
> In one of my first posts about this topic I stated that "virtual world"
> should
> be considered to be the Region Domain (although I didn't use that term at
> the
> moment) and be completely independent of the Agent Domain, based on typical
> cases of abuse and griefing etc: if anyone annoys some other user, or
> breaks
> almost any ToS, it will be region based; which is why I've always said that
> any type of abuse can and should be handled at the sim (single region)
> level:
> the estate owner and managers in SL, even, but that idea definitely extends
> to "world administrations": the people running the REGION (domain) is the
> one
> that should decide what is the local ToS and deal with abuse etc. That is
> why I strongly argue to define "virtual world" as Region Domain, and leave
> the AD out of it. Nevertheless, now I have the term "Region Domain" I don't
> need "virtual world" anymore.
>
> > 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.
>
> I'm afraid that is purely a matter of opinion. I agree that it is likely
> that a single 'administrative entity' that runs a RD will also run an AD
> and allow users authenticated with their AD visit their RD, but it is no
> more than *likely*. There will almost certainly be service provides that
> ONLY run an AD, and don't have a RD! And I can imagine that there will
> be some that only run a RD and do not care about running their own AD.
>
> Therefore, "virtual world" cannot be synonym for "the set of services
> run by a single administrative entity" as you seem to argue, and at
> the SAME time be argued to include an RD *and* AD at all times.
>
> > 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.
>
> Of course, LL happens to run all services that are needed to create one
> virtual world; there are no third parties they can hire from yet, so they
> have to provide it all themselves.
>
> But after SL implemented VWRAP they might decide to do away from one of
> their services and only keep their RD. Unlikely, but possible.
>
> >   • 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.
>
> Exact same argument.
>
> > 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.
>
> If you want to put it that way (including everything above that you said)
> then
> I have to side with Infinity: you cannot define a virtual world that way
> and
> use it for useful discussions regarding VWRAP.
>
> In the end, one virtual world as defined by "all services together to make
> things work" will be, or can be, a mix of many RD's and many AD's with a
> complex
> web of trust/non-trust between them that makes the concept of "virtual
> world"
> rather fuzzy at best.
>
> [...]
> > 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.
>
> You can about peering with just two RD's and one AD, or one RD and two
> AD's.
>
> > 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. ;-)
>
> I can't comment on that cause I didn't see VWRAP yet, but from the
> charter and the comments on this list I'd think that full support
> for interop between any number of RD's and AD's is intended.
>
> --
> Carlo Wood <carlo@alinoe.com>
>