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

From: Carlo Wood <[email-masked]>
Date: Thu, 1 Oct 2009 12:55:27 +0200

On Wed, Sep 30, 2009 at 09:10:13AM -0700, Joshua Bell 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.

I'd formulate this as: It is the destination (the region (domain) that the user
is in) that determines the ToS. This is something else than the RD making
protocol-level policy decisions. The link between RD and ToS is in most cases
not really a technical one (it will only require to use the current region
to get relevant arguments for some messages).

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

Of course (excellent examples).

The AD determines if you are allowed to teleport somewhere or not.
Every example you give is about denying teleport: the user is not allowed to
go the desired destination.

However, if the user *is* allowed to go to the desired destination then
depending on that destination restriction will still apply, and those
restrictions will in most cases be a function of that destination.

For example agentd.A.and.B.allowed.example.com will allow teleports
to region.A.allowed.example.com and region.B.allowed.example.com,
but once there, only A or B is allowed, for everyone in that region,
independent of the agent domain.  An agentd.A.and.B.are.evil.com would
not allow their users to even go to those regions.

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

These are again about access restrictions, which is not my concern.

> 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 <[email-masked]>
> 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 <[email-masked]>
>     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 <[email-masked]> 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 <[email-masked]>
>             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 <[email-masked]>
>             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 <[email-masked]>
>             >
>             >
> 
>             > _______________________________________________
>             > ogpx mailing list
>             > [email-masked]
>             > https://www.ietf.org/mailman/listinfo/ogpx
> 
> 
>             --
>             Carlo Wood <[email-masked]>
>             _______________________________________________
>             ogpx mailing list
>             [email-masked]
>             https://www.ietf.org/mailman/listinfo/ogpx
> 
> 
> 
> 
> 
>     _______________________________________________
>     ogpx mailing list
>     [email-masked]
>     https://www.ietf.org/mailman/listinfo/ogpx
> 
> 
> 

> _______________________________________________
> ogpx mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx

-- 
Carlo Wood <[email-masked]>

---

From: Vaughn Deluca <[email-masked]>
Date: Thu, 1 Oct 2009 14:16:42 +0200

Argg, again forgot the list...

---------- Forwarded message ----------

On Thu, Oct 1, 2009 at 12:55 PM, Carlo Wood <[email-masked]> wrote:

> Its not clear to me what you mean Carlo. How does
"the RD making protocol-level policy decisions" differ from
"It is the destination (the region (domain) that the user is in) that
determines the ToS."

Asume the RD is mature, and therefore states in its terms of service that
any agent present should be above 18.
An agent domain without age verification will be happy to TP its agents to
that RD
The RD will want to inform the AD its not going to happen.  In this example
I fail to see the destinction you mention above.

Vaughn

---

From: Carlo Wood <[email-masked]>
Date: Thu, 1 Oct 2009 18:06:25 +0200

On Thu, Oct 01, 2009 at 02:16:42PM +0200, Vaughn Deluca wrote:
> Asume the RD is mature, and therefore states in its terms of service that any
> agent present should be above 18.
> An agent domain without age verification will be happy to TP its agents to that
> RD
> The RD will want to inform the AD its not going to happen.  In this example I
> fail to see the destinction you mention above.

Access restriction again...

Take for example: some region demands that everyone is an alien of
some sorts. Nobody can be rejected based on the AD they use, and no
AD will refuse to teleport to the region either.

Once there, the users must use an alien avatar. If they do not,
then they break a local (region) rule and the administration of
the region will want to warn/ban them. This is nothing to do
with AD's, nor can VWRAP detect and enforce what avie you use.

---

From: Joshua Bell <[email-masked]>
Date: Thu, 1 Oct 2009 09:44:48 -0700

Ah, I believe your point is clear now - there are policies that can be
enforced at a protocol level, and policies that cannot. Thanks for bringing
that up; it will be important to note so we don't make blanket statements.

I would point out that this occurs on both the agent side and region side,
just like access control; your agent domain may have a policy which states
"no kissing anyone with cooties"; the region domain you visit may allow such
hi-jinks, but the user would be violating the agent domain's policy by doing
so. This is also, presumably, unenforceable by protocol.

(One could imagine an extensible mechanism for machine-readable policy that
could be enforced by the domains, but us creative humans can always think of
examples that can't be encoded.)

---

From: Meadhbh Siobhan <[email-masked]>
Date: Thu, 1 Oct 2009 09:46:44 -0700

hmm.. carlo.. while the alien example you give does describe a
"policy" that can be set by a RD, for the purpose of the protocol
definition, that's drifting a bit far afield. when used in the same
sentence as "protocol", i think it's common to mean only those things
which the participant in the protocol can detect in a reasonably
automated way, and are expressed in the protocol itself.

though i suppose, if we really wanted to, we could create the "alien
garment tag" that allows the producer of an attachment or clothing
texture to declare assets as being suitably alien in appearance, then
the RD could check that all assets and garmets on an incoming avatar
bear this tag.

but i'm not seriously recommending we do this; just trying to give an
example of what i mean when i say "policy" in describing a protocol.
we've already had the debate about the meaning of the term "virtual
world," i would like to get consensus that when we say "policy" in
terms of a protocol, we're using it in terms of what a protocol
endpoint could reasonably be assumed to be able to intuit.

-cheers
-meadhbh / infinity

---

From: Morgaine <[email-masked]>
Date: Thu, 1 Oct 2009 22:34:10 +0100

On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell <[email-masked]> 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 <[email-masked]> wrote:

> 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.
>
> On Tue, Sep 29, 2009 at 5:51 PM, Morgaine <[email-masked]>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
>> 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.  :-)
>>
>> 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. :-)
>>
>> 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
>> 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.
>>
>> 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.
>>
>> 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
>> 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 <[email-masked]>wrote:
>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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 Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood <[email-masked]> 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
>>>> > describes to us.  Nothing very contentious there, everyone likes a
>>>> >     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
>>>> > 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
>>>> >     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.
>>>> >
>>>> >
>>>> > imagine policy-free VWs that temporarily  take on the policy of any
>>>> other world
>>>> >     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
>>>> >     Rather I should say: I ask you to reconsider if that definition is
>>>> very
>>>> >     useful.
>>>> >
>>>> > 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
>>>> 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.
>>>>
>>>> > (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
>>>> > provider similar to LL), and then we can proceed with your example
>>>> case.
>>>>
>>>> Ok
>>>>
>>>> >     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
>>>> > abuse control and conflict resolution, and so on and so forth.  If
>>>> they were
>>>> As I stated in one of my first posts, it will (hopefully!!!) be mainly
>>>> the
>>>> You keep saying that it's mainly the AD that determines these things,
>>>> but
>>>> world, that is - if they are standing next to eachother in one region
>>>> and
>>>> and the same ToS: it is the region that determines the rules, not the AD
>>>> 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
>>>> 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 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
>>>> >     I think this is what Infinity means when she says that "virtual
>>>> world"
>>>> >     cannot
>>>> >     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
>>>> Sorry, but I think you should try harder to understand my point of view
>>>> first.
>>>> > 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
>>>> >   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
>>>> You CANNOT define "virtual world" as "AD" (see above) nor as "AD + RD"
>>>> because
>>>> > 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 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
>>>> >     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:
>>>> >     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
>>>> > 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
>>>> No, if the service prodiver of some AD disagrees with the (say) a ToS
>>>> that applies
>>>> allow you to go there and then demand that you follow their ToS, that
>>>> would not
>>>> Say, ToS1 says: you MUST wear purple clothes, and ToS2 says: you MUST
>>>> wear blue
>>>> *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:
>>>> If it's against providers religious believe to support wearing purple
>>>> > 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
>>>> be using a different AD! PLEASE let the RD determine the rules they have
>>>> > ADs were merely login services then your model would apply, and RD
>>>> could be
>>>> > considered "VW".
>>>>
>>>> Ah! At last..
>>>>
>>>> > 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
>>>> 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.
>>>>
>>>> >     > 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
>>>> >     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
>>>> >     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.
>>>> >
>>>> >
>>>> >
>>>> >     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
>>>> > that VWRAP is extended to allow cross-VW interop).  No world is going
>>>> to give
>>>> > 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
>>>> >     > 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.
>>>> >
>>>> >     virtual world; there are no third parties they can hire from yet,
>>>> so they
>>>> >     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
>>>> > 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
>>>> > 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
>>>> >     > 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
>>>> > 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
>>>> > 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
>>>> >     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
>>>> > single virtual world" is not only fuzzy, it is totally non-existent in
>>>> practice
>>>> > In contrast, the concept of multiple virtual worlds is crystal clear.
>>>>  Several
>>>> > 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.
>>>> >
>>>> >
>>>> > 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
>>>> >     > 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
>>>> > 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
>>>> > Notice however that even if the protocol were modified to be able to
>>>> handle two
>>>> > continue to raise the perennial question of "Which virtual world?".
>>>>  After all,
>>>> > 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,
>>>> > 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
>>>> > 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 <[email-masked]> 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
>>>> >     Rather I should say: I ask you to reconsider if that definition is
>>>> very
>>>> >     useful.
>>>> >
>>>> >     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
>>>> >     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:
>>>> >     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
>>>> >     > 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
>>>> >     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.
>>>> >
>>>> >     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.
>>>> >
>>>> >     virtual world; there are no third parties they can hire from yet,
>>>> so they
>>>> >     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
>>>> >     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
>>>> >     > 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

---

From: Infinity Linden <[email-masked]>
Date: Thu, 1 Oct 2009 14:42:28 -0700

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 <[email-masked]> wrote:
> I think we're finally approaching the road towards Destination Determines
> Policy now, which is a prerequisite for real interop between virtual
> It's a two-part problem.  Naturally your source world can impose
> 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.
>
>> 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.
>>
>> 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
>>> 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
>>> 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
>>>> RD- would be more useful when extended with one asset service AS. Explicit
>>>>> >     > 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... 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
>>>>> >     Rather I should say: I ask you to reconsider if that definition
>>>>> > is very
>>>>> >     useful.
>>>>> >
>>>>> >     A user that authenticates with either AD1 or AD2 can travel to
>>>>> > RD1 AND RD2,
>>>>> > defined but is being used non-normatively, while in practice using
>>>>> > the phrase "
>>>>> >     > In our new protocol, these services may either be implemented
>>>>> > internally
>>>>> >     within
>>>>> >     > 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
>>>>> >     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
>>>>> >     be some that only run a RD and do not care about running their
>>>>> > own AD.
>>>>> >
>>>>> >
>>>>> >     >     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.
>>>>> >
>>>>> >     >     Is OSgrid a virtual world?  Undoubtedly.  Is OSgrid just a
>>>>> > Region
>>>>> >     Domain
>>>>> >     >     (assuming it were implemented using VWRAP)?  No, of course
>>>>> > not, it
>>>>> > clusters of regions (equivalent to RDs) together combine to create
>>>>> > the virtual
>>>>> >     > 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
>>>>> > single virtual world" is not only fuzzy, it is totally non-existent
>>>>> > in practice
>>>>> > they are unclear about what they operate.  We've been sold a bridge
>>>>> > on that
>>>>> > "uncertainty".  Multiple virtual worlds presenting VWRAP endpoints
>>>>> > are the
>>>>> >     > disentangled and clarified and the protocols will be defined
>>>>> > and evolve,
>>>>> >     but
>>>>> >     > between VWs that could be described as "peering".  It is the
>>>>> > asymmetry of
>>>>> >     the
>>>>> >     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
>>>>> >     > 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
>>>>> > think is intended because the intention is not actually spelled out
>>>>> > in the
>>>>> > that is creating such a problem.  That phraseology was appropriate
>>>>> > for that
>>>>> >     > 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... 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
>>>>> >     Rather I should say: I ask you to reconsider if that definition
>>>>> > is very
>>>>> >     useful.
>>>>> >
>>>>> >     A user that authenticates with either AD1 or AD2 can travel to
>>>>> > RD1 AND RD2,
>>>>> >     > In our new protocol, these services may either be implemented
>>>>> > internally
>>>>> >     within
>>>>> >     > 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
>>>>> >     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
>>>>> >     be some that only run a RD and do not care about running their
>>>>> > own AD.
>>>>> >
>>>>> >     >     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.
>>>>> >
>>>>> >     >     Is OSgrid a virtual world?  Undoubtedly.  Is OSgrid just a
>>>>> > Region
>>>>> >     Domain
>>>>> >     >     (assuming it were implemented using VWRAP)?  No, of course
>>>>> > not, it
>>>>> >     > 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
>>>>> >     > disentangled and clarified and the protocols will be defined
>>>>> > and evolve,
>>>>> >     but
>>>>> >     > between VWs that could be described as "peering".  It is the
>>>>> > asymmetry of
>>>>> >     the
>>>>> >     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
>>>>> >     > 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

---

From: Charles Krinke <[email-masked]>
Date: Thu, 1 Oct 2009 14:48:28 -0700 (PDT)

This seems like the right path to me, too.

In thinking about this, lets consider saying that where two policies of two interoperable grids intersect is the interesting case.

To take it back to SecondLife and say, an OpenSim grid, the first few things in an interop teleport are going to be avatarName and avatarAppearance.

In thinking of how this may work, it would seem that we will probably end up with something like "[email-masked]" when teleporting to, say OSGrid from Secondlife to OSGrid and perhaps "[email-masked]" when teleporting from OSGrid to SecondLife. So, ... perhaps the policy may define the format of the name carried across in the teleport as it is reasonable to assume that an avatar in SecondLife does not have an account on OSGrid, and the converse is also true.

Second, I suspect we need to define what happens when an avatar attempts a teleport with attachments (particularly scripted attachments). I rather suspect that neither grid will wish to allow teleporting with scripting attachments without a significant amount of negotiation between the two corporations.

As far as inventory goes, I rather suspect we wish to either avoid moving inventory between grids, or, ... perhaps define a 'vanilla' subset such as those items marked with 'export from grid, full permissions' bits set. I am taking that from memory in thinking about the additional bitfield for object exports discussion on SecondLife a year or so ago.

I am trying to think of the simplest cases that will have the minimum of cussin, discussin and debate to get our minds wrapped around how to move forward a bit. 

Certainly, I have my mind wrapped around Zha's statement a year or so ago that went (if I recall more or less correctly):

"We will have interop when I can slay a monster on WoW, teleport to a club in SecondLife, mount the monsters head on the wall and buy everyone a drink".

Charles

________________________________
From: Morgaine <[email-masked]>
To: [email-masked]
Sent: Thursday, October 1, 2009 2:34:10 PM
Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01

On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell <[email-masked]> 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.

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 <[email-masked]> 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 <[email-masked]> 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
>>>
>>>
>>>
>>>
>>>
>>>>>>>>>     > 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... 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
>>>>>>>>>     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)"?
>>>>
>>>>>>>>>     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
>>>>
>>>>>>>>> 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
>>>>>>>>>     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.
>>>>>>>>>
>>>>>>>>>     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.
>>>>>>>>> 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
>>>>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.
>>>>> 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.
>>>>>>>>> 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
>>>>>>>>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
>>>>>>>>As example, ToS1 says: it's ok to be naked; and ToS2 says: it's a bannable
>>>>>>>>sense: that naked person is using a different AD. To his/her AD administration
>>>>>>>>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,
>>>>>>>>to your or the others AD administration. Same holds for the things related
>>>>>>>>>     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
>>>>Sorry, but I think you should try harder to understand my point of view first.
>>>>>>>>> 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.
>>>>>>>>> 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
>>>>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.
>>>>
>>>>
>>>>>>>>number is an integer doesn't mean you have to hold on tight the "definition"
>>>>>>>>>   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,
>>>>>>>>> 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 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
>>>>>>>>>     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
>>>>>>>>> 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
>>>>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
>>>>>>>>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
>>>>>>>>> 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
>>>>>>>>There can be any number of people in a given RD, and each can in principle
>>>>>>>>> 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..
>>>>
>>>>
>>>>>>>>> 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.
>>>>
>>>>>>>>isn't something that should be enforced or controlled by the protocol) by
>>>>>>>>the way.
>>>>
>>>>>>>>>     > 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
>>>>>>>>> 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
>>>>>>>>>     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
>>>>>>>>> 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
>>>>>>>>> [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
>>>>>>>>> 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
>>>>>>>>>     > 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
>>>>>>>>>     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
>>>>>>>>>     But after SL implemented VWRAP they might decide to do away from one of
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>>     > 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
>>>>>>>>>     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
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>>     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
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> 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,
>>>>>>>>> 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,
>>>>>>>>> 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
>>>>>>>>> PS. If anyone else read this far other than Carlo, you have a lot of stamina
>>>>>>>>> and dedication. ;-)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     > 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... 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.
>>>>>>>>>
>>>>>>>>>     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.
>>>>>>>>>     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
>>>>>>>>>     > 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
>>>>>>>>>     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
>>>>>>>>>     > 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
>>>>>>>>>     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
>>>>>>>>>     But after SL implemented VWRAP they might decide to do away from one of
>>>>>>>>>     >     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
>>>>>>>>>     > 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
>>>>>>>>>     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
>>>>>>>>>     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

---

From: Joshua Bell <[email-masked]>
Date: Thu, 1 Oct 2009 14:57:23 -0700

On Thu, Oct 1, 2009 at 2:34 PM, Morgaine <[email-masked]>wrote:

>
> 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
I don't agree with this at all.

A VW service provider could operate a region domain with no agent domain. I
believe this is VERY LOOSELY equivalent to running an OpenSim instance in
Grid mode today (but I can't state that definitively) the person running the
sim is basically running just the region, and relying on someone else's
agent domain (agent-centric services).

Similarly, BigGiantCo could operate an agent domain for their employs (as a
bolt-on to their enterprise LDAP server, say) with no region domain.

A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to
place the agent in a region. There aren't necessarily any other RDs or ADs
involved at all. This is where protocol and policy come into play - the AD
needs to communicate with and trust the RD and vice versa (even if that's
nil-trust).

---

From: Charles Krinke <[email-masked]>
Date: Thu, 1 Oct 2009 15:13:05 -0700 (PDT)

Well, no, thats not quite how OpenSim works.

A standalone OpenSim region with no grid services is probably loosely equivalent to no AD and I think that was the mode in which the tests were performed with the IBM OpenSim region and OGP a year or so ago.

An OpenSim region running in grid mode is connected to a number of servers that connect the grid together. These are a UserServer, GridServer, Asset/InventoryServer and MessagingServer. So these are *more or less* equivalent to AD notions.

Charles

________________________________
From: Joshua Bell <[email-masked]>
To: [email-masked]
Sent: Thursday, October 1, 2009 2:57:23 PM
Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01

A VW service provider could operate a region domain with no agent domain. I believe this is VERY LOOSELY equivalent to running an OpenSim instance in Grid mode today (but I can't state that definitively) the person running the sim is basically running just the region, and relying on someone else's agent domain (agent-centric services).

Similarly, BigGiantCo could operate an agent domain for their employs (as a bolt-on to their enterprise LDAP server, say) with no region domain. 

A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to place the agent in a region. There aren't necessarily any other RDs or ADs involved at all. This is where protocol and policy come into play - the AD needs to communicate with and trust the RD and vice versa (even if that's nil-trust).

---

From: Infinity Linden <[email-masked]>
Date: Thu, 1 Oct 2009 15:18:02 -0700

isn't an OpenSim region running in standalone mode like having all the
services locally. i mean... it's beginning to sound like a petty
distinction, but in order to serve up information about the user or
the region or assets in the region, you have to have SOMETHING that
behaves like a user server or asset server. i always looked at it as
being that all these "services" were local to the machine, not that
they didn't really exist.

On Thu, Oct 1, 2009 at 3:13 PM, Charles Krinke <[email-masked]> wrote:
> A standalone OpenSim region with no grid services is probably loosely
> equivalent to no AD and I think that was the mode in which the tests were
> performed with the IBM OpenSim region and OGP a year or so ago.
>
> An OpenSim region running in grid mode is connected to a number of servers
> that connect the grid together. These are a UserServer, GridServer,
> Asset/InventoryServer and MessagingServer. So these are *more or less*
> equivalent to AD notions.
>
> Charles
>
>> 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.
>>
>

---

From: David W Levine <[email-masked]>
Date: Thu, 1 Oct 2009 18:25:22 -0400

One.. I think its very important to keep in mind that services are going 
to manage policy, not the domains they reside in. This is important, 
because it highlights the fact that what's going to happen when different 
people deploy this stuff in different deployments is going to vary.  I 
think we need to be very careful to focus not on any one deployment 
pattern, but the broader set of possible deployment patterns we are 
attempting to enable. This goes hand in glove with Joshua's comments 
below. 

This leads to 

Two.. I *think* the correct model is "All the services involved may have 
policies they bring to the table."  The set of actions which are possible 
between an arbitrary service inside of one deployment and an arbitrary 
service inside another is going to be
dictated by the policies those two services follow.  This is especially 
likely when looking at things like asset permissions.  Consider the case 
of a region attempting to pass a prim to an asset store for storage. The 
Region may have policies about which
asset stores it is willing to deliver assets to. The Asset store may have 
policies about which regions it is willing to accept assets from. If the 
user's agent domain holds his inventory (One, but not the only possible 
deployment pattern) it may have policies about
the asset servers it interacts with. Its possible to imagine cases where 
the only role the ADs play in this policy decision is that they have 
authenticated the user, 

We need to be careful, when looking at this stuff to strike a balance 
between focusing on the current deployed clusterings, and turning 
everything into soup. That said, the actual deployed systems which 
implement these specifications are only going to be able
to enforce policy at the interfaces we define, and these interfaces are on 
services, not domains.  In fact, as I've argued several times, I think, in 
general, the notion of a domain emerges from the policies of the deployed 
services, not the other way around. Infinity's made a very nice case for 
describing the key distinctions as being "Agent domains include the auth 
service" and "Region Domains include the presence service"  If we keep 
this in mind, I think it helps us move away from thinking purely in terms 
of the split that Linden Labs has focused on. To circle back to the 
question of soup, simply focusing on the services risks describing stuff 
that's falls into the HLA/DIS trap of having deployments which are each 
"conforming" but vary so much in assumption as to not actually 
interoperate. 

- David
~Zha

Joshua Bell <[email-masked]> 
Sent by: [email-masked]
10/01/2009 05:57 PM

To
[email-masked]
cc

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

On Thu, Oct 1, 2009 at 2:34 PM, Morgaine <[email-masked]> 
wrote:

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:

A VW service provider could operate a region domain with no agent domain. 
I believe this is VERY LOOSELY equivalent to running an OpenSim instance 
in Grid mode today (but I can't state that definitively) the person 
running the sim is basically running just the region, and relying on 
someone else's agent domain (agent-centric services).

Similarly, BigGiantCo could operate an agent domain for their employs (as 
a bolt-on to their enterprise LDAP server, say) with no region domain.

---

From: Joshua Bell <[email-masked]>
Date: Thu, 1 Oct 2009 15:27:59 -0700

Cool, thanks for the clarification. Yeah... I think if you take GridServer
out of that mix you'd get something conceptually equivalent to the AD.

On Thu, Oct 1, 2009 at 3:13 PM, Charles Krinke <[email-masked]> wrote:

> ------------------------------
> *From:* Joshua Bell <[email-masked]>
> *To:* [email-masked]
> *Sent:* Thursday, October 1, 2009 2:57:23 PM
> *Subject:* Re: [ogpx] VWRAP Draft Charter - 2009 09 01
>
>

---

From: Morgaine <[email-masked]>
Date: Thu, 1 Oct 2009 23:30:30 +0100

On Thu, Oct 1, 2009 at 10:42 PM, Infinity Linden <[email-masked]>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 <[email-masked]>wrote:

> if
> work!")
> ADs
> in
> Explicit
> create
> almost
> architecture
> service.
> on
> AND
> its
> mainly
> can
> view
> any
> don't
> just
> RD"
> anything
> total
> based
> always
> Domain,
> focus
> focus
> accepting
> interop.
> protocol)
> AD
> there
> world,
> instead
> going
>  You
> OSgrid
> yet,
> from
> there.
> just
> adds
> in
> meaning
> not
> conjure
> AD's
> clear.
> saying
> avoided
> to
> interoperating
> goal
> legacy
> where
> create
> on
> based
> always
> Domain,
> there
> yet,
> from
> AD's

---

From: David W Levine <[email-masked]>
Date: Thu, 1 Oct 2009 18:30:55 -0400

