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

From: Infinity Linden <[email-masked]>
Date: Tue, 1 Sep 2009 15:49:13 -0700

Working Group Name:

  Virtual Worlds Region Agent Protocol (VWRAP)

Chairs:

  TBD

Area and Area Directors:

  Applications Area

  Lisa Dusseault <[email-masked]>
  Alexey Melnikov <[email-masked]>

Responsible Area Director:

  TBD

Mailing List:

  [email-masked]
  http://www.ietf.org/mailman/listinfo/ogpx

Description of Working Group:

The working group will define the Virtual Worlds Region Agent Protocol
(VWRAP)  for  collaborative  3-dimensional  virtual  environment.  The
protocol permits  users to interact as  digital representations called
"avatars".  Avatars exist  in at  most  one location  within a  shared
virtual  space. Conforming  client  applications use  the protocol  to
manipulate  and  move  the  user's  avatar,  create  virtual  objects,
interactd with other users  and their surroundings, consume and create
media and information from  sources inside and outside their simulated
environment.

Adjacent points in  virtual spaces accessible by this  protocol may be
explicitly partitioned into  "regions" to facilitate the computational
and  communication load  balancing  required to  simulate the  virtual
environment.  Such   virtual  environments  may   consist  of  regions
administered  by distinct organizations.  Regions provide  the service
endpoints  for  interacting  with  the inhabitants  and  objects  they
contain.  Regions uniquely  represent their  partition of  the virtual
space (that is,  they are not a "sharding" mechanism).  The state of a
virtual world is independent of the client applications that access it
and may persist between user sessions.

Regions and other services implemented according to the specifications
may be  deployed by separate  organizations with varying  policies and
trust  domains. The  VWRAP protocol  will provide  the  mechanisms for
these virtual world services to interoperate, when permitted by policy
and   shared  trust   domains.  To   support  the   exegesis   of  the
specifications,  the   group  may  define  a   non-exhaustive  set  of
non-normative policies protocol participants may enforce.

Foundational components of the protocol include the publication of:

  * an abstract  type system, suitable for  describing the application
    protocol in an implementation neutral manner,

  * a   security   model   describing  trust   relationships   between
    participating entities,

  * guidelines   for   the   use   of  existing   authentication   and
    confidentiality mechanisms,

  * an application-layer  protocol for establishing  the user's avatar
    in a region,

  * an application-layer  protocol for changing  an avatar's position,
    including moving between regions,

  * format descriptions for objects and avatars, and

  * an  application-layer  protocol   for  identifying  entities,  and
    requesting information about them.

The protocol  defined by this  group will carry information  about the
virtual  environment,  its contents  and  its  inhabitants.  It is  an
application layer protocol,  independent of transport, based partially
on these previously published internet drafts:

  * http://tools.ietf.org/html/draft-hamrick-ogp-intro
  * http://tools.ietf.org/html/draft-hamrick-llsd
  * http://tools.ietf.org/html/draft-hamrick-ogp-auth
  * http://tools.ietf.org/html/draft-hamrick-ogp-launch
  * http://tools.ietf.org/html/draft-lentczner-ogp-base
  * http://tools.ietf.org/html/draft-levine-ogp-clientcap
  * http://tools.ietf.org/html/draft-levine-ogp-layering

The  protocol  should describe  interaction  semantics independent  of
transport,  leveraging existing standards  where practical.  It should
define interoperability expectations for server to server interactions
as  well  as  client-server   interactions.  Though  the  protocol  is
independent of  transport, early interoperability  trials used HTTP(S)
for  non-real-time messages.  The working  group will  define specific
features that must  be replicated in other transports  and will define
the use of HTTP(S) as a transport of protocol messages.

Goals and Milestones:

  * December  2009  "Introduction  and   Goals"  to  the  IESG  as  an
    Informational RFC

  * March 2010  "Abstract Type System for the  Transmission of Dynamic
    Structured Data" to the IESG as Proposed Standard

  * March 2010  "Foundational Concepts and  Transport Expectations" to
    the IESG as Proposed Standard

  * March  2010  "Service  Establishment"  to  the  IESG  as  Proposed
    Standard

  * July 2010 "Guidelines  for Host Authentication" to the  IESG as an
    Informational RFC

  * July 2010  "Client Application Launch  Message" to the IESG  as an
    Informational RFC

  * July  2010  "Simulation Presence  Establishment"  to  the IESG  as
    Proposed Standard

  * November 2010  "Primitive Object Format"  to the IESG  as Proposed
    Standard

  * March 2011 "Digital Asset Access" to the IESG as Proposed Standard

  * June 2011 "Entity Identifiers" to the IESG as Proposed standard

---

From: Joshua Bell <[email-masked]>
Date: Tue, 1 Sep 2009 16:48:15 -0700

Thanks for sending out the latest draft of the charter, Infinity. I have my
fingers crossed that this is the last iteration...

We made several changes in this latest version incorporating the targeted
feedback a few list contributors have provided. A few examples:

* Where "virtual worlds" was used in a way that could lead to
misinterpretation, we reworked the text or used a more neutral term like
"virtual environment". We did leave the term "virtual world" in a few
places, namely the introduction and in places where it was qualified like
"virtual world services" - it didn't seem to make that a definition and
would remind casual readers what we're talking about.

* We worked the "un-sharded" text, to define more clearly what regions are,
and parenthetically that they are not a sharding mechanism (which becomes
implicitly defined as a way of non-uniquely representing locations to
provide load balancing - huzzah!)

* By beefing up the definition of region, we believe this text clarifies the
interop goals: "Regions and  other services ... may be deployed by separate
organizations with varying policies and trust domains.  The VWRAP protocol
will  provide the mechanisms for these virtual world  services to
interoperate, ..."

Again, this is a charter, so we have avoided diving into detail about, say,
the agent/region domain split (which presupposes the solution to the
problem) and other definitions except where strictly necessary (i.e.
"avatar", "region"). We toyed with text around such as "service providers
and end users may choose to call collections of VWRAP-implementing services
a virtual world or virtual worlds" but it seemed obvious and/or confusing...
and downright limiting to implementers.

On Tue, Sep 1, 2009 at 3:49 PM, Infinity Linden <[email-masked]>wrote:

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

---

From: Kari Lippert <[email-masked]>
Date: Tue, 1 Sep 2009 22:26:16 -0400

I like it. This version of the charter is very clear and concisely
stated. To confound or misrepresent the concepts or the intent would
be difficult. I applaud your effort in pulling this out of the various
conversations over the past few days. Now when do we start?  :)  (I am
most interested in the "Primitive Object Format" but am happy to
participate across the board.

Kari

---

From: Infinity Linden <[email-masked]>
Date: Tue, 1 Sep 2009 19:42:36 -0700

thx, kari! thanks for your work in making it better.

---

From: Carlo Wood <[email-masked]>
Date: Wed, 2 Sep 2009 15:27:08 +0200

Since I don't see my last reply get through, I might have 'replied'
instead of 'group replied', so allow me to try again:

With this wording I can agree with the Charter and forming a working group.
Thanks for making these changes.

I'm not *entirely* happy, since it seems that the most important
goal of this WG, to create a protocol that will allow interoperability
between <we still don't have a term for this> isn't explicitely
mentioned in the charter :/, but I guess it's good enough to move on.

I'm also sad that Infinity still doesn't seem to understand the problem
of miscommunication that she and several others have (and still have, imho).

Note that recently I have developed RSI (Repitive Stess Injury), again,
which means that I shouldn't be sitting behind my PC, let alone type
the long emails that I just typed. Therefore this is going to be my
last post for a while, until I truely recovered my left arm back.

Regards,
Carlo

-- 
Carlo Wood <[email-masked]>

---

From: Carlo Wood <[email-masked]>
Date: Wed, 2 Sep 2009 15:15:12 +0200

Ok,... (finally, I might add)...
with this wording I can agree that we continue to form a working group.

Thanks

---

From: Morgaine <[email-masked]>
Date: Wed, 2 Sep 2009 14:41:37 +0100

Joshua, this draft of the charter reads a lot better than the previous ones,
the iterations are definitely helping. :-)

Admittedly, our job has been simplified tremendously by knowing that VWRAP
will not address interop between VWs, so that we can focus on the
single-world building aspects of the work.  This is good.  (Not ideal but
still very useful.)  We could have been here already on the 20th August if
my call for clarity had been accepted.

The following is worth noting:  because you still have not spelled out that
the protocol does not allow for more than one world to be mentioned (it
never talks to a peer world), the workgroup will probably continue to
receive input from people expecting VWRAP to be a VW interop protocol.  I
think it would have been to the benefit of all readers to add Meadhbh's
clear words to the charter so that the scope of the workgroup is not subject
to the whims of interpretation.  This will probably come back to haunt us,
so it's a pity that the advice was not taken.

One great benefit of excluding cross-VW interop is that our deliverables do
not need to be expanded, which immediately gets us closer to a viable
charter.  That's a clear win.

 In respect of referenced documents,
http://tools.ietf.org/html/draft-hamrick-ogp-launch has no direct relevance
to our network protocols at all and should probably be dropped, but the rest
of the list seems reasonable.

The sentence "Regions uniquely represent their partition of  the virtual
space (that is, they are not a "sharding" mechanism)." is probably
superfluous.  The protocol is only concerned with endpoint reachability, not
with how a region wishes to arrange or present its population or objects, so
other arrangements are possible.  Really this is just a world implementation
detail.

If you're going to mention "sharding" then you probably need to mention
"instancing" too, which is a related partitioning on the local scale instead
of on the world scale.  Neither reference is really helpful or necessary
though.  Mentioning sharding has probably reduced rather than enhanced
comprehension, and it is close to being a cultural reference which will date
it.  I would drop the reference to "sharding", and possibly drop the whole
sentence.

Finally, the sentence "*To support the exegesis of the specifications, the
group may define a non-exhaustive set of non-normative policies protocol
participants may enforce*" is obscure in the extreme, and when analysed
deeply means almost nothing because everything is doubly optional.  It
pretty much says "*The group may do stuff*."  This needs to disappear, as it
makes a charter that is progressing well become entirely meaningless for
scoping.

Good progress, but it will need some more iterations, particularly in view
of Carlo's work on terminology.

Morgaine.

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

On Wed, Sep 2, 2009 at 12:48 AM, Joshua Bell <[email-masked]> wrote:

> * By beefing up the definition of region, we believe this text clarifies
> the interop goals: "Regions and  other services ... may be deployed by
> separate organizations with varying policies and trust domains.  The VWRAP
> protocol will  provide the mechanisms for these virtual world  services to
> interoperate, ..."
>

---

From: Carlo Wood <[email-masked]>
Date: Thu, 3 Sep 2009 01:03:38 +0200

On Wed, Sep 02, 2009 at 02:41:37PM +0100, Morgaine wrote:
> Admittedly, our job has been simplified tremendously by knowing that VWRAP will
> not address interop between VWs, so that we can focus on the single-world
> building aspects of the work.  This is good.  (Not ideal but still very
> useful.)  We could have been here already on the 20th August if my call for
> clarity had been accepted.
> 
> The following is worth noting:  because you still have not spelled out that the
> protocol does not allow for more than one world to be mentioned (it never talks
> to a peer world), the workgroup will probably continue to receive input from
> people expecting VWRAP to be a VW interop protocol. 
[..snip..]

Morgaine,

I think that Meadhbh's standpoint is not that VWRAP shouldn't allow VW interop,
we just failed to understand eachother.

I think I now FINALLY start to understand what she's been trying to say,
so let ME try to give you a clear explanation:

The refusal to define "virtual world" is, imho, irrational and apparently
based on the fact that the MMOX effort failed because they couldn't get
an agreement on it's definition. Fearing that any attempt to define
it in this group would lead to a failure again, Meadhbh dogmatically
refused to even consider talking about it. A definition of the term
"virtual world" is taboo. Not rational, but lets just accept that
as a fact. After all, the solution is simple: use a different term!

I've seen some people the term 'grid', but also that isn't very
clearly defined (although not as much taboo).
A better term however is apparently "Region Domain".
"Region Domain" is defined within OGPX namely, and means something
along the way of:

* A collection of regions run by a single entity (in the trust model).

What WE consider a "single administration", or, for example,
the current participants like Linden Lab, or people running
a given VW/grid using OpenSim right now is as good as synonym
for "single entity in the trust model."

Therefore, your (and my) view of "virtual world", namely a
collection of regions run by a single administration, who obviously
can decide to use any arbitrary inter-world protocol, and therefore
which ALSO can be defined more technically by being set of regions
that define VWRAP endpoints at it's boundary, is the same as a
"region domain"! :)

Hopefully this clarifies things and I propose to start using
"region domain" instead of "virtual world", because the last term
is not usuable in a technical context without clear definition.

Most importantly, Meadhbh/Joshua et al ARE concerned with
allowing interop between different region domains and definitely
think that this is an important part of VWRAP.

The main difference, I think, is that they are mostly interested
(from their background with LL) in a tight trust model where
there is no room for "stealing content" without legal consequences
while you and me, and Cable Beach, think that the VWRAP universe
will benefit most from a nil trust model. We'll just have to
make sure that VWRAP will allow as much as possible with as
little trust as possible. I think a win-win solution is definitely
possible here.

---

From: Morgaine <[email-masked]>
Date: Thu, 3 Sep 2009 04:28:03 +0100

[This discussion should now be regarded as post charter agreement, I
believe.]

> that define VWRAP endpoints at it's boundary, is the same as a
Carlo, unfortunately that interpretation is not correct. :-))))

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.

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.

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

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.

Also note that an RD cannot provide the full set of VWRAP endpoints, but
only those endpoints appropriate to the region services, proxying aside.
Instead, it is the *VW* that provides the full set of VWRAP endpoints, but
only a subset of those are contained in or provided by the RD.  VW != RD.

And this is why the VWRAP protocol as currently defined by our old reference
OGP documents cannot possibly interoperate between VWs because it defines
interoperation between one VW and one or more regions or Region Domains, and
not between one VW and another VW, nor between two RDs.  If VWs and RDs were
indeed identical then there would be no issue, but I doubt that Linden Lab
wishes to demote Second Life to the status of an RD only. ;-)

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.

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

Morgaine.

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

---

From: Carlo Wood <[email-masked]>
Date: Fri, 4 Sep 2009 21:58:22 +0200

On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote:
> 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.

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

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

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

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

---

From: Charles Krinke <[email-masked]>
Date: Sat, 5 Sep 2009 11:29:10 -0700 (PDT)

In OpenSim, we use a different set of acronyms for similar things. We dont have AD's or RD's, but we do have UGAIM and Region Servers.

In our case, UGAIM stands for the array of five servers known as the Userserver, Gridserver, Assetserver, Inventoryserver and Messagingserver.

Certainly, I can imagine analogs as our Userserver is very similar to an AD and our Gridserver is very similar to an RD, so I think we can get there from here, but I also see nomemclature as being a continuous source of frustration for all concerned for some time.

I guess there is no way out of this, so I would say, lets just move forward. Eventually, we will get down to the nitty gritty of logins across different grids from, for instance, SecondLife to OSGrid or ReactionGrid and back. In fact, as I recall, we have already proven OGP from both the SecondLife betagrid to an IBM SecondLife grid, from the SecondLife betagrid to an IBM OpenSim standalone and from the SecondLife betagrid to some regions on OSGrid, so I know we can get there from here.

Its always an experience traversing the floors on the "Tower of Babel" when we do one of these things and I find that just moving forward and getting into the details helps to avoid spending years getting too hung up on the nomemclature. 

So, good job in getting to this point and I would say "Full speed ahead and darn the torpedoes as we try not to get too hung up on the TLA's and FLA's".

Charles

p.s. TLA, an ambiguous term means either ThreeLetterAcronym or FourLetterAcronym.

p.p.s FLA, another ambiguous term means either FourLetterAcronym or FiveLetterAcronym

p.p.p.s Acronyms "love" conversations on the "Tower of Babel"

________________________________
From: Carlo Wood <[email-masked]>
To: Morgaine <[email-masked]>
Cc: [email-masked]
Sent: Friday, September 4, 2009 12:58:22 PM
Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01

Exact same argument.

[...]

---

From: Carlo Wood <[email-masked]>
Date: Sun, 13 Sep 2009 13:18:17 +0200

This one (the one I reply to now).

---

From: Morgaine <[email-masked]>
Date: Mon, 14 Sep 2009 06:43:06 +0100

Carlo asked for detailed comments on the below, so here goes. :-)

> Well... that is purely semantic. It is a way to define VW, but not one that

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

> virtual world, like SL or OG: A Region Domain (RD) and an Agent Domain

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.

> will need to provide both: an RD *and* an AD, otherwise they don't have a

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 policies which they are not going to change on interop.

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

> Or do you think it would make most sense in THIS case to speak of a single

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.

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

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.

The contention that we don't know what "virtual world" means is just plain
bizarre.  I don't know of any VW operator who doesn't know what their world
is.  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.

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

In one of my first posts about this topic I stated that "virtual world"
> should

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

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".  But that's not how it is currently structured --- RDs
are 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.

> within

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

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

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

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

> >     become similar to those of Second Life.

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.

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

> web of trust/non-trust between them that makes the concept of "virtual

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

> possible

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.

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

> within
> possible

---

From: Carlo Wood <[email-masked]>
Date: Mon, 14 Sep 2009 10:44:20 +0200

On Mon, Sep 14, 2009 at 06:43:06AM +0100, Morgaine wrote:
> 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
> 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.

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

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:

OG runs another RD and AD, called RD2 and AD2.

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

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

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

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

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

> 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
> 
> 
> 
> 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.
> 
>  
> 
> 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.
> 
> example), but post-interop this may no longer be possible --- it depends on the
> implementation.  No doubt we will visit this issue within VWRAP.]
>  
> 
> 
>     >     Is Second Life a virtual world?  Undoubtedly.  Is Second Life just a
>     Region
> 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
> 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.
> 
> 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.
> 
> 
> 
> 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.
>  
> 
> 
> 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". 
> 
>  
> 
>     [...]
> 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.
> 
> 
> 
> 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.
> 
>     >     Is Second Life a virtual world?  Undoubtedly.  Is Second Life just a
>     Region
>     >     Is OSgrid a virtual world?  Undoubtedly.  Is OSgrid just a Region
>     Domain

---

