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