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

Infinity Linden <infinity@lindenlab.com> Thu, 01 October 2009 21:41 UTC

Return-Path: <infinity@lindenlab.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C561728C0F1 for <ogpx@core3.amsl.com>; Thu, 1 Oct 2009 14:41:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.754
X-Spam-Level:
X-Spam-Status: No, score=0.754 tagged_above=-999 required=5 tests=[AWL=-2.549, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, SARE_FWDLOOK=1.666]
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 rtSYm3SHyzx3 for <ogpx@core3.amsl.com>; Thu, 1 Oct 2009 14:41:05 -0700 (PDT)
Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id 8D9313A6886 for <ogpx@ietf.org>; Thu, 1 Oct 2009 14:41:05 -0700 (PDT)
Received: by pzk35 with SMTP id 35so818769pzk.29 for <ogpx@ietf.org>; Thu, 01 Oct 2009 14:42:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.141.4.20 with SMTP id g20mr709901rvi.121.1254433348324; Thu, 01 Oct 2009 14:42:28 -0700 (PDT)
In-Reply-To: <e0b04bba0910011434i13f890bfodd22cd15eef17697@mail.gmail.com>
References: <3a880e2c0909011549n504111ebi2729273631cdee74@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> <e0b04bba0910011434i13f890bfodd22cd15eef17697@mail.gmail.com>
Date: Thu, 01 Oct 2009 14:42:28 -0700
Message-ID: <3a880e2c0910011442q5b35bf8epfad7cea37eb5d5d1@mail.gmail.com>
From: Infinity Linden <infinity@lindenlab.com>
To: Morgaine <morgaine.dinova@googlemail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: ogpx@ietf.org
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:41:10 -0000

did we read the same response? i totally didn't get "destination
determines policy" from josh's response.

and what? a single AD defines the trust policy of the RDs it connects to? huh?

i'm totally reading different documents than you are morgaine.

On Thu, Oct 1, 2009 at 2:34 PM, Morgaine <morgaine.dinova@googlemail.com> wrote:
> 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
>>
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>