From: Morgaine <[email-masked]>
Date: Wed, 30 Sep 2009 01:51:13 +0100

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:
>
>> >     > 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
>> >     virtual world, like SL or OG: A Region Domain (RD) and an Agent
>> Domain
>> >     (AD).
>> >
>> >
>> >     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.
>> >
>> AD.
>> >     I think this is what Infinity means when she says that "virtual
>> world"
>> >     cannot
>> >     not as clear as the current situation (no interop) or the above
>> example
>> >     (100%
>> >     interop).
>> >
>> >
>> virtual
>> >     be considered to be the Region Domain (although I didn't use that
>> term at
>> >     the
>> >     cases of abuse and griefing etc: if anyone annoys some other user,
>> or
>> >     breaks
>> >     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
>> >     > 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
>> just
>> expected.
>> >     >     Domain (assuming it were implemented using VWRAP)?  No, of
>> course
>> >     not, SL
>> virtual
>> >     > So you see, the idea that has been floated which claims that "VW
>> == RD"
>> >     is
>> >     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
>> meaningful
>> >     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.
>> >
>> >
>> >     > 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
>> >     > VW-RD relationship that has been the crux of the "no VW interop"
>> issue.
>> >     For
>> >     You can about peering with just two RD's and one AD, or one RD and
>> two
>> >     AD's.
>> >
>> >
>> between
>> >     > 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
>> wording
>> >     > 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
>> >     virtual world, like SL or OG: A Region Domain (RD) and an Agent
>> Domain
>> >     (AD).
>> >
>> >     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.
>> >
>> >     I think this is what Infinity means when she says that "virtual
>> world"
>> >     cannot
>> >     not as clear as the current situation (no interop) or the above
>> example
>> >     (100%
>> >     interop).
>> >
>> >     be considered to be the Region Domain (although I didn't use that
>> term at
>> >     the
>> >     cases of abuse and griefing etc: if anyone annoys some other user,
>> or
>> >     breaks
>> >     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
>> >     > 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
>> >     >     Domain (assuming it were implemented using VWRAP)?  No, of
>> course
>> >     not, SL
>> >     > So you see, the idea that has been floated which claims that "VW
>> == RD"
>> >     is
>> >     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
>> >     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.
>> >
>> >     [...]
>> >     > 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
>> >     > VW-RD relationship that has been the crux of the "no VW interop"
>> issue.
>> >     For
>> >     You can about peering with just two RD's and one AD, or one RD and
>> two
>> >     AD's.
>> >
>> >     > 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: Vaughn Deluca <[email-masked]>
Date: Tue, 29 Sep 2009 22:16:41 +0200

Carlo and Morgaine have above been involved in a very interesting discussion
about the nature of the (or *a*) virtual world.

Vaughn

On Mon, Sep 14, 2009 at 10:44 AM, Carlo Wood <[email-masked]> wrote:

> >     situation without any interop. Now "correct" might not be the correct
> word
> >     - heh.
> >     to "world administrations": the people running the REGION (domain) is
> the
> >     one
> >     > So you see, the idea that has been floated which claims that "VW ==
> RD"
> >     is
>  If
> >     > way, and it seems certain that communication services from multiple
> VWs
> >     will be
> they
> >     situation without any interop. Now "correct" might not be the correct
> word
> >     - heh.
> >     to "world administrations": the people running the REGION (domain) is
> the
> >     one
> >     > So you see, the idea that has been floated which claims that "VW ==
> RD"
> >     is
> >     > way, and it seems certain that communication services from multiple
> VWs
> >     will be

---

From: Joshua Bell <[email-masked]>
Date: Wed, 30 Sep 2009 09:10:13 -0700

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:

> 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
> 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
>> 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.
>>
>> 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
>> 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
>>> >     > The problem you see is that a virtual world is much more than
>>> just a
>>> >     Region
>>> >     Currently, without any interop, each administrative entity (or
>>> trust
>>> >     entity)
>>> >     reconsider if that conclusion is correct, because it is based on
>>> the
>>> >     current
>>> >     > a virtual world, or some might be implemented as external
>>> services
>>> >     offered by
>>> >     > operator.  In all cases however, the virtual worlds are defined
>>> by a set
>>> >     of
>>> >     I have to side with Infinity: you cannot define a virtual world
>>> that way
>>> >     and
>>> >     > Of course the situation could change as the protocol evolves.
>>>  For
>>> >     example,
>>> >     > merged because residents demand this.  This would start to take
>>> us into
>>> >     VW-VW
>>> >     > The problem you see is that a virtual world is much more than
>>> just a
>>> >     Region
>>> >     Currently, without any interop, each administrative entity (or
>>> trust
>>> >     entity)
>>> >     reconsider if that conclusion is correct, because it is based on
>>> the
>>> >     current
>>> >     > a virtual world, or some might be implemented as external
>>> services
>>> >     offered by
>>> >     > operator.  In all cases however, the virtual worlds are defined
>>> by a set
>>> >     of
>>> >     I have to side with Infinity: you cannot define a virtual world
>>> that way
>>> >     and
>>> >     > Of course the situation could change as the protocol evolves.
>>>  For
>>> >     example,
>>> >     > merged because residents demand this.  This would start to take
>>> us into
>>> >     VW-VW

---

From: Vaughn Deluca <[email-masked]>
Date: Wed, 30 Sep 2009 21:17:13 +0200

@Morgaine -- OK, i see now how your comments were intendend. Thanks for that
clarification.

@Joshua -- Yes, that seems to be a much more sensible way to organise
things. I was merely building on what Morgaine seemed to suggest,and it
turns out i was in error .  So it looks like we all agree here, good!

Vaughn