[mmox] MMOX: Strawman scope/goals/approach

[David W Levine <[e-mail]>]

After chewing through the entire mailing list the past week, I've banged 
out something which *might* help structure our discussions a bit. I offer 
the following as an attempt to distill and focus some of our thinking.  We 
are roughly 4 weeks from a face to face, and while i do not expect a 
charter to emerge directly from that BOF, I think we need to end the face 
to face with enough of an agreed broad framework, that we can imagine 
generating a consensus charter on the mailing list prior to the next IETF 
face to face in July. 

I am posting this as a complete document. I am looking for broad consensus 
and proposed revisions, and will take them and spin back subsequent 
versions on a hopefully daily turn around. I don't expect the document to 
survive close to unchanged, but I'd like to try and manage it as a series 
of successive drafts, so we can have something consistent to talk about. I 
look at this as "If we can get rough consensus on this" then we can use it 
as a basis for driving forward on a set of charter level tasks. 


I am attaching the input as a .txt and a (sigh) Microsoft  word document. 
I am also posting it in line as plan text. (tho ugly, I'll work on that 
for future versions)
There has been a fair bit of discussion on the MMOX mailing list, and in 
casual 
discussions about what we are actually trying to achieve. In service of a 
better answer, I 
am going to try and summarize:

1.      The problem space we are tackling
2.      An Enumeration of interoperability goals in the problem space
3.      Some approaches to solving these goals
4.      How to both make concrete progress within the IETF approach and 
end up with a 
                solution that people will actually want to adopt. 
5.      Some things which fall out of scope 

I will try to cast both the problems and solutions separately from any 
specific virtual 
worlds or MMOS and instead draw on several underlying models as I describe 
things. 
Please view this as a strawman intended to provoke discussion, but also 
think of it as 
intended to evolve into something we can actually use to structure our 
work going 
forward. 
v
I am taking as a given that we are all professionals, engaged in a 
respectful, and 
thoughtful exercise to generate good engineering solutions. I welcome 
engaged, 
constructive, on topic discussion. Please read the IETF NOTEWELL notice: 
http://www.ietf.org/NOTEWELL.html  Our goal, is a code driven, process, 
anchored in 
the ability to prove that specifications we create actually interoperate 
and work as 
described.  Specifications do not advance in the IETF in the absence of 
demonstrated 
interoperability based on running code. 

- David W. Levine
~ Zha Ewry (In Second Life)


------------------------------------------- 

The Problem Space:

I take MMOX as Massively MultiParty Online eXperiences (Since Meadbh 
didn't define 
X, we all get a shot at it) Lets take this one bit at a time. Massively, 
as in experiences 
intended to be shared by tens, hundreds, thousands, and over time, a 
significant fraction 
of the interne community. Online, focusing our attention on the concurrent 
shared portion 
of the experiences and eXperience as a shorthand for (Games, Applications 
and shared 
experiences.) 

The group's name and remit is intentionally broad, focused on a general 
set of Games and 
Applications, not any single game, application or experience.  The group's 
roots, and 
interests are largely, but not exclusively shaped by Virtual Worlds, 
including MMO 
games, Virtual worlds, Collaboration and Simulation Environments and 
shared online 
streaming environments. Examples of these platforms include, but are not 
limited to 
World Of Warcaft, ProtonSphere, Eve Online, Forterra's  OLIVE platform, 
Club 
Penguin,  Linden Lab's Second Life,  IMVU, There.com, Croquet, 
OpenSimulator.org, 
Weblins. 

The common thread across all of these environments is a concurrent shared 
experience, 
often, but not exclusively rendered in a three dimensional space.  Here's 
one attempt to 
scope what these environment share:

1.      One or more virtual spaces
2.      A set of users
3.      A representation of the users projected into the space
4.      A shared experience of the events in the space projected back to 
all the users 
                currently in the space. (Text, Voice, and the results of 
actions) 

Many of these environments will also include one or more of:

5.      Objects which can be dynamically created and modified to form part 
of the 
                space's setting
6.      Persistent state in the virtual space(s)
7.      Mechanisms to associate external streams of media with portions of 
the 
                immersive space 
8.      Mechanisms to run scripted behaviors in the space
9.      Simulated physics and behavior of objects and projected users in 
the spaace
10.     Mechanisms for users to  move from one virtual space to another 
(by hand off 
                between regions implicitly, or by explicit user request 
(teleport) 
11.     Libraries of material the users can add to the space
12.     Mechanisms for users which are not in a common virtual space to 
interact with 
                each other in some form (be aware of each other's 
locations and online status, 
                message each other, etc) 

Note I've very carefully avoided using most of the common words for the 
shared 
experience. We often speak of Simulators, Avatars, Regions, Assets and so 
forth, for the 
moment, I'm going to keep those terms off the table to think about the 
problem in its 
more general form. 

Note that I'm also very consciously taking a minimal base with optional 
features 
approach to describing the space. This allows us to focus on the core 
overlapping 
features, and then a set of services which add to this core. Think about 
how these goals 
and solutions could be applied to collaborative spaces such as Wikis, 
Micro blogging 
streams and collaborative desktop and application environments. 

Interoperability is not about defining the one true system which satisfies 
these goals. 
Interoperability is about making multiple existing implementation 
interoperate by the use 
of standards we define. 
Goals: 

What sort of interoperability do we desire out of these spaces? 

I will start with some statements from the perspective of user experience, 
and then talk 
about the technical implications of these use cases. I will also start 
with the broadest, 
most expansive goals and then look at how to break these apart into a 
series of sub goals. 

These goals are structured with the intent of listing a range of 
experiences we hope to 
enable.  There sometimes seems to be a strong desire to think about the 
ultimate end 
state, where there is one uber-client, and every single virtual space 
implements every 
single capability in super grid spanning the world. I think that, its 
important to think of 
interoperability as happening over time, and in clusters of increasingly 
integrated services 
and spaces. Some low hanging fruit will come early. Some worlds, which are 
close in 
design will get deeper benefits sooner, others will only gradually become 
more tightly 
integrated. There are many important, useful, and desirable states between 
"nothing 
shares" and "Its one single model of everything."

Note: These goals are not use cases. Ideally, each goal will, over time, 
spawn a set of use 
cases to help define them, and  additionally some "cross goal" use cases 
will be generated 
which will show how multiple goals work together to provide valuable 
results. 



1.      The ability to manage one's identity when interacting in multiple 
MMOX spaces. 
        a.      Allowing presence information to be shared and coordinated 
across 
MMOX spaces
        b.      Permitting friends lists, and IMs to be shared across 
spaces
        c.      Permitting MMOX spaces to share naming 
        d.      Simple ways of allowing a consistent name, managed by the 
user, and 
                verifiable by other users
        e.      Single sign on, mediated by multiple spaces, within the 
policy constraints 
                of the spaces
        f.      A consistent appearance, within the constraints of the 
various systems
        g.      The ability to manage the degree of visibility / coupling 
between identities 
        in MMOX spaces

 Note that for all of these, there is no requirement to couple the systems 
together 
beyond managing identity, and share presence and IM information. These use 

cases don't speak to how you move between spaces. You may have to shutdown 

your client on one system and start another. This also is not a "You must 
enable 
this" this is very much a "Make it easy for spaces which want to enable 
this to do 
it." Also, note that "presence and messaging" speak to user needs, and 
consitent 
appearance and name (when desired by users) again speeks to meeting user's 

desires. 

2.      The ability for the services in an MMOX world to be named, and 
authenticated
        a.      Services to associate virtual places and the services 
which support them 
        with authentication and administrative domains
        b.      Services to permit a service to validate the membership of 
a remote 
        service in one or more authentication and administrative domains

This is needed so that we can do essentially any of the interoperability 
work. 
Without some framework which lets us know who we are talking to, it is 
impossible to trust the behavior of distributed systems. 

3.      The ability to share content between MMOX spaces
        a.      Import and Export of content and models (This may well 
leverage off of 
        existing work such as Collada) Static, import/export of content 
while not 
        terribly dramatic is an important part of the value chain of 
interoperability
        b.      Mark up schemes which recognize the existence of multiple 
presentation 
        environments, but permit the sharing of content
                i.      Shared "type" information for the various types of 
graphical 
                        content which MMOX spaces contain
                ii.     Extensible, with a common registry, so that we can 
understand the 
                        types of contents a client can accept, and a 
virtual space, or virtual 
                        asset store can be asked to provide
        c.      A MMOX based, system independent asset addressing scheme 
which includes
                i.      Content negotiation based on 2b
                ii.     Access Management based on (1) and (2)

This is, to my mind, the key mid term deliverable 

4.      The affordances in MMOX to permit the creation of micro-payment 
economies
        a.      Appropriate spots defined in MMOX protocols for cost 
information
        b.      Appropriate spots defined in MMOX protocols for reference 
to 
                micropayment systems

5.      The ability to share "non immersive streams" between spaces 
        a.      Markup to permit the consistent sharing of stream media 
such as voice, 
                and video, with shared start and synchronization 
information to permit 
                "parallel" events between MMOX space

6.      The ability to express Policy intent between MMOX services and 
virtual spaces
        a.      Places in reserved in the MOX protocols for expressing 
policy intent
        b.      One or more policy languages for expressing policy


The solution space:

Most of the deployed solutions partition the software problem into the 
following chunks.

1.      Some form of a client which permits a user to interact with the 
shared experience
2.      Virtual space servers which manage the state of a portion of 
virtual space
3.      A set of supporting services used by the virtual space servers 

Note that exactly how these three large chunks are assembled and the 
granular nature of 
the services can vary radically, even when serving very similar 
environments. Some 
environments push a large amount of rendering and management onto complex 
clients, 
others perform the bulk of rendering in the server portion of the 
deployment. Some 
implementations combine client and simulation into a single entity which 
does some 
simulation and some user presentation. Some distribute the simulation, 
some centralize it. 

The heart of most of the solutions is managing to accept and merge a 
stream of updates, 
and then distribute the merged updates back to users. This can happen at a 
range of 
granularities. The two ends of the spectrum, are, roughly, sending updates 
as a fully 
merged audio visual stream, which the client merely displays, and sending 
low level 
changes to a underlying mode, which the client uses to assemble a complete 
visual 
representation of the scene.  Variations include croquet and qwaq which 
use an 
underlying distributed object model to pass large amounts of updates, and 
approaches 
such as used by SecondLife and Protonsphere, where voice is managed in a 
separate 
service, with the merged state service merely letting the voice service 
know where the 
users are located. 

Closely related, are issues of representation and format of content. This 
takes several, 
separable forms. Import and Export of material to the core environment, 
and, more 
problematically, run time representations

Approach
Our overall approach should be web centric, and web services oriented. We 
can, and 
should think of sets of related services which can be composed as part of 
different 
solutions which will enable varying degrees of interoperability. We can, 
and should 
attempt to provide as web like an approach to function as possible. 
Content negotiation, 
separation of protocol from security, separation of interface from 
implementation and 
other techniques. 

Our goal is not to enshrine any single virtual world as the standard for 
all MMOX spaces, 
but rather create a flexible, extensible set of services which will allow 
us to grow larger 
and large overlapping sets of capabilities. My expectation is that we will 
see a lot of low 
hanging fruit in the area of identity, authentication, authorization and 
presence 
management (Where a user is, and allowing messaging to them across MMOX 
spaeces) 
and initially, we will find a lot of format and content area addressed by 
gateways, 
markup, and content negotiation. I see nothing wrong with having a URI 
which refers to 
"A pretty maple tree with fall colors" which provides a way to fetch the 
"Collada Style 
version" the "3dMax Mesh version" the "Linden Lab 1.2 sculpty spec 
version"  such that 
a virtual space can select, through content negotiation the one most 
useful to it. 

We get value, when we have consistent ways of referring to all the various 
forms of 
content, and we get more value when we have ways of using existing content 
negotiation 
to allow a web light selection of an appropriate form. It is equally 
possible to imagine 
negotiating between a client and a virtual space, the desired form of 
objects. There are 
some deep challenges lurking, such as when two different approaches have 
radically 
different 

What I would encourage us, as a mailing list to do, is look through the 
problem 
statement, and interoperability goals I've put together here. They are an 
attempt to 
capture the various sentiments in the ongoing discussion. I am sure I have 
missed points, 
and I am sure some people will disagree with some of the points I have 
made. 

I would ask people to look for "No, you missed X" and "Hey, I don't think 
Y" is true. I 
will attempt to capture all of those, and revise the document, until we 
think it represents 
something close to the general group consensus. (I am not looking for 100% 
consensus, 
but a "Yeah, this captures most of what we're trying to do." With that in 
hand, I would 
suggest we could then begin to enumerate the specific services and markups 
we need to 
support our goals, and begin to flesh out use cases to help us understand 
the goals and 
services. 

I do not expect this to yield a set of specs which Linden Lab, or OpenSim, 
Or any one 
virtual world vendor or project would implement whole. What I expect it to 
yield is a set 
of specs, which can be combined with existing projects and code bases to 
drive us 
towards a more interoperable future. 

Out of scope

I also want to begin to accumulate a short list of "No, this is out of 
scope" assertions

1.      We will provide all the affordances necessary to permit a broad 
range of 
interaction policies. Appropriate policies for various deployed solutions 
and 
future deployed solutions is out of scope, beyond providing us use cases 
which 
highlight specific affordances we may wish to consider
2.      Whether or not immersive multi-party spaces are useful and which 
specific 
capabilities are required is out of scope. We aspire to support a broad 
range of 
possible capabilities, and we respect that different organizations will 
have 
different perspectives on what is required. Our goal is to define broad, 
interoperable frameworks which will enable a range of deployments, not to 
define 
the one true model for this space
3.      Propose additional statements here

Closing comments

I don't think our collective goal can be to take any one existing spec or 
solution and 
simply declare it the basis for our work going forward. At the same time, 
we must base 
our work in actually running code, showing real interoperability. Our goal 
must be to 
build supersets of function, based on existing products and solutions 
which demonstrate 
real interoperability. 

The IETF favors working code and growing consensus over blank paper and 
blue sky 
efforts. This is based in a history of success and failure in the industry 
when it comes to 
building, promoting and succeeding at standards work. Work at the IETF is 
grounded in 
working code. 

One way forward is to focus on several clusters of work. One: a clear, 
broad framework, 
which forms the basis for long term broad interoperation. Two: Capturing 
the current set 
of incompatible and overlapping formats and protocols in use, so that we 
can create a 
extensible and shared catalog of artifacts for sharing. (eg. "Here is the 
canonical, 
extensible  list of graphic content types you might want to move on a MMOX 
transport" 
Three grow out  proposed solutions such as LLSD, OGP, and others, as they 
are 
contributed towards a common superset which can be used to as the basis 
for 
demonstrating concrete progress towards interop goals. Four, Identify 
places where we 
simply want to use existing work, such as OpenID, OAuth,  X.509  and 
create a shared 
profile for how we can use these protocols to further interoperability.