Subject: [ogpx] Virtual worlds versus the real world

From: Morgaine <[email-masked]>
Date: Mon, 5 Oct 2009 13:30:18 +0100

Given the recent rash of preoccupation with real-world attributes, I think
it needs stating that virtual worlds are immensely broader in scope than a
mere pixellated 3D re-enactment of the real world with all its historical
baggage and petty cultural issues.

Our interest is in enabling interop between worlds using our particular
protocol, not in prescribing the nature of worlds nor in proscribing others.

For those who have not before seen the topic addressed, I suggest you read
Henrik Bennetsen's useful summary at
http://slcreativity.org/wiki/index.php?title=Augmentation_vs_Immersion .
The topic of *augmentism* versus *immersionism* has been discussed in
immense detail over many years, and if a single article can be said to
capture the essence, Henrik's comes close.   If after reading this you are
still in denial about the separation of worlds, this positions you as an
augmentist, which is a highly coercive worldview.  Immersionists affirm that
all worlds are possible and separate and non-interfering, so their worldview
is inherently inclusive.

Supporting virtual worlds in all their diversity and generality requires a
broader approach than does a mere re-enactment of the physical world.  More
specifically, it requires an understanding that only a small subset of
virtual worlds reflect the real world, and that trying to force them all to
do so is out of place.

Morgaine.

---

From: "Dickson, Mike (ISS Software)" <[email-masked]>
Date: Mon, 5 Oct 2009 14:59:00 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Morgaine
Sent: Monday, October 05, 2009 7:30 AM
To: [email-masked]
Subject: [ogpx] Virtual worlds versus the real world

[snip]

For those who have not before seen the topic addressed, I suggest you read Henrik Bennetsen's useful summary at http://slcreativity.org/wiki/index.php?title=Augmentation_vs_Immersion .  The topic of augmentism versus immersionism has been discussed in immense detail over many years, and if a single article can be said to capture the essence, Henrik's comes close.   If after reading this you are still in denial about the separation of worlds, this positions you as an augmentist, which is a highly coercive worldview.  Immersionists affirm that all worlds are possible and separate and non-interfering, so their worldview is inherently inclusive.
Henrik's summary is indeed well written and a good synopsis.  I guess I feel like given the wide range of possible use cases for virtual worlds both models are "correct".   So nothing in the protocol should preclude either approach but IMO conversely the distinction is almost unimportant at the protocol level.  As long as there's a mechanism for the AD/RD to negotiate with the client the caps/constraints in play and a way to represent and visualize the in world content the VW content developer (which may be its users) should be free to evolve as appropriate for that VW context.

Mike

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Mon, 5 Oct 2009 22:17:20 -0700

this is definitely cool stuff, but fwiw, i disagree that the purpose
of this working group is to work on interop between virtual worlds.
MMOX is the place for those discussions.

--
   infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
         http://wiki.secondlife.com/wiki/User:Infinity_Linden

On Mon, Oct 5, 2009 at 05:30, Morgaine <[email-masked]> wrote:
> The topic of augmentism versus immersionism has been discussed in immense
> detail over many years, and if a single article can be said to capture the
> essence, Henrik's comes close.   If after reading this you are still in
> denial about the separation of worlds, this positions you as an augmentist,
> which is a highly coercive worldview.  Immersionists affirm that all worlds
> are possible and separate and non-interfering, so their worldview is
> inherently inclusive.
>
> _______________________________________________
> ogpx mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

---

From: Morgaine <[email-masked]>
Date: Tue, 6 Oct 2009 17:29:26 +0100

On Tue, Oct 6, 2009 at 6:17 AM, Infinity Linden (Meadhbh Hamrick) <
[email-masked]> wrote:

this is definitely cool stuff, but fwiw, i disagree that the purpos of this
> working group is to work on interop between virtual worlds.
>

We've just spent a week discussing multi-world deployments of VWRAP,
consisting of two virtual worlds W1 and W2 containing AD1/AD2, RD1/RD2, and
an agent A1 that travels between worlds, and we achieved more progress on
this deployment pattern last week than in the preceding 2 years of AWG.
Joshua has given us some excellent insights into the requirements of that
deployment pattern, culminating in wholesale agreement here --
http://www.ietf.org/mail-archive/web/ogpx/current/msg00451.html .

Consequently, we most certainly *are* working on interop between virtual
worlds, VWRAP-compatible ones naturally.  This has been decided and agreed
by the group repeatedly over the last several months, because it is a
deployment pattern that interests almost everybody in the group.  You many
wish to consult Joshua on this.

> MMOX is the place for those discussions.

MMOX is the place for discussions about worlds that cannot or do not wish to
interoperate via VWRAP.  We do not prescribe the kinds of worlds that can
use VWRAP, nor proscribe which worlds cannot.  If two worlds implement
VWRAP-compatible endpoints to VWRAP services, then they fall under the
banner of VWRAP.  It's not our business to forbid them.

(It's worth noting that this applies similarly to every other IETF
protocol.)

While it is common to use the shortcut "SL-like" to describe the worlds that
are relevant to us here, VWRAP also applies very strongly to Opensim-based
virtual worlds as well of course.  Yet, Opensim-based virtual worlds can
communicate through MXP and various other interop technologies that are not
VWRAP, and those styles of interop would not concern us here but be a
subject for MMOX.

This highlights vividly that the nature of the worlds that communicate is
not our concern.  Only their interoperation using VWRAP  is relevant to this
workgroup.

Morgaine.

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

---

From: Joshua Bell <[email-masked]>
Date: Tue, 6 Oct 2009 10:32:09 -0700

>> working group is to work on interop between virtual worlds.
(snip)

> worlds, VWRAP-compatible ones naturally.
>

FWIW, I read Meadhbh's comment as "...between different VW
technologies/types (as defined by protocol implementation)", so I don't see
a disagreement between these statements.

The distinction is between (1) attempting to define broad interop between
all possible VWs (so I can TP from SL to Webkins and visit my son's
creature) , and (2) defining basic operation of Agent/Region-style VWs with
a protocol that therefore enables interop between conforming
implementations.

Anyone want to take on the task of collecting all of the definitions of
"virtual world" that have been floated about, as an informational draft?

---

From: "Dickson, Mike (ISS Software)" <[email-masked]>
Date: Tue, 6 Oct 2009 17:39:53 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Joshua Bell
Sent: Tuesday, October 06, 2009 12:32 PM
To: [email-masked]
Subject: Re: [ogpx] Virtual worlds versus the real world

Anyone want to take on the task of collecting all of the definitions of "virtual world" that have been floated about, as an
informational draft?

Related, is there a pointer to the other informational documents that are relevant to VWRAP (like the OGP stuff for instance)?  There’s nothing on the VWRAP page or wiki on the IETF site.  It’s clear I could do with some background reading on what’s come before.  I see references to it in other posts.

Mike

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Tue, 6 Oct 2009 11:44:28 -0700

the intro doc is a good place to start.
http://tools.ietf.org/html/draft-hamrick-ogp-intro-00

i've got a LOT of feedback that still needs to be incorporated into a
new rev though.

were you looking at http://trac.tools.ietf.org/wg/vwrap/trac/wiki/ ? i
know josh said that he's in the process of putting some content up
there.

-cheers
-meadhbh

On Tue, Oct 6, 2009 at 10:39, Dickson, Mike (ISS Software)
<[email-masked]> wrote:
> "virtual world" that have been floated about, as an
>
> informational draft?
>
>
>
> Related, is there a pointer to the other informational documents that are
> relevant to VWRAP (like the OGP stuff for instance)?  There’s nothing on the
> VWRAP page or wiki on the IETF site.  It’s clear I could do with some
> background reading on what’s come before.  I see references to it in other
> posts.
>
>
>
> Mike
>

---

From: "Dickson, Mike (ISS Software)" <[email-masked]>
Date: Tue, 6 Oct 2009 18:57:05 +0000

there.

-cheers

-meadhbh

--

Yep.  I did find the charter just now as well so it should be easier for others to find these references.  I don't recall seeing it before but I'm sure I just missed it.    Now for some reading....

Mike

---

From: Morgaine <[email-masked]>
Date: Tue, 6 Oct 2009 20:01:48 +0100

Bringing up non-VWRAP virtual worlds here only to reject them is just a
straw man that is occasionally trotted out for no reason that I can
identity, and it derails discussions.

Nobody in this group discusses any virtual worlds except those which are
compatible with the VWRAP model and VWRAP service endpoints, except possibly
a newcomer who might need to be brought up to speed.  In that case then of
course we help them out.

At other times it amounts to a tactic for dismissing an argument, and I'm
going to make sure that I draw attention to it if it seems to be done on
purpose.

Morgaine,

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

On Tue, Oct 6, 2009 at 6:32 PM, Joshua Bell <[email-masked]> wrote:

>> this is definitely cool stuff, but fwiw, i disagree that the purpos of
>>> this working group is to work on interop between virtual worlds.
>>>
>>
> (snip)
>
>

---

From: Joshua Bell <[email-masked]>
Date: Tue, 6 Oct 2009 13:06:27 -0700

I made the trac/wiki updates in response to Mike's inquiry; your searching
skills are not at fault!

Suggestions for other updates to the wiki are welcome. I cribbed the top
content to include from some other WGs.

On Tue, Oct 6, 2009 at 11:57 AM, Dickson, Mike (ISS Software) <
[email-masked]> wrote:

> Yep.  I did find the charter just now as well so it should be easier for
> others to find these references.  I don't recall seeing it before but I'm
> sure I just missed it.    Now for some reading....
>
>
>
> Mike
>
>
>
>
>

---

From: David W Levine <[email-masked]>
Date: Tue, 6 Oct 2009 17:45:09 -0400

>From this mornings AWGroupies discussion, I want to try and pin down
some terminology:

I've been saying "Policy happens at services." I think I need to make
this more precise, so:

The current model grounds out in Web Services and streams of "events"
(Notionally delivered in UDP or over an event queue in the current
discussions) So.. From the bottom up:

Web Services End point (URI + the LLIDL (encoded on LLSD, Binary, or
JSON) which defines a web service capability A set of "events" which
are notionally short, asynchronous and delivered quickly.. (How much,
content flows in this form is at yet unclear)

Web service endpoints cluster into set of services, which describe the
bulk of the functionality in the specifications. (Loosely, this tends
to be the Authentication Services, Region Service, Inventory services,
Asset Services and IM services) There is nothing in this model which
dictates how to implement or deploy these services behind the defined
interfaces

Laid over this lose description we have had the notion of "domains" in
particular, the Agent and Region domains. The current (somewhat
backlevel) intro document says: 

   The Open Grid Protocol assumes a division between systems offering
   user / avatar oriented services and systems offering virtual world
   simulation services.  OGP was designed to support the case where the
   administrative authority for agent services is distinct from the
   authority providing simulation and object persistence services.  The
   administrative authority of the former group is termed the "agent
   domain" while the latter is termed the "region domain."  The protocol
   allows the agent domain and region domain to be distinct; in other
   words, a user's identity may be managed by one person or organization
   while the virtual world they inhabit may be simulated by hosts owned
   by a completely different organization.

Over the past few weeks, there has been a lot of discussion about the
possible deployment patterns people will support, and the last
definition of the split I have seen on the lists seems to be

that if it holds the Authentication and Agent ID services its an agent
domain, and if it holds the Virtual Presence services its a region
domain. This seems quite reasonable.

There is also the notion, that domains represent administrative
spans of control, and that services within a domain share policy. 

At the same time.. actual policy is mediated by service end
points. This is to say the moment we can actually apply policy is
when a remote service requests a capability, or invokes a capability
or (possibly) delivers an event or message to us on an asynchronous 
connection. 

I see two or possibly three bits of confusion here. I'm going to start
with the basic one, which has come up over the past week. 

People keep saying "Region Domain Decides" or "Agent Domain Decides"
or "The service consults the Agent Domain" I think this muddies stuff
because it promotes the domain to an active element, when the real
behavior is "A service endpoint is called, possibly with some special 
tokens,
possibly, with a negotiation ensuing and the service endpoint acts
according to its policy." 

Now, the service endpoint may well reside inside an administrative
domain, and may have its policy dictated by its deployer. But without
an active element, I don't think the domain "participates"

The second thing which concerns me is that we're sort of conflating
two useful ideas here. One, the split between authenticator and
holders of agents, and virtual spaces, and the other, a pattern of
common use in deploying services. I think this becomes increasingly
strained, as you look at regions interacting with multiple services,
and with services which fall outside of the agent/region split, and
yet belong to one or more administrative domains. 

So.. I am not suggesting we throw away these concepts, I am suggesting
that we look carefully at how we are tossing the word around, whether
we are overloading it, and whether we could better serve our
developing a shared understanding by being more rigorous, and more
careful about how we attack some of these concepts

- David Levine
~ Zha Ewry

---

From: Vaughn Deluca <[email-masked]>
Date: Sat, 10 Oct 2009 22:02:08 +0200

Does somebody have a suggestion were to start reading if i want to learn
about the use and meaning of a "Public Region Seed Cap"?
To put my question in context, i started with Davids layering document,
working on the details of deployment pattern 5.  I consulted the TP_draft_5,
and used the high level description in that as a guide for my thinking.
Looking at the details of the calls i stumbled over  "Public Region Seed
Cap". Before i start a random walk in the documentation,  a call for some
pointers here might save me some time.

-Vaughn

---

From: Vaughn Deluca <[email-masked]>
Date: Sun, 11 Oct 2009 09:03:34 +0200

I should like at the obvious places before asking... like the base document
-- sorry-Vaughn

---

From: Morgaine <[email-masked]>
Date: Sun, 11 Oct 2009 09:51:09 +0100

The beginning is undoubtedly a good place to start. :-)  So, let's start
reviewing this!

The first task before us is immediately apparent.  We need to do to this
document what we did to the charter in order to make it acceptable for
multi-world deployments --- in other words get rid of all occurrences of
"the virtual world" so that the specification can be applied to our multiple
virtual worlds.

Morgaine.

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

On Sun, Oct 11, 2009 at 8:03 AM, Vaughn Deluca <[email-masked]>wrote:

>>> I made the trac/wiki updates in response to Mike's inquiry; your
>>> searching skills are not at fault!
>>>

---

From: Vaughn Deluca <[email-masked]>
Date: Mon, 12 Oct 2009 00:55:51 +0200

I realise now I have been confused about the meaning of the Region Domain,
but your post clears up a lot for me.
Some of this has been voiced by others already, but here is my personal
view.

I think the notion of RD is very useful as a tool to specify *common* policy
for some regions.
Looking at the TP draft, its absolutely clear that the region is the
endpoint, and a rez cap will also point to the region. Yet, as you already
mentioned *behind* that interface, the region can get some of its policy
from a region domain "service".  Viewed like this the RD becomes a lookup
service for information that otherwise has to be duplicated in possibly a
lot if regions. The RD is not a *front*end containing the regions, but its a
*back* end service *used* by the regions, and the fact that some regions do
use this particular service places them de-facto *in* a that RD.

Since policy it outside the protocol, it is not  needed to specify how the
regions consults the RD policy "service". All of that interaction is hidden
behind the interface to the region, and it is up to the deployer of the
region to decide how to deal with this problem. However, if somebody feels
the need,  I have no objection to formalising the interaction in  *optional*
protocol steps, that the region can take to help it making policy decisions.

-Vaughn

---

From: Kari Lippert <[email-masked]>
Date: Sun, 11 Oct 2009 19:30:37 -0400

Any service request, invocation, message delivery, or other type of
communication attempt with either an AD or an RD will likely require
the presentation of some sort of credential. Policy is outside the
protocol as it is an implementation detail, but the protocol needs to
indicate what would be (minimal) credentials. Clearly we need more
than a notional idea of what that information entails. The policies
that determine how (or even if) the domain uses that information is
clearly up to the domain implementation and beyond the scope of the
protocol.