A stand alone region in OpenSim effectively has all the services hosted 
locally. The services may have not external exposure (Tho, if you run a 
multi-region, standalone deployment that's a fuzzy statement)  The Client 
does auth, fetches inventory and assets and gets region services from the 
single executable. The regions simply talk to all those services locally. 
As the ROBUST stuff rolls through OpenSim, I think the distinction is 
likely to become even muddier. 

- David
~ Zha

Infinity Linden <[email-masked]> 
Sent by: [email-masked]
10/01/2009 06:18 PM

To
Charles Krinke <[email-masked]>
cc
[email-masked]
Subject
Re: [ogpx] VWRAP Draft Charter - 2009 09 01

the

---

From: Charles Krinke <[email-masked]>
Date: Thu, 1 Oct 2009 15:32:50 -0700 (PDT)

Yes, certainly, Infinity.

In standalone mode, those services to exist and are somewhat simplified, but indeed you are correct.

And perhaps this discussion might be a bit premature in that OpenSim doesnt have anything named RD or AD, but we do have something *more or less* functionally equivalent.

I think it is fair to say that as this group works through the details that there are those that will wish to 'harmonize' as much as practical modules in OpenSim to provide the services this group is working on.

Or at the very least, to provide additional modules consistent with this group as the UGRM, Robust and other gridServer notions continue to evolve in their own directions.

Charles

________________________________
From: Infinity Linden <[email-masked]>
To: Charles Krinke <[email-masked]>
Cc: Joshua Bell <[email-masked]>; [email-masked]
Sent: Thursday, October 1, 2009 3:18:02 PM
Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01

---

From: Infinity Linden <[email-masked]>
Date: Thu, 1 Oct 2009 15:33:58 -0700

"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 <[email-masked]> wrote:
> You need to go further back to find the reference to Destination Determines
> Policy, which I wrote in my reply to Vaugh, here:
>> >>>>> > than
>> >>>>> > Agent
>> >>>>> > possibly
>> >>>>> > Agent
>> >>>>> you
>> >>>>> > I
>> >>>>> > definition
>> >>>>> I
>> >>>>> assets
>> >>>>> things,
>> >>>>> > above
>> >>>>> you
>> >>>>> > actual
>> >>>>> (Q)
>> >>>>> ToS
>> >>>>> MUST
>> >>>>> with
>> >>>>> it
>> >>>>> > implemented
>> >>>>> > defined
>> >>>>> > they
>> >>>>> > (that's
>> >>>>> > non-existent
>> >>>>> > bridge
>> >>>>> > evolves.
>> >>>>> > take
>> >>>>> > out
>> >>>>> > adding
>> >>>>> > than
>> >>>>> > Agent
>> >>>>> > possibly
>> >>>>> > Agent
>> >>>>> > I
>> >>>>> > definition
>> >>>>> > above
>> >>>>> > implemented
>> >>>>> > defined
>> >>>>> > evolves.
>> >>>>> > take

---

From: Infinity Linden <[email-masked]>
Date: Thu, 1 Oct 2009 15:34:13 -0700

right. VWRAP should be at least as functional as the old OGP stuff
from summer 2008 (guess that's kind of a given.)

i believe the decision process for what to work on back then was something like:

   * you have to do auth before you can do anything else, so let's do auth
   * you have to do initial rez before you can do anything else in-world
      * and the way we've done initial rez in the past is as half of
teleport, and that seemed to work, so let's to teleport

sounds like you're adding:

   * it's nice to not look like ruth when you rez, so lets do appearance, and
   * we really should know what name to put above your head, so let's
discuss names.

which are things i can get behind.

i would add:

    * it's good to define trust so you know who you can give your assets out to

which will be necessary for the discussion on attachments. (frankly,
i'm tired of showing up in vaak without my prim hair.) a proper
discussion of trust will probably also include a discussion on
deployment patterns, which zha has discussed many times in the past.

i think the FirstLast@agent domain is a good hack for right now, and
i'm thinking it _should_ be relatively easy to code. long term we may
want to consider something more flexible, but right now, at this
point, i'm happy to just move forward with Charles' name display
proposal. what gets displayed above your avatar's head is really a
matter for people writing clients, and i think they may want to have a
"richer" experience in the future, but for the work at hand, of
getting interop rolling again, it sounds like a good solution 'til we
know that people want something different.

-cheers
-meadhbh

On Thu, Oct 1, 2009 at 2:48 PM, Charles Krinke <[email-masked]> wrote:
> In thinking about this, lets consider saying that where two policies of two
> interoperable grids intersect is the interesting case.
>
> To take it back to SecondLife and say, an OpenSim grid, the first few things
> in an interop teleport are going to be avatarName and avatarAppearance.
>
> In thinking of how this may work, it would seem that we will probably end up
> with something like "[email-masked]" when teleporting to, say
> OSGrid from Secondlife to OSGrid and perhaps "[email-masked]" when
> teleporting from OSGrid to SecondLife. So, ... perhaps the policy may define
> the format of the name carried across in the teleport as it is reasonable to
> assume that an avatar in SecondLife does not have an account on OSGrid, and
> the converse is also true.
>
> Second, I suspect we need to define what happens when an avatar attempts a
> teleport with attachments (particularly scripted attachments). I rather
> suspect that neither grid will wish to allow teleporting with scripting
> attachments without a significant amount of negotiation between the two
> corporations.
>
> As far as inventory goes, I rather suspect we wish to either avoid moving
> inventory between grids, or, ... perhaps define a 'vanilla' subset such as
> those items marked with 'export from grid, full permissions' bits set. I am
> taking that from memory in thinking about the additional bitfield for object
> exports discussion on SecondLife a year or so ago.
>
> I am trying to think of the simplest cases that will have the minimum of
> cussin, discussin and debate to get our minds wrapped around how to move
> forward a bit.
>
> Certainly, I have my mind wrapped around Zha's statement a year or so ago
> that went (if I recall more or less correctly):
>
> "We will have interop when I can slay a monster on WoW, teleport to a club
> in SecondLife, mount the monsters head on the wall and buy everyone a
> drink".
>
> Charles

---

From: Morgaine <[email-masked]>
Date: Fri, 2 Oct 2009 00:13:42 +0100

> needs to communicate with and trust the RD and vice versa (even if that's

Those are valid examples, but they're cherry picked to support your specific
use case.

Please examine the more general use case of two complete SL-like worlds
using VWRAP, W1 and W2.  They both have ADs and RDs, so let's label those
with 1's and 2's accordingly.

If both ADs and RDs determine policy together (as you stated), then you
can't expect a resident of W1 to TP from RD1 to RD2 without AD2's policy
coming into play, otherwise you would be subverting AD2's policy.

There *IS* one way of allowing the above, and that is to require that ADs
carry no region-related policies at all, so that consulting only the
destination RD is sufficient.  This would give us a perfect *Destination
Determines Policy* (DDP) system.  The W1 resident could then TP from RD1 to
RD2 without consulting AD2 at all.

If you wish to define ADs in this way then we are in perfect agreement,
since DDP is essential for interop between worlds.  I am hoping that this is
what you had in mind for when we start discussing specific AD and RD
policies. :-)

Morgaine.

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

---

From: Joshua Bell <[email-masked]>
Date: Thu, 1 Oct 2009 16:32:11 -0700

I think we're converging...

On Thu, Oct 1, 2009 at 4:13 PM, Morgaine <[email-masked]>wrote:

>
> Those are valid examples, but they're cherry picked to support your
> specific use case.
>
>
Well, simplified examples. I don't believe more complicated examples
actually add meaningfully at a protocol level, as will become clear...

> with 1's and 2's accordingly.

At a protocol level, I don't think VWs exist. There are services, which
we're clustering into AD and RD. Although we may later determine there are
further subdivisions, that's our working model in the drafts. Further drafts
are strongly encouraged!

> coming into play, otherwise you would be subverting AD2's policy.

Here's the crux of the issue: in our model, the provider of W2 is offering
two sets of services, AD2 and RD2. There may be a policy covering W2 in
general, which would affect the AD2 and RD2 services. However, if an agent
"from" W1, meaning the agent services are provided by AD1, attempts to visit
RD2, then AD2 does *not* come into play. The protocol describes the
negotiation between the client, AD1 and RD2 *only*.

(Again, this is insofar as the model in the current drafts are concerned. If
we're missing something, please bring the conversation back to the drafts
and point out issues and/or submit new work for discussion!)

Let me restate: even if AD2 and RD2 are governed by the same policy -
potentially even to the point of being implemented by the same monolithic
piece of code! - AD2 is irrelevant *from a protocol perspective* in the
attempt to place an agent from AD1 into AD2, since by definition the AD2 and
RD2 services are disjoint.

> Determines Policy* (DDP) system.  The W1 resident could then TP from RD1
> to RD2 without consulting AD2 at all.
>

.... and so it looks like we're in agreement - if this wasn't clear, then we
need to review the drafts (please, go for it!); it should be the case that
ADs carry policies about region services... except, of course, that the AD
may say "hey, you can't go to *that* RD...".

I believe I may have misread some of your earlier posts as implying that the
agent's AD was not allowed to have a say in policy decisions, only the
destination RD. I have a clearer reading of your DDP statement, though, that
of course it's the AD reasoning about the RD, and contrariwise the RD
reasoning about the AD. If we call that "DDP" then we're copacetic.

---

From: Carlo Wood <[email-masked]>
Date: Fri, 2 Oct 2009 02:51:23 +0200

On Thu, Oct 01, 2009 at 04:32:11PM -0700, Joshua Bell wrote:
> Here's the crux of the issue: in our model, the provider of W2 is offering two
> sets of services, AD2 and RD2. There may be a policy covering W2 in general,
> which would affect the AD2 and RD2 services. However, if an agent "from" W1,
> meaning the agent services are provided by AD1, attempts to visit RD2, then AD2
> does *not* come into play. The protocol describes the negotiation between the
> client, AD1 and RD2 *only*.

Good :). Actually, I considered this to be trivial.

---

From: Carlo Wood <[email-masked]>
Date: Fri, 2 Oct 2009 03:23:35 +0200

On Thu, Oct 01, 2009 at 06:25:22PM -0400, David W Levine wrote:
> We need to be careful, when looking at this stuff to strike a balance between
> focusing on the current deployed clusterings, and turning everything into soup.
> That said, the actual deployed systems which implement these specifications are
> only going to be able
> services, not domains.

It is because we can't allow *every* possible deployment to be supported (soup)
that I brought up my worries about which service should determine policy (ToS).

It would be easy to choose a simplification (== not allow every possibility)
that leaves out a deployment that is essential, imho.

My proposal was this:

The AD can only allow a user to connect to (teleport to) a region (domain)
or not. If it allows a user to teleport there, then everything that that
domain allows is allowed.

I probably should have been more clear about this from the beginning:
this (my concern) has everything to do with where Abuse Reports go to:
Once a user is in a given region and breaks a policy (or not) and someone
else wants to report this user, then the only authority that this report
should go to is the administration of the region (personally, I even
advocate the sim, but alas).

If to whomever an 'abuse report' goes has nothing to do with VWRAP
than we can skip this topic; but I think it might be relevant and it
is certainly something we need to keep in mind while designing the
protocol (to make sure that won't go wrong).

Example:

Region RD1 runs on servers in country X whose laws state that adult
content may be accessed at the age of 16 or older. However, the
administration of RD1 has it in their ToS that one has to be 18.
They do not see a reason to ban people of age 16 or 17 however.

Agentd AD2 is seated in another country where one has to be 21 before
one is allowed to access adult content.  AD2 does age verification.

If a person of age 18 logs in with AD2 and tries to TP to RD1 then
* AD2 may disallow that if they so choose.
* If AD2 allows the TP, than the user is allowed to access adult
  content by the ToS of RD1 if their age is 18 or older.

If the user lives in a country where 18 is old enough as well,
than I don't think that it matters (legally) where the AD2 is
seated: the administration of AD2 cannot be sued for allowing
a person to teleport to RD1 (I hope :p).

***************************************************************
* Hence, it is possible to apply the simplication:            *
*- AD policies ONLY come into play at the moment of teleport  *
*  (allow or not).                                            *
*- Once arrived in a new region, the policies of the AD can   *
*  be 'forgotten' and only the policies of the RD apply.      *
*  If the AD doesn't want that, they shouldn't allow the TP.  *
***************************************************************

We shouldn't take this simplification (or deployment limitation) too
lightly, but I think it is one that will work VERY well in practice
and well worth it, as it's benefits will far outweight the disadvantages,
imho.

If anyone can think of a clear counter example where a TP should
be allowed but still the AD ToS should determine what is allowed
and what not, please let us know.

A clear advantage of this simplification is that it makes
it trivial where an Abuse Report would go to: namely the to the
administration of the Region (domain).

A clear disadvantage of NOT making this simplification is that
it would be totally unclear where Abuse Reports have to go, and
that lots of confusion will arise about who can do what and why
they can and you not.

---

From: Vaughn Deluca <[email-masked]>
Date: Fri, 2 Oct 2009 03:47:14 +0200

@ Joshua & Carlo, You have beaten me to the punch, i write to slow...
@ Morgaine, since its written  i might as well post my response, it broadly
agree's with what has been said already :) convergence indeed!

[...]
>If both ADs and RDs determine policy together (as you stated), then you
can't expect a resident of W1 to TP from RD1 to RD2 without >AD2's policy
coming into play, otherwise you would be subverting AD2's policy.

No, it does not have to be that complicated, for the *teleport* (and
ignoring assets for now) of an agent from AD1 (present in RD1) to RD2 the
only interaction needed is between AD1 and RD2.
So for sure AD1 caries RD related policy, but *only* in respect to allowing
the TP  to RD2.  On the destinations world's end, AD2 has for this TP no
role at all,  AD1 does not need to talk to AD2, all policy can be in RD2.

However, maybe its *technically*  more convenient to derive all policy for
RD2 from AD2, and make RD2 a straw man for AD2 as far as policy is
concerned. As long as AD2 and RD2 fully trust each other it makes no
difference, it would under full trust even be possible to cut RD2 completely
out of the loop regarding policy aspects, and have AD1 and AD2 work out the
intended TP to RD2.  Its up to the owner of RD2 to decide if she wants to do
it that way, and simply trust an external AD2, or be more careful and run
her own AD2 allowing her to keep full control over who is going to be
allowed into RD2.

So yes, in this case destination largely determines policy, but not
exclusively, AD1 has to agree to let the agent go. If destination policy  is
defined by RD2 alone, or by a combination AD2/RD2 or even by AD2 alone is
not really important.
I think that *protocol efficiency* should be used as  guideline to determine
that. In terms of freedom it does not matter, since its always possible to
run your own AD services if you feel you can't trust somebody else his
service.

>destination RD is sufficient.  This would give us a perfect Destination
Determines Policy (DDP) system.  The W1 resident could then TP >from RD1 to
RD2 without consulting AD2 at all.

I would view that example as a special case were AD1 has a full trust policy
regarding were it allows its residents to travel to, in combination with a
version of VWRAP were the trust issues for a RD are all handled by the RD
itself, rather than delegating the trust issues to a trusted AD.

>If you wish to define ADs in this way then we are in perfect agreement,
since DDP is essential for interop between worlds.  I am hoping that >this
is what you had in mind for when we start discussing specific AD and RD
policies. :-)

I *think* Infinity had something like what i described above in mind, but
she can speak for herself.

Anyhow I have the feeling that there is a very high level of basic agreement
in this group. But Zha's remark about the danger of creating a system were
everybody complies, yet hardly any interop is possible is highly relevant.
This "Balkanisation" has been mentioned before, but i do not see a principle
way to prevent it. In the end it will be the trust networks that determine
what happens in terms of interop, and users will probably vote with their
feet.

The next step are the assets services. That is slightly more tricky, but in
principle not different from the TP case. Here AS1 has policies about
letting stuff go, so clearly its *not* only "DDP" in this phase. Yet, RD2
(or its ruling AD2 if we prefer that format) does have a voice, and might
not want to accept objects from an AS (or optionally its ruling AD/RD) if
that service has griefer associations.

-Vaughn

On Fri, Oct 2, 2009 at 1:13 AM, Morgaine <[email-masked]>wrote:

>> I believe this is VERY LOOSELY equivalent to running an OpenSim instance in
>> I believe this is VERY LOOSELY equivalent to running an OpenSim instance in

---

From: Morgaine <[email-masked]>
Date: Fri, 2 Oct 2009 06:52:42 +0100

I agree Joshua, I think we are converging. :-)

>> to RD2 without consulting AD2 at all.
.... and so it looks like we're in agreement ...

That's a very good start then.  If ADs have no region-related policies, then
AD2 clearly doesn't need to be consulted when RD2 is entered from RD1.

Unfortunately, you then wrote:

it should be the case that ADs carry policies about region services...

Is there a typo in that?  If it's free of typos and hence ADs carry policies
about region services, then clearly AD2 *does* have to be consulted before
you can TP from RD1 to RD2.  (I assume it has a typo, and you actually meant
to write "do *not* carry policies about region services", to make this line
consistent with what you said above.)

Leaving the above to be clarified, we seem to be arriving at a *Destination
Determines Policy* (DDP) model which makes tourism possible, by giving RDs
control over their region-related policies so that AD2 doesn't need to be
consulted on entry to RD2.  That's fine, but it's not yet clear how you're
going to achieve this since you haven't narrowed the scope of the AD to
exclude region services.

One promising angle stems from this very interesting phrase of yours:

... by definition the AD2 and RD2 services are disjoint.

It's a bit ambiguous though:

   - If by this you mean that AD1 has no say over region services in RD2,
   then that's very cool! :-)  (It's cool because it provides DDP and hence
   allows tourism.)
   - But instead you might mean the following:  "*if RD2 uses some service
   of type X, say X2, then AD1 cannot provide an X service when in RD2"*.
   That would be extremely not cool, since this would totally block meaningful
   tourism.  For example, RD2 could be using Asset Service AS2, as a result of
   which AD1 would not supply an asset service to its travelling agent A1, and
   hence A1 would never be able to appear in RD2 wearing any asset available in
   W1.  Clearly this interpretation would mean no useful interop between W1 and
   W2 at all.  I'm hoping this interpretation is wrong.

I'd appreciate more info about the disjointness please, to clear up this
ambiguity.

>
>
> I believe I may have misread some of your earlier posts as implying that
> the agent's AD was not allowed to have a say in policy decisions, only the
> Ah good, I think we're starting to talk the same language now. :-)  AD1 has
plenty to say in regards to a TP from RD1 to RD2, as long as it sticks to
the affairs of its own world W1 and its own agent A1.  What it cannot do is
impose W1's region-related policies on W2's regions, otherwise we end up
with Vaughn's "war on purple". ;-)   In other words, once in RD2, DDP
applies and AD1 has no say.

The DDP principle is so obvious from our experience in RL that I didn't
bother explaining its scope, but perhaps some basic scoping is needed to
alleviate fears that the source AD has no say at all.  The only thing that
DDP requires is that the travelling agent *obey the law of the land* on
arrival in W2, namely the region-related policies that hold in RD2, and not
those that would hold in a W1 homeworld region like RD1.  It's pretty
simple, and non-optional if tourism between worlds is desired.  "When in
Rome, do as the Romans do" says it all.

As you say, I believe we're converging. :-)

Morgaine.

On Fri, Oct 2, 2009 at 12:32 AM, Joshua Bell <[email-masked]> wrote:

> (Again, this is insofar as the model in the current drafts are concerned.
> If we're missing something, please bring the conversation back to the drafts
> .... and so it looks like we're in agreement - if this wasn't clear, then
> we need to review the drafts (please, go for it!); it should be the case
> that ADs carry policies about region services... except, of course, that the
> AD may say "hey, you can't go to *that* RD...".
>
> I believe I may have misread some of your earlier posts as implying that
> the agent's AD was not allowed to have a say in policy decisions, only the

---

From: Vaughn Deluca <[email-masked]>
Date: Fri, 2 Oct 2009 10:44:17 +0200

Morgaine,

I am equally worried about the problem you sketch in the paragraph below,
however, i think you put the source of that problem in the wrong place. You
argue that if only AD2 is cut out of the equation, all will be fine, and
tourism will be possible. I wish it was true, but even when things are fully
organised as you suggested its the *trust* relations that determine what
will happen, let me explain:

>[...] But instead you might mean the following:  "if RD2 uses some service
of type X, say X2,
>then AD1 cannot provide an X service when in RD2".  That would be extremely
not cool, since
>this would totally block meaningful tourism.

I agree with this sad conclusion, i think the wording could be a lot
sharper, i will come to that below, but loosely speaking you are right. Now
you make the example more explicit:

> For example, RD2 could be using Asset Service AS2, as a result
> of which AD1 would not supply an asset service to its traveling
> agent A1, and hence A1 would never be able to appear in RD2 wearing
> any asset available in W1.

Note that you now say "would not supply" not "cant not provide" as you did
above. This distinction is important. I will follow the more explicit
example, since that is how things are intended IMHO. Also you seem to
suggest an all or nothing behaviour of the asset server that i feel is not
needed, and probably not desirable.

>Clearly this interpretation would mean no useful interop between
>W1 and W2 at all.  I'm hoping this interpretation is wrong.

It would mean no meaningful interop between some of the involved services,
and that as a result of *policy* decisions that can be in *each and every
case* right there where they belong. As i will show below, you can not
escape this situation by trying to deny AD2 any role in the process. The
pain is elsewhere.  Lets do this example a bit more careful:

Our tourist is at home in W1. W1 is a container concept for a collection of
services. The agent is in fact registered in AD1, it uses a big collection
of (purple) clothes from AS1, and is presently located in RD1, trying to
become a tourist and travel for the first time to RD2 (to show off its
purple clothes).

AD1 talks to RD2, trying to gain access rights. RD2 has some age
restrictions, but AD1 manages to convince RD2 its agent is worthy of entry
based on some shared trust of a third party identity provider. No role for
AD2  as you stipulated (although RD2 might have passed responsibility for
this part of the process to AD2, but for clarity lets assume that is not the
case).

Our tourist could now enter RD2 as Ruth. Next AD1 tries to organise the
passage of the purple cloths. That transfer has two endpoints, the asset
service AS1, and RD2. Again RD2 might have some policy what to allow in, and
lets assume its cool with anything, purple or not. Infinity and Carlo looked
at some alien boundary cases, but here we  assume RD2 is happy with any
tourism it can get, including all assets. AS1 on the other hand has
obligations to a large group of purple cloths makers, and will only give out
purple stuff to RD2 if RD2  satisfies some strong conditions.  It has the
protocol means to test those conditions, it *could*  send the purple object,
but does not *want to* based on policy, in particular obligations towards
purple clothes makers  and the lack of trust in the behaviour of RD2. AS1
will however probably send any non-purple clothes to RD2. Cursing under its
breath our tourist might go there in blue, mentally making a note to find a
different clothes shop next time its shopping time.

I completely fail to see what you would like to put in the protocol, or
leave out of it, to remedy this situation.  The would-be tourist has only
one option, and that is to find an asset server that is willing to give out
at least the blue  clothes to RD2.  The restriction in this example is in
AS1 not willing to serve the purple clothes, and AS1 is a service that the
*tourist* has picked. If that turns out to be an unlucky choice and AS1
refuses to give *anything* out to RD2 as you implied in your original
example, the tourist might opt to start using an additional AS, say AS2. If
AD1 in turn  refuses to use AS2 next to AS1, it might really be time to pack
up and move world. Hence my remark (and that of several others) that in the
end interop will be a question of trust, and users will vote with their
feet.
In fact its not even AS1 that is the root of the problem, its the buying
decision of the avatar itself. It might be have been wiser to check more
careful on the export conditions of the purple wonders.

In summary, i see your problem, its big and bad, but i fail to see your
solution. Could you go over this example and point out how things should be
done to prevent the blocked transfer of purple clothes? I do not think that
within the scope of the protocol there is a solution.

Looking in even more detail at the example brings up deeper problems, like
how the clothes maker is going to  know in what AS the purple clothes will
end up. But that is for later i think.

Sorry for the long mail, i will tty to be more brief in the future
Vaughn

On Fri, Oct 2, 2009 at 7:52 AM, Morgaine <[email-masked]>wrote:

> That's a very good start then.  If ADs have no region-related policies,
> then AD2 clearly doesn't need to be consulted when RD2 is entered from RD1.
>
> Is there a typo in that?  If it's free of typos and hence ADs carry
> policies about region services, then clearly AD2 *does* have to be
> consulted before you can TP from RD1 to RD2.  (I assume it has a typo, and
> you actually meant to write "do *not* carry policies about region
> services", to make this line consistent with what you said above.)
>
>> Ah good, I think we're starting to talk the same language now. :-)  AD1
> has plenty to say in regards to a TP from RD1 to RD2, as long as it sticks
> to the affairs of its own world W1 and its own agent A1.  What it cannot do
> is impose W1's region-related policies on W2's regions, otherwise we end up

---

From: Joshua Bell <[email-masked]>
Date: Fri, 2 Oct 2009 08:55:30 -0700

> services", to make this line consistent with what you said above.)
Ugh, yes, typo... I indeed meant to echo your statement: "ADs carry no
region-related policies". Thanks for catching that.

>    then that's very cool! :-)  (It's cool because it provides DDP and hence
Did you mean AD2 or AD1? I agree for AD2. For AD1, being nitpicky, here's a
scenario that possibly contradicts that: if RD2 tries to give you inventory,
AD1 may refuse it since it is the final arbiter of your agent (and hence
your inventory). I'm not sure if that counts as "say over region services"
or not. Based on previous conversation, I think we agree that in that
scenario, AD1 is enforcing agent-related policy in the interaction with
region services, not "having a say" over those region services.

>    -
> This is an extremely good point. "Disjoint" was too strong a word. I don't
think we've sorted out assets yet, but from early brainstorming, asset
services could indeed be provided by both ADs and RDs. (And a VW provider
might host just one asset service that its ADs and RDs both reference.)
"Mostly disjoint" :)

---

From: Infinity Linden <[email-masked]>
Date: Fri, 2 Oct 2009 09:32:22 -0700

i am vaguely confused by the path we're taking. a lot of what we're
fretting over was discussed over the summer.

i am also disappointed that morgaine believes that simply making a
fiat statement like "we are arriving at DDP" makes it true. it is not
true. BOTH the agent domain and the region domain MUST have an
opportunity to express their policy.

the problem outlined by carlo above is interesting, but tractable.

the agent domain is the entity with a direct relationship with the
user. we should not require the region domain to have information
about the user (such as the user's age.) and here's why...

in VWRAP, as discussed before, it is the agent domain that acts as a
trust broker. the user trusts the agent domain and the agent domain
trusts the provider of other services (such as the agent presence
service running on a host in the region domain.) we do not require the
user to have a direct relationship with the region domain. instead, we
define trust transitively.

if the agent domain must ensure that underage users do not visit
regions with adult content, then they should disallow underage user's
avatars from visiting those regions. if this is an organizational
policy that must be adhered to, then the agent domain should have
information to make that decision: the user's age and whether a
specific region (or entire region domain) allows adult content.

if the region domain operator believes that the agent domain operator
may believe that an acceptable age to view adult content is lower than
they are comfortable with, they should communicate this concern at the
time that they are negotiating access. please note that in this
scenario, the evaluation of organizational policies is something that
is performed by humans, not automated systems.

the policy enforcement tool the AD can use in this scenario is to
decide to not place a user's avatar in a particular region. the
information the AD uses to evaluate whether they want to allow or deny
a teleport request is largely not a concern of the protocol. though..
if the decision depends on the state of a region in the region domain,
then there has to be a way to communicate this information from the
region domain to the agent domain. and that _is_ definitely a protocol
concern.

the situation with the region domain is largely similar. the tool the
RD has to enforce policy in this scenario is to disallow an agent
domain from placing an avatar in one of it's regions.

but i really like this example, so i created a diagram from this
example at https://wiki.secondlife.com/wiki/File:VWRAP_adult_content_evaluation_example.jpg
.

it shows two agent domains and two region domains. one of the agent
domains and one of the region domains define adult content as being
viewable by those 18 and older, the others think adult content is
viewable by those 21 and older. each has two regions; one of which has
adult content, the other does not. lets assume that the user is 19.
when the agent domain attempts to place an avatar in each of the
regions, you get 8 scenarios.

A - no adult content in the region, AD allows transfer, RD allows transfer
B - adult content, but both the AD and RD agree that if you're 19,
you're okay to view adult content. AD allows transfer, RD allows
transfer.
C - no adult content in the region, AD allows transfer, RD allows transfer
D - adult content, but AD2 believes the user isn't old enough. AD does
not allow transfer.
E - no adult content in the region, AD allows transfer, RD allows transfer
F - no adult content in the region, AD allows transfer, RD allows transfer
G - adult content. AD1 believes the user is old enough, begins
transfer. RD believes the user is not old enough, disallows transfer.
H - adult content, but both AD2 and RD2 believe the user is old
enough. AD allows transfer, RD allows transfer.

i think the most vexxing scenario is scenario G. it forces the RD to
make a policy decision based on information about the user maintained
by the agent domain. there are a couple of ways to handle this.

1. the agent domain and the region domain hash out an agreement
beforehand where the region domain operator tells the agent domain
operator the equivalent of... "whoa dude, you'll get me in trouble
with the state if you let 19 year olds into my adults only sim, PLEASE
block them from entering sims i mark as adult." this effectively turns
scenario G into scenario D for the AD2 / RD2 pairing.

2. the agent domain offers information in the teleport request about
the user's age to the RD, allowing the RD to disallow the transfer of
agent presence into adult regions.

3. the agent domain offers an interface the RD that lets the RD query
information about the user (including their age.)

all of these have some drawbacks. my employer is probably most
interested in solution 1. linden views the relationship of agent
domain to region domain as a long-term trust relationship with a fair
amount of effort involved in setting it up. still, there are people
that want to have more of a tourist model where the user enters the
URL of a region into the client app and off you go without a
previously established agreements on policy enforcement.

for the tourist model, you could do either 2 or 3. 2 has the advantage
that the RD doesn't need to make a request back to the AD before
deciding whether to complete the teleport. it has the disadvantage
that it requires the AD to give information about the user's age to an
RD who may or may not be trustworthy (cause... remember... we're
talking about the tourist model here.)

i think what i'm getting at here is that carlo's example is
interesting, but it does yield to analysis. i think it also exposes
the difference between linden's vision of their service and what
morgaine (and presumably others) want people to build. but we can get
one protocol that works for both models, we just have to be careful,
and the end result will likely be more complicated than we would
prefer. but. welcome to the world of standards.

-cheers
-meadhbh

---

From: Morgaine <[email-masked]>
Date: Sat, 3 Oct 2009 06:15:15 +0100

IMO, this post of David's is one of the most important ones in the thread,
in particular its opening paragraph:

On Thu, Oct 1, 2009 at 11:25 PM, David W Levine <[email-masked]> wrote:

>
> One.. I think its very important to keep in mind that services are going to
> manage policy, not the domains they reside in. This is important, because it
> highlights the fact that what's going to happen when different people deploy
> this stuff in different deployments is going to vary.  I think we need to be
> very careful to focus not on any one deployment pattern, but the broader set
> of possible deployment patterns we are attempting to enable.
>

It's important firstly because it provides us with a clear path towards
implementation, and it seeks to reduce the focus on "domains" that has
caused so much trouble --- services are so much easier to understand and to
implement and to discuss.

And it's important secondly because it underlines the massive and overriding
power of the Agent Domain, because an AD provides caps that give access to
services, and therefore it has more power in dictating policy than any
service to which it gives access.  This places a mammoth constraint upon
David's first statement that "services are going to manage policy", because
there will be no access to those services *at all* unless an AD allows it.

(It's also worth pointing out that the AD's power to provide caps is in
direct conflict with the 2nd part of David's sentence (highlighted):  "services
are going to manage policy, *not the domains they reside in*".  The AD
clearly is managing policy, *in a major way*, by providing caps that allow
access to services.)

Fortunately, the way out of this dilemma has already been provided by
Joshua, namely limiting the scope of the AD to agent-related services only,
while RDs control region-related services thus allowing DDP, in much the way
that Carlo desired many weeks ago. :-)

If ADs are limited to agent-only services such as authentication, then there
are no significant problems.  For example, if ADs provides only
authentication, then AD2 doesn't need to be consulted when agent A1
teleports from RD1 to RD2, since A1 is already authenticated with AD1 and
additional authentication with AD2 is not required.

However, if ADs also provide caps to region-related services such as Asset
Services, then AD2 will need to be consulted when agent A1 teleports to RD2,
otherwise A1 won't have access to the assets of W2 that happen to reside in
RD2.

The following paragraph is crucial and its impact needs to be understood.

If ADs are allowed to provide caps to asset services *in any deployment
pattern whatsoever*, then AD2 will *always* have to be consulted if it
exists, *in all deployments*, because W1 does not know what kind of
deployment pattern is used by W2.  This affects our protocol very strongly
--- looking for an AD2 and querying it if it exists will not be optional.

Clearly we have some thinking to do about what is allowed in ADs if we wish
to avoid this.

Finally, I want to quote a sentence from David's 2nd paragraph, which I
think is quite illuminating:

> If we keep this in mind, I think it helps us move away from thinking purely
> in terms of the split that Linden Labs has focused on.

I agree entirely.  The rather coarse AD/RD split worked OK in its original
scope as an implementation mechanism for adding regions to an existing
world, but it's not very helpful now that we have started examining what
really needs to happen for interop in multi-world deployments.

If we feel a need for additional domains, let's add them --- for example, a
separate Storage Domain might be helpful to ensure that AD2 never need to be
consulted (unfortunately Asset Domain provides a conflicting abbreviation).
And if we feel the need to abandon the concept of domains entirely and just
leave services, then let's do that too.  After all, the domain model was
meant to help, not hinder.  Our work is concerned primarily with defining a
protocol --- domains are optional!  :-)

Morgaine.

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

On Thu, Oct 1, 2009 at 11:25 PM, David W Levine <[email-masked]> wrote:

>
> One.. I think its very important to keep in mind that services are going to
> manage policy, not the domains they reside in. This is important, because it
> highlights the fact that what's going to happen when different people deploy
> this stuff in different deployments is going to vary.  I think we need to be
> very careful to focus not on any one deployment pattern, but the broader set
> of possible deployment patterns we are attempting to enable. This goes hand
> in glove with Joshua's comments below.
>
> This leads to
>
> likely when looking at things like asset permissions.  Consider the case of
> a region attempting to pass a prim to an asset store for storage. The Region
> may have policies about which
> between focusing on the current deployed clusterings, and turning everything
> into soup. That said, the actual deployed systems which implement these
> specifications are only going to be able
> service" and "Region Domains include the presence service"  If we keep this
> in mind, I think it helps us move away from thinking purely in terms of the
> split that Linden Labs has focused on. To circle back to the question of
> soup, simply focusing on the services risks describing stuff that's falls
> into the HLA/DIS trap of having deployments which are each "conforming" but
> vary so much in assumption as to not actually interoperate.
>
> - David
> ~Zha
>
>
>
>
>
>  *Joshua Bell <[email-masked]>*
> [email-masked]  cc
> On Thu, Oct 1, 2009 at 2:34 PM, Morgaine <[email-masked]*<[email-masked]>>
> wrote:
>

---

From: Morgaine <[email-masked]>
Date: Sat, 3 Oct 2009 09:56:14 +0100

> opportunity to express their policy.

Of course they must have that opportunity, and nobody said they mustn't.
:-)  You may have misinterpreted the scope of the DDP principle slightly,
that's all.  I explained its narrow scope at the end of this response to
Joshua -- http://www.ietf.org/mail-archive/web/ogpx/current/msg00445.html .
It applies only at the destination, so perhaps we should give it yet another
'D' and turn it into *Destination Determines Destination Policy*, although
really it's implicit that it only applies in the destination region.

