Subject: [ogpx] OGPX WG draft charter, 2009-08-19 revision

From: Joshua Bell <[email-masked]>
Date: Wed, 19 Aug 2009 12:06:09 -0700

Howdy, folks.

Please find attached the latest draft of the proposed OGPX working
group charter. It incorporates feedback from many list and
face-to-face meeting participants. I think it's much closer to a
document that reflects the group consensus. There are a few points, we
may want to comment on separately:

1. The Name. We're still using the name OGPX in this draft. There has
been much discussion about other names, but we're not at consensus
yet. When we have agreement on a new name, it's easy enough to do a
search and replace in the document before submitting it for
consideration.

2. The Mailing List. Since we're not at consensus on a name yet, I
recommend we continue to us the [email-masked] mailing list for the
time being. When we've selected a new name, and after a working group
is approved, we can request a mailing list with the same name as the
working group. Again, we can just simply do a search and replace after
we have consensus on the name.

3. Description of the Group's Work. The first two paragraphs in the
description outline the scope of the working group's efforts. The
intent is to briefly describe the group's work to people outside the
working group and to "draw a line in the sand" regarding the
group's focus (so we don't experience scope creep.) This revision
defines terms as they are introduced. It was thought that this
approach made for easier reading than having a separate glossary
section.

4. Previous Work. Several people have commented that the charter
should be explicit regarding what documents we think we're starting
from. There is a list of related internet drafts in this draft to meet
this requirement.

5. Selecting a Transport. We added verbiage supporting the idea that
OGP is transport agnostic, and that we should somewhere describe how
OGP uses it's transports and which features it needs. It also lists
HTTP(S) as the protocol of choice for OGP messages.

6. Objectives. There is a list of specific objectives, defined in
terms of the problem domain. This list is thought to be roughly
complete at the moment. The process of adding objectives or
refactoring them after working group formation is non-trivial, but not
impossible. But, we should have agreement that the objectives are an
honest assessment of what we think we need to be working on.

7. Milestone Dates. The dates listed below may be a touch optimistic.
They may need to be massaged before the charter is submitted to the
IESG.

Here is the draft charter...

Working Group Name:

 Open Grid Protocol (OGPX)

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 Open Grid Protocol (OGP) for collaborative
3-dimensional virtual  worlds. The protocol  permits users to  interact with
each other while represented as "avatars," or digital representations of the
user. Within a  single virtual world, avatars exist in  at most one location
in a shared  virtual space. Conforming client applications  use the protocol
to  manipulate and move  the user's  avatar, create  objects in  the virtual
world,  interact with  other users  and their  surroundings and  consume and
create media and  information from sources inside and  outside their virtual
world.

Adjacent  locations in  virtual worlds  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  worlds may  consist of  regions  administered by
distinct organizations. Though these virtual worlds may be partitioned, they
remain "un-sharded;" all inhabitants and objects in a particular location in
the virtual  world may initiate  interaction with all other  inhabitants and
objects in that  location; and, service endpoint addresses  refer to at most
one location.  The state of the  virtual world is independent  of the client
applications that access it and may persist between user sessions.

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 for these virtual worlds,
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.

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 the
   virtual world,

 * an  application-layer  protocol  for  moving  a  user's  avatar  between
   adjacent and remote locations in the virtual world,

 * format descriptions for objects and avatars in a virtual world, and

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

Goals and Milestones:

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

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

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

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

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

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

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

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

 * June 2010 "Digital Asset Access" to the IESG as Proposed Standard

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

---

From: Morgaine <[email-masked]>
Date: Thu, 20 Aug 2009 01:05:17 +0100

Joshua,

This latest draft of the charter reads quite well, but it seems to be
missing an opening paragraph without which it is easy to misinterpret the
purpose of the workgroup and of the protocol.  That opening paragraph should
be something like this:

"This following work is aimed at defining a protocol for the integration of
individual regions into a single virtual world, and providing client
applications with access to these.  Interoperation between such a virtual
world and any other virtual world is outside of the scope of this protocol."

Without this introduction, it is easy to mistake OGPX for a VW interop
group.

After all, it follows nearly two years of discussions about interop between
worlds in the Architecture Working Group within Second Life, and it follows
6 months of work in the IETF MMOX group which was specifically targetting
interoperation between virtual worlds, and it follows a MMOX BoF in which
numerous participants (of which Lindens were only one) discussed interop
between worlds, and finally, it follows a decision to partition off a new
workgroup from MMOX so that its scope can be limited to interoperation
between SL-like worlds alone.

As it turns out, this new workgroup is not intending to address interop
between SL-like worlds at all, but only to integrate individual regions into
an existing world, which is extremely different.  As the new draft charter
describes well, OGPX is dedicated to growing walled gardens by addition of
new regions, and it is not concerned with interoperation between such walled
gardens.

That should be made immediately clear in the introduction --- it is I think
this group's main statement of scope, and I assume that our Area Directors
will encourage such clarity.  I recommend my opening paragraph above to
accomplish this.

On a more general note ...

In addition to making the above clear, what's going to be done about interop
between SL-like worlds?  There are already many SL-compatible Opensim-based
grids, and they currently believe that Linden Lab is defining OGP to
interoperate with them.  Clearly they are badly mistaken, but their need for
interop still remains.

Morgaine.

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

On Wed, Aug 19, 2009 at 8:06 PM, Joshua Bell<[email-masked]> wrote:
> _______________________________________________
> ogpx mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx
>

---

From: Infinity Linden <[email-masked]>
Date: Wed, 19 Aug 2009 17:38:04 -0700

hunh? if it makes sense for Linden to interoperate with OSGrid, and
both parties want to do it, i think it will happen irrespective of the
language in the charter. this work is not intended to be exclusively
"the protocol that people use to communicate with Second Life." it is
the protocol systems use to participate in a virtual world simulation.
it makes no statement about which virtual world participating systems
interact with.

by their nature, open protocols do not limit participation to fixed
systems. adding language to the charter that implies this is the case
is inappropriate and inaccurate.

---

From: Morgaine <[email-masked]>
Date: Thu, 20 Aug 2009 03:14:45 +0100

Infinity, Linden Lab's interoperation with OSgrid is a matter of company *
policy* which is not our business here.  We are involved only with defining
protocols, which are *mechanisms* that can be used to implement many
different policies.  You are suggesting that OGP provides no barrier to
interop apart from your own local policy, when this is clearly not true.

The OGP protocol is not being defined to permit any kind of interop between
virtual worlds *at all*.  As Joshua's latest charter describes clearly, it
is concerned only with the addition of single regions to a given virtual
world.  It does not address interop between two or more such virtual worlds
in any shape or form.

Your response therefore completely misses the point that OGP does not
provide any means for interop between worlds whatsoever, even when the world
operators desire it.  It is not a protocol for interoperation between
virtual worlds, even when these worlds are identical in architecture.  Being
clear is important in standards work.

Your last comment rejecting clarity in language escapes me at this time.

If OGPX does not intend to address interop between virtual worlds, that's a
conscious decision and is not something to hide.  A protocol that grows a
world by adding regions is still a useful protocol, despite providing no
interop between worlds.  Stating the goal clearly is to everyone's benefit.

Morgaine.

On Thu, Aug 20, 2009 at 1:38 AM, Infinity Linden <[email-masked]>wrote:

> >> Adjacent  locations in  virtual worlds  accessible by  this protocol
>  may
> >> be
> >> environment.  Such virtual  worlds may  consist of  regions
>  administered
> >> by
> >> remain "un-sharded;" all inhabitants and objects in a particular
> location
> >> in
> >> independent of transport, leveraging  existing standards where
> practical.
> >> It
> >> interactions as  well as client-server interactions. Though  the
> protocol
> >> is
> >> must be replicated in other transports and will define the use of
> HTTP(S)
> >> as

---

From: Infinity Linden <[email-masked]>
Date: Wed, 19 Aug 2009 19:25:06 -0700

morgaine. i am not rejecting language that increases clarity, but
language that enforces a false requirement. none of the implementers
involved in developing the draft charter share your belief that
deployers MUST NOT use OGP for interoperability between virtual
worlds. rather, it would be a policy decision, and not a protocol
decision.

On Wed, Aug 19, 2009 at 7:14 PM, Morgaine<[email-masked]> wrote:
> Infinity, Linden Lab's interoperation with OSgrid is a matter of company
> policy which is not our business here.  We are involved only with defining
> protocols, which are mechanisms that can be used to implement many different
> policies.  You are suggesting that OGP provides no barrier to interop apart
> from your own local policy, when this is clearly not true.
>
> virtual worlds at all.  As Joshua's latest charter describes clearly, it is
> concerned only with the addition of single regions to a given virtual
>> >> each other while represented as "avatars," or digital representations
>> >> of
>> >> the
>> >> world,  interact with  other users  and their  surroundings and
>> >>  consume
>> >> and
>> >> explicitly partitioned  into "regions"  to facilitate the
>> >>  computational
>> >> and
>> >> the virtual  world may initiate  interaction with all other
>> >>  inhabitants
>> >> and
>> >> independent  of transport,  early interoperability  trials used
>> >>  HTTP(S)
>> >> for
>> >>  * February 2010  "Guidelines for  Host Authentication" to  the IESG
>> >>  as
>> >> an
>> >>    Informational RFC
>> >>
>> >>  * February  2010 "Client  Application Launch  Message"  to the  IESG
>> >> as
>> >>  an
>> >>   Informational RFC
>> >>

---

From: Morgaine <[email-masked]>
Date: Thu, 20 Aug 2009 04:03:45 +0100

On Thu, Aug 20, 2009 at 3:25 AM, Infinity Linden <[email-masked]>wrote:

> none of the implementers involved in developing the draft charter share
> your belief that *deployers MUST NOT use OGP* for interoperability between
> virtual worlds. rather, it would be a policy decision, and not a protocol
> decision.
>
>
Who wrote "*deployers MUST NOT use OGP"* which you then proceed to reject?
I did not, and straw men misrepresentations do not help in this discussion.

More importantly, you are avoiding the central point that *OGP cannot be
used* to provide interoperability between virtual worlds, because it does
not define this case.  It defines only how a separate region can be added to
a given virtual world, and not how two such worlds can interoperate.

The claim "*it would be a policy decision, and not a protocol decision*" is
false, because OGP does not provide for any alternative.

Morgaine.

On Thu, Aug 20, 2009 at 3:25 AM, Infinity Linden <[email-masked]>wrote:

> > On Thu, Aug 20, 2009 at 1:38 AM, Infinity Linden <[email-masked]
> >
> > wrote:
> >>
> >> On Wed, Aug 19, 2009 at 5:05 PM, Morgaine<
> [email-masked]>
> >> wrote:
> >> > Joshua,
> >> >
> >> > "This following work is aimed at defining a protocol for the
> integration
> >> > of
> >> > between SL-like worlds at all, but only to integrate individual
> regions
> >> > into
> >> > describes well, OGPX is dedicated to growing walled gardens by
> addition
> >> > of
> >> > interoperate with them.  Clearly they are badly mistaken, but their
> need
> >> > for
> >> > interop still remains.
> >> >
> >> >
> >> > Morgaine.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >> 3-dimensional virtual  worlds. The protocol  permits users to
>  interact
> >> >> with
> >> >> distinct organizations. Though these virtual worlds may be
> partitioned,
> >> >> they
> >> >> objects in that  location; and, service endpoint addresses  refer to
> at
> >> >> most
> >> >> environment, its  contents and its  inhabitants. It is an
>  application
> >> >> layer
> >> >> non-real-time messages. The working group will define specific
> features
> >> >> that
> >> >>  * an application-layer protocol for  establishing the user's avatar
> in
> >> >> the
> >> >>    virtual world,
> >> >>
> >> >>  * October 2010  "Foundational Concepts and Transport  Expectations"
> to
> >> >> the

---

From: Carlo Wood <[email-masked]>
Date: Thu, 20 Aug 2009 16:07:33 +0200

>  * an  application-layer protocol  for identifying  agents,  and requesting

This speaks of "a virtual world", which refering back to the introduction
seems to define that there are more than one virtual world possible,
and hence the phrase "the virtual world" seems to refer to a single virtual
world like Second Life (explicitely excluding open grid virtual worlds),
or vica versa.

Therefore, the "foundational component":

states that support will be provided for "teleporting" between regions
of a single virtual world, but explicitely omits "teleporting" between
different virtual worlds.

I'd like to know, too, why there is no mention of support for
interop like teleporting (and sharing inventory) between DIFFERENT
virtual worlds.

Someone very clearly has to state what is the intent here.
Thanks,

-- 
Carlo Wood <[email-masked]>

---

From: Carlo Wood <[email-masked]>
Date: Thu, 20 Aug 2009 16:18:35 +0200

I think that what Morgaine is trying to say is that
if Linden Lab's official (or hidden) policy is to NOT
interop with other virtual worlds, then they are not
the right party to trust when it comes to defining
a protocol that most, if not all, other parties DO
want to support interop.

Since it seems, at this point, that the policy of
LL will prohibit interop in the future between
SL and other grids, there is a lack of trust right now;
and as a result of that lack of trust, a very clear
statement about the intent of the OGPX (as opposed to LL)
about interop MUST be part of this draft.

Personally, I will reject any protocol that doesn't
make it a priority to concentrate on interoperability
(such as sharing LM's and teleporting). So, instead
of adding a paragraph that clearly states that the
objective of OGPX is to not support interop, I'd rather
see a paragraph added that clearly states that it
IS to support interop.

The keyword here being "clearly". That is certainly
not the case at the moment.

---

From: Meadhbh Siobhan <[email-masked]>
Date: Thu, 20 Aug 2009 10:54:28 -0700

Are you seriously suggesting that Linden Lab should not participate in
the development of an open virtual worlds protocol? wha?

We originally wanted to have a working group where we could resolve
issues that separate different virtual worlds protocols. That group
was MMOX, and at the BoF we couldn't even get agreement as to what the
term "interoperable" meant.

Because we could not get agreement, this effort (OGPX) was initiated.
Our objective is NOT to define a protocol that encompasses every
existent virtual world. It is to produce a protocol that may be used
by deployers to produce one, two or many distinct virtual worlds.
Deployers would then get to decide which virtual worlds they wish to
interact with. They may also choose to provide access to some or all
of their "virtual real estate" to other participants through a
federation scheme. This latter use case is considered the most common
use case, because it allows virtual worlds deployers to share part of
their world without requiring them to share ALL of their world.

Morgaine has several times mentioned she does not agree with the
approach we are taking. I do not apologize that those of us who
organized the MMOX and OGPX BoFs have requirements different from
hers. Nor do I apologize for taking the "let's boil the ocean one
thimble at a time," approach. At the end of the day, there are people
interested in deploying open virtual worlds, that are implemented
using an open protocol. If people wish to participate constructively
in this effort with us, we will participate with them. If people wish
to discount the experience of over six years of deploying virtual
worlds, and a business model that DEPENDS on providing services to
others, they can participate in other standardization efforts.

-Cheers
-Meadhbh / Infinity

---

From: Meadhbh Siobhan <[email-masked]>
Date: Thu, 20 Aug 2009 11:01:06 -0700

and to your point about landmarks and teleport.

teleporting between points in the virtual world, even if the origin
and destination are managed by different administrative domains has
always been part of the protocol proposal. we're not taking that out.

sharable landmarks haven't been explicitly mentioned, but we do
require a way to uniquely address locations in a virtual world
(otherwise how do you represent where you're teleporting too?) there's
been a lot of discussion about using URLs to uniquely identify
regions. If you added an offset from the middle of the region to the
region's URL, that would be the beginning of a landmark.

hmm... i don't think we've explicitly mentioned that regions have a
bounding surface and an origin, but lemme put that on the list of
things to add to the spec.

-cheers
-meadhbh

---

From: Meadhbh Siobhan <[email-masked]>
Date: Thu, 20 Aug 2009 11:11:26 -0700

right. we're supposed to be using "a" virtual world instead of "the"
virtual world. lemme change that.

i don't know if we're supporting teleporting between radically
different virtual worlds like WoW and Second Life. But teleporting
between two virtual worlds that are both using OGP is not outside the
realm of possibility, and is a use case that has recently been brought
up in discussions about solutions like Sametime 3d and Linden's yet to
be named "behind the firewall" solution.

However... the protocol assumes the existence of a virtual world whose
different simulation regions MAY be administered by distinct
organization entities. That is, you might have one virtual world where
half the land is managed by IBM and the other half by Linden. Or, you
might have a virtual world where each region is administered by an
individual. Or, you might have a virtual world where you own all the
land. We're not defining the ownership / administration policy in
terms of who owns what, but to say "it's possible for each region and
each agent host to be owned / operated by a different
organization/individual, so don't make ANY assumptions that the peer
you're talking too is implicitly trusted."

Which is my way of saying... teleporting AND region crossings are
supposed to be covered by the protocol.

We put it in the charter in with the text: "Such virtual  worlds may
consist of  regions  administered by
distinct organizations." If the implications of that sentence aren't
clear, let's make it clearer.

do you think we should add something like "and avatars can walk across
administrative boundaries or teleport across them." ?

---

From: Morgaine <[email-masked]>
Date: Thu, 20 Aug 2009 21:19:54 +0100

Meadhbh is once again misrepresenting people:

> the development of an open virtual worlds protocol? wha?

No, Carlo did not suggest that.  Carlo simply asked for an answer on whether
OGP would also cover interop between more than one virtual world.  Joshua's
latest group charter does not list such communication in the scope of OGPX,
and therefore Carlo's question is a good one.

 I have also been misrepresented, but that is of no matter compared to
getting the scope of OGPX clarified cleanly and openly, so that we know
exactly what the protocol will be specified to do and what it will not
address.

Morgaine.

---

From: Infinity Linden <[email-masked]>
Date: Thu, 20 Aug 2009 13:42:14 -0700

morgaine, let's let carlo speak for carlo. -thx

On Thu, Aug 20, 2009 at 1:19 PM, Morgaine<[email-masked]> wrote:
> On Thu, Aug 20, 2009 at 6:54 PM, Meadhbh Siobhan <[email-masked]>
> wrote, in answer to Carlo:
>>
> On Thu, Aug 20, 2009 at 6:54 PM, Meadhbh Siobhan <[email-masked]>
> wrote:
>>

---

From: Morgaine <[email-masked]>
Date: Thu, 20 Aug 2009 21:42:53 +0100

On Thu, Aug 20, 2009 at 7:01 PM, Meadhbh Siobhan
<[email-masked]>wrote, in answer to Carlo Wood:

> always been part of the protocol proposal. we're not taking that out.

That was not Carlo's point.  Carlo asked about landmarks and teleports
*between
virtual worlds*, so stating that you're not taking them out from within a
single world is not answering his question.

The question being asked is a very simple one.  I do not understand why a
clear answer is not being given.

This is a matter of huge importance to the large number of SL-compatible
open grids that already exist, with more appearing regularly.  It needs to
be clearly stated whether mechanisms for interop between SL-compatible
worlds will be within the scope of the OGPX group, or not.

Defining our scope is our primary task at this time.  This question cannot
be dodged.

Morgaine.

---

From: Infinity Linden <[email-masked]>
Date: Thu, 20 Aug 2009 14:06:50 -0700

morgaine. flip back up in the thread where we talk about teleport and
landmarks. it's the message that begins with "and to your point about
landmarks and teleport"

i think we've also very clearly responded to the question, "do you
support interaction between virtual worlds in addition to interactions
within a single virtual world?" the answer is yes, because the
protocol defines the mechanism for communicating between hosts, not
the policy of "you should only communicate between hosts supporting
the same virtual world."

we do not explicitly call it out as being supported for the same
reason we do not explicitly say "you can only have red avatars on the
'red avatars only grid.'" that is, this is a POLICY decision. the same
protocol can carry information about the "red avatars only grid" as
well as other virtual worlds.

i would argue that intentionally calling out detailed use cases in the
charter; use cases that do not violate the wording of the charter, may
imply that use cases that are not detailed in the charter are
explicitly out of scope. Further, if we started enumerating use cases
in the charter, some might feel it was appropriate to introduce
prohibitions against other use cases in the protocol itself.

the intent of this group is to work on a protocol that will enable
open virtual worlds. the primary focus is to define the interaction
between components in the same virtual world and between external data
sources and the virtual world, but it does not preclude work on
world-to-world interactions where group participants believe such use
cases are important and practical. we do not explicitly call out this
focus because it is one of policy; our job is to define the protocol
and processing expectations, not tell deployers what features their
virtual world should support or who should be allowed to participate.

-cheers
-meadhbh

On Thu, Aug 20, 2009 at 1:42 PM, Morgaine<[email-masked]> wrote:
> On Thu, Aug 20, 2009 at 7:01 PM, Meadhbh Siobhan <[email-masked]>
> wrote, in answer to Carlo Wood:
>
> between  virtual worlds, so stating that you're not taking them out from
> within a single world is not answering his question.
>
> On Thu, Aug 20, 2009 at 7:01 PM, Meadhbh Siobhan <[email-masked]>
> wrote:
>>

---

From: Joshua Bell <[email-masked]>
Date: Thu, 20 Aug 2009 15:59:13 -0700

> world like Second Life (explicitely excluding open grid virtual worlds),

Ah, here's the crux of the problem - terminology. The protocol suite
we're envisioning talks about agents and regions, not about world or
worlds.

If you think of a set of regions under the control of one
administrative domain as being a "world", then depending on the
policy, then you could see the protocol as enabling interop between
"worlds".

However, we (the folks banging on the charter) don't believe (at this
point!) that such a deployment pattern concept needs to be either
explicitly described in the charter or is implicit in the protocol
itself.

Once you have an agent domain/region domain split, the concept of
"world" is much fuzzier. If "world" is the set of all locations an
avatar can visit, then multiple region domains create the "world" and
thus it is conceivable (modulo policy) that all services that
implement OGP region services are part of one big "world".

By analogy, the set of all publicly available sites that implement
HTTP could be called "the Web" - there is only one "web" even though
parts are blocked from access by policy (site policy, user policy,
government policy, etc). That doesn't preclude intranets. The analogy
isn't perfect by any means, however. And I don't think we're trying to
say "world" is the same as "web" intentionally - it just means that at
a protocol level, "world" isn't well defined.

I believe (but I'm not an active user), that in "Grid" mode, a
collection of OpenSims under distinct administrative control play
together to form a coherent "world"; they share some services but not
others, and users have a relatively seamless experience. (Please jump
in and correct me, OpenSim peeps!)

Another wrinkle in the terminology: it's easy to imagine that a large
VW provider like Linden Lab could, purely for administrative purposes,
split the VW service across both multiple agent and region domains. I
can imagine separate region domains being used purely for scale (e.g.
limiting the number of hosts per region domain), real-world geography
(e.g. region domains don't span colos), and so forth. Similar
divisions might occur for agent domains. Policy would dictate access;
in the cases listed above, I would imagine that it would be completely
transparent to users which agent domain/region domain they associated
with or in. In this scenario, referring to the collection of multiple
region domains as multiple "worlds" would be confusing to the end
user.

So... I wouldn't get hung up on it. From a protocol level, we need to
support interop between regions under distinct administrative control,
but we don't need to be explicit about it. That said, Zha's take on
deployment patterns will be critical for making sure we're addressing
the real world scenarios.

Now that I've said all of this - does anyone have concrete suggestions
for refining the charter text?

---

From: Joshua Bell <[email-masked]>
Date: Thu, 20 Aug 2009 15:59:43 -0700

Re-reading my post, let me clarify something:

* We haven't been explicit about a definition of "world" or "worlds"
and how that maps to regions and administrative domains, and I do not
think we need to. Even stronger, I think doing so would have negative
consequences.

* We should be explicit in the charter that we're talking about
protocol use that may span administrative domains. If that isn't clear
enough, we should update the charter text. Suggestions welcome.

---

From: Joshua Bell <[email-masked]>
Date: Thu, 20 Aug 2009 16:00:33 -0700

Ugh, I just realized that my last several posts were private replies, not
reply-all messages. D'oh. Resending, but some context may be lost.

On Thu, Aug 20, 2009 at 1:42 PM, Morgaine <[email-masked]>wrote:

> On Thu, Aug 20, 2009 at 7:01 PM, Meadhbh Siobhan <
> [email-masked]> wrote, in answer to Carlo Wood:
>
> That was not Carlo's point.  Carlo asked about landmarks and teleports *between

I think we all agree (ahem, have rough consensus) on this statement:

* OGP should support teleports between regions that are part of different
administrative domains, when policy permits.

I think the hard part is that "world" is not a well defined concept in OGP.
We can't say "OGP should support teleports between different worlds" when we
can't define "world". I maintain that "world" is not a technical term, just
as the HTTP RFCs do not define "web". (The term is used in the preamble, but
not defined.) Personally, I think the term "world" will come to mean
something I'll hand-wavily call policy-clusters-of-agent/region-domains,
meaning groups of places avatars can easily (not necessarily freely)
traverse; some "worlds" will span multiple administrative domains, some
won't. But I don't want to try and define that now!

> worlds will be within the scope of the OGPX group, or not.

Would it help if we added a parenthetical "(which may be described as one or
more virtual worlds)" or something somewhere in the charter? IMHO, it does
not add technical detail to the charter, but if it makes it more appealing
or comprehensible to those not embedded in the process, it's worthwhile.

> Defining our scope is our primary task at this time.  This question cannot

Agreed. And it may be that we're being too precise/pedantic in the charter
text.

---

From: Meadhbh Siobhan <[email-masked]>
Date: Thu, 20 Aug 2009 16:09:38 -0700

the charter already says "Such virtual worlds may consist of regions
administered by distinct organizations."

i think we used the term "virtual world(s)" to help contextualize the
effort. if the term is confusing, we could use "region" and "region
domain" and "region host / simulator" in the body of the charter.

though i would argue that the term "virtual world" should appear
somewhere early in the description of the working group so people
reading the charter will have some context. (Dave C. and others have
argued persuasively out that peeps from outside the VW/OGP community
won't automatically know that "OGP" means "virtual worlds protocol."
consequently, i think "region domain" won't automatically translate to
"part of a virtual world" unless explicitly mentioned.)

-cheers
-meadhbh

On Thu, Aug 20, 2009 at 4:00 PM, Joshua Bell<[email-masked]> wrote:
>> <[email-masked]> wrote, in answer to Carlo Wood:
>>

---

From: Joshua Bell <[email-masked]>
Date: Thu, 20 Aug 2009 16:36:20 -0700

Right - and I'm not opposed to using "virtual world(s)" terminology at all,
and agree it's critical to use that phrase so people outside the current
effort can make sense of what we're talking about.

So... I guess we come back to: given the current draft (and specifically
phrasing such as what Meadhbh higlights below), and without rigorously
defining what a "world" for all time... are we missing something to make it
clear that crafting something that enables teleporting from Foo's World to
Bar's World (policy permitting) is entirely within the goals of this effort?

On Thu, Aug 20, 2009 at 4:09 PM, Meadhbh Siobhan
<[email-masked]>wrote:

> > On Thu, Aug 20, 2009 at 1:42 PM, Morgaine <

---

From: Carlo Wood <[email-masked]>
Date: Fri, 21 Aug 2009 01:50:51 +0200

I'm feeling a bit dizzy of all the terminology :p
And, I'm still not sure if I understand it: it's still unclear.

Perhaps we'll just have to use hard examples on this mailinglist
first to make things clear, and only then we can think about
ways to achieve the same clearness in more abstract terms.

---

1) Right now, there is 'Second Life', and there are several
   opensim worlds that are very very like Second Life. Never I
   am refering to or even thinking about WoW.

2) Right now, therefore, we can call those entirely separated
   administrative domains, different "worlds", as has been
   done in the past several years.

   We might want to change that terminology, but let me use
   "world" to refer the currently existing different worlds,
   where "Second Life" is one of them and -say- "opengrid X" is
   another.

