Subject: [mmox] what does it mean to be interoperable?

From: Meadhbh Hamrick (Infinity) <[email-masked]>
Date: Thu, 26 Feb 2009 10:37:23 -0800

so it seems clear we all have different ideas of what it means to be  
interoperable.

i thought i might try to define a couple of the definitions i think  
i've seen people use:

1. interoperability means all virtual worlds, wherever they are, may  
be accessed via a single unified client.

2. interoperability means all virtual worlds, wherever they are, use  
precisely the same protocol(s) and all virtual worlds represent data  
in formats understandable by all other virtual worlds, with a  
universal client.

3. interoperability means some virtual worlds may be accessed via a  
single unified client.

4. interoperability means some virtual worlds use precisely the same  
protocol(s) and all virtual worlds represent data in formats  
understandable by all other virtual worlds, without a universal client.

5. interoperability means some virtual worlds use some of the same  
protocols, without a universal client

6. interoperability means the "model" is the same, but with different  
protocols that may be bridged with protocol gateways.

it seems to me that many of us are using different descriptions for  
the word "interoperable" and it's causing mild discord and at least a  
couple instances of us talking past each other.

personally.. i'm kind of interested in option 5. it has the benefit of  
producing a protocol that is identifiable by routers, network  
management software, etc. it also provides a "slowly moving target"  
for open source developers (as opposed to the "fast moving target" of  
linden's existing protocol(s)). by making it public, VW operators can  
choose whether or not they wish to implement it. it also doesn't  
require VW operators to implement it (as if we could anyway) and it  
allows VW operators to avoid having to test interoperability with  
every other virtual world.

but it's not without drawbacks... this model can lead to a "MOSS-like"  
environment. (for those of you who don't remember MOSS or MIME  
Object(?) Security Services... it was a response to the drawbacks of  
PEM (privacy enhanced mail) which had a relative paucity of encryption  
options. but IMHO, MOSS introduced so many options that it was VERY  
easy for two implementations to adhere to the spec, but not actually  
be interoperable.)

so... i recommend that if we (as a group) wanted to pursue option-5..  
we also explicitly define what goes in an "interoperability profile."  
that way you could get the benefit of having a relatively stable  
protocol that could be targeted by open source developers which could  
be used by VW operators to help make client / server apps.

VW operators could publish their "interoperability profile" to tell  
people who wanted to build tools, extra services, or interoperable  
worlds what options would be available and how they would work.

-cheers
-m

---

From: Jon Watte <[email-masked]>
Date: Thu, 26 Feb 2009 11:53:06 -0800

> understandable by all other virtual worlds, without a universal client.

I would add option 4.5:

4.5: interoperability means all virtual worlds understand a precise set 
of protocols and all virtual worlds understand data represented in a 
common set of formats, without a universal client.

That may be what you meant, but the way you wrote it, it sounds like it 
dictates implementation details, which I think we should stay away from.

> be used by VW operators to help make client / server apps.

I think we need to pursue 4.5, for exactly the reason you're suggesting: 
we want to avoid what you call "MOSS-like" behavior: two systems that 
claim to be interoperable, can't actually interoperate.

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Thu, 26 Feb 2009 21:58:13 +0000

On Thu, Feb 26, 2009 at 6:37 PM, Infinity Meadhbh Hamrick <
[email-masked]> wrote:

> ...
> personally.. i'm kind of interested in option 5.

Options 5 is a perfectly good option for a workgroup formed around the
common goal of implementing some specific protocols in a similarly-focused
group.  As you pointed out in your paragraph that I quoted concerning
"taxonomy of topics"<http://www.ietf.org/mail-archive/web/mmox/current/msg00724.html>,
the protocols which you intend to use are those based on the OGP model.
This sounds like an excellent thing to tackle, in an OGP workgroup.  I would
look forward to that work, as it would undoubtedly help advance interop
between SL-like worlds.  Furthermore, the workgroup name and charter would
honestly reflect the intent, allowing participants interested in such a goal
to work productively with helpful consensus.

In contrast, as pointed out by our co-chair under "Charter, Scope,
Activities"<http://www.ietf.org/mail-archive/web/mmox/current/msg00025.html>and
in even more detail under "Strawman
scope/goals/approach"<http://www.ietf.org/mail-archive/web/mmox/current/msg00626.html>,
the goals and intent of MMOX are very different to the above, and the name
of the group reinforces that.  The narrow scope of Option 5 and the specific
focus on LL technologies doesn't come anwhere near the catchment area that
MMOX participants have been discussing.

I think that both of the above are worthy goals to be handled under the
aegis of the IETF.  But work on OGP is hampered by the very clear fact that
MMOX discussions and requirements are far broader and can't be forced into
an a priori straightjacket.  By the same token, work on MMOX is likewise
being hampered by a narrow focus on near-term Linden goals.

This is why I am trying to find an approach that will allow both groups of
interests to be successful and productive.  Currently there is little
commonality owing to the gulf between the actual narrow intent stated in
your "taxonomy of topics" and the very much broader goals of MMOX.

Morgaine.

On Thu, Feb 26, 2009 at 6:37 PM, Infinity Meadhbh Hamrick <
[email-masked]> wrote:

> i thought i might try to define a couple of the definitions i think i've
> seen people use:
>
> 1. interoperability means all virtual worlds, wherever they are, may be
> accessed via a single unified client.
>
> precisely the same protocol(s) and all virtual worlds represent data in
> formats understandable by all other virtual worlds, with a universal client.
>
> 3. interoperability means some virtual worlds may be accessed via a single
> unified client.
>
> protocol(s) and all virtual worlds represent data in formats understandable
> by all other virtual worlds, without a universal client.
>
> it seems to me that many of us are using different descriptions for the
> word "interoperable" and it's causing mild discord and at least a couple
> instances of us talking past each other.
>
> producing a protocol that is identifiable by routers, network management
> software, etc. it also provides a "slowly moving target" for open source
> developers (as opposed to the "fast moving target" of linden's existing
> protocol(s)). by making it public, VW operators can choose whether or not
> they wish to implement it. it also doesn't require VW operators to implement
> it (as if we could anyway) and it allows VW operators to avoid having to
> test interoperability with every other virtual world.
>
> environment. (for those of you who don't remember MOSS or MIME Object(?)
> Security Services... it was a response to the drawbacks of PEM (privacy
> enhanced mail) which had a relative paucity of encryption options. but IMHO,
> MOSS introduced so many options that it was VERY easy for two
> implementations to adhere to the spec, but not actually be interoperable.)
>
> so... i recommend that if we (as a group) wanted to pursue option-5.. we
> also explicitly define what goes in an "interoperability profile." that way
> you could get the benefit of having a relatively stable protocol that could
> be targeted by open source developers which could be used by VW operators to
> help make client / server apps.
>
> VW operators could publish their "interoperability profile" to tell people
> who wanted to build tools, extra services, or interoperable worlds what
> options would be available and how they would work.
>
> -cheers
> -m
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Thu, 26 Feb 2009 14:26:20 -0800

why would MMOX be limited to pursuing only OGP if we want to define  
OGP in a standards body?

POP3 and IMAP are both defined in RFCs, after all. ( though i believe  
they did come out of different working groups )

maybe we _should_ re-charter with a more OGP-centric view and pursue  
interoperability option 5, but this would effectively move any OLIVE  
standardization effort into a different WG, and with two different VW  
"regimes," interop options 1 and 2 would be impossible. JW spoke in  
support of option 4.5 (which yes, has the same intent as what i was  
going for with option 4.)

i don't know if linden could ever support an option-4, because of our  
desire to have interoperability drive "user innovation." in other  
words, we'll always be interested in a situation where developers  
could extend the protocol to support value-added services. we're not  
terribly frightened of option-5 because our view of the world has VW  
operators deploying client software unique to their solution to handle  
these value-added services.

in short, we expect OGP to never be a complete specification of a  
virtual world protocol, but rather a protocol framework that together  
with an interoperability profile sufficiently specifies client and  
server behavior to achieve some measure of interoperability.

On Feb 26, 2009, at 1:58 PM, Morgaine wrote:

> On Thu, Feb 26, 2009 at 6:37 PM, Infinity Meadhbh Hamrick <[email-masked] 
> > wrote:
>
> Options 5 is a perfectly good option for a workgroup formed around  
> the common goal of implementing some specific protocols in a  
> similarly-focused group.  As you pointed out in your paragraph that  
> I quoted concerning "taxonomy of topics", the protocols which you  
> intend to use are those based on the OGP model.  This sounds like an  
> excellent thing to tackle, in an OGP workgroup.  I would look  
> forward to that work, as it would undoubtedly help advance interop  
> between SL-like worlds.  Furthermore, the workgroup name and charter  
> would honestly reflect the intent, allowing participants interested  
> in such a goal to work productively with helpful consensus.
>
> Activities" and in even more detail under "Strawman scope/goals/ 
> approach", the goals and intent of MMOX are very different to the  
> above, and the name of the group reinforces that.  The narrow scope  
> of Option 5 and the specific focus on LL technologies doesn't come  
> anwhere near the catchment area that MMOX participants have been  
> discussing.
>
> I think that both of the above are worthy goals to be handled under  
> the aegis of the IETF.  But work on OGP is hampered by the very  
> clear fact that MMOX discussions and requirements are far broader  
> and can't be forced into an a priori straightjacket.  By the same  
> token, work on MMOX is likewise being hampered by a narrow focus on  
> near-term Linden goals.
>
> This is why I am trying to find an approach that will allow both  
> groups of interests to be successful and productive.  Currently  
> there is little commonality owing to the gulf between the actual  
> narrow intent stated in your "taxonomy of topics" and the very much  
> broader goals of MMOX.
>
>
> Morgaine.
>
>
>
>
>
>
>
> On Thu, Feb 26, 2009 at 6:37 PM, Infinity Meadhbh Hamrick <[email-masked] 
> > wrote:
> 6. interoperability means the "model" is the same, but with  
> different protocols that may be bridged with protocol gateways.
>
> the word "interoperable" and it's causing mild discord and at least  
> a couple instances of us talking past each other.
>
> personally.. i'm kind of interested in option 5. it has the benefit  
> of producing a protocol that is identifiable by routers, network  
> for open source developers (as opposed to the "fast moving target"  
> of linden's existing protocol(s)). by making it public, VW operators  
> can choose whether or not they wish to implement it. it also doesn't  
> but it's not without drawbacks... this model can lead to a "MOSS- 
> like" environment. (for those of you who don't remember MOSS or MIME  
> PEM (privacy enhanced mail) which had a relative paucity of  
> encryption options. but IMHO, MOSS introduced so many options that  
> it was VERY easy for two implementations to adhere to the spec, but  
> not actually be interoperable.)
>
> so... i recommend that if we (as a group) wanted to pursue  
> option-5.. we also explicitly define what goes in an  
> "interoperability profile." that way you could get the benefit of  
> having a relatively stable protocol that could be targeted by open  
> source developers which could be used by VW operators to help make  
> client / server apps.
>

---

From: Kajikawa Jeremy <[email-masked]>
Date: Fri, 27 Feb 2009 07:51:48 +0900

If the Open Grid Protocol needs redefining ...

Here is a proposal for consideration...

In which case the OGP itself becomes a defined framework with modules
  and each module has a preset function...

<OGP> being the root access of the Open Grid Protocol

<OGP>/Session -- Module for maintaining "Client" connection to the VW,
  *all* additional modules use "handle" for the session module in-use.

 The OGP library only define a standard access library for code modules,
 where individual clients may provide an "own session" module for
protocol

There is two "global" methods used for accessing modules of the OGP
library

  OpenModule()  Load and call an Init Function for the Module named
  CloseModule()  call an Exit() function also allowing the module to be
free'd

 The "Session" module is defined with the following functionality,

  Login - Creating an Active Connection and Identifying to a User
Account
  Logout - Ending an Active Connection
 
  Send() - Extension Modules call this to send anything,
  Recv() - Extension Modules call this to read anything within a set
time,

  ErrorString() - *Optional* provision of error code strings for user
messages

<OGP>::OpenModule(name) returns "handle" for module reference
<OGP>::CloseModule(handle)

<OGP>/Session::Login(server,user,pass) returns token
<OGP>/Session::Logout(token) -> return always success
<OGP>/Session::Send()
<OGP>/Session::Recv()
<OGP>/Session::ErrorString()

The above lacks any reference or allowance for incoming messages to
trigger events,
  and I am assuming everyone here is capable of setting up a mechanism
for read()
  calls to trigger as required or occur at extremely frequent timing
intervals.

Im allowing for the protocol itself to have multiple versions installed
and current code
  to be used side-by-side with new code... if this is feasible...

or am I missing something about the way python works different from C ?

Jeremy

---

From: Christian Scholz <[email-masked]>
Date: Fri, 27 Feb 2009 00:15:27 +0100

I just wonder if you not first need to define what a virtual world is as 
it seems to me a conglomeration of lots of concepts.

E.g. there is the whole social space which seems very similar in what's 
going on on the web and has many aspects to it already. There is also 
the 3D area which is about objects and how to transfer and display them, 
there are avatars, there are actual worlds and so on.

And I think some areas here might be easier to tackle (e.g. mostly 2D 
space) because there might be more common understanding already about 
this (and it's mostly HTML/HTTP based which is used by everybody and 
thus makes things easier).

On the 3D part the question is how to partition further.

I think for different sub-protocols we might choose different variants 
of the choices below.

But one is maybe for sure and that is that 1) and 2) are out for not 
only VWs but for basically everything.

But if you exchange "virtual worlds" by some sub-area then there might 
actually be a unified client for these (again most likely in the social 
space where it can be a web browser). For the full stack it's most 
likely no unified client because I doubt that we all can find one 
solution which fits us all (in all eternity).

So it probably will come down to 5. Maybe some stuff is bridgable with 
not too much effort, then this might be an option for 6 but I have too 
little understanding of all things to really be able to speculate about 
that.

-- Christian

Meadhbh Hamrick (Infinity) schrieb:
> protocol(s)). by making it public, VW operators can choose whether or 
> not they wish to implement it. it also doesn't require VW operators to 
> implement it (as if we could anyway) and it allows VW operators to avoid 
> having to test interoperability with every other virtual world.
> 
> enhanced mail) which had a relative paucity of encryption options. but 
> IMHO, MOSS introduced so many options that it was VERY easy for two 
> also explicitly define what goes in an "interoperability profile." that 
> way you could get the benefit of having a relatively stable protocol 
> that could be targeted by open source developers which could be used by 
> VW operators to help make client / server apps.
> 

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

---

From: Jon Watte <[email-masked]>
Date: Thu, 26 Feb 2009 15:20:39 -0800

> these value-added services.

I believe in that model (4), too. Now there are two things that I think 
are important:
1) An option-4 solution (there are protocols and formats that everyone 
recognizes), it's easy enough to add extensibility, on the level of 
"while we recognize the basic set, we can also recognize these 
additional things." In fact, not doing that would be almost criminally 
shortsighted.
2) An option-4 solution provides the model for interoperability, but for 
innovation or platform-specific features, you simply don't interoperate 
those bits. They are, after all, platform specific. For example, when 
interoperating, the network usage for an OLIVE client will go up, 
because the svelte network usage of OLIVE requires OLIVE-proprietary 
technology.

> server behavior to achieve some measure of interoperability.

So, in effect, it will probably lead to the MOSS outcome, except for 
certain small cliques (There.com clusters talking to other There.com 
clusters; OpenSim talking to Second Life, Croquet talking to Qwaq, etc). 
That is not partucularly exciting to me, because I don't believe it will 
lead to the kinds of interoperability that our customers (and the world 
in general) deserves and demands.

I asked the question before, but didn't get an answer: What would you 
opinion be of doing the OGP/SL/OSim work in a forum like the AWG, and 
doing the option-4 work in the MMOX group? Would you lose anything if 
that's the approach?

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Thu, 26 Feb 2009 15:29:03 -0800

>   CloseModule()  call an Exit() function also allowing the module to be

A protocol and a library are two totally different things. The charter 
of this group is to define a wire protocol, not an API or a library. Do 
you think you can re-phrase your suggestion as a change in protocol, 
rather than change in API?

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Fri, 27 Feb 2009 09:40:32 +0000

On Thu, Feb 26, 2009 at 10:26 PM, Meadhbh Hamrick (Infinity) <
[email-masked]> wrote:

why would MMOX be limited to pursuing only OGP if we want to define OGP in a
> standards body?

Nobody said "*MMOX [would] be limited to pursuing only OGP if we want to
define OGP in a standards body*", so it's not an argument you get to knock
down.