Think of it just like in the physical world.  If "When in Rome, do as the
Romans do" isn't sufficient, then consider what happens when you travel from
USA to France.  When in France, French laws apply --- no US law has
jurisdiction in France.

Yet, despite French law being the only valid one during your stay, this
doesn't mean that the US had no say in your exit from the US and your
boarding of a plane.  Nor does it mean that France has the power to override
US laws while you are inside her borders, not does it mean that something
you buy legally in France can necessarily be admitted into the US when you
return.  Despite DDP (or DDDP) in France, US law most certainly continues to
apply in its own jurisdiction.  However, US law does not apply on French
soil when you travel there.

Hopefully this squashes the worry that DDP means that AD1's agent-related
policies have no opportunity to be expressed --- they can be expressed
wherever agent-related policies are relevant to its agent A1.  It is only
the *region-related* policies of W2 that are determined by RD2 when A1 is in
RD2.  RD2 has no power beyond that.

Morgaine.

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

On Fri, Oct 2, 2009 at 5:32 PM, Infinity Linden <[email-masked]>wrote:

> example at
> https://wiki.secondlife.com/wiki/File:VWRAP_adult_content_evaluation_example.jpg
> .
>

---

From: Morgaine <[email-masked]>
Date: Sat, 3 Oct 2009 10:02:14 +0100

