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

[Ryan McDougall <[e-mail]>]

Excellent post. The only one worth reading since I joined.

Very agreeable.

Cheers,
Ryan McDougall
realXtend

On Tue, Feb 24, 2009 at 6:04 PM, David W Levine <[e-mail]> wrote:
>
> 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.
>
>
>
>
>
>
>
>
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox
>
>