3) These worlds are separated in EVERY way:
   - You cannot teleport bewteen them.
   - There is no notion of Landmarks that refer outside a given world.
   - You cannot send IM's to avatars in the other world.
   - You cannot access any asset (or inventory) of another world.

4) I thought that the OGPX effort had as goal to change this
   *complete* separation.

However, if we want to make these limitations vanish then they
cannot be used to DEFINE what (separate) world mean... Hence,
the term becomes undefined and unclear (in the future).

But-- there are things that define the "worlds" that do NOT
want to change:

* The administration is entirely different:
  - A TOS only applies to one world.
  - An Abuse Report only has effect within one virtual world.
  - A ban by such an administration only affects their own world.

I think that most ideal situation would be when it is entirely
and only the user that decides if they want to visit another world,
completely independent of which world that is (as they can now
by simply logging out, and logging in elsewhere).

This CAN be supported; but it would mean to both region domain
AND agent domain (in order to switch completely between administrations etc).

Of course, viewers could simply support a seemless logout and login
elsewhere, but we (the users) want support for this in the format
of LandMarks, so that it is relatively easy to invite someone to
that other place, in another world.

Trivially, however, two major annoyances arrise with such a simple sheme:

* The need to create a new account (avatar name / password)
* Complete loss of access to inventory:
  - loss of shape, skin, clothes and attachments during teleport
  - loss of everything else in the inventory