While we need to consider the types of things the domains might do so
that the protocol supports the transmittal of the appropriate
information, we are only specifying a format for communicating
information between the domains.  Unless I've missed some critical
point somewhere, I believe we can largely treat the domains as black
boxes and not worry their implementation or how they will use the
information they receive. We only need to understand what information
a domain would require to accept or react to a communication. True?

Kari

---

From: Vaughn Deluca <[email-masked]>
Date: Mon, 12 Oct 2009 08:19:48 +0200

Kari,

I think we should treat AD and RD separately, since they are not completely
similar in the way they are currently used. For now I like to stick to the
region domain. You wrote:

>I believe we can largely treat the domains as black boxes
>and not worry their implementation or how they will use the
>information they receive.

Yes, absolutely, in any case as far as the region domain is concerned. That
domain is only an instruments of policy and administration, and as such IMHO
completely out of scope of the protocol, so not only can we can treat it as
a black box, we could even completely forget about it in protocol terms, and
leave it up to the administrators to use it in whatever way they like,
behind the endpoints of the protocol.  That said, I *do* think the region
domain is a useful administrative concept, and an efficient way to implement
policy.  Given that fact, a case can be made that we should specify
something, if only to make clear how we view the concept can be used
effectively. I have no real desire to do so, but if we go that way, you re
right:

>We only need to understand what information a domain would require to
accept or >react to a communication. True?

Yes, i think so. Infinity gave 3 common ways to determine policy at the
bottom of this post:
http://www.ietf.org/mail-archive/web/ogpx/current/msg00541.html

>a. identity implies policy.
>b. authenticator implies policy.
>c. region metadata implies policy.

For the Region domain <-> Region service interaction,  option a. will work
perfectly. Since by definition all involved hosts are under the same
administration, the identity of the hosts (is indicated by host name or IP
address) is all that is needed to tell the domain it can trust the region
service. The content of the message exchange does not concern us. But if we
wished we could provide some examples along the lines Magnus and Infinity
suggested here:
http://www.ietf.org/mail-archive/web/ogpx/current/msg00492.html
where  they were discussing solutions for policy exchange between Agent
Domain and Region Service. I like the third case, were the interaction
follows the REST style.

-Vaughn

---

From: Kari Lippert <[email-masked]>
Date: Mon, 12 Oct 2009 06:27:00 -0400

Thanks - and I see from the posts that you referenced that the discussion
initiated in the AD <--> RD exchange. I think by "policy" what is meant is
"access rights", where if I can't answer the questions at the door, I can't
get in, and there may be a series of doors (I can stand in the vestibule, I
can get to the whole place, etc.) which I think is a combination of both
validating my identity (I am who I say I am) and then based on that identity
(and other information TBD) a region implements an access policy.

Regarding the three options, they should all be valid, as should the one we
haven't thought of. The easiest way to do that is with a bit of metadata in
the message header. Ultimately, I think that option a) is a bad idea since
IPs can be spoofed and hijacked. Option b) will require regions to keep
access control determination rules with potentially a third party (think
corporate espionage here).
Having a multi-level handshake seems the best idea. AD knocks (announcing
who I am), RD answers with metadata that enables the AD to determine if they
should/can proceed (this splits access control responsibility to both
parties and is powerful for age based content restriction). After seeing the
region's metadata the AD responds and, if it still wants access, presents
credentials that validate and indicate access "level" entitlement or being
sought. These messages should be of standardized format as specified in the
protocol but should not be restricted to a particular implementation (e.g.
REST).

The first contact (who I am) could be IP-based and the rest could just be
meaningless in a trusted domain situation. I can't envision (other than
through hacking) where this dual message handshake approach would cause
difficulty. It does give the RD a level of protection against inappropriate
access by the AD if the AD presented false credentials.

I have a bit of a problem with
For the Region domain <-> Region service interaction,  option a. will work
perfectly. Since by definition all involved hosts are under the same
administration,
which is probably my misunderstanding but I thought it was not necessary
that the RD and RS are under the same administration. It might be the
reference to the RS that's throwing me here.  I shall go read more....

Kari

On Mon, Oct 12, 2009 at 2:19 AM, Vaughn Deluca <[email-masked]>
wrote:
>> > *back* end service *used* by the regions, and the fact that some
regions
>> > do