Re: [mmox] MMOX: Strawman scope/goals/approach

+1

I really like the approach David is taking here. The first two items:

   * managing identity
   * naming and authenticating services in MMOX worlds

are prerequisites for getting anywhere with cross-system  
interoperability,
would benefit users of existing systems, and should be achievable in the
fairly near term. Understanding how to negotiate these services is the
place to start, rather than defining an abstract wire-level protocol, if
the intent is to bring something other than Second Life-like worlds into
the fold.

Mark McCahill

On Feb 24, 2009, at 11:04 AM, David W Levine wrote:
>
> 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.
>
>
>
>
>
>
>
> <Scope01C.txt><Scope01C.doc>
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox