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

Morgaine <morgaine.dinova@googlemail.com> Thu, 01 October 2009 21:32 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 2C73A3A68B9 for <ogpx@core3.amsl.com>; Thu, 1 Oct 2009 14:32:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.059
X-Spam-Level: *
X-Spam-Status: No, score=1.059 tagged_above=-999 required=5 tests=[AWL=-2.376, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, 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 CG499EZkS2OA for <ogpx@core3.amsl.com>; Thu, 1 Oct 2009 14:32:48 -0700 (PDT)
Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 9665D3A67B3 for <ogpx@ietf.org>; Thu, 1 Oct 2009 14:32:47 -0700 (PDT)
Received: by ewy28 with SMTP id 28so750486ewy.42 for <ogpx@ietf.org>; Thu, 01 Oct 2009 14:34:10 -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=DkHqubJiuNX47a/WuvHyWvipknbrfMD0F2kAwV3EiVY=; b=pOaa9E/9KPf0iYssZ/wBoJuhw+drCHd7qYyqTdoNtpoddsiJDRuvybSRvP0AfDTeRh 4UMOrgkxbbc4G+G5okAtM9Qi+N0C2P9YTTGGlU61kM5KKx/kC7an85Q3PK5+c2JvxzRD mZGDyCKcO7gQrKDMi+DDnFIduE29gMZVJjsiE=
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=udZCHuzNH+15uOR/ecibBJ+9CZUKnCuAthRlAjEfMAm29rppgpn1G0Q7JJ8uC/2rgf lPIqQw2J404ML0366nOZzC+TwL/3LJlS/+oZpzVDytzfE5HvAkff0pyUMQSg9L0Pslhq Xhd3Nv3GjIBt7gzXGGhioVVikPxh5gXShSPLo=
MIME-Version: 1.0
Received: by 10.211.160.4 with SMTP id m4mr2047888ebo.24.1254432850216; Thu, 01 Oct 2009 14:34:10 -0700 (PDT)
In-Reply-To: <f72742de0909300910t23131532i1719d2c86423fa41@mail.gmail.com>
References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <e0b04bba0909020641y7cb795b8ie167f8c4a035197e@mail.gmail.com> <20090902230338.GC6652@alinoe.com> <e0b04bba0909022028g68227199t86212294fe6faefc@mail.gmail.com> <20090904195822.GA15341@alinoe.com> <e0b04bba0909132243r10730a3fq275f8143087807c6@mail.gmail.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <e0b04bba0909291751g157d2043g1c15e8d8ac417ccf@mail.gmail.com> <f72742de0909300910t23131532i1719d2c86423fa41@mail.gmail.com>
Date: Thu, 01 Oct 2009 22:34:10 +0100
Message-ID: <e0b04bba0910011434i13f890bfodd22cd15eef17697@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: ogpx@ietf.org
Content-Type: multipart/alternative; boundary="00504502d38a6e91d40474e66857"
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, 01 Oct 2009 21:32:55 -0000

On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell <josh@lindenlab.com> wrote:

>
> IMHO, it should be apparent that both AD (which is the agent/advocate for
> the user) and RD (where the user wants to be) both need to make policy
> decisions.
>
>
Excellent, Joshua!

I think we're finally approaching the road towards *Destination Determines
Policy* now, which is a prerequisite for real interop between virtual
worlds.  This was simply not possible with the old OGP thinking in which
policy was given by a "trust domain" defined by a single AD alone.

It's a two-part problem.  Naturally your *source* world can impose
restrictions on travel (a walled garden may disallow any foreign travel at
all, for example), that's clear.  What hasn't been clear until now is that
the *destination* world will have conditions which are every bit as strong
and important as the source world, and represented in the same way (eg. in
their AD).  Both sides must be allowed equivalent representation in the
protocol.

This is why the single-world terminology was such a barrier earlier.  It
completely prevented us from bringing the two worlds into the discussion
simultaneously, which is necessarily when both source and destination are
completely equivalent peer worlds.

Your next step is to realize that, for two structurally identical worlds, if
the seat of policy of one lies in its AD, then the seat of policy of the
other also lies in its AD.  Therefore your statement needs to be modified to
the following:

IMHO, it should be apparent that both the AD of the source world and the RD
and AD of the destination world all need to make policy decisions.


What's true for the source world is also true for the destination world,
policy-wise.  The destination world is not "inferior" in any way.  It's a
necessary peer in the protocol.  You can't exclude it from the equation.


Morgaine.






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

On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell <josh@lindenlab.com> wrote:

> Without diving in too deep, I believe this thread is putting up a two-level
> false dichotomy - either the RD determines policy or the AD determines
> policy, OR things aren't sensible w/o nil trust. If that's a mis-reading, my
> apologies.
>
> IMHO, it should be apparent that both AD (which is the agent/advocate for
> the user) and RD (where the user wants to be) both need to make policy
> decisions.
>
> A corporate AD may restrict where users may visit (e.g.
> agentd.corp.example.com may say "no visiting party.example.com from
> work!") or an AD may restrict users based on personal preferences (
> agentd.safesurf.example.com may say "scam.example.com is on a shared
> blacklist of malicious sites, teleport blocked"), legal or political
> requirements (agentd.kidfriendly.example.com may say "you can't visit
> adultgrid.example.com"). Note that in all cases the AD is enforcing policy
> as an agent of the user, just as a web browser on a local network does
> today. Presumably, there will exist many ADs that provide no restrictions
> whatsoever, just as most Web browsers accessing the 'net via most ISPs in
> most countries today don't restrict access to Web content via policy.
>
> On the flip side, the RD will also have policy. Corporate VWs may limit
> access to employees. Adult-centric VWs may limit access to agents from ADs
> that verify accounts with some well known service.
> Real-world-region-specific RDs may require citizenship checks and deny
> access to citizens of some nation-states. And of course permissions would
> doubtless exist on a per-user basis as well as per-AD. Again - no different
> than access permissions today on the Web, except that instead of being a
> two-party user/service, it's three party user/AD/RD. And one hopes that,
> like most of the Web, content is freely visitable by all.
>
> On the topic of nil-trust: again, I wholeheartedly support the stance that
> the protocol should support nil trust operation. I hope that both the
> protocol and operations of VWRAP-based worlds allow the bulk of VWRAP
> traffic to occur in a nil trust environment, just like the Web does today.
> However, I *suspect* that, in practical terms, the abilities we want to
> grant to regions by visiting them - to display our avatars, to broadcast
> information about our agents, to give and receive virtual goods - will
> require at least a modicum of trust for most VW interaction, at least on the
> level of an SSL-style secured connection that gives users a certificate to
> look at that provides some identity/trust information about the service
> provider.
>
> I suspect I'm going to beat this drum a lot - "VWs are just like the Web,
> except where they're different" :)
>
>
> On Tue, Sep 29, 2009 at 5:51 PM, Morgaine <morgaine.dinova@googlemail.com>wrote:
>
>> Hi Vaughn! :-)
>>
>> Your description of our discussion is quite accurate.  However, it seems
>> to imply that I advocate in favour of the view that the AD must be the seat
>> of all policy for connected regions.  I do not.  I was merely explaining the
>> architecture of AD+RD pairing as it has been described to us repeatedly
>> throughout the two years of our OGP-related work in the LL+IBM sponsored
>> Architecture Working Group within Second Life.
>>
>> After the emails, Carlo and I examined this issue with higher discussion
>> bandwidth inside SL, and it turned out that we were describing two different
>> things:  I was explaining the AD+RD relationship in OGP, while Carlo was
>> describing RDs *as they should be designed* if an RD were an autonomous
>> unit with its own policies, effectively a small world.  If OGP were designed
>> differently and less restrictively to allow that, then there would have been
>> no discussion.  :-)
>>
>> Of course, OGP is not VWRAP, but only the seedcorn for VWRAP.  We can make
>> VWRAP as flexible as we like, and it's easy to see its potential flexibility
>> in David's deployments document.  Consequently, I have high hopes that all
>> parties will be happy with the eventual outcome. :-)
>>
>> You may have missed the primary reason why I do not advocate a design in
>> which an OGP-style AD is the seat of all power, possibly because the
>> discussion has been spread out across all of OGPX and MMOX.  It's easy to
>> summarize in one sentence though:  such a design cannot underpin an
>> Internet-wide metaverse of interoperating virtual worlds because it doesn't
>> respect the key meme of virtual and non-virtual tourism:  *Destination
>> Determines Policy*.
>>
>> This meme is so fundamental and crucial (and obvious) that OGP's support
>> of the exact opposite is terminally broken, as a basis for the hypothetical
>> metaverse.  Indeed, you yourself have referred to the problem in the funny
>> "war over purple". :-)  At best such a design can support only a random
>> scattering of VPN-like walled gardens, all isolated and *incapable of
>> interoperating* because they all claim the "one true policy".  We should
>> not go there.
>>
>> The most recent description of this problematic aspect of the OGP design
>> was posted by Magnus Zeisig in his excellent email at
>> http://www.ietf.org/mail-archive/web/ogpx/current/msg00324.html , which I
>> fully support.  Such balkanization is not a desireable goal when designing a
>> VW interop protocol.
>>
>> So where are we now?  We're at the stage of examining David's VWRAP
>> deployment patterns to see how the protocol can support them.  And in that
>> examination, it is likely to become clear that the old OGP model of "AD
>> determines policy" is completely non-viable for interoperating between
>> VWRAP-compatible virtual worlds, except when that policy is "nil trust" as a
>> common denominator.
>>
>> Consequently, we will either decide to live with the original OGP split
>> and use "nil trust" as our basis for VW interop, or else we will redesign
>> the AD/RD relationship to place many more important policy decisions where
>> they really belong, at destination.  The latter seems the best choice to me,
>> and of course it would make Carlo happy, and it is also the model that every
>> single existing world already operates --- when in Rome, do as the Romans
>> do.  Only the old OGP AD/RD two-way split design is out of step.  Let's hope
>> that we can correct that in VWRAP. :-))
>>
>>
>> Morgaine.
>>
>>
>>
>>
>>
>>
>> ====================================
>>
>>
>>
>> On Tue, Sep 29, 2009 at 9:16 PM, Vaughn Deluca <vaughn.deluca@gmail.com>wrote:
>>
>>> Carlo and Morgaine have above been involved in a very interesting
>>> discussion about the nature of the (or *a*) virtual world.
>>>
>>> Painting their positions with  broad strokes, Morgaine stresses the
>>> primary role of the AD as the seat of policy and trust, up to the point
>>> where he denies the RD any role above that of a convenient extension of the
>>> AD, i.e. the RD as "colony without a government". Carlo passionately argues
>>> for the independent role of the RD in policy issues.
>>>
>>> I feel that both positions are valid (to some degree), and both can be
>>> covered by VWRAP.
>>>
>>> Calo makes absolutely clear that having all policy in the respective ADs
>>> of the avatars leads to problems when several avatars meet in one region
>>> domain, say RD1. Avatars will be busy killing each other over the right to
>>> wear purple, and for the innocent bystanders caught in the crossfire it will
>>> be fully unclear were to complain. Stepping in Morgaines shoes, i think i
>>> would argue that what Carlo asks for can be realised by applying the policy
>>> of a *particular* AD to RD1. The rules to deal with color of clothes, could
>>> be formulated in AD1 associated with RD1. In principle Carlo could run this
>>> domain himself, even without a single avatar in it, and in this way get his
>>> "government" and set any policy he wants. If two avatars from AD2 and AD3
>>> visit RD1, The policy in RD1 would be governed by what is specified by AD1.
>>>
>>> While this fully fits Morgaines view of "AD rules all", and also fits
>>> Carlo call for autonomy of RD1, it feels decidedly like a kludge, and in
>>> this particular case it seems much more straightforward to make RD1 more
>>> autonomous. Yet, to keep everything within one framework, this kludge seems
>>> to be the logical solution... I would like to hear what others think about
>>> this.
>>>
>>> One other remark: the minimal example for  a "world"  -one AD and one RD-
>>> would be more useful when extended with one asset service AS. Explicit
>>> mentioning of the AS will make it much easier to discuss IP issues.
>>>
>>> Vaughn
>>>
>>>
>>>
>>> On Mon, Sep 14, 2009 at 10:44 AM, Carlo Wood <carlo@alinoe.com> wrote:
>>>
>>>> On Mon, Sep 14, 2009 at 06:43:06AM +0100, Morgaine wrote:
>>>> > 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.
>>>>
>>>> I totally disagree that the AD is the representative...and why do you
>>>> say
>>>> that below a sentence of me where I say "A Region Domain (RD) and an
>>>> Agent Domain (AD)"?
>>>>
>>>> This is like I say "VW = AD + RD", and you go: "yes, VW = AD". We can't
>>>> have a discussion like that Morgaine.
>>>>
>>>> >     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
>>>>
>>>> I even *stressed* the '*and*' here, and you do it again.
>>>>
>>>> > 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
>>>>
>>>> I might not understand what the real Cable Beach is or wants to be, I
>>>> was just
>>>> trying to give an example to work with. So, again:
>>>>
>>>> LL runs one RD and AD, called RD1 and AD1.
>>>> OG 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.
>>>>
>>>> > 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.
>>>>
>>>> Ok
>>>>
>>>> >     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.
>>>>
>>>> As I stated in one of my first posts, it will (hopefully!!!) be mainly
>>>> the
>>>> the *RD* and NOT the AD that all of those things are a function of!
>>>>
>>>> You keep saying that it's mainly the AD that determines these things,
>>>> but
>>>> that would be confusing and very annoying. If two people meet in a
>>>> virtual
>>>> world, that is - if they are standing next to eachother in one region
>>>> and
>>>> using local chat - then they should fall under the same legal
>>>> jurisdiction
>>>> and the same ToS: it is the region that determines the rules, not the AD
>>>> that they used to login with.
>>>>
>>>> As example, ToS1 says: it's ok to be naked; and ToS2 says: it's a
>>>> bannable
>>>> offence to be naked. Do you really think that it's even workable if the
>>>> ToS to be applied is a function of the AD? Say you login using AD2, so
>>>> ToS2 applies to you. You meet someone else that is naked. You know that
>>>> you are not allowed to and you are offended. You create an abuse report;
>>>> where does that report go to? To your AD administration? That makes no
>>>> sense: that naked person is using a different AD. To his/her AD
>>>> administration
>>>> then? That makes also no sense since they allow it.
>>>>
>>>> Seriously, there is only one reasonable thing to do: the ToS that
>>>> applies
>>>> is a function of the Region Domain *only*, and if you write an abuse
>>>> report,
>>>> it should go to the administration of the region that you are in and not
>>>> to your or the others AD administration. Same holds for the things
>>>> related
>>>> to legal jurisdiction and any other 'rules' that applies at any given
>>>> moment (to users). The only thing that might be a function of the AD are
>>>> technical policies that are automatically enforced by VWRAP.
>>>>
>>>> >     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).
>>>>
>>>> Sorry, but I think you should try harder to understand my point of view
>>>> first.
>>>> I didn't give the examples so you can ignore them.
>>>>
>>>> > 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.
>>>>
>>>> I was trying to make you understand WHY Infinitely tells you they don't
>>>> "exist",
>>>> if you understand her (and you don't, imho) then it will be easier to
>>>> solve this
>>>> miscommunication.
>>>>
>>>> > The contention that we don't know what "virtual world" means is just
>>>> plain
>>>> > bizarre.
>>>>
>>>> Only if you already have a definition of "virtual world" they way you
>>>> do.
>>>>
>>>> > I don't know of any VW operator who doesn't know what their world is.
>>>>
>>>> That is the *current* situation... which is 100% simpler than what we'll
>>>> have in the future.
>>>>
>>>> Compare with math... currently we only have Integers (Z). We're about
>>>> to introduce division and by that we need to extend the definition of
>>>> 'number' from Z to Q. Q aren't integers, even though currently every
>>>> number is an integer doesn't mean you have to hold on tight the
>>>> "definition"
>>>> of "number" == integer. That definition will be broken and you will
>>>> have to redefine "number".
>>>>
>>>> >   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.
>>>>
>>>> You CANNOT define "virtual world" as "AD" (see above) nor as "AD + RD"
>>>> because
>>>> that is too simple and only holds in the current situation. You can
>>>> only, at most,
>>>> if you really want, say - well, lets define it as being some RD.
>>>>
>>>> > 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.
>>>>
>>>> I agree that as long as it isn't normatively defined, the term shouldn't
>>>> be
>>>> used in documents except in places where it can literally mean anything
>>>> without
>>>> that anyone will care (like in the protocol name).
>>>>
>>>> >   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. ;-)
>>>>
>>>> Sorry, but that is like saying that defining the Rational Numbers (Q)
>>>> makes it
>>>> impossible to talk about 'numbers', because 3/7 isn't an integer.
>>>> What you have to do is let go of your current definition.
>>>>
>>>> >     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.
>>>>
>>>> No, if the service prodiver of some AD disagrees with the (say) a ToS
>>>> that applies
>>>> when you go to some RD then they should disallow you go there; they
>>>> should not
>>>> allow you to go there and then demand that you follow their ToS, that
>>>> would not
>>>> be a practical solution that is workable.
>>>>
>>>> To use mathematics again, it's easy to make two ToS that have no
>>>> intersection:
>>>> Say, ToS1 says: you MUST wear purple clothes, and ToS2 says: you MUST
>>>> wear blue
>>>> clothes. Obviously those will apply to regions.
>>>>
>>>> So then we have:
>>>>
>>>> Provider1: RD1 --> TOS1 --> purple clothes
>>>> Provider2: RD2 --> TOS2 --> blue clothes
>>>>
>>>> *if* Provider 2 runs an AD (AD2) and they allow people logged in with it
>>>> to go to region RD1 then the people there should wear purple clothes:
>>>> TOS2 will not apply because of the AD you use.
>>>>
>>>> If it's against providers religious believe to support wearing purple
>>>> clothes than they might disallow people to go to RD1, that is their
>>>> choice (policy).
>>>>
>>>> > 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.
>>>>
>>>> That makes no sense :/
>>>>
>>>> There can be any number of people in a given RD, and each can in
>>>> principle
>>>> be using a different AD! PLEASE let the RD determine the rules they have
>>>> to live by! Anyone else that disagrees with me about that?!
>>>>
>>>> > 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".
>>>>
>>>> Ah! At last..
>>>>
>>>> > But that's not how it is currently structured --- RDs are
>>>>
>>>> If you are refering to OGP, then OGP should be changed.
>>>>
>>>> > 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.
>>>>
>>>> What I seem to keep missing is the fact that VWRAP is already completely
>>>> defined in those previous OGP documents and we're merely here to rewrite
>>>> them in an IETF document of sorts.
>>>>
>>>> Yes we need multiple ADs to interact, and they will.
>>>> But yes, RD's will handle whatever they have to handle with VWRAP.
>>>> I never said that capabilities equal 'rules' (ToS and legal jurisdiction
>>>> isn't something that should be enforced or controlled by the protocol)
>>>> by
>>>> the way.
>>>>
>>>> ... sorry my RSI forces me to stop typing here... shouldn't have
>>>> typed this much alrady anyway :(
>>>>
>>>> >     > 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>
>>>> >
>>>> >
>>>>
>>>> > _______________________________________________
>>>> > ogpx mailing list
>>>> > ogpx@ietf.org
>>>> > https://www.ietf.org/mailman/listinfo/ogpx
>>>>
>>>>
>>>> --
>>>> Carlo Wood <carlo@alinoe.com>
>>>> _______________________________________________
>>>> ogpx mailing list
>>>> ogpx@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ogpx
>>>>
>>>
>>>
>>
>> _______________________________________________
>> ogpx mailing list
>> ogpx@ietf.org
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>