I'm totally in accord with you on all points here, Joshua.

You raised a question about what I meant in one particular section, and the
answer to that is *initially*  that "it's fine under your preferred
interpretation".  However, further down I then show that we're forced to
merge the two interpretations for symmetry or "bad things happen", so it
turns out not to be an either/or answer.  This was your query:

> region services, not "having a say" over those region services.

That you agree for AD2 is crucial, so let's accept that, and let's leave AD1
contributing to A1's asset service policy when in RD2 (as well as in charge
of asset service policy in RD1 for consistency) for now as you suggest.
(This is going to change slightly when we look at its ramifications in a few
paragraphs.)

> might host just one asset service that its ADs and RDs both reference.)

Excellent. :-)  It's great that this point is taken and we understand that
asset service cannot come *only* from the destination RD, nor from W1
alone.  Unfortunately, this means that now the key paragraph I wrote in
answer to David in post
http://www.ietf.org/mail-archive/web/ogpx/current/msg00449.html comes into
play, which I'll rewrite here for easy reading and with more explanation
added:

If ADs are allowed to provide caps to asset services *in any deployment
pattern whatsoever*, then AD2 will *always* have to be consulted if it
exists, *in all deployments*, because nobody knows what kind of deployment
pattern is used in W2, so AD2 might be providing asset services as well as
RD2.  This affects our protocol very strongly --- looking for an AD2 and
querying it if it exists will not be optional.

By noting that we require Asset Services contributions from both W1 and W2,
then if the W1 contribution is made to come from AD1, we have lumbered
ourselves with the need to consult AD2 because of symmetry (if AD1 can
provide asset services then so can AD2, so it must be consulted).  This is
not what we wanted.

I can see two ways out of this dilemma:

   1. Let the W1 asset service contribution come *not from AD1* but from *
   RD1*.  This not only avoids the need to consult ADs on asset services,
   but it is also nicely symmetrical for both source and destination, and it
   also respects the maxim "ADs do not provide region-related services" and
   hence allows DDP.  This is the clear winner on all counts.
   2. Alternatively, define another domain to carry asset services, such as
   a Storage Domain, so that ADs do not need to provide region-related
   services.  I don't see any real benefit in this, given that option 1 seems
   so good.  It's just substituting an SD2 lookup in place of the unwanted AD2
   lookup.  That's close to being a mere word change so I don't find any real
   merit in it.

