Subject: [mmox] Greetings, MMOX Charter, Scope, Activities..

From: David W Levine <[email-masked]>
Date: Fri, 6 Feb 2009 15:32:24 -0500

Greetings, all, quite a few familiar names going by.. For anyone who 
doesn't keep track of the RL/SL mapping you'll find me in SL under Zha 
Ewry. (Hey, you never know,
someone might not be paying attention.) 

I'd like to start with some perspective on what I expect out of an IETF 
Working Group in this space, and then, follow up with several notes on 
specific issues, one per note.

The reason to bring work to the IETF is to help establish it as a usable 
specification for interop between as large a community as possible. My 
personal and professional interest in this work, is not to codify the 
current state of the Linden Lab grid, or to codify the next iteration of 
that codebase. I think of the goal as parallel to one of the goals of the 
OpenSim code base itself, establishing a set of specifications from which 
a broad range of immersive, virtual spaces can be created.  If MMOX only 
addresses the concerns of Linden Lab, or the OpenSim community, or a small 
set of corporate players, I see little point in the exercise.
OpenSim and Linden Lab have different code bases, sometimes strikingly so 
as the OpenSim community has been creative and original in solving 
problems. But, both groups share a common heritage, linked by the client, 
and shaped by Linden Lab's initial design choices. This may well be too 
narrow to fully engage the larger community.

The proposed Charter that Infinity provided, is a starting point for 
discussion, and the work items are those Linden has offered to the MMOX 
effort. The point of a BOF, and using the mailing list and developing a 
charter, is to sort out what the entire community of interest thinks 
belongs in the charter, the workgroup and the work items. 

My hope is that we end up with a set of specifications, which define three 
broad sets of items. Low level encoding and formats specifications, and 
protocols aimed at building blocks for moving content around.  Sets of 
services, such as Inventory management, asset Storage, Messaging, 
presence, and so forth, which can be deployed in a wide variety of 
combinations to get useful effects. finally, there is a set of services 
centering around that Linden calls a region simulator, which, are in 
essence, the mechanisms used to manage a shared scene graph. Please note, 
that the current deployment of these services within the Linden Lab Grid, 
and on OpenSim grids, is one model for how a scene graph can be shared. 
The core problem, of accepting control inputs from many sources, creating 
a stream of updated states and sharing them back out to concerned parties, 
is, I believe, the nub of the problem. Many variations can be imagined, 
with more or less detail handled centrally, peer to peer simulations, and 
largely client side simulations. Our challenge is to capture a set of 
services and models which lets us describe these various implementation 
choices at the services and protocol level, and, as much as possible, 
separate deployment and implementation choices from the interoperable 
building blocks we define. 

I strongly encourage everyone to share news of the BOF, and of the 
proposed working group as widely as possible. While there is a clear 
danger in boiling the ocean, if we end up with too diverse a set of 
interests, I think that danger is far less than the danger of creating a 
small focused set of specifications which don't allow the majority of 
possible virtual worlds environments to interoperate. 

Finally, a small word on process and participation. The IETF works by 
"rough consensus" how rough, and how broad, is somewhat ill defined. It is 
not unanimity, nor is there a precise measure of what is meant by the 
phrase. My personal belief is that standards live and die by the ability 
of the working group to attract sufficient  participants to the consensus. 
 Standards which unify multiple approaches and allow a diversity of 
implementations are of much higher value than ones which codify a single 
approach, no matter how well they define that approach.  The broader a set 
of participants we attract, and the broader a set of possibilities we 
enable, the more impact we can have. 

I don't expect that a successful IETF working group will define a set of 
specifications which maps exactly to any one implementation. I expect  we 
will, as a community, begin the process of creating a set of shared 
building blocks from which we can compose many implementations. The 
balancing acts between generality and efficiency, between learning from 
the existing code bases, and imagining better ones
will be some of the biggest challenge we face. The goal is not  a single 
homogenous grid, but rather defining a broad set of possible virtual 
spaces, and enabling as fluid and transparent movement between them as we 
can manage. 

- David W. Levine 
~ Zha Ewry (ISL)

---

From: Morgaine Dinova <[email-masked]>
Date: Sun, 8 Feb 2009 00:10:40 +0000

On Fri, Feb 6, 2009 at 8:32 PM, David W Levine <[email-masked]> wrote:

> services, such as Inventory management, asset Storage, Messaging, presence,
> and so forth, which can be deployed in a wide variety of combinations to get
> useful effects. finally, there is a set of services centering around that
> Linden calls a region simulator, which, are in essence, the mechanisms used
> to manage a shared scene graph. Please note, that the current deployment of
> these services within the Linden Lab Grid, and on OpenSim grids, is one
> model for how a scene graph can be shared. The core problem, of accepting
> control inputs from many sources, creating a stream of updated states and
> sharing them back out to concerned parties, is, I believe, the nub of the
> problem. Many variations can be imagined, with more or less detail handled
> centrally, peer to peer simulations, and largely client side simulations.
> Our challenge is to capture a set of services and models which lets us
> describe these various implementation choices at the services and protocol
> level, and, as much as possible, separate deployment and implementation
> choices from the interoperable building blocks we define.
>
> I strongly encourage everyone to share news of the BOF, and of the proposed
> working group as widely as possible. While there is a clear danger in
> boiling the ocean, if we end up with too diverse a set of interests, I think
> that danger is far less than the danger of creating a small focused set of
> specifications which don't allow the majority of possible virtual worlds
> environments to interoperate.
>
> phrase. My personal belief is that standards live and die by the ability of
> the working group to attract sufficient  participants to the consensus.
> will, as a community, begin the process of creating a set of shared building
> blocks from which we can compose many implementations. The balancing acts
> between generality and efficiency, between learning from the existing code
> bases, and imagining better ones will be some of the biggest challenge we
> face. The goal is not  a single homogenous grid, but rather defining a broad
> set of possible virtual spaces, and enabling as fluid and transparent
> movement between them as we can manage.
>
> That is such a wonderfully complete and forward-looking statement that I
hesitated to respond initially to avoid gilding the lily.  But the lack of
comments has made me respond, as I don't want David's words to be lost.

I support the above view 100%, and I would encourage everyone else to lend
vocal support to such an all-embracing vision.  It may seem slightly in
conflict with near-term business plans I know, but the fact that we're here
at all is testament to many very people (I think I should say "everyone
here") being strongly interested in the long term.  I think that David has
given us a perfect vehicle upon which to ride --- please buy your tickets.
I wish to state that I'm on board.

Morgaine.