Subject: Re: [mmox] Interop Metrics and MMOX Goals

From: Morgaine <[email-masked]>
Date: Sun, 1 Mar 2009 16:14:18 +0000

I am pulling out a point made in a recent thread so that we can discuss *values
of interoperability* and our *goals relating to them* in its own right:

On Sun, Mar 1, 2009 at 3:24 AM, Jon Watte <[email-masked]> wrote:

But architecture neutrality is only a necessary constraint on a standard;
> it's not sufficient to provide interoperability.

Jon, you've said words to this effect several times now, so I'm going to
respond to your use of "interoperability" in this atomic way, separating it
out from its parent thread, because I think that such use doesn't capture
what we need.  The issue of interop metrics deserves more in-depth
examination so that we can fully understand our goals.

Interoperability as a metric is not a boolean with values of 0 and 1.  It is
a continuum, with zero at one end and 100% at the other.  In MMOX we
consider only non-zero values of that scale because achieving zero
interoperability is not the goal we seek.  On the other hand we must also
acknowledge that 100% interoperability is not the goal we seek either
because that would imply that *all* properties of one world are reflected in
another, which is clearly not possible unless the two worlds are identical.
100% would conflict with the premise/goal that interop is being sought
between different types of worlds.

So, what values of interoperability are we aiming for?  All we can say is "*as
high as possible*", because even giving a specific number would run counter
to the premise of world diversity.  What we are trying to do then is the
following:

   1. to identify the largest possible intersection between the property
   sets of all the worlds that we represent or know about and as many others as
   we can capture, and then
   2. to create a protocol that permits the properties in that intersection
   to be transported between worlds.

That's what we're doing here, reduced to its bare essentials.

Implicit in our work is that the *actual* amount of interoperability we
achieve will vary between any two specific types of worlds under
consideration.  It can only be very high for two nearly identical types of
worlds, and it must never be zero nor close to zero between two worlds
within our catchment area because that would imply that our protocol has not
been designed with adequate and fair coverage of the intersection of world
properties.

I see the above as both establishing our plan of attack and also defining
what we mean by "success" in our task.  We will have succeeded if our
protocol has achieved transport with highly complete and fair coverage of
the intersection of world properties that we have identified.

Morgaine.

On Sun, Mar 1, 2009 at 3:24 AM, Jon Watte <[email-masked]> wrote:

> Morgaine wrote:
>
>> On Sat, Feb 28, 2009 at 7:20 PM, Jon Watte <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
>>    client/server interface. That doesn't solve any of the hard
>>    problems, like how to interoperate different objects that are
>>    built using different execution environments within the same space.
>>
>>
>> flexibility of Opensim but also to the architecture-neutrality of MXP.
>>
>>
> But architecture neutrality is only a necessary constraint on a standard;
> it's not sufficient to provide interoperability. Specifically, I don't quite
> see how MXP supports the case where the same space contains entities
> simulated by different hosts -- given that it suggests entities are "handed
> off," that necessarily means that bubbles have to use the same technology,
> which necessarily precludes multi-architecture interop.
>
>  On the similarities between MXP and OLIVE, the two architectures look like
>> variations on a theme to me.  In both cases every client performs the same
>> simulation, this being of a "shared space/room" in OLIVE and of a "Bubble"
>> in MXP.  In both cases, the communication seems to be a form of P2P,
>> proxy-aided in the case of MXP.  Both approaches seem unable to simulate
>> widely diverse world environments because simulation is done on every
>> client, which means that the
>>
>
> Surely, there is simulation on the client even in Second Life? Else, you
> would need to get updates from each object at 60 Hz to be able to show
> smooth movement.
> Specifically, MXP sends state snapshots, and lets the client dead reckon
> between those snapshots. That is, in itself, a robust technique, used by a
> lot of systems (harking back to before DIS, and used by pretty much all
> networked computer games) -- but it's nowhere near what OLIVE does
> internally. OLIVE requires deterministic simulation on client and server,
> and only forwards time-stamped command input, no state snapshots.
> The LESS protocol I have proposed, though, is similar to MXP in this
> regard, because it's based on the "common ground" of state snapshots and
> dead reckoning. I based it on that just because it's so common, robust and
> well known, and the fact that MXP is also based on that proposal means it's
> probably a good common ground technology.
> But, that in itself does not lead to interop. There is a difference between
> building a working virtual world protocol, which may be open, documented,
> and unencumbered, and building a protocol that is designed for interop
> between different virtual world implementations.
>
>  same simulation code has to exist on every client for the simulation to be
>> accurate.  This would seem to preclude effective interop with different
>> worlds whose simulation code is not divulged --- at best some rough feedback
>> telemetry can then attempt to reflect something vaguely sensible to
>> "foreign" local simulations.  And in neither case is there a "world-centric"
>> model as in SL or Opensim, since rooms and bubbles aren't really topological
>> entities per se.
>>
>>
> Bubbles are topological in the sense that they have location in cartesian
> 3D space. At the same time, they are not topological enough, if you want to
> map them 1:1 to arbitrary technologies, because OLIVE uses a sector
> partition where the shape and size of a given sector/bubble can be an almost
> arbitrary graph (including disjoint), and other technologies like BigWorld
> let sectors/bubbles be polygonal shapes (they use Voroni diagrams to
> partition space); the bubble concept doesn't map to that 1:1, either. When
> you build a virtual world protocol (to use as basis of a particular
> implementation), specifying the size/shape of bubbles is required. However,
> when you design for interop, specifying that actually may get in the way,
> and leaving it unspecified may actually be preferable.
>
>  I do agree that the hard questions do not appear to have been answered,
>> but this is true for every proposal so far:  the detailed semantics of
>> interop remain to be defined.
>>
>
> Well, I tried to answer some hard questions in LESS. I think the biggest
> drawback of the LESS proposal is that it requires support from other
> protocols which have not yet been published (but which I have drafts or
> examples of). However, I believe LESS answers more of the hard questions
> than the others.
>
> It may turn out that an agreeable protocol in the end uses the
> marshaling/entity/component/property/ownership separation of LESS, the
> connection/authority negotiation of OGP, and some other bits of MXP, but I
> don't think any one of those protocols can stand on its own, unmodified, as
> is. I think LESS would have to be modified the least, but that's because it
> attempts to solve the fewest problems, but in the most detail, of the three
> :-)
>
> Sincerely,
>
> jw
>
>

---

From: Jon Watte <[email-masked]>
Date: Sun, 01 Mar 2009 10:13:05 -0800

Morgaine wrote:
> So, what values of interoperability are we aiming for?  All we can say 
> is "/as high as possible/", because even giving a specific number 
> would run counter to the premise of world diversity.  What we are 
> trying to do then is the following:
>
>    1. to identify the largest possible intersection between the
>       property sets of all the worlds that we represent or know about
>       and as many others as we can capture, and then
>    2. to create a protocol that permits the properties in that
>       intersection to be transported between worlds.
>
>

I would phrase that somewhat differently. I want us to identify the 
properties necessary to satisfy our accepted use cases, and make sure 
that those are transportable. We're all creative people, and we can 
think of thousands of properties that "might make sense" -- but that 
would be over-engineering. We need to settle on specifically those 
properties that are necessary to satisfy our use cases, and no more.

For example: There.com avatars can blush. This is done using a "blush" 
scalar property on the avatars. (Other options might be to support 
animations that animate color values, using texture swaps, using texture 
scrolling, etc). However, I believe that interop, in the use cases I can 
see, actually doesn't need "blush," so I don't think we need to specify 
that property.

>
> I see the above as both establishing our plan of attack and also 
> defining what we mean by "success" in our task.  We will have 
> succeeded if our protocol has achieved transport with highly complete 
> and fair coverage of the intersection of world properties that we have 
> identified.

I think that's necessary, but not sufficient.

We need to identify a set of properties that we can assume are 
understood by everyone. That means that if two worlds say that they 
support MMOX, I know what that means. (It won't be the MOSS situation).
Additionally, we must allow additional properties to be exchanged 
between worlds that can agree on additional semantics. In general, this 
is how the protocol can grow organically.
Finally, we need to come up with a model that allows all of this to 
happen in a way that makes sense to users, to implementors, and that 
enables the actual use cases we agree on. Note that the use cases are 
likely to require specification of things like "when can you interop 
between two systems," "what permissions do you have when you interop," 
"how do we represent various media types (meshes, textures, sounds, 
animations etc)," etc.

This is why I think that agreeing on use cases is necessary to get 
anywhere. Once we have use cases, we can tease out requirements. Once we 
have requirements, we can let those guide the interoperability model and 
the fusing of protocols necessary.

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Sun, 1 Mar 2009 21:01:48 +0000

On Sun, Mar 1, 2009 at 6:13 PM, Jon Watte <[email-masked]> wrote:

> properties necessary to satisfy our accepted use cases, and make sure that
> those are transportable. We're all creative people, and we can think of
> thousands of properties that "might make sense" -- but that would be
> over-engineering. We need to settle on specifically those properties that
> are necessary to satisfy our use cases, and no more.

Sure!  Uses cases are the primary tool by which a world identifies its most
important properties, so I agree completely.  And what's more, it's up to
each world (or world *type *at least) to define which use cases are most
relevant, and hence to define its own "most important properties".  It's
nobody else's business, because aims and goals and worldviews will differ
widely.

And once we have done that, for all the classes of worlds that we choose to
consider (that choice itself will be an interesting topic), then we can find
the intersection to satisfy my point 1.

> see, actually doesn't need "blush," so I don't think we need to specify that
> property.
>

Let's assume for a moment that There is one of the worlds types that we
choose to embrace (that's a separate discussion so let's not visit it
here).  If blushing is determined to be important within key use cases
central to the operation of that world (determined by There proponents
preferably, although presumably we could "do our best" in their absence),
then it gets added to There's property set.

When the intersection of world property sets is made, if blushing doesn't
appear in the intersection set then we have two options, only one of which
is consistent with our diversity goals in my opinion:

   - We can totally exclude blushing from further consideration -- I find
   this objectionable because There has named blushing as important, and it
   would deny There the ability to use our protocol for talking to other "There
   worlds".  Alternatively,
   - We can find a means to handle blushing by making our protocol
   sufficiently type-extensible, so that while nobody else uses a blushing
   extension because it has no meaning to them, multiple There worlds still
   can.  Unless very strong reasons are presented why this would be a disaster
   for everyone else, I believe that this would be the correct way to approach
   the problem.  After all, it might then allow the protocol to handle the case
   of "Going Pale with Fright" in some other world too.

>
> We need to identify a set of properties that we can assume are understood
> by everyone.

Everything in the intersection set has that property.  Agreed.

> That means that if two worlds say that they support MMOX, I know what that
> means. (It won't be the MOSS situation).
> Additionally, we must allow additional properties to be exchanged between
> worlds that can agree on additional semantics. In general, this is how the
> protocol can grow organically.

That's extensibility.  Agreed.

>
> Finally, we need to come up with a model that allows all of this to happen
> in a way that makes sense to users, to implementors, and that enables the
> actual use cases we agree on. Note that the use cases are likely to require
> specification of things like "when can you interop between two systems,"
> "what permissions do you have when you interop," "how do we represent
> various media types (meshes, textures, sounds, animations etc)," etc.
>

Sure, as long as we don't mix up world semantics and policy decisions with
what's carried as payload by the protocol.  The protocol will merely allow
systems to carry out the relevant discussions (the syntax being entirely
world-agnostic), and it will always be up to the endpoints to choose
payloads and to reply Yes or No in responses.

> have requirements, we can let those guide the interoperability model and the
> fusing of protocols necessary.
>
> Agreed.

Incidentally, during the early months of the AWG, we did an immense amount
of Brainstorming <https://wiki.secondlife.com/wiki/Brainstorming> work to
tease out existing and expected Use
Cases<https://wiki.secondlife.com/wiki/Use_Cases>.
Most of this was SL-specific, but since the SL use cases will naturally
populate the SL properties set, such prior breakdowns will undoubtedly
provide input to the SL side of the analysis.

Morgaine.

On Sun, Mar 1, 2009 at 6:13 PM, Jon Watte <[email-masked]> wrote:

> Morgaine wrote:
>
>> So, what values of interoperability are we aiming for?  All we can say is
>> "/as high as possible/", because even giving a specific number would run
>> counter to the premise of world diversity.  What we are trying to do then is
>> the following:
>>
> properties necessary to satisfy our accepted use cases, and make sure that
> those are transportable. We're all creative people, and we can think of
> thousands of properties that "might make sense" -- but that would be
> over-engineering. We need to settle on specifically those properties that
> are necessary to satisfy our use cases, and no more.
>
> see, actually doesn't need "blush," so I don't think we need to specify that
> property.
>
>
> We need to identify a set of properties that we can assume are understood
> by everyone. That means that if two worlds say that they support MMOX, I
> know what that means. (It won't be the MOSS situation).
> Additionally, we must allow additional properties to be exchanged between
> worlds that can agree on additional semantics. In general, this is how the
> protocol can grow organically.
> Finally, we need to come up with a model that allows all of this to happen
> in a way that makes sense to users, to implementors, and that enables the
> actual use cases we agree on. Note that the use cases are likely to require
> specification of things like "when can you interop between two systems,"
> "what permissions do you have when you interop," "how do we represent
> various media types (meshes, textures, sounds, animations etc)," etc.
>
> have requirements, we can let those guide the interoperability model and the
> fusing of protocols necessary.
>
> Sincerely,
>
> jw
>
>
>

---

From: Jon Watte <[email-masked]>
Date: Sun, 01 Mar 2009 13:30:00 -0800

Morgaine wrote:
>
> And once we have done that, for all the classes of worlds that we 
> choose to consider (that choice itself will be an interesting topic), 
> then we can find the intersection to satisfy my point 1.

I believe that, for practical interoperability, there needs to be a core 
set of capabilities that everyone must implement. If we just define 
profiles, then the major systems will be type-incompatible, because they 
will each just decide to put their own types down the protocol. For 
example, Forterra will put user input into the protocol, and Second Life 
will put server simulation results.

>     * We can find a means to handle blushing by making our protocol
>       sufficiently type-extensible, so that while nobody
>

This seems like a repeat of what I already said, so I guess we agree :-)

> Sure, as long as we don't mix up world semantics and policy decisions 
> with what's carried as payload by the protocol.  The

I believe that there are some major policy decisions that have to be 
decided upon for interoperability's sake, though. For example, the 
policy decision "universal client" versus "translation gateway," and the 
policy decision "common execution environment" vs "separate execution 
environments." I happen to think that "universal client" and "common 
execution environment" are non-starters in this day and age (perhaps 10 
years down the line we can talk about it), but we all need to formally 
agree on that before that can be assumed. And if we're not all agreeing 
on that, we won't reach any reasonable degree of interop.