Quite the opposite is true.  MMOX would *NOT* be limited to pursuing only
OGP if the "OGP-only" work were being done in an OGP workgroup.  The MMOX
group would then be free to pursue the broad interop implied in the "MMOX"
name and affirmed by many MMOX posts.  In contrast, conflating the two goals
(both of them very worthy) is causing a lot of conflict, and we could avoid
that with some honest workgroup naming.

> "regimes," interop options 1 and 2 would be impossible. JW spoke in support
> of option 4.5 (which yes, has the same intent as what i was going for with
> option 4.)
>

Re-chartering MMOX to be OGP-only would be a less than upstanding attempt to
acquire the generic "MMOX" label for a technology that is clearly not
vendor-neutral.  It would inherently exclude all participants who have
strong interest in MMO interop but no interest at all in the SL model.  It
would also conflict with the numerous statements made on this list about the
broad aspirations of the group.  OGP-only work should be labelled "OGP",
that would be honest and helpful.

>
> in short, we expect OGP to never be a complete specification of a virtual
> world protocol, but rather a protocol framework that together with an
> interoperability profile sufficiently specifies client and server behavior
> to achieve some measure of interoperability.
>
>
>
Excellent, there is *HUGE* merit in that, which is why I would support such
OGP-oriented work directly and avidly.  But it should be done in an "OGP"
workgroup so that there is clear understanding that the work is devoted to
one particular implementation and does not seek to embrace the world
diversity (and implementation diversity) of "MMOX".

I'm just trying to give everybody the elbow room to be able to work
productively.  Saying that the goal is broad VW interop while simultaneously
requiring the MMOX group to use the SL model is not a recipe for effective
group cooperation.

Morgaine.

On Thu, Feb 26, 2009 at 10:26 PM, Meadhbh Hamrick (Infinity) <
[email-masked]> wrote:

> why would MMOX be limited to pursuing only OGP if we want to define OGP in
> a standards body?
> POP3 and IMAP are both defined in RFCs, after all. ( though i believe they
> did come out of different working groups )
>
> "regimes," interop options 1 and 2 would be impossible. JW spoke in support
> of option 4.5 (which yes, has the same intent as what i was going for with
> option 4.)
>
> desire to have interoperability drive "user innovation." in other words,
> we'll always be interested in a situation where developers could extend the
> protocol to support value-added services. we're not terribly frightened of
> option-5 because our view of the world has VW operators deploying client
> software unique to their solution to handle these value-added services.
>
> in short, we expect OGP to never be a complete specification of a virtual
> world protocol, but rather a protocol framework that together with an
> interoperability profile sufficiently specifies client and server behavior
> to achieve some measure of interoperability.
>
> Activities"<http://www.ietf.org/mail-archive/web/mmox/current/msg00025.html>and in even more detail under "Strawman