Re: [ogpx] VWRAP Draft Charter - 2009 09 01
Infinity Linden <infinity@lindenlab.com> Thu, 01 October 2009 22:32 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 AFDA528C0FB for <ogpx@core3.amsl.com>; Thu, 1 Oct 2009 15:32:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.406
X-Spam-Level:
X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[AWL=-1.295, BAYES_00=-2.599, 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 dh-aLjH5DxyC for <ogpx@core3.amsl.com>; Thu, 1 Oct 2009 15:32:36 -0700 (PDT)
Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id 5FB5A3A67EC for <ogpx@ietf.org>; Thu, 1 Oct 2009 15:32:36 -0700 (PDT)
Received: by pxi6 with SMTP id 6so701892pxi.32 for <ogpx@ietf.org>; Thu, 01 Oct 2009 15:33:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.162.7 with SMTP id k7mr718359rve.192.1254436438649; Thu, 01 Oct 2009 15:33:58 -0700 (PDT)
In-Reply-To: <e0b04bba0910011530k3f88ae6y6f7e8ad6f8346c37@mail.gmail.com>
References: <3a880e2c0909011549n504111ebi2729273631cdee74@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> <3a880e2c0910011442q5b35bf8epfad7cea37eb5d5d1@mail.gmail.com> <e0b04bba0910011530k3f88ae6y6f7e8ad6f8346c37@mail.gmail.com>
Date: Thu, 01 Oct 2009 15:33:58 -0700
Message-ID: <3a880e2c0910011533q38cbd3b2wadf1def2e3058be6@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 22:32:41 -0000
"RD also determines policy" means that BOTH the RD and the AD determine policy. this is distinct from "destination RD determines policy." On Thu, Oct 1, 2009 at 3:30 PM, Morgaine <morgaine.dinova@googlemail.com> wrote: > On Thu, Oct 1, 2009 at 10:42 PM, Infinity Linden <infinity@lindenlab.com> > wrote: > did we read the same response? i totally didn't get "destination > determines policy" from josh's response. > > > You need to go further back to find the reference to Destination Determines > Policy, which I wrote in my reply to Vaugh, here: > http://www.ietf.org/mail-archive/web/ogpx/current/msg00417.html . > > Joshua then replied to that, and very clearly stated that the destination RD > will also determine policy. Of course, the destination RD's policy may be > given by its world's AD, so naturally that AD will have to be party to the > protocol. > > SL provides a good example. Would you want an external grid to provide > teleports into one of your regions, consulting only its own AD and not SL's > AD? I think not. > > There's total symmetry between the worlds here. You need to stop thinking > of one world as "special" and trying to grow it with regions, and start > thinking of worlds as peers. > > Destination Determines Policy is the only approach that allows for tourism > to one world simultaneously from multiple other worlds each having different > policies, which is why it's so important. > > Under any other model, you either have no interop at all because the tourism > is disallowed, or else you get the perpetual state of war that Vaughn nicely > mocked as "war over purple". > > This is why I'm so pleased that the profile of the RD is being raised in > respect of determining policy. It's a small step from there to realizing > that Destination Determines Policy is where you're actually heading because > it's needed for interop between worlds. > > > Morgaine. > > > > > > > > ========================================== > > On Thu, Oct 1, 2009 at 10:42 PM, Infinity Linden <infinity@lindenlab.com> > wrote: >> >> 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 >> > >> > > >
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Kari Lippert
- [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Charles Krinke
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- [ogpx] Fwd: VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] Fwd: VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] Fwd: VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] Fwd: VWRAP Draft Charter - 2009 09 01 Meadhbh Siobhan
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Charles Krinke
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Charles Krinke
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 David W Levine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 David W Levine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Charles Krinke
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Dickson, Mike (ISS Software)
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Dickson, Mike (ISS Software)
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 SM
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Dickson, Mike (ISS Software)
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Dickson, Mike (ISS Software)
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- [ogpx] Policy between services David W Levine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 SM
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood