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

Mark P. McCahill schrieb:
> +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.

+1 and I would actually list:

  - defining an identity endpoint
  - service discovery to find services for this identity such as profile
    definition, friends list, inventory server, ...
  - distributed authorization

Then having a way defined for services to be found and authorized one 
could define the specifics of these services.

I would extend this beyond MMOX worlds though because there is huge 
interest in the web and social networking players as well.

So maybe a seperate working group which has not the focus so much just 
on virtual worlds for this part might make sense. But I have no idea 
about the IETF process anyway at this time and if and how this would be 
possible or wanted.

-- Christian

> 
> 
> 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
> 
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox

-- 
Christian Scholz
Blog: http://mrtopf.de/blog
Company: http://comlounge.net
Podcasts: http://datawithoutborders.net, http://openweb-podcast.de