Option 2 is so bad (I think) that really I'm only proposing option 1.
Option 1 makes the VWRAP model in respect of asset services very simple and
symmetric, as well as consistent with our common view in the last pair of
emails:

   - ADs do not provide any asset services at all.
   - RDs are the sole providers of asset services.  These asset services are
   provided to all three categories of agent: (i) homeworld residents in a home
   RD, (ii) homeworld residents touring in other worlds, and (iii) foreign
   tourists arriving in the home RD from other worlds.

Such a scheme avoids needing to consult RD2, while still providing A1 with
W1 assets to carry into RD2 for full interop alongside W2's assets provided
by RD2.  And of course it's a DDP scheme since RD2 has full control over its
own policies, so this allows full tourism.

How does this sound?

Morgaine.

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

On Fri, Oct 2, 2009 at 4:55 PM, Joshua Bell <[email-masked]> wrote:

>>    - But instead you might mean the following:  "*if RD2 uses some
>>    service of type X, say X2, then AD1 cannot provide an X service when in RD2"
>>    *.  That would be extremely not cool, since this would totally block
>>    meaningful tourism.  For example, RD2 could be using Asset Service AS2, as a
>>    result of which AD1 would not supply an asset service to its travelling
>>    agent A1, and hence A1 would never be able to appear in RD2 wearing any
>>    asset available in W1.  Clearly this interpretation would mean no useful
>>    interop between W1 and W2 at all.  I'm hoping this interpretation is wrong.
>>

---

From: Carlo Wood <[email-masked]>
Date: Sat, 3 Oct 2009 21:21:59 +0200

Can't type much with my RSI, but I'd like to add that instead
I'd prefer this for D, (not G):

1. the agent domain and the region domain hash out an agreement
beforehand where the region domain operator tells the agent domain
operator the equivalent of... "whoa dude, you won't get me in trouble
with the state if you let 19 year olds into my adults only sim, PLEASE
DON'T block them from entering sims i mark as adult." this effectively turns
scenario D into scenario B for the AD2 / RD1 pairing.

Reason, it's the region (destination) that really determines the law.
And as extension to this, it should be the region that determines all
rules that a visiting user must follow (independent of AD they use).

---

From: Morgaine <[email-masked]>
Date: Sat, 3 Oct 2009 22:52:18 +0100

On Sat, Oct 3, 2009 at 8:21 PM, Carlo Wood <[email-masked]> wrote:

> *Reason, it's the region (destination) that really determines the law.*
Yes indeed.  And that's pure *DDP*.  W2's regions or RDs may be run by a
provider located in a different country to W1's regions, so no way can W1
determine policy in RD2.

W1's policies can at most dictate whether A1 is allowed to TP to a W2 region
or RD, and which items can be brought back to W1.  That's all.

It's important to highlight (as you did) that issues such as age
verification have no place in a worldwide IETF protocol standard, so while
you provide a good example of policy variations among worlds, any such
agreements are outside of the context of our protocol.

Morgaine.

---

From: Carlo Wood <[email-masked]>
Date: Sun, 4 Oct 2009 00:21:18 +0200

On Sat, Oct 03, 2009 at 10:52:18PM +0100, Morgaine wrote:
> It's important to highlight (as you did) that issues such as age verification
> have no place in a worldwide IETF protocol standard, so while you provide a
> good example of policy variations among worlds, any such agreements are outside
> of the context of our protocol.

Not entirely... age verification is necessary in many countries with
what's going on in an SL-like world.

A RD cannot do the age-verification; that is a job for an AD.

However, I think it's the RD that needs to make the decision whether
or not a user is allowed in (based on its age), which in turn means
that the AD has to tell the RD if it knows the age, and if so, what
it is; hence, it should be part of the protocol.

---

From: Morgaine <[email-masked]>
Date: Sun, 4 Oct 2009 00:33:40 +0100

On Sat, Oct 3, 2009 at 11:21 PM, Carlo Wood <[email-masked]> wrote:

> verification
It's no business of an IETF protocol to deal with the age of participants.
That's like SMTP rejecting connections or mail delivery based on the ages of
the MTA operator and owner of the mail client.  The whole idea is completely
ludicrous, not to mention unimplementable.

Please let's try not to engage in what Schneier calls "security theater", a
politically correct feelgood factor that actually achieves nothing while
adding layers of red tape and complexity.

Morgaine.

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

On Sat, Oct 3, 2009 at 11:21 PM, Carlo Wood <[email-masked]> wrote:

> verification

---

From: "Dickson, Mike (ISS Software)" <[email-masked]>
Date: Sun, 4 Oct 2009 00:36:06 +0000

The algorithm or mechanism to enforce an age related connection policy is outside the scope of the protocol, yes.  But its not at all  inconceivable that the protocol could carry age information as an attribute that an AD/RD pair could use to make a decision as to whether a connection is to be allowed.

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Morgaine
Sent: Saturday, October 03, 2009 6:34 PM
To: Carlo Wood
Cc: [email-masked]
Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01

On Sat, Oct 3, 2009 at 11:21 PM, Carlo Wood <[email-masked]<mailto:[email-masked]>> wrote:

It's no business of an IETF protocol to deal with the age of participants.  That's like SMTP rejecting connections or mail delivery based on the ages of the MTA operator and owner of the mail client.  The whole idea is completely ludicrous, not to mention unimplementable.

Please let's try not to engage in what Schneier calls "security theater", a politically correct feelgood factor that actually achieves nothing while adding layers of red tape and complexity.

Morgaine.

---

From: Morgaine <[email-masked]>
Date: Sun, 4 Oct 2009 03:14:52 +0100

On Sun, Oct 4, 2009 at 1:36 AM, Dickson, Mike (ISS Software) <
[email-masked]> wrote:

>  The algorithm or mechanism to enforce an age related connection policy is
> outside the scope of the protocol, yes.  But its not at all  inconceivable
> that the protocol could carry age information as an attribute that an AD/RD
> pair could use to make a decision as to whether a connection is to be
> allowed.
>

As carried payload, sure.  Just like an SMTP message could carry a message
body or even a Subject line about the age of a mail user or about the ages
of the MTA sysadmins.  But that's not at the level of protocol at all.  If
the SMTP protocol dealt with the ages of the users of its endpoint
applications as a machine-processable semantic, we would be entering an age
of total madness and police states.

Admittedly, there are totally mad people and police-state advocates around,
but hopefully we are not among them.  Particularly when it's purely *security
theater* and doesn't actually achieve anything.

Morgaine.

On Sun, Oct 4, 2009 at 1:36 AM, Dickson, Mike (ISS Software) <
[email-masked]> wrote:

>  The algorithm or mechanism to enforce an age related connection policy is
> outside the scope of the protocol, yes.  But its not at all  inconceivable
> that the protocol could carry age information as an attribute that an AD/RD
> pair could use to make a decision as to whether a connection is to be
> allowed.
>
>
>
> Mike
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Morgaine
> *Sent:* Saturday, October 03, 2009 6:34 PM
> *To:* Carlo Wood
> *Cc:* [email-masked]

---

From: "Dickson, Mike (ISS Software)" <[email-masked]>
Date: Sun, 4 Oct 2009 03:25:13 +0000

On Sun, Oct 4, 2009 at 1:36 AM, Dickson, Mike (ISS Software) <[email-masked]<mailto:[email-masked]>> wrote:

As carried payload, sure.  Just like an SMTP message could carry a message body or even a Subject line about the age of a mail user or about the ages of the MTA sysadmins.  But that's not at the level of protocol at all.  If the SMTP protocol dealt with the ages of the users of its endpoint applications as a machine-processable semantic, we would be entering an age of total madness and police states.

Except that in the case of virtual worlds there already is a practice around defining regions in terms of age specific characteristics.  Are you saying you don't like the practice so you don't want it in the protocol?  Or are you really saying it's not necessary and if so how do you propose someone providing a region to a VW environment who wishes to restrict it to "Adult" content where age matters.  And I don't understand your assertion that its not at the "protocol" level...  In an SMTP exchange when I connect and send the HELO I generally need to identify myself.  The from address is an attribute in the same way that age information could be carried in the protocol (in SMTP more analogous to the additional message headers like mailer, etc).

Admittedly, there are totally mad people and police-state advocates around, but hopefully we are not among them.  Particularly when it's purely security theater and doesn't actually achieve anything.

Again, I don't understand this assertion given this is an already existing practice.

Mike

On Sun, Oct 4, 2009 at 1:36 AM, Dickson, Mike (ISS Software) <[email-masked]<mailto:[email-masked]>> wrote:

Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Morgaine
Sent: Saturday, October 03, 2009 6:34 PM
To: Carlo Wood
Cc: [email-masked]<mailto:[email-masked]>

Morgaine.

---

From: Morgaine <[email-masked]>
Date: Sun, 4 Oct 2009 08:45:00 +0100

On Sun, Oct 4, 2009 at 4:25 AM, Dickson, Mike (ISS Software) <
[email-masked]> wrote:

>
>
> Again, I don’t understand this assertion given this is an already existing
> practice.
>

It is "existing practice" in one single proprietary virtual world (Second
Life), and nowhere else.  In particular, it is not existing practice in the
many open virtual worlds that use the Opensim framework.

And further on the proprietary example, SL added it only very recently, and
that despite mass objections from a good 90% of its resident population who
were completely ignored and overridden in the alleged "consultation".

So your attempt at making this sound normal and desired merely reflects your
minority bias and lack of concern for balkanizing the metaverse even further
than the "trust agreements" are going to do already.

No thanks.  Age restrictions have no place in an IETF interop protocol.

As payload, of course everything will be carried, but we don't need to add a
totally ridiculous piece of security theater to the protocol just to carry
such data.

Morgaine.

On Sun, Oct 4, 2009 at 4:25 AM, Dickson, Mike (ISS Software) <
[email-masked]> wrote:

> Except that in the case of virtual worlds there already is a practice
> around defining regions in terms of age specific characteristics.  Are you
> saying you don’t like the practice so you don’t want it in the protocol?  Or
> are you really saying it’s not necessary and if so how do you propose
> someone providing a region to a VW environment who wishes to restrict it to
> “Adult” content where age matters.  And I don’t understand your assertion
> that its not at the “protocol” level…  In an SMTP exchange when I connect
> and send the HELO I generally need to identify myself.  The from address is
> an attribute in the same way that age information could be carried in the
> protocol (in SMTP more analogous to the additional message headers like
> mailer, etc).
>
> Again, I don’t understand this assertion given this is an already existing
> practice.
>
> Mike
>
>
>
>
>

---

From: Morgaine <[email-masked]>
Date: Sun, 4 Oct 2009 08:50:43 +0100

Vaughn, I think I'm with you on the problems you've highlighted, although
perhaps I'd better tick the paragraphs to be sure:

> will happen, let me explain:

It should be noted that I'm trying to cut AD2 out of the equation mainly
because this is one of Joshua's requirements stemming from the original OGP
scheme.  If our various goals can be achieved without needing to involve AD2
then all the better, since reduction of complexity is always a good thing,
so I support Joshua in that.

As it happens, it is possible to achieve DDP using Joshua's scheme by
limiting ADs to agent policies and RDs to region policies, and therefore I'm
happy with this approach.  However, I am fully aware that this doesn't
always make tourism possible, since it still requires the cooperation of
both worlds.  A prison world will not let its inmates escape, and a closed
society will not allow foreign visitors to enter, so just because DDP makes
tourism *possible*  doesn't mean that individual world policies will always
allow it.

> >then AD1 cannot provide an X service when in RD2".  That would be
> extremely not cool, since
> > any asset available in W1.

While this is catastrophic for interop in multi-world deployments, note that
Joshua has already accepted this and recognized that asset service
contributions are required from both W1 and W2.  Although we are still
working out the details, the point is already somewhat moot because the
severity of the problem has been accepted.

Note that I offered one solution to this problem at the end of this post --
http://www.ietf.org/mail-archive/web/ogpx/current/msg00451.html .  It's
really simple, and boils down to asset services being provided entirely by
the RDs.  RD1 provides access to the asset service AS1 (typically proxy
access --- after all, SL's regions already work as proxies to an asset
service, so it's no big leap), while RD2 provides access to the asset
service AS2.  No AD can ever provide an asset service, and therefore AD2
does not need to be consulted on TP.

> needed, and probably not desirable.
I meant *cannot provide*, very specifically.  The reason is that my analysis
stemmed from Joshua's statement about *disjointness* of AS and RD services.
The "cannot" is a mathematical "cannot", in the sense that if the AD and RD
service sets are *disjoint*  then the same services cannot appear in both.
Joshua accepted the problem and softened his phrase to the funny "mostly
disjoint". :D

Note that my proposal resolved this quite simply by requiring asset services
to be provided only by RDs.  This gives us the DDP necessary for tourism (or
*potential*  tourism, I should say), plus it allows assets from W1 and W2 to
appear in RD2, and it does not require AD2 to be consulted.  That seems
quite a nice package deal.

> different clothes shop next time its shopping time.

I believe that I understand your point.  You are describing the situation
that arises when W1 policy overrides the user-chosen policy that the user
encodes in her assets in AS1.

I agree that this is an issue.  I pointed it out here
http://www.ietf.org/mail-archive/web/ogpx/current/msg00433.html in answer to
David's statement that "services are going to manage policy, not the domains
they reside in",  Clearly David's statement doesn't quite reflect where we
are at the moment with the protocol, in which domains are totally crushing
the policies of services, although of course it is still early days. :-)

