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

[Infinity Linden <[e-mail]>]

"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 <[e-mail]> wrote:
> On Thu, Oct 1, 2009 at 10:42 PM, Infinity Linden <[e-mail]>
> 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 <[e-mail]>
> 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 <[e-mail]>
>> wrote:
>> > On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell <[e-mail]> 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 <[e-mail]> 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
>> >> <[e-mail]>
>> >> 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
>> >>> <[e-mail]>
>> >>> 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 <[e-mail]>
>> >>>> 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 <[e-mail]>
>> >>>>> > 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 <[e-mail]>
>> >>>>> > 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 <[e-mail]>
>> >>>>> >
>> >>>>> >
>> >>>>>
>> >>>>> > _______________________________________________
>> >>>>> > ogpx mailing list
>> >>>>> > [e-mail]
>> >>>>> > https://www.ietf.org/mailman/listinfo/ogpx
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Carlo Wood <[e-mail]>
>> >>>>> _______________________________________________
>> >>>>> ogpx mailing list
>> >>>>> [e-mail]
>> >>>>> https://www.ietf.org/mailman/listinfo/ogpx
>> >>>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> ogpx mailing list
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/ogpx
>> >>>
>> >>
>> >>
>> >> _______________________________________________
>> >> ogpx mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/ogpx
>> >>
>> >
>> >
>> > _______________________________________________
>> > ogpx mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/ogpx
>> >
>> >
>
>