If I'm correct then the latter has everything to do with the
agent domain; thus, if someone would stay in the same agent domain
(ie, one run by Linden Lab), then one would not need to create a
new account, would not need to logout and re-login, would not
lose appearance or inventory.

The question remains now:

how will that affect the ideal solution? Because to the user those
worlds will suddenly appear to be a single world.

What if a griefer logins in with LL, teleports to opengrid X and
halts a sim there by running 10,000 scripts in attachments.

Whose TOS determines if that is allowed? I'd say opengrid X's tos.
And if opengrid X's TOS does not allow halting a sim, then where does
an Abuse Report go to? I'd say... still to opengrid X's administration.
And when they decide to ban this person, will it be possible to
ban that (LL) account from opengrid X?

These questions are not trivial, but of utmost importance (yes,
also for the protocol): any and all administrative issues should
be a case of the administration of the *region* one is in, and
never of the agent domain someone belongs to.

As a result, an agent domain shouldn't care less where someone
wants to go, because they are never responsible, and therefore
it should NOT be a matter of policy where someone can or cannot
teleport while keeping their inventory: it should simply be
possible, because the address is given in the LandMark.

---

From: Carlo Wood <[email-masked]>
Date: Fri, 21 Aug 2009 01:56:57 +0200

> possible, because the address is given in the LandMark.

What I guess is my main point, is that I think that we can
keep using "virtual world" (or just world in short) and
that that should refer to a (group of) region(s) under
one administration, and not to the agent domain; where
the world can (therefore) have a different TOS, has
world-wide bans issued by said administration, deals with
every Abuse Report against avatars in their region,
and which even could run on machines in a country with
different laws than the worlds of other administrations.

---

From: Joshua Bell <[email-masked]>
Date: Thu, 20 Aug 2009 17:12:20 -0700

> the term becomes undefined and unclear (in the future).

Agreed (with this and preceding points)

>  - A ban by such an administration only affects their own world.

Here I think you're projecting from the way things are now too directly. As
you mention later on...

> ban that (LL) account from opengrid X?

I don't think we know the answers to those questions yet. We need actual
implementers to speak up and describe how they'd want their systems to work
(on their own and with partners) and it should be within the working group's
charter to ensure the protocols support those administrative needs and
scenarios.

> possible, because the address is given in the LandMark.

I disagree with that. As a corporation providing tools to my employees, I
may dictate policy about where my employees may go using those tools - e.g.
they may teleport to and bring inventory with corporate content to partner
company worlds where the companies have signed NDAs, to have meetings to
discuss shared interests. It is entirely a matter of policy. This is no
different than having corporate firewalls that block access to certain sites
or content.

That may not be the primary use case (again, see the Web) but we can't
discard it.

Joshua

---

From: Joshua Bell <[email-masked]>
Date: Thu, 20 Aug 2009 17:16:06 -0700

> different laws than the worlds of other administrations.

I'm a fan of that loose definition of "world" myself. I think I alluded to
something similar earlier, but to try and rephrase to cover our shared
thinking: the boundaries of a "world" are where a user notices (or should
notice) a difference due to policy or behavior.

Like "web site" it isn't clear that that's a technical term; it shouldn't
keep us from using the term (since we have roughly shared understanding of
the meaning) but on the other hand we shouldn't fixate on a rigorous
technical definition since it doesn't seem to be a first-class entity within
the drafts we're focusing on right now.

Huzzah, convergence!

---

From: Meadhbh Siobhan <[email-masked]>
Date: Thu, 20 Aug 2009 17:16:09 -0700

carlo. i think we're on the same page here with respect to the
definition of the term "world." part of the confusion may stem from
the fact that radically similar discussions came up in the MMOX
effort.

one of the objectives of the OGP protocol is to allow a virtual world
to be constructed from regions, agent hosts and asset servers from
different administrative domains. in order to do that, one of the
things we think we need to do is to have a scheme by which regions are
unambiguously identified with a URL. we don't currently list
"unambiguous landmarks" in the charter because we don't talk about
landmarks at all in the charter. it's also unclear whether a landmark
format will be defined as part of this effort.

that being said, if you have an unambiguous URL that addresses a
region, you could use that as the basis for a landmark quite easily.
remember that we're only specifying the protocol in this effort, not
the application that uses it. protocol messages that carry landmarks
aren't in-scope because we're not defining a service that will produce
or consume them.

however... i think you bring up a good point, we could be more
explicit about including the "unambiguous URL defines a region" thing
in the charter. This would put it in-scope and would allow app
developers to define their own landmark format that leverages it.

so i guess what i'm saying is that if we listed "a format for
unambiguous landmarks" in the charter, shouldn't we also list other
Second-Life-like features like the C/M/T permissions system? the
unambiguous URL representing a region is required for proper operation
of teleport, which IS in scope, but the unambiguous landmark format is
not required as landmarks are concepts more appropriately manipulated
by client applications.

so, is it enough to add verbiage to the charter indicating that the
protocol requires regions to be addressable by unambiguous URLs, but
not explicitly constrain their use in the charter?

-cheers
-meadhbh

---

From: Meadhbh Siobhan <[email-masked]>
Date: Thu, 20 Aug 2009 17:25:21 -0700

but upon reflection, we should take landmarks as a use case and work
backwards to ensure the things we're doing don't preclude landmarks
being defined.

i'm still a little on the fence about whether we need to say "each
region should be individually addressable with a unique URL" in the
charter. it would go a long way to make sure that cross-world
landmarks could be implemented and i think we should say it, i just
don't know if it needs to go in the charter. (the charter which is
supposed to be a definition of the problem domain, not the solution
domain.)

---

From: Morgaine <[email-masked]>
Date: Fri, 21 Aug 2009 03:16:46 +0100

Carlo has expressed the issue perfectly in his post.

This isn't merely about a choice of words, it's a matter of actual
functionality.  Given two SL-compatible virtual worlds each comprising
multiple regions, either OGP provides a mechanism for teleporting from a
region in the first world to a region in the second world, or it doesn't.

Many things go along with cross-world teleports of course.  Cross-world
landmarks is one issue, continuity of inventory while in compatible worlds
is another, and so on.

While the details are of course complex to work out, at the heart of it is a
very simple question about goals, and it deserves a clear answer.  Will OGP
provide interop between SL-compatible virtual worlds, or is that not
intended OGP functionality?

 We need to know what is in scope for OGPX, because that scope determines
our discussions, our implementations, our deliverables and our timelines.

Morgaine.

---

From: David W Levine <[email-masked]>
Date: Fri, 21 Aug 2009 09:54:45 -0400

I am going to suggest inserting a very  concise paragraph after the second 
paragraph. 

>>> Insert 

Regions and Services implemented according to the specifications may be 
assembled into
multiple virtual worlds. These worlds may embody multiple domains of 
trust. Deployed virtual
worlds may support different policies of use. Constrained by these 
policies, the protocols will
permit interoperation across OGPX  virtual worlds with compatible policies 
and trust models. 

>>> end insert

I poersonally think this is implicit, but making it explicit doesn't hurt. 

I think this preserves the separation of concern we desire. Mechanisms are 
defined at the
protocol level. Policy is defined separate from mechanism. It should be 
possible to deploy
everything from highly constrained walled gardens to very open grids. The 
degree of 
avatar, agent, service and digital goods flow between specific virtual 
worlds will vary according
to the policies, and trust boundaries established by deployers. Nothing in 
the specifications
dictates specific policies

This follows the existing  practices of the web and internet.The core 
protocols
and formats of the internet permit interoperation, but deployers routinely 
constrain 
the accessibility and reach of services based on policy. 

- David W. Levine
~ Zha Ewry (ISL)

---

From: Infinity Linden <[email-masked]>
Date: Fri, 21 Aug 2009 07:33:08 -0700

i would argue that we shouldn't be introducing a term into the charter
that we can't define. the term "virtual world" is more appropriate for
the MMOX effort. OGP has an intentionally loose definition of the term
"virtual world," and it means (roughly) "the set of places you can
teleport or walk to." this is NOT a feature that is defined by
protocol, but by trust.

there is absolutely nothing in the protocol that requires region
operator 'A' to trust region operator 'B' or agent domain operator
'C'. we do, however, define message formats and techniques to carry
artifacts of this trust. there is nothing in the PROTOCOL that defines
who trusts who.

this is EXACTLY the issue that torpedoed PEM and led to MOSS and later
S/MIME. the protocols MUST NOT define trust relationships for
operators. they MUST be deferred to deployers. because we cannot
define trust in the protocol, it is inappropriate to insert language
in the charter based on that assumption.

if you define the term "virtual world" as "the set of places you can
teleport to" then this term CAN'T have meaning because it depends on
local policy that is out of the control of the protocol specifiers.
this is why the term is not used. this is why we define the protocol
in terms of things we CAN make some assumptions about: the required
parties in a protocol transaction. in the case of teleport, this
includes the originating region, the target region and the agent
domain.

this is the moral equivalent to saying the following in the ssh
specification "every ssh server must define a user called 'root', and
that user must have full permissions over the server." as it happens,
a great number of ssh servers have a superuser named root, but some
don't. there's no reason to define it in the protocol because it's a
matter of local policy.

when we say "there are things called virtual worlds, and they're
defined as the set of all places you can teleport to," what does that
give us? from a protocol perspective, it gives us nothing, because we
will never user it.

as part of the introduction, we may want to say "this protocol can be
used to construct a set of connected regions that MAY be rendered by a
client application in a form that appears as a virtual world." but
this gets us what?

-cheers
-meadhbh

On Fri, Aug 21, 2009 at 6:54 AM, David W Levine<[email-masked]> wrote:
> multiple virtual worlds. These worlds may embody multiple domains of trust.
> Deployed virtual
> worlds may support different policies of use. Constrained by these policies,
> the protocols will

---

From: David W Levine <[email-masked]>
Date: Fri, 21 Aug 2009 12:01:05 -0400

Fair enough. So.. Let me try an even crisper wording. 

Regions and Services implemented according to the specifications may be
deployed by separate organization with varying policies and trust domains. 

The OGPX protocols will provide the mechanisms for these services to 
interoperate,
when permitted by policy and shared trust domains. 

Infinity Linden <[email-masked]> 
08/21/2009 10:33 AM

To
David W Levine/Watson/IBM@IBMUS
cc
Meadhbh Siobhan <[email-masked]>, [email-masked], 
[email-masked]
Subject
Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision

-cheers
-meadhbh

> multiple virtual worlds. These worlds may embody multiple domains of 
trust.
> worlds may support different policies of use. Constrained by these 
policies,

---

From: Joshua Bell <[email-masked]>
Date: Fri, 21 Aug 2009 09:10:35 -0700

I do think this is one of the places in the charter where using "virtual
world(s)" is justified; the crisper wording may not imply much about the
intent to folks outside the effort, and (to Morgaine's point) seems very
abstract even to those inside the effort. Much of the draft charter feedback
we've gotten is that "concrete is a good thing"!

How about a tweak:

Regions and Services implemented according to the specifications may be
deployed by separate organization with varying policies and trust domains.
The OGPX protocols will provide the mechanisms for these virtual world
services to interoperate, when permitted by policy and shared trust domains.

Or:

Regions and Services implemented according to the specifications may be
deployed by separate organization with varying policies and trust domains.
The OGPX protocols will provide the mechanisms for these services to
interoperate, when permitted by policy and shared trust domains, enabling
the creation of interoperating virtual worlds.

(This rather short paragraph repeats "interoperate", "trust domain" and
"policy" twice, alas.)

On Fri, Aug 21, 2009 at 9:01 AM, David W Levine <[email-masked]> wrote:

>  *Infinity Linden <[email-masked]>*
>
> 08/21/2009 10:33 AM
>   To
> David W Levine/Watson/IBM@IBMUS  cc
> [email-masked]  Subject

---

From: Infinity Linden <[email-masked]>
Date: Fri, 21 Aug 2009 09:14:53 -0700

works for me.

---

From: David W Levine <[email-masked]>
Date: Fri, 21 Aug 2009 12:17:50 -0400

Either of those is fine with me. I think the former is crisper, the later 
slightly
more elegant. (And yeah the repeat's annoying, but its hard to avoid)

I think, we're about ready to say "last call" on comments. 

- David W. Levine 

Joshua Bell <[email-masked]> 
Sent by: [email-masked]
08/21/2009 12:10 PM

To
[email-masked]
cc

Subject

I do think this is one of the places in the charter where using "virtual 
world(s)" is justified; the crisper wording may not imply much about the 
intent to folks outside the effort, and (to Morgaine's point) seems very 
abstract even to those inside the effort. Much of the draft charter 
feedback we've gotten is that "concrete is a good thing"!

How about a tweak:

Regions and Services implemented according to the specifications may be
deployed by separate organization with varying policies and trust domains.
The OGPX protocols will provide the mechanisms for these virtual world 
services to interoperate, when permitted by policy and shared trust 
domains.

Or:

To

-cheers
-meadhbh

trust.
policies,

---

From: "Dickson, Mike (ISS Software)" <[email-masked]>
Date: Fri, 21 Aug 2009 16:17:42 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Joshua Bell
Sent: Friday, August 21, 2009 11:11 AM
To: [email-masked]
Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision

How about a tweak:

I like this since it defines “services” as those related to VW hosting.  It also will require that the protocol address how interoperation happens when policy does permit it.  That’s at the core of what I see others asking for.  And I agree without that OGPX is far less interesting.
Mike

---

From: Infinity Linden <[email-masked]>
Date: Fri, 21 Aug 2009 09:40:26 -0700

that works too. the only nit i have is that "organization" should
probably be plural.

and, i would use the phrase "the protocol defined by this group" since
that's what we use elsewhere in the draft. okay. so that was two nits.

and, should Services be capitalized? okay. amongst the nits i have are ...

so i think something like:

"Regions and services implemented according to the specifications may
be deployed by separate organizations with varying policies and trust
domains. The protocol defined by this group will provide the
mechanisms for these virtual world services to interoperate, when
permitted by policy and shared trust domains."

-cheers
-meadhbh

On Fri, Aug 21, 2009 at 9:17 AM, Dickson, Mike (ISS
Software)<[email-masked]> wrote:
> I like this since it defines “services” as those related to VW hosting.  It
> also will require that the protocol address how interoperation happens when
> policy does permit it.  That’s at the core of what I see others asking for.
> And I agree without that OGPX is far less interesting.
>
> Mike
>

---

From: Carlo Wood <[email-masked]>
Date: Sat, 22 Aug 2009 03:03:29 +0200

> permitted by policy and shared trust domains."

Great! This clarifies a lot about the intent of the protocol to me,
which should say something about the value of adding this paragraph! ;)

---

From: Carlo Wood <[email-masked]>
Date: Sat, 22 Aug 2009 03:25:36 +0200

On Thu, Aug 20, 2009 at 05:12:20PM -0700, Joshua Bell wrote:
> I disagree with that. As a corporation providing tools to my employees, I may
> dictate policy about where my employees may go using those tools - e.g. they
> may teleport to and bring inventory with corporate content to partner company
> worlds where the companies have signed NDAs, to have meetings to discuss shared
> interests. It is entirely a matter of policy. This is no different than having
> corporate firewalls that block access to certain sites or content.
> 
> That may not be the primary use case (again, see the Web) but we can't discard
> it.

You're right. I wrote a long story with what I really meant (but formulated
wrongly)... and deleted it again :p

---

From: Carlo Wood <[email-masked]>
Date: Sat, 22 Aug 2009 04:13:23 +0200

On Thu, Aug 20, 2009 at 05:16:09PM -0700, Meadhbh Siobhan wrote:
[deleted what I agree with, or just needs no comment]
> different administrative domains. in order to do that, one of the

Okaaayy... now you're using "a virtual world" again for a collection
of regions run by *different* administrations, while I was proposing
to keep the fact that currently all different (Second Life like)
worlds are run by different administrations. But... I'm not in a hurry
to have the meaning of "world" clearly defined, the only thing
that is important for me is the intent of the people on this mailinglist
and those working for Linden Lab in particular ;)

> format will be defined as part of this effort.

Okay. Note that I only talked about landmarks as example with
as goal to get clarity between us, here and now; followed by
a search for correct wording of paragraphs. I never thought that
"landmark" had to be added to the charter in said paragraphs.

> not required as landmarks are concepts more appropriately manipulated

I don't think that even unambiguous URL needs to be mentioned.

> not explicitly constrain their use in the charter?

Again, it was just a down-to-earth example, not suitable for the
charter.

The problem that we're trying to tackle, that I was trying to tackle,
is this (going to formulate this VERY explicit, almost embarrashingly so ;).

There are people on this list that run (currently) small grids
with (obviously) opensim servers. They would very much like it
to be possible for people in SL to teleport directly to their
grid (and back), preferably (but not necessarily) while keeping
access to their inventory and keeping there appearance intact.
The reason they want that is simply: the more seamless that is
possible, the more people will come; and more people is Good(tm).

The likeliness that this is going to happen for them in the
future depends mainly on two things:

1) Will the protocol support it at all
2) Will Linden Lab grant those grids whatever access they need

Point 2 is policy, and has nothing to do with the efforts of
this group.

It is my understanding that Morgaine after reading the charter
lost all hope to achieve this goal of interoperability, and
concluded that with the given formulation (as proposed by you)
*apparently* Linden Lab wasn't interested the slightest to
have this kind of interoperability with any of the current
opensim pioneers; which led to some emotions and rather direct
attempt to let you "confess" that LL wasn't interested, and
when you said "that doesn't belong in the charter" that was
interpreted as "we have a hidden agenda".

At this point I believe that all of that has been a misunderstanding,
that is directly caused by the confusion that exists about what
"virtual world" means. Morgaine (and me) interpreted "world"
as "run by a different administration", while you seem use the
word for "all regions that one can teleport to". Obviously,
the latter says NOTHING about the intent of Linden Lab to
interoperate with any opensim grids :p, and I suppose you
don't have to tell us if they do. But it's good to know now
that the protocol will support this.

We're not there yet though:

The reason that two grids (or virtual worlds, or different
administrations) might decide not to allow teleporting is
probably for a large part going to be determined by (not) trusting.

Therefore, in order to achieve the goal of teleporting between
Second Life and the smaller opensim grids, we'd like a protocol
that demands as LITTLE trust as possible.

For example, if the protocol would define something like:
- in order to teleport, grid A logs into auth services of grid B
once and then has access the everything after that (including
allowing to teleport); then teleporting would be impossible unless
grid B would trust grid A completely.

Other shemes are thinkable that require less trust. One result
of a "hidden agenda" could be that the protocol would be designed
such that ANY operability would only be possible with FULL access
to everything, and therefore full trust, and therefore (in practise)
no interoperability at all (except between large companies with
lawyers and contracts-- not the little pioneers that run opensim
grids now).

---

From: Morgaine <[email-masked]>
Date: Sat, 22 Aug 2009 08:47:17 +0100

Carlo Wood has once again done a magnificent job of presenting the key
issues.  I'll get to this in a minute.

I've stayed away from the discussion for a day while you all battled away at
defining terms, not because I'm not interested in terminology (I'll be as
pedantic as the rest of you once we get to the drafts :P), but because I'm
attempting to focus on the end goal without getting distracted by the means
to achieve it.

The end goal is of course to determine whether the OGP *mechanism* will
handle interoperation between SL-type virtual worlds (independent
collections of regions), or not.  *How* that is achieved, and what
terminology is used to describe it, is of no interest whatsoever compared to
the actual answer, in this context.

I am thrilled that the consensus appears to be moving towards unanimous
agreement that such interop via this protocol is indeed the end goal.

Some have suggested that it was always the end goal of OGP, but the highly
ambiguous and rather eclectic nature of the terminology in the charter
easily exposed the workgroup to eventual rejection of such a goal as being
"out of scope".  The last day's deliberations have been invaluable, because
they have ensured that this end goal is indeed in scope for the workgroup
and hence cannot be dismissed or minimized.  This will have a significant
impact on our work and our deliverables.

Carlo has again performed a masterful analysis of the situation.

I agree with every word, except that my personal impression that "*Linden
Lab wasn't interested in the slightest to have this kind of interoperability
with any of the current opensim pioneers*" refers to interop policy and
hence misses my focus.  It should be replaced by "*Linden Lab did not
specify this kind of interoperabiliy in the OGPX charter and therefore it is
unsafe to assume that this interoperability will be in the OGP protocol"*.
These are quite different things, and my interest is in the latter, the
mechanism of OGP, since I am focussed on technology.

Now that we know that OGP is intended to provide such interoperability (if
there is still disagreement about this in any quarter, please speak up now),
we can make provision to ensure that the work of OGPX does actually deliver
it.

There are numerous areas impacted by the decision to provide such
interoperation, but the charter is not the place to describe them.  However,
the charter must provide food and shelter for this area of work, otherwise
it delivers a de facto rejection of such interop instead.  In other words,
such interop must be a deliverable.

(I will mention some of the issues that may need addressing to achieve this,
not because they are relevant now, but because it demonstrates that the
currently listed deliverables do not necessarily cover them.  Included are
(this is *NOT* exhaustive):  interaction between two or more Agent Domains,
multi-domain identity handling, symmetric relationships between peer worlds,
composition of inventories from multiple agent domains, multi-world
addressing or landmarks for cross-world teleports, multi-world currency
where available, open trust relationships, and transitive trust
relationships.  In particular is must be pointed out that full connectivity
is not viable in an internet-scale metaverse, and this impacts on the core
design.)

Without going into the detail at charter time, I hope it is nevertheless
clear that delivering cross-world interop is not trivial.  In order to
ensure that it does not fall victim to accidental (or intended) disinterest,
it needs a specific deliverable to be listed among the Goals and Milestones
detailing cross-world operation in overview, and it also needs every other
deliverable to consider cross-world issues in passing.  It should be noted
that, if OGP was always intended to support such interop, then *the latter
will entail no extra work*.

As Carlo said, when we state that cross-world interop is the goal, "We're
not there yet".  We also have to provide care and feeding for this, to make
the goal a genuine one.

Morgaine.

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

---

From: Bill Windwalker <[email-masked]>
Date: Sat, 22 Aug 2009 04:41:44 -0700 (PDT)

Some times even the mega companys have had great programs that they have let slip out of there control just to find out in the end some part of it was very importent.
no one can see how importent some thing can be till they have lost owner rights to it.

xstorm Radek

________________________________
From: Morgaine <[email-masked]>
To: [email-masked]
Sent: Saturday, August 22, 2009 3:47:17 AM
Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision

Carlo Wood has once again done a magnificent job of presenting the key issues.  I'll get to this in a minute.

I've stayed away from the discussion for a day while you all battled away at defining terms, not because I'm not interested in terminology (I'll be as pedantic as the rest of you once we get to the drafts :P), but because I'm attempting to focus on the end goal without getting distracted by the means to achieve it.

The end goal is of course to determine whether the OGP mechanism will handle interoperation between SL-type virtual worlds (independent collections of regions), or not.  How that is achieved, and what terminology is used to describe it, is of no interest whatsoever compared to the actual answer, in this context.

I am thrilled that the consensus appears to be moving towards unanimous agreement that such interop via this protocol is indeed the end goal.

Some have suggested that it was always the end goal of OGP, but the highly ambiguous and rather eclectic nature of the terminology in the charter easily exposed the workgroup to eventual rejection of such a goal as being "out of scope".  The last day's deliberations have been invaluable, because they have ensured that this end goal is indeed in scope for the workgroup and hence cannot be dismissed or minimized.  This will have a significant impact on our work and our deliverables.

I agree with every word, except that my personal impression that "Linden Lab wasn't interested in the slightest to have this kind of interoperability with any of the current opensim pioneers" refers to interop policy and hence misses my focus.  It should be replaced by "Linden Lab did not specify this kind of interoperabiliy in the OGPX charter and therefore it is unsafe to assume that this interoperability will be in the OGP protocol".  These are quite different things, and my interest is in the latter, the mechanism of OGP, since I am focussed on technology.

Now that we know that OGP is intended to provide such interoperability (if there is still disagreement about this in any quarter, please speak up now), we can make provision to ensure that the work of OGPX does actually deliver it.

There are numerous areas impacted by the decision to provide such interoperation, but the charter is not the place to describe them.  However, the charter must provide food and shelter for this area of work, otherwise it delivers a de facto rejection of such interop instead.  In other words, such interop must be a deliverable.

(I will mention some of the issues that may need addressing to achieve this, not because they are relevant now, but because it demonstrates that the currently listed deliverables do not necessarily cover them.  Included are (this is NOT exhaustive):  interaction between two or more Agent Domains, multi-domain identity handling, symmetric relationships between peer worlds, composition of inventories from multiple agent domains, multi-world addressing or landmarks for cross-world teleports, multi-world currency where available, open trust relationships, and transitive trust relationships.  In particular is must be pointed out that full connectivity is not viable in an internet-scale metaverse, and this impacts on the core design.)

Without going into the detail at charter time, I hope it is nevertheless clear that delivering cross-world interop is not trivial.  In order to ensure that it does not fall victim to accidental (or intended) disinterest, it needs a specific deliverable to be listed among the Goals and Milestones detailing cross-world operation in overview, and it also needs every other deliverable to consider cross-world issues in passing.  It should be noted that, if OGP was always intended to support such interop, then the latter will entail no extra work.

As Carlo said, when we state that cross-world interop is the goal, "We're not there yet".  We also have to provide care and feeding for this, to make the goal a genuine one.

Morgaine.