> careful on the export conditions of the purple wonders.

I think that my view on this is more in tune with David.  We have made a rod
for our own backs by defining domains as enforcers of policy, instead of
leaving policy to the services.  If we had left policy to the services then
a user would be able to configure her asset service AS1 to allow purple
clothing to enter RD2, despite the cartel operating in W1 seeking to
restrict any travel while wearing purple clothing.

> within the scope of the protocol there is a solution.
You may be right to be worried.  The protocol as it stands denies any
possibility of such user freedom.  Perhaps domains should be removed from
the model altogether, leaving just services.

An interesting post, Vaughn, thanks. :-)

Morgaine.

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

>>> On Thu, Oct 1, 2009 at 4:13 PM, Morgaine <[email-masked]
>>> > wrote:
>>>
>>>
>>>> There *IS* one way of allowing the above, and that is to require that
>>>> ADs carry no region-related policies at all, so that consulting only the
>>>> Determines Policy* (DDP) system.  The W1 resident could then TP from
>>>> RD1 to RD2 without consulting AD2 at all.
>>>>
>>>
>> Determines Policy* (DDP) model which makes tourism possible, by giving
>> RDs control over their region-related policies so that AD2 doesn't need to
>> be consulted on entry to RD2.  That's fine, but it's not yet clear how
>> you're going to achieve this since you haven't narrowed the scope of the AD
>> to exclude region services.
>>
>>> On Thu, Oct 1, 2009 at 4:13 PM, Morgaine <[email-masked]
>>> > wrote:
>>>
>>>>
>>> Here's the crux of the issue: in our model, the provider of W2 is
>>> offering two sets of services, AD2 and RD2. There may be a policy covering
>>> W2 in general, which would affect the AD2 and RD2 services. However, if an
>>> agent "from" W1, meaning the agent services are provided by AD1, attempts to
>>> visit RD2, then AD2 does *not* come into play. The protocol describes the
>>>> There *IS* one way of allowing the above, and that is to require that
>>>> ADs carry no region-related policies at all, so that consulting only the
>>>> Determines Policy* (DDP) system.  The W1 resident could then TP from
>>>> RD1 to RD2 without consulting AD2 at all.
>>>>
>>>

---

From: Vaughn Deluca <[email-masked]>
Date: Sun, 4 Oct 2009 13:21:46 +0200

On Sun, Oct 4, 2009 at 2:36 AM, Dickson, Mike (ISS Software) <
[email-masked]> wrote:

> I think SMTP is a very good example. An SMTP server  will reject mail from
untrusted sources; if I try to use the SMTP server in Domain X while logged
in at domain Y it normally fails, because the SMTP server does not trust
anybody but those it has information on (that might include age, real world
address etc.), i.e. users  from X.

The age restriction is not carried explicitly in the protocol, but is coded
in the source of the message. Its actually the trust relation between the
SMTP server and that domain were the user is logged in that determines the
SMTP protocol response.

In my view this is fully analogous to the way VWRAP should deal with age
restrictions or whatever other constrain.

-Vaughn

---

From: Carlo Wood <[email-masked]>
Date: Sun, 4 Oct 2009 15:11:53 +0200

On Sun, Oct 04, 2009 at 08:50:43AM +0100, Morgaine wrote:
> http://www.ietf.org/mail-archive/web/ogpx/current/msg00451.html .  It's really
> simple, and boils down to asset services being provided entirely by the RDs. 
> RD1 provides access to the asset service AS1 (typically proxy access --- after
> all, SL's regions already work as proxies to an asset service, so it's no big
> leap), while RD2 provides access to the asset service AS2.  No AD can ever
> provide an asset service, and therefore AD2 does not need to be consulted on
> TP.

Your phrase "RD1 provides access to the asset service AS1" is slightly misleading...
It should read: "RD1 provides (proxy) access to all asset services involved".

For example, three users visit RD1, they respectively use AS1, AS2 and AS3.
Then in order to see what they wear (or rezzed) all three asset servers need
to be accessed.

---

From: Vaughn Deluca <[email-masked]>
Date: Sun, 4 Oct 2009 15:59:12 +0200

Morgaine,

>We have made a rod for our own backs by defining domains as enforcers of
policy, instead of leaving
> policy to the services.

I see domains merely as a convenience making it easier to organise things.
Indeed as David says, the service will ultimately enforce the policy, yet if
a service is deployed within the domain you might as well say the domain
enforces the policy by *picking* this particular service. Its just wordplay.

> If we had left policy to the services then a user would be able to
configure her
>asset service AS1 to allow purple clothing to enter RD2, despite the cartel
operating in W1 seeking to
>restrict any travel while wearing purple clothing.

I do not like the way you frame the situation here. I am interested in my
own freedom to experience a unified virtual world, irrespective of the
underlaying ownership of services. I have no objection against people
running their own worlds in the way they like. The word "cartel" implies
that  i have no other options, and  are forced to use something i don't
like. The protocol should give me the freedom to do things the way i do
like. Yet, I can *not* demand control over resources i do not own. If i take
residence in W1 (better: if i subscribe to AD1) that does not give me any
right to configure asset services used by AD1.

I might expect however that AS1 will give me back anything i trusted it
with. But if i put object in AS1 that carry export restrictions, i know AS1
will under certain conditions refuse to send that object outside its
jurisdiction. Nothing wrong with that. Its *my* choice to put the object in
AS1.

I do expect however that AS1 will allow me to take to RD2 anything that
carries *no* restrictions. If AS1 is not flexible enough to determine what
it can give out to RD2 and what not, and therefore refuses to give out
anything to RD2, i would be disappointed, and feel compelled to store all my
stuff in AS2, that acts more intelligent (Alas, I will not be able to put my
purple clothes in AS2, because the maker does not want to sell to me if i
don't put them in AS1 first and AS1 does not want to give them out to AS2).
 I would certainly expect that when I am in AD1/RD1 I can get access to AS2
were i have a lot of other  stuff, and in this way prevent the need to copy
or move everything from AS2 to AS1 before i try to use it in RD1.

My conclusion is the protocol should allow me to contact  *any* AS i choose.
But it is up to RD1 to decide if it wants to accept stuff from my chosen AS
(that's your DDP). If RD1 has a policy that prevent me from rezzing anything
 but objects from AS1, and AS1 insists on giving objects only to RD1, well
thats fine, but i am not going to live in such a world. It might mean though
i have to stop wearing the nice purple clothes only sold in RD1,  (or more
precise, only sold if placed in AS1). But regarding the protocol, the
important question is if it allows me access to AS2 when in AD1. As soon as
that is the case, i have my freedom.

>You may be right to be worried.  The protocol as it stands denies any
possibility of such user freedom.
>Perhaps domains should be removed from the model altogether, leaving just
services.

I should have been more clear, i meant to say that i don't see how *any*
protocol  change can solve this problem since we are actually discussing
trust and rights issues. Doing away with domains will not help. So probably
its wrong to call it a "problem" in the sense that it needs solving before
we can proceed. That is not the case. We should focus on the *possibility*
to use external services when in a particular domain, and i feel confident
there are very workable solutions for that, that will make all parties
happy.

-Vaughn

On Sun, Oct 4, 2009 at 9:50 AM, Morgaine <[email-masked]>wrote:

> tourism *possible*  doesn't mean that individual world policies will
> always allow it.
>
>
>>
>> >[...] But instead you might mean the following:  "if RD2 uses some
>> service of type X, say X2,
> While this is catastrophic for interop in multi-world deployments, note
> that Joshua has already accepted this and recognized that asset service
> I meant *cannot provide*, very specifically.  The reason is that my
> analysis stemmed from Joshua's statement about *disjointness* of AS and RD
> services.  The "cannot" is a mathematical "cannot", in the sense that if the
> AD and RD service sets are *disjoint*  then the same services cannot
> appear in both.  Joshua accepted the problem and softened his phrase to the
> funny "mostly disjoint". :D
>
> Note that my proposal resolved this quite simply by requiring asset
> services to be provided only by RDs.  This gives us the DDP necessary for
> tourism (or *potential*  tourism, I should say), plus it allows assets
> from W1 and W2 to appear in RD2, and it does not require AD2 to be
> consulted.  That seems quite a nice package deal.
>
>
>
>> Our tourist is at home in W1. W1 is a container concept for a collection
>> of services. The agent is in fact registered in AD1, it uses a big
>> collection of (purple) clothes from AS1, and is presently located in RD1,
>> trying to become a tourist and travel for the first time to RD2 (to show off
>> its purple clothes).
>>
> http://www.ietf.org/mail-archive/web/ogpx/current/msg00433.html in answer
> to David's statement that "services are going to manage policy, not the
> domains they reside in",  Clearly David's statement doesn't quite reflect
> where we are at the moment with the protocol, in which domains are totally
> crushing the policies of services, although of course it is still early
> days. :-)
>
>
>
> I think that my view on this is more in tune with David.  We have made a
> rod for our own backs by defining domains as enforcers of policy, instead of
>>>> On Thu, Oct 1, 2009 at 4:13 PM, Morgaine <
>>>> [email-masked]> wrote:
>>>>
>>>>
>>>    - If by this you mean that AD1 has no say over region services in
>>>    RD2, then that's very cool! :-)  (It's cool because it provides DDP and
>>>    hence allows tourism.)
>>>> On Thu, Oct 1, 2009 at 4:13 PM, Morgaine <
>>>> [email-masked]> wrote:
>>>>
>>>>>
>>>> (Again, this is insofar as the model in the current drafts are
>>>> concerned. If we're missing something, please bring the conversation back to
>>>> the drafts and point out issues and/or submit new work for discussion!)
>>>>
>>>> .... and so it looks like we're in agreement - if this wasn't clear,
>>>> then we need to review the drafts (please, go for it!); it should be the
>>>> case that ADs carry policies about region services... except, of course,
>>>> that the AD may say "hey, you can't go to *that* RD...".
>>>>

---

From: SM <[email-masked]>
Date: Sun, 04 Oct 2009 07:56:46 -0700

At 04:21 04-10-2009, Vaughn Deluca wrote:
>I think SMTP is a very good example. An SMTP server  will reject 
>mail from untrusted sources; if I try to use the SMTP server in 
>Domain X while logged in at domain Y it normally fails, because the 
>SMTP server does not trust anybody but those it has information on 
>(that might include age, real world address etc.), i.e. users  from X.

SMTP is not based on a concept of "trust domains".  If a SMTP server 
were to reject mail from untrusted sources, this email would not 
reach your mailbox.

You are using a gmail.com email address.  Does your email provider 
have your real name, your real world address and did it validate your age?

Regards,
-sm

---

From: "Dickson, Mike (ISS Software)" <[email-masked]>
Date: Sun, 4 Oct 2009 16:07:29 +0000

I think SMTP is a very good example. An SMTP server  will reject mail from untrusted sources; if I try to use the SMTP server in Domain X while logged in at domain Y it normally fails, because the SMTP server does not trust anybody but those it has information on (that might include age, real world address etc.), i.e. users  from X.

The age restriction is not carried explicitly in the protocol, but is coded in the source of the message. Its actually the trust relation between the SMTP server and that domain were the user is logged in that determines the SMTP protocol response.

In my view this is fully analogous to the way VWRAP should deal with age restrictions or whatever other constrain.

-Vaughn

You've expressed this more concisely than me. Yes, I completely agree and that was the point I was making.  Not to code the policy in the exchange but to allow the exchange of information such that a policy decision can be made.

Mike

---

From: "Dickson, Mike (ISS Software)" <[email-masked]>
Date: Sun, 4 Oct 2009 16:18:44 +0000

reach your mailbox.

Regards,

-sm

Sure it does if I'm required to authenticate to use it.  That is, if I'm sending using my gmail.com address and I'm required to authenticate to use it then yes, its very possible to make the association.  True, I may be able to find an SMTP server that will accept my mail anonymously.  In that sense the protocols are different (though even then an SMTP gateway can refuse to accept or forward from a server that accepts such anonymous connections).

Mike

ogpx mailing list

[email-masked]

---

From: Vaughn Deluca <[email-masked]>
Date: Sun, 4 Oct 2009 20:46:35 +0200

On Sun, Oct 4, 2009 at 4:56 PM, SM <[email-masked]> wrote:

> SMTP is not based on a concept of "trust domains".  If a SMTP server were
> to reject mail from untrusted sources, this email would not reach your
> mailbox.
>
> You are using a gmail.com email address.  Does your email provider have
> your real name, your real world address and did it validate your age?
>

No, but that is besides the point, they *could* have done so, in fact they
implicitly did, since they made me accept their TOS including this:

2.3 You may not use the Services and may not accept the Terms if (a) you are
not of legal age to form a binding contract with Google,

and this:

  5.1 In order to access certain Services, you may be required to provide
information about yourself (such as identification or contact details)   as
part of the registration process for the Service, or as part of your
continued use of the Services. You agree that any registration information
you give to Google will always be accurate, correct and up to date.

I read that as:
a) I have to be 18 or older
b) I am obliged to prove my true age if asked for.

But the discussion is drifting,  were talking about the way that for
instance an age limit might be passed in the protocol.  Carlo said that info
was needed, Morgaine set it has no place in the protocol, using SMTP as an
example, Mike stated that it is very well possible to transfer the age
information without putting it explicitly in the protocol, and indeed
Morgaine's example of SMTP is a perfect model to demonstrate how that could
work.
There are still complications, but if feel this is a good basis to work
from.
--Vaughn

---

From: Morgaine <[email-masked]>
Date: Sun, 4 Oct 2009 20:34:14 +0100

Google have not modified SMTP to carry SMTP-readable metadata about the age
of participants, so the whole example of Google is inaccurate and moot.

Carrying data as payload is a different matter entirely to using it in the
protocol.

There is nothing to stop arbitrary payloads being sent between world to
implement random policies which, indirectly, could deny connections or deny
object transfer, but this is outside the scope of the protocol.

It **HAS** to be outside of the scope of the protocol, because there exist
an infinite number of possible attributes on the basis of which a world
could implement an exclusion policy, and we're not here to ennumerate such
attributes nor to support one particular type of attribute over another.

Morgaine.

On Sun, Oct 4, 2009 at 7:46 PM, Vaughn Deluca <[email-masked]>wrote:

>>> I think SMTP is a very good example. An SMTP server  will reject mail
>>> from untrusted sources; if I try to use the SMTP server in Domain X while
>>> logged in at domain Y it normally fails, because the SMTP server does not
>>> trust anybody but those it has information on (that might include age, real
>>> world address etc.), i.e. users  from X.
>>>
>>
> 2.3 You may not use the Services and may not accept the Terms if (a) you
> are not of legal age to form a binding contract with Google,
>
> and this:
>

---

From: David W Levine <[email-masked]>
Date: Sun, 4 Oct 2009 17:26:57 -0400

I've changed the subject, because the thread drift has become brutal 

I want to make a couple of points, one of, something akin to etiquette. 
Lets start there. 

I don't think it advances our technical agenda when we start dragging in 
philosophical,
political and cultural issues around some of the use cases people are 
advancing. 
One persons abhorred policy is another's legally required to stay in 
business use case. 

We also need to be careful to separate the use cases, such as "I don't 
want people
who haven't passed some form of age verification accessing some virtual 
spaces"
from possible mechanisms for achieving those use cases. 

It is also worth keeping in mind the limitations of  what we can express 
in a protocol
and what  mechanisms we have for allowing services to express and manage 
policy.

At the end of the day the policy enforcement points are primarily when 
either:

        1) first contact is made with a cluster of services, where 
meta-data is
            included in the request, and based on this, and policy, caps 
are
                    granted (or not) and meta-data is associated with 
those caps. This
            is one of the nice bits of a cap grant, it permits a policy 
decision to
                    be made once, and encapsulated in the cap(s) granted. 

        2) at invocation of a cap, mediated by meta-data associated with
                    the request. This is notably more expensive, as it 
requires the check
                   to be made in all cases, but it provides a finer 
grained policy enforcement
                   scheme. 

Also note protocol is unlikely to directly encode complex, "semantic" 
concepts such as 
"age-verified." They are far more likely to permit set of deploys to 
define mechanisms 
for making (and possibly in some cases verifying)  properties of the users 
they represent 

This is rather like the point made by several people, a distinction 
between having the
spots to carry the information, and mandating the contents of those slots. 
The nice
thing about LLSD protocol elements  is that they are easily extensible. if 
we say "Here is where
a set of properties that the authenticating service vouches for about the 
user go" 
we can stop there, and allow the community to define the properties they 
care about. 

We also need to recognize the limits of any specification. We describe 
mechanisms
to enable interoperability. We cannot mandate how people extend those 
mechanisms
nor deployment choices they make, nor policy choices they make which are 
beyond those
defined in the specifications. 

Lastly, for better or worse, some of the use cases involved in policy 
effectively are
about linking a real world legal contract with the use of services. We're 
not going to
flow protocol elements which are legal contracts, but.. we may well end up 
using
things like PKI to prove the a given end user or service is in procession 
of a proof
token for having signed a specific legal document . In this case, less a 
matter
of defining the mechanisms as much as leveraging existing ones. 

- David Levine
~ Zha Ewry

---

From: SM <[email-masked]>
Date: Mon, 05 Oct 2009 02:21:41 -0700

At 09:18 04-10-2009, Dickson, Mike (ISS Software) wrote:
>Sure it does if I'm required to authenticate to use it.  That is, if 
>I'm sending using my gmail.com address and I'm required to 
>authenticate to use it then yes, its very possible
>to make the association.  True, I may be able to find an SMTP server 
>that will accept my

That's mail submission.  I'll skip the discussion about the analogy.

At 11:46 04-10-2009, Vaughn Deluca wrote:
>instance an age limit might be passed in the protocol.  Carlo said 
>that info was needed, Morgaine set it
>  has no place in the protocol, using SMTP as an example, Mike 
> stated that it is very well

The discussion seems to be about acquiring policy information to 
authorize access to a resource and whether that should be part of the 
protocol.  It could be age, location or other non-technical information.

Regards,
-sm

---

From: Morgaine <[email-masked]>
Date: Mon, 5 Oct 2009 11:20:42 +0100

Judging by personal mails received on this topic, I sense that sanity is
prevailing, and that there is no desire nor intention to make trigger
concepts such as age, sex, race, religion, creed, DNA genome or any other
sensitive and/or personal information part of the protocol.

It would be the thin end of the wedge, and I'm hoping that people are clever
enough not to go there.

Services are authenticated.  Let that be enough.

Morgaine.

On Mon, Oct 5, 2009 at 10:21 AM, SM <[email-masked]> wrote:

>> Sure it does if I'm required to authenticate to use it.  That is, if I'm
>> sending using my gmail.com address and I'm required to authenticate to
>> use it then yes, its very possible
>> to make the association.  True, I may be able to find an SMTP server that
>> will accept my
>>
>
>> was needed, Morgaine set it
>>  has no place in the protocol, using SMTP as an example, Mike stated that
>> it is very well
>>
>
> The discussion seems to be about acquiring policy information to authorize
> access to a resource and whether that should be part of the protocol.  It
> could be age, location or other non-technical information.
>
> Regards,
> -sm

---

From: Carlo Wood <[email-masked]>
Date: Mon, 5 Oct 2009 20:25:05 +0200

Nobody reacted to this post of me so far,
does that mean everyone agrees?

---

From: Infinity Linden <[email-masked]>
Date: Mon, 5 Oct 2009 11:31:52 -0700

silence does not mean agreement.

---

From: Infinity Linden <[email-masked]>
Date: Mon, 5 Oct 2009 11:41:34 -0700

i agree that identifying information should not be included in the
protocol, but for use cases where such information is required for
proper operation (i.e. - the adult verification example) we should not
eliminate it as a possibility.

i would recommend making it not be a required part of the protocol,
but identify where in the protocol flows such information SHOULD be
included if that option is to be used by collaborating AD's and RD's.
one of the reasons LLSD was designed was for situations like this; it
is quite possible for agent domains that do not want to reveal
sensitive information (like the account holders age or whether they
are considered an "adult" for the purposes of accessing adult content)
then they do not have to include those bits of information in the
protocol flow. these agent domains may find, howerver, that some
region operators will refuse to allow them to place avatars in their
regions. this is a POLICY issue that should be left entirely up to the
AD and RD.

morgaine, if the {agent|region} domain code you write wants to connect
potentially underage account holders with adult content, that's
entirely your call. however, there are a number of us here who operate
in an environment in which these concerns are very real.

also. i'm sure the people who have been sending email to you on this
topic are perfectly capable of participating in the conversation here.

-cheers
-meadhbh

On Mon, Oct 5, 2009 at 3:20 AM, Morgaine <[email-masked]> wrote:
>>> sending using my gmail.com address and I'm required to authenticate to use
>>> it then yes, its very possible

---

From: Morgaine <[email-masked]>
Date: Mon, 5 Oct 2009 19:53:28 +0100

On Mon, Oct 5, 2009 at 7:25 PM, Carlo Wood <[email-masked]> wrote:

> Nobody reacted to this post of me so far, does that mean everyone agrees?

I agreed with your approach Carlo when I found total accord with Joshua here
-- http://www.ietf.org/mail-archive/web/ogpx/current/msg00451.html .  As you
have probably noticed, we've been moving gradually towards your general
position on RD-controlled region policy just by analysing deployment
requirements.

My post didn't make an arbitrary proposal that the AD's policy be limited to
allowing the TP.  Instead it reasoned out that this was the only known
approach that provides DDP to allow tourism and at the same time allows us
to omit querying AD2 on TP from RD1.

This approach sounds fine to me Carlo, and it's quite simple, symmetrical
and elegant.  What's more, I can't think of any alternative, if we're
constrained to not querying AD2. :-)

Morgaine.

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

---

From: Carlo Wood <[email-masked]>
Date: Tue, 6 Oct 2009 00:32:42 +0200

The rationale behind this is that this is the only reasonable
way to achieve that for any two people in a given region, the
same rules apply.

Hopefully we can reach consensus on that it would be unworkable
if one person is allowed to X, while the person next to him/her
is not, where X being anything and everything.

Example, one person is allowed to use avatar Foo without clothes,
then everyone in the region should be allowed to use avatar Foo
without clothes (not taking into account local rules set by
sim owner or parcel owner).

Since two different people can be using two different AD's,
no AD can force a limitation upon a user (beyond what the
region already demands) because another AD might not enforce
that leading to different rules for different people in the
same region.

It's really quite logical, almost trivial, but seeing previous
confusion about things on this list it would be nice to see
people agree. Thanks!

---

From: Infinity Linden <[email-masked]>
Date: Mon, 5 Oct 2009 16:01:03 -0700

we will not be able to reach consensus with a protocol that supports
"destination determines policy" exclusively.

if we want to add that as an option, i'm down with that, but i cannot
imagine my employer signing onto a proposal that would disallow the
agent domain from enforcing it's policies as well as the region
domain's policies.

but the great thing about policies is they're outside of the protocol
definition. so... i'm hip to adding the "tourist model" as a supported
use case if this will allow us to get on with more important matters.

i would suggest we not add the "allowed to wear clothes" bits to the
protocol, but leave this as a POLICY for the deployers. personally, i
have NO PROBLEM with an agent domain and a region domain making
asymmetric agreements. that is, if region domain X wants to make
policy A with agent domain Y, but wants to make a different policy
(call it policy B) with agent domain Z, well good on 'em. i guess i'm
too much of libertarian at heart to have a protocol demand that each
participant or pair of participants use exactly the same protocol.

-cheers
-meadhbh

---

From: Infinity Linden <[email-masked]>
Date: Mon, 5 Oct 2009 16:03:41 -0700

ack. and when i say "i guess i'm  too much of libertarian at heart to
have a protocol demand that each participant or pair of participants
use exactly the same PROTOCOL," i obviously mean "i guess i'm too much
of libertarian at heart to have a protocol demand that each
participant or pair of participants use exactly the same POLICY."

---

From: Morgaine <[email-masked]>
Date: Tue, 6 Oct 2009 00:27:38 +0100

On Tue, Oct 6, 2009 at 12:01 AM, Infinity Linden <[email-masked]>wrote:

> "destination determines policy" exclusively.

That has already been addressed in numerous places.  DDP does not imply that
*only* "destination determines policy" exclusively in the way you suggest at
all.

You may have missed this post the first time around, but it was written
specifically to help you understand DDP ---
http://www.ietf.org/mail-archive/web/ogpx/current/msg00450.html  .

You may also wish to examine Joshua's post here ---
http://www.ietf.org/mail-archive/web/ogpx/current/msg00447.html  , in which
we were discussing the implications of tourism enabled by DDP on the
services provided by ADs and RDs.  Good progress was made by understanding
this basic principle for tourists interacting in a non-local RD.

Morgaine.

---

From: Carlo Wood <[email-masked]>
Date: Tue, 6 Oct 2009 13:39:54 +0200

> participant or pair of participants use exactly the same protocol.

and that isn't a problem, as long as the AD policy is ONLY used to
decide if a user is let in or not.