> Incidentally, during the early months of the AWG, we did an immense 
> amount of Brainstorming 
> <https://wiki.secondlife.com/wiki/Brainstorming> work to tease out 
> existing and expected Use Cases 
> <https://wiki.secondlife.com/wiki/Use_Cases>.  Most of this was 
> SL-specific, but since the SL use cases will naturally populate the SL 
> properties set, such prior breakdowns will undoubtedly provide input 
> to the SL side of the analysis.

Interesting. That's the first I've seen of those, although I've bee 
asking for use cases other than the five I proposed for a while.

However, the use cases listed seem to have two weaknesses:
1) They don't describe in sufficient detail what the actions and 
reactions are.
2) They seem to specify a lot of actions that are provider- and 
technology-specific, and thus are probably not good use cases for interop

Are you, or someone you know, working on teasing out the appropriate 
interop cases from that list, and presenting them in a richer form 
suitable for capturing requirements? I think that would be very worthwhile.

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Sun, 1 Mar 2009 22:00:41 +0000

Jon highlighted how use-case analysis actually drives the process of
discovering world properties, which I had rather obscured by making point 1
the *intersection *of world property sets.  Describing this step separately
would I think add clarity.  What's more, the role played by extensibility,
as we discussed, can be added to this skeleton too.  Let's rewrite this
top-down master plan (;-) making these additions explicit.

What we are trying to do then, quite explicitly, is the following:

   1. To identify the key set of properties relevant to each world that we
   represent or know about (and as many others as we can capture), most
   commonly through examination of use cases and their corresponding
   requirements.
   2. To identify the largest possible intersection between the property
   sets identified in point 1, adding extensibility mechanisms where necessary
   to avoid excluding worlds.
   3. To create a protocol that permits the properties in that intersection
   to be transported between the diverse worlds.

As before, this both establishes our plan of attack and defines
what we mean by "success" in our task.  We will have succeeded if our
protocol has achieved transport with highly complete and fair coverage of
the intersection of world properties that we
identified in 2.

Morgaine.

PS. Note that this top-down approach does not preclude simultaneous
discussion of the lowest level data abstractions that we will use in point
3.  The reason for this is simply that we *already* *know* from our combined
prior experience the kinds of data representation that will be needed for
this task.

---

From: Jon Watte <[email-masked]>
Date: Sun, 01 Mar 2009 16:34:23 -0800

Morgaine wrote:

    3. To create a protocol that permits the properties in that
    intersection to be transported between the diverse worlds.

I think a protocol and a model would be necessary.

> protocol has achieved transport with highly complete and fair coverage 
> of the intersection of world properties that we
> identified in 2.
>

I believe we're not successful until this transport has been implemented 
in at least two separate virtual world technologies, and we can actually 
deliver on the use cases we set out to deliver on. Protocol transport is 
a necessary but not sufficient part of that.

> The reason for this is simply that we /already/ /know/ from our 
> combined prior experience the kinds of data representation that will 
> be needed for this task.
>

However, there is a significant risk that we work on things we /already 
know/, but which end up not being suitable or needed for interoperability.
For example, the published OGP mostly talks about how to inject avatars 
and other state into simulation servers. I believe that the process of 
how authoritative objects come to run on simulation servers is actually 
something that is technology dependent, and thus outside the purview of 
interop.

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Mon, 2 Mar 2009 01:02:25 +0000

On Sun, Mar 1, 2009 at 9:30 PM, Jon Watte <[email-masked]> wrote:

> set of capabilities that everyone must implement.

I don't see it that way at all.  I see the protocol offering a smorgasbord
of capabilities, but it being entirely up to the endpoints to choose which
items they pick from it.

We've already mentioned Limited Capability Clients in that context:  the
screenless music player might pick only a live music concert location and
audio stream capabilities, while the braille reader might pick only a
textual lecture location and text stream capabilities.  Yet, these options
could be requested from a world that offers a vastly greater set of choices
for full-capability clients.  Indeed, IM-only clients already exist for the
SL platform.

Requiring a core set of capabilities that everyone *must* implement is
completely unnecessary, and would preclude the above scenarios.

> If we just define profiles, then the major systems will be
> type-incompatible, because they will each just decide to put their own types
> down the protocol. For example, Forterra will put user input into the
> protocol, and Second Life will put server simulation results.
>

Well we can't *force* providers to interoperate.  If they desire to though,
then they will choose common data types.

> decided upon for interoperability's sake, though. For example, the policy
> decision "universal client" versus "translation gateway," and the policy
> decision "common execution environment" vs "separate execution
> years down the line we can talk about it), but we all need to formally agree
> on that before that can be assumed.

Well we're just defining protocols for endpoints, and how people choose to
use them is really up to them.  "Universal client" seems to be a bit of a
trigger word for some, but *generic* clients are very common in many areas,
and undoubtedly they will be common in VWs too.

Indeed, we already have the beginings of that in the SL sphere, where third
parties have already made clients that work with at least 3 different grid
types, and include a superset of the client capabilities required by them
(for instance, multiple avatar implementations).

>
> And if we're not all agreeing on that, we won't reach any reasonable degree
> of interop.
>

Well I started this thread so that we could have a more analytic measure of
what constitutes "good interop", because a fair amount of handwaving was
going on with "interop" being used to mean whatever currently suited the
argument. ;-)  To recap:

"*We will have succeeded if our protocol has achieved transport with highly
complete and fair coverage of the intersection of world properties that we
identified in 2*."

What clients look like isn't really germane to this, so we don't really need
to agree much about them at all, with the possible exception of
connection/login issues that pertain even to LCCs.  The execution
environment does impact very strongly on world properties of many worlds
though, so I'm sure that we'll be looking at it very soon. :-)

>> tease out existing and expected Use Cases <
>> https://wiki.secondlife.com/wiki/Use_Cases>.  Most of this was
>> properties set, such prior breakdowns will undoubtedly provide input to the
>> SL side of the analysis.
>>
>
> Interesting. That's the first I've seen of those, although I've bee asking
> for use cases other than the five I proposed for a while.
>
> 1) They don't describe in sufficient detail what the actions and reactions
> are.

Item 1) is true.  Those use cases were created for a somewhat different
purpose than to illustrate interop.  However, they may help by providing
input to the process, and they do capture some of the scalability
requirements that will apply in an extended metaverse.

Item 2) is inevitable:  the use cases of most interest within an existing
world will always be captured in terms of that world's technology and with
reference to its main providers.  Also, as we outlined when examining the
top-down protocol design process, it is an important purpose of use cases to
identify the most important properties of a world without reference to
interop at all, so that subsequently we can identify the intersection of all
such world property sets.

> interop cases from that list, and presenting them in a richer form suitable
> for capturing requirements? I think that would be very worthwhile.
>

Not me specifically, as I don't represent SL.  I do however have great
interest in scalability and in going beyond the limitations of existing
worlds in that area, so I am very likely to describe use cases that reflect
that interest across a variety of worlds.  No doubt others will be focussing
on use cases specific to SL's needs.

Morgaine.

On Sun, Mar 1, 2009 at 9:30 PM, Jon Watte <[email-masked]> wrote:

> Morgaine wrote:
>
>>
>> And once we have done that, for all the classes of worlds that we choose
>> to consider (that choice itself will be an interesting topic), then we can
>> find the intersection to satisfy my point 1.
>>
>
> will each just decide to put their own types down the protocol. For example,
> Forterra will put user input into the protocol, and Second Life will put
> server simulation results.
>
>> what's carried as payload by the protocol.  The
>>
>
> decided upon for interoperability's sake, though. For example, the policy
> decision "universal client" versus "translation gateway," and the policy
> decision "common execution environment" vs "separate execution
> years down the line we can talk about it), but we all need to formally agree
> on that before that can be assumed. And if we're not all agreeing on that,
> we won't reach any reasonable degree of interop.
>
>> tease out existing and expected Use Cases <
>> https://wiki.secondlife.com/wiki/Use_Cases>.  Most of this was
>> properties set, such prior breakdowns will undoubtedly provide input to the
>> SL side of the analysis.
>>
>
> Interesting. That's the first I've seen of those, although I've bee asking
> for use cases other than the five I proposed for a while.
>
> 1) They don't describe in sufficient detail what the actions and reactions
> are.
> interop cases from that list, and presenting them in a richer form suitable
> for capturing requirements? I think that would be very worthwhile.
>
> Sincerely,
>
> jw
>
>

---

From: Jesrad <[email-masked]>
Date: Mon, 2 Mar 2009 11:33:31 +0100

> of capabilities, but it being entirely up to the endpoints to choose which

A tree of interoperability levels or shared compatible features will
need a common trunk to branch from, in any case. I tend to think this
common trunk would be the Agent domain features, but if we're to limit
the VWs to those who have spatial representation of elements, the
Region domain might fit too.

> Well we can't force providers to interoperate.  If they desire to though, then they will choose common
> data types.

Wouldn't arrange for reasonable common data types help, though ? A PDU
can pass information as both payload and reference: I can see MMOX
have a "native" format in addition to being capable of encapsulating
non-native formats for cross-grid delivery.

> trigger word for some, but generic clients are very common in many areas,

Completely agree here, the endpoint for any cross-grid case can be
centralized or distributed as the grid's locale commands. However this
implies the MMOX protocol does not do many exotic routing/caching
signalling (we cannot expect a simple translation gateway to also do
massive caching of an entire P2P library of assets from outside, or to
proxy some simulation processes).

I believe there also are fairly generic server software available for
MMOs these days, although they are certainly not used by the "big
players" it might be worth a look.

(I think someone earlier listed me as a representative for Solipsis ?
I'd like to point out that I'm not, I just happen to work for the
company that develops it and have a personal interest in it)

On Mon, Mar 2, 2009 at 2:02 AM, Morgaine <[email-masked]> wrote:
> Requiring a core set of capabilities that everyone must implement is
> Well we can't force providers to interoperate.  If they desire to though,
> trigger word for some, but generic clients are very common in many areas,
>> And if we're not all agreeing on that, we won't reach any reasonable
>> degree of interop.
>
>
> "We will have succeeded if our protocol has achieved transport with highly
> identified in 2."
>>> amount of Brainstorming <https://wiki.secondlife.com/wiki/Brainstorming>
>>> work to tease out existing and expected Use Cases
>>> <https://wiki.secondlife.com/wiki/Use_Cases>.  Most of this was SL-specific,
>>> but since the SL use cases will naturally populate the SL properties set,
>>> such prior breakdowns will undoubtedly provide input to the SL side of the
>>> analysis.
>>
>>> amount of Brainstorming <https://wiki.secondlife.com/wiki/Brainstorming>
>>> work to tease out existing and expected Use Cases
>>> <https://wiki.secondlife.com/wiki/Use_Cases>.  Most of this was SL-specific,
>>> but since the SL use cases will naturally populate the SL properties set,
>>> such prior breakdowns will undoubtedly provide input to the SL side of the
>>> analysis.
>>
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>
>

---

From: "Frisby, Adam" <[email-masked]>
Date: Mon, 2 Mar 2009 08:36:03 -0500

This actually raises the question of maybe we should be defining more than interop.

Eg - avatar animations like 'Blush' could probably use their own separate standard, say a 'Simple Avatar Expression Protocol' or something that rides on over the top as part of a 'Content-type: application/mmox-avatar'.

I think what we want to be defining is a set of standards which can be utilized either together or separately, and extended individually, as a starter set, I think we probably need to decide on mechanisms for:

-          Connection, Authentication and other non-world identity issues

-          A world 'wire-protocol' (MXP, LESS, etc) which allows transmitting of Scenegraph updates.

-          A content/asset description and download protocol (HTTP?), utilizing something like MIME content-type's.

-          A suggested standard for content packaging, transmission and decoding (COLLADA?)

Then once those are done, it becomes possible to look at what worlds share and build side standards so those can be displayed in a variety of worlds that support them.

Regards,

Adam

From: [email-masked] [mailto:[email-masked]] On Behalf Of Morgaine
Sent: Sunday, 1 March 2009 1:02 PM
To: Jon Watte
Cc: MMOX-IETF
Subject: Re: [mmox] Interop Metrics and MMOX Goals

On Sun, Mar 1, 2009 at 6:13 PM, Jon Watte <[email-masked]<mailto:[email-masked]>> wrote:
Morgaine wrote:

  1. to identify the largest possible intersection between the property sets of all the worlds that we represent or know about and as many others as we can capture, and then
  2. to create a protocol that permits the properties in that
     intersection to be transported between worlds.

I would phrase that somewhat differently. I want us to identify the properties necessary to satisfy our accepted use cases, and make sure that those are transportable. We're all creative people, and we can think of thousands of properties that "might make sense" -- but that would be over-engineering. We need to settle on specifically those properties that are necessary to satisfy our use cases, and no more.

Sure!  Uses cases are the primary tool by which a world identifies its most important properties, so I agree completely.  And what's more, it's up to each world (or world type at least) to define which use cases are most relevant, and hence to define its own "most important properties".  It's nobody else's business, because aims and goals and worldviews will differ widely.

And once we have done that, for all the classes of worlds that we choose to consider (that choice itself will be an interesting topic), then we can find the intersection to satisfy my point 1.

For example: There.com avatars can blush. This is done using a "blush" scalar property on the avatars. (Other options might be to support animations that animate color values, using texture swaps, using texture scrolling, etc). However, I believe that interop, in the use cases I can see, actually doesn't need "blush," so I don't think we need to specify that property.

Let's assume for a moment that There is one of the worlds types that we choose to embrace (that's a separate discussion so let's not visit it here).  If blushing is determined to be important within key use cases central to the operation of that world (determined by There proponents preferably, although presumably we could "do our best" in their absence), then it gets added to There's property set.

When the intersection of world property sets is made, if blushing doesn't appear in the intersection set then we have two options, only one of which is consistent with our diversity goals in my opinion:

 *   We can totally exclude blushing from further consideration -- I find this objectionable because There has named blushing as important, and it would deny There the ability to use our protocol for talking to other "There worlds".  Alternatively,
 *   We can find a means to handle blushing by making our protocol sufficiently type-extensible, so that while nobody else uses a blushing extension because it has no meaning to them, multiple There worlds still can.  Unless very strong reasons are presented why this would be a disaster for everyone else, I believe that this would be the correct way to approach the problem.  After all, it might then allow the protocol to handle the case of "Going Pale with Fright" in some other world too.

> I see the above as both establishing our plan of attack and also defining what we mean by "success" in our task.  We will have succeeded if our protocol has achieved transport with highly complete and fair coverage of the intersection of world properties that we have identified.

We need to identify a set of properties that we can assume are understood by everyone.

That means that if two worlds say that they support MMOX, I know what that means. (It won't be the MOSS situation).
Additionally, we must allow additional properties to be exchanged between worlds that can agree on additional semantics. In general, this is how the protocol can grow organically.

Finally, we need to come up with a model that allows all of this to happen in a way that makes sense to users, to implementors, and that enables the actual use cases we agree on. Note that the use cases are likely to require specification of things like "when can you interop between two systems," "what permissions do you have when you interop," "how do we represent various media types (meshes, textures, sounds, animations etc)," etc.

Sure, as long as we don't mix up world semantics and policy decisions with what's carried as payload by the protocol.  The protocol will merely allow systems to carry out the relevant discussions (the syntax being entirely world-agnostic), and it will always be up to the endpoints to choose payloads and to reply Yes or No in responses.

This is why I think that agreeing on use cases is necessary to get anywhere. Once we have use cases, we can tease out requirements. Once we have requirements, we can let those guide the interoperability model and the fusing of protocols necessary.
Agreed.

Incidentally, during the early months of the AWG, we did an immense amount of Brainstorming<https://wiki.secondlife.com/wiki/Brainstorming> work to tease out existing and expected Use Cases<https://wiki.secondlife.com/wiki/Use_Cases>.  Most of this was SL-specific, but since the SL use cases will naturally populate the SL properties set, such prior breakdowns will undoubtedly provide input to the SL side of the analysis.

Morgaine.

On Sun, Mar 1, 2009 at 6:13 PM, Jon Watte <[email-masked]<mailto:[email-masked]>> wrote:
Morgaine wrote:
So, what values of interoperability are we aiming for?  All we can say is "/as high as possible/", because even giving a specific number would run counter to the premise of world diversity.  What we are trying to do then is the following:
  1. to identify the largest possible intersection between the

I would phrase that somewhat differently. I want us to identify the properties necessary to satisfy our accepted use cases, and make sure that those are transportable. We're all creative people, and we can think of thousands of properties that "might make sense" -- but that would be over-engineering. We need to settle on specifically those properties that are necessary to satisfy our use cases, and no more.

For example: There.com avatars can blush. This is done using a "blush" scalar property on the avatars. (Other options might be to support animations that animate color values, using texture swaps, using texture scrolling, etc). However, I believe that interop, in the use cases I can see, actually doesn't need "blush," so I don't think we need to specify that property.

I see the above as both establishing our plan of attack and also defining what we mean by "success" in our task.  We will have succeeded if our protocol has achieved transport with highly complete and fair coverage of the intersection of world properties that we have identified.

We need to identify a set of properties that we can assume are understood by everyone. That means that if two worlds say that they support MMOX, I know what that means. (It won't be the MOSS situation).
Additionally, we must allow additional properties to be exchanged between worlds that can agree on additional semantics. In general, this is how the protocol can grow organically.
Finally, we need to come up with a model that allows all of this to happen in a way that makes sense to users, to implementors, and that enables the actual use cases we agree on. Note that the use cases are likely to require specification of things like "when can you interop between two systems," "what permissions do you have when you interop," "how do we represent various media types (meshes, textures, sounds, animations etc)," etc.

This is why I think that agreeing on use cases is necessary to get anywhere. Once we have use cases, we can tease out requirements. Once we have requirements, we can let those guide the interoperability model and the fusing of protocols necessary.

Sincerely,

jw

---

From: Lawson English <[email-masked]>
Date: Mon, 02 Mar 2009 07:57:51 -0700

Frisby, Adam wrote:
> Eg – avatar animations like ‘Blush’ could probably use their own 
> separate standard, say a ‘Simple Avatar Expression Protocol’ or 
> something that rides on over the top as part of a ‘Content-type: 
> application/mmox-avatar’.
>
> I think what we want to be defining is a set of standards which can be 
> utilized either together or separately, and extended individually, as 
> a starter set, I think we probably need to decide on mechanisms for:
>
> - A world ‘wire-protocol’ (MXP, LESS, etc) which allows transmitting 
> of Scenegraph updates.
>
> - A content/asset description and download protocol (HTTP?), utilizing 
> something like MIME content-type’s.
>
> Then once those are done, it becomes possible to look at what worlds 
> share and build side standards so those can be displayed in a variety 
> of worlds that support them.
>
> Regards,
>
> Adam
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Morgaine
> *Sent:* Sunday, 1 March 2009 1:02 PM
> *To:* Jon Watte
> *Cc:* MMOX-IETF
> *Subject:* Re: [mmox] Interop Metrics and MMOX Goals
>
> sets of all the worlds that we represent or know about and as many 
> others as we can capture, and then
> Sure! Uses cases are the primary tool by which a world identifies its 
> most important properties, so I agree completely. And what's more, 
> it's up to each world (or world /type /at least) to define which use 
> cases are most relevant, and hence to define its own "most important 
> properties". It's nobody else's business, because aims and goals and 
> worldviews will differ widely.
>
>     For example: There.com avatars can blush. This is done using a
>     "blush" scalar property on the avatars. (Other options might be to
>     support animations that animate color values, using texture swaps,
>     using texture scrolling, etc). However, I believe that interop, in
>     the use cases I can see, actually doesn't need "blush," so I don't
>     think we need to specify that property.
>
>
>
> Let's assume for a moment that There is one of the worlds types that 
> we choose to embrace (that's a separate discussion so let's not visit 
> it here). If blushing is determined to be important within key use 
> cases central to the operation of that world (determined by There 
> proponents preferably, although presumably we could "do our best" in 
> their absence), then it gets added to There's property set.
>
> When the intersection of world property sets is made, if blushing 
> doesn't appear in the intersection set then we have two options, only 
> one of which is consistent with our diversity goals in my opinion:
>
>     * We can totally exclude blushing from further consideration -- I
>       find this objectionable because There has named blushing as
>       important, and it would deny There the ability to use our
>       protocol for talking to other "There worlds". Alternatively,
>       sufficiently type-extensible, so that while nobody else uses a
>       blushing extension because it has no meaning to them, multiple
>       There worlds still can. Unless very strong reasons are presented
>       why this would be a disaster for everyone else, I believe that
>       this would be the correct way to approach the problem. After
>       all, it might then allow the protocol to handle the case of
>       "Going Pale with Fright" in some other world too.
>
>
>     succeeded if our protocol has achieved transport with highly
>     complete and fair coverage of the intersection of world properties
>     that we have identified.
>
>     understood by everyone.
>     That means that if two worlds say that they support MMOX, I know
>     what that means. (It won't be the MOSS situation).
>     between worlds that can agree on additional semantics. In general,
>     this is how the protocol can grow organically.
>
>
>     Finally, we need to come up with a model that allows all of this
>     to happen in a way that makes sense to users, to implementors, and
>     that enables the actual use cases we agree on. Note that the use
>     cases are likely to require specification of things like "when can
>     you interop between two systems," "what permissions do you have
>     when you interop," "how do we represent various media types
>     (meshes, textures, sounds, animations etc)," etc.
>
>
> with what's carried as payload by the protocol. The protocol will 
> merely allow systems to carry out the relevant discussions (the syntax 
> being entirely world-agnostic), and it will always be up to the 
> endpoints to choose payloads and to reply Yes or No in responses.
>
>
>     anywhere. Once we have use cases, we can tease out requirements.
>     Once we have requirements, we can let those guide the
>     interoperability model and the fusing of protocols necessary.
>
> Agreed.
>
> animations that animate color values, using texture swaps, using 
> texture scrolling, etc). However, I believe that interop, in the use 
> cases I can see, actually doesn't need "blush," so I don't think we 
> need to specify that property.
>

MPEG-21 has been working on avatar/mesh/facial expression definitions. 
I'm not sure how "realtime" they are in comparison to what virtual 
worlds use, but it might be good to consider the work that has been done.

And I think that we need to understand that not every virtual world is 
going to interact with every other virtual world in the same way to the 
same degree. Different solutions may make sense for interactions between 
different worlds. Certainly, when two worlds are quite close, like plain 
vanilla OpenSim and Second Life, concentrating on a LESS-ish protocol 
might be counter-productive. On the other hand, assuming that LESS (or 
whatever grows out of it) has no place whatsoever in interop between 
closely related worlds would probably be wrong as well.

L