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