Subject: [mmox] Chartering for requirements only

From: Heiner Wolf <[email-masked]>
Date: Wed, 25 Feb 2009 22:09:40 +0100

Hi,

I understand that the original intention was to make OGP public and
get comments. But if that's the purpose you probably should call the
WG OGP.

We had a similar situation in the Instant Message and Presence WG,
where several vendors tried to talk about "their" protocol. Lisa
probably remembers. The situation was solved by chartering the IMPP WG
to create only requirements, then 2 new WGs worked on "their" protocol
(SIMPLE, XMPP). I bet we get a similar discussion. Maybe MMOX should
define requirements and an OGP WG may then work on the OGP way later.
This gives time for other developers to speak up and add learnings
from "their" worlds and protocols. Do we have people from Everquest,
WoW, There, EVE Online, Runescape, Google Earth here? We need them for
something thats called MMOX. We should give them time to speak up.

BTW: we are building a virtual world based on XMPP chat rooms. There
are more, like IMVU, which use chat protocols for their virtual
worlds. The chat room is what you would call a region domain.

This is quite a different angle, but an interesting one, because the
transport protocol is very simple and has few extensions.The
extensions carry the 3D stuff. An interesting feature of worlds which
are based on chat protocols is, that there is low in-band traffic. The
reason is, that off the shelf chat servers are not build for heavy
traffic. So, only notifications are transferrred in the chat protocol.
Assets use a separate data access protocol, usually HTTP.

This simplistic view of people who use chat protocols for virtual
worlds could be useful in identifying "what you really need" for a VW
interop protocol.

hw
-- 
Dr. Heiner Wolf
[email-masked]
www.wolfspelz.de
www.virtual-presence.org

---

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

excellent insight, heiner!

i would not be surprised if this is the direction we take.

On Feb 25, 2009, at 1:09 PM, Heiner Wolf wrote:

> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox

---

From: Gareth Nelson <[email-masked]>
Date: Fri, 27 Feb 2009 01:30:12 +0000

I once built an IMVU-like hack on top of IRC (used a specially
formatted topic, rather messy), it works beautifully well for
IMVU-like systems but breaks down fast once you need physics, there
needs to be more than mere message passing and what Zha constantly
likes to remind us of: state melding.

---

From: Kajikawa Jeremy <[email-masked]>
Date: Fri, 27 Feb 2009 13:24:19 +0900

this is the type of material I am considering in my own plans...

and I am considering Object Vector updates being applicable
  as well as how to divorce an object being represented
  from the active scripting enabling extended functionality.

Ive already got something in mind towards a LOT of this material
  but getting beyond documenting it in my own scrawled notes
  is the part where I am slow

Jeremy

---

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

Well said, Heiner.   Conflating the two quite separate interests into just
one is not helping progress in either direction at the moment.

Morgaine.

---

From: Jesrad <[email-masked]>
Date: Fri, 27 Feb 2009 12:23:35 +0100

Heartily seconded, there are lots of divergent interests that would
hamper the broad adoption of the protocol if we tried to include too
many things, just as well as including too little would severly limit
the interest of the whole thing for the end users.

Which makes me think we might need to tag some of the features as optional.

---

From: Lawson English <[email-masked]>
Date: Fri, 27 Feb 2009 05:27:35 -0700

>> one is not helping progress in either direction at the moment.

My own take is that fragmenting the working group at this point is 
counter-productive. We can
recognize several [types of] low-hanging fruit[s] that may apply to many 
worlds or just 2 or more
of a given type (e.g. Second Life/OpenSIm compatible).

In other words, here's more than one possible sub-tree these 
inter-operable fruits are hanging from and
it is likely more like a digraph than a simple tree (who knows, possibly 
not merely a digraph either if
there are dependencies that go back up the "tree").

E.G.:

Interoperability scenarios for virtual worlds
                          |
-------------------------------------------------------------------------
                          |                                          |

Authentication for SL-type worlds          Authentication of Other worlds
                              /  |  \                                    
                /  |   \     
--------------------------------------------------------   
[...]                 etc
|                               |                        
|                                        / ] \
Agent Domain     HyperGrid      Something Else

At the same level we might search for alternate ways of:

expressing basic protocols

LLSD vs xxSD vs ...

or  of geometry:

OBJ vs SL-extended prims vs Callada vs world-specific terrains/...

or of group IM:

SL-style vs javbber vs irc vs...

Etc.

There's no reason to assume that full interoperability can be obtained 
amongst all worlds
in the same way, but no reason to assume we can't find points of 
commonality which can
mix and match.

 The OGP has made a good start for authentication and TP
between OpenSim and Second Life, and OpenSim has come up with an 
alternative called HyperGrid.
Our meeting on video streaming showed that there are points of 
inter-operability between SL, OpenSim
and Croquet/Qwaq. Surely we can find others. To say: "let us split the 
working group up from the start
into SL-compatible and incompatible worlds" assumes that we can find no 
common ground at all.

I think that is the wrong way to go.

Lawson

---

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

> of a given type (e.g. Second Life/OpenSIm compatible).

But it is of no interest to the MMOX group *as a whole* to achieve
interoperability between only 2 or more worlds of a given type.  Such
progress would be great for the worlds concerned, but of no use to anyone
else.

> in the same way, but no reason to assume we can't find points of

"Full interoperability" is not something that anyone has proposed, so
knocking it down is just a straw man.  Instead, we've been looking for ways
to achieve *some* degree of interop by focusing on just a few things that
are common to virtually all worlds.  A common protocol that deals extensibly
with those few things would be an amazing achievement, but locking down the
solution space even before the group has a charter is not the way to go
about it ... except in a group dedicated to a specific solution.

> Oh I'm fairly certain that we *CAN* find common ground in MMOX --- indeed,
that's the whole reason we're here.  Unfortunately the effort is derailed
when one party requires that that all the "common ground" has to be within
their own solution space.

The only reason I proposed a split is to get around the impasse of what
appears to be one entrenched position, so that everyone can make good
progress on all fronts to the benefit of all.  If there are no preconditions
though, then of course we could continue to search for natural common
ground, and I have no reason to believe that we would not succeed.

The phrase "Where there's a will there's a way" is very germane here.  Given
the will to move off one's own turf opens up numerous avenues for finding
common ground with others.

Morgaine.

On Fri, Feb 27, 2009 at 12:27 PM, Lawson English <[email-masked]> wrote:

> In other words, here's more than one possible sub-tree these inter-operable
> fruits are hanging from and
> --------------------------------------------------------   [...]
>     etc
> |                               |                        |
>                        / ] \

---

From: Lawson English <[email-masked]>
Date: Fri, 27 Feb 2009 08:51:00 -0700

Morgaine wrote:
> On Fri, Feb 27, 2009 at 12:27 PM, Lawson English <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>      
>     recognize several [types of] low-hanging fruit[s] that may apply
>     to many worlds or just 2 or more
> But it is of no interest to the MMOX group */as a whole/* to achieve 
> progress would be great for the worlds concerned, but of no use to 
> anyone else.

But interoperation between worlds is obviously eaisier with some than 
others. It seems to me that YOU are proposing an "all or none" solution 
here. The OGP solution should work for most worlds, as long as people 
understand the abstraction:

login to Agent Domain means to get some kind of recognition from that 
specific authorizing authority (however its done behind the scenes)

teleport from one region to another means to request that the Agent 
Domain signal the destination world/sim/whatever should start the 
process of creating a presence for the avatar while signalling the 
current world that such a presence is no longer valid combined with 
providing connections/services/whatevers between the client and relevant 
server(s) to make this work.

Lawson

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Fri, 27 Feb 2009 09:41:32 -0800

really?

why is it of no interest to achieve interoperability between 2 or more  
worlds of a given type?

On Feb 27, 2009, at 7:40 AM, Morgaine wrote:

> recognize several [types of] low-hanging fruit[s] that may apply to  
> many worlds or just 2 or more
> But it is of no interest to the MMOX group as a whole to achieve  
> interoperability between only 2 or more worlds of a given type.   
> Such progress would be great for the worlds concerned, but of no use  
> to anyone else.
>
>
> There's no reason to assume that full interoperability can be  
> obtained amongst all worlds
> "Full interoperability" is not something that anyone has proposed,  
> so knocking it down is just a straw man.  Instead, we've been  
> looking for ways to achieve some degree of interop by focusing on  
> just a few things that are common to virtually all worlds.  A common  
> protocol that deals extensibly with those few things would be an  
> amazing achievement, but locking down the solution space even before  
> the group has a charter is not the way to go about it ... except in  
> a group dedicated to a specific solution.
>
>
> Our meeting on video streaming showed that there are points of inter- 
> operability between SL, OpenSim
> and Croquet/Qwaq. Surely we can find others. To say: "let us split  
> the working group up from the start
> into SL-compatible and incompatible worlds" assumes that we can find  
> no common ground at all.
>
>
> Oh I'm fairly certain that we CAN find common ground in MMOX ---  
> indeed, that's the whole reason we're here.  Unfortunately the  
> effort is derailed when one party requires that that all the "common  
> ground" has to be within their own solution space.
>
> The only reason I proposed a split is to get around the impasse of  
> what appears to be one entrenched position, so that everyone can  
> make good progress on all fronts to the benefit of all.  If there  
> are no preconditions though, then of course we could continue to  
> search for natural common ground, and I have no reason to believe  
> that we would not succeed.
>
> The phrase "Where there's a will there's a way" is very germane  
> here.  Given the will to move off one's own turf opens up numerous  
> avenues for finding common ground with others.
>
>
> Morgaine.
>
>
>
>
>
>
>
> recognize several [types of] low-hanging fruit[s] that may apply to  
> many worlds or just 2 or more
> In other words, here's more than one possible sub-tree these inter- 
> operable fruits are hanging from and
> it is likely more like a digraph than a simple tree (who knows,  
> possibly not merely a digraph either if
>                             /  |   
> \                                                   /  |   \      
> There's no reason to assume that full interoperability can be  
> obtained amongst all worlds
> Our meeting on video streaming showed that there are points of inter- 
> operability between SL, OpenSim
> and Croquet/Qwaq. Surely we can find others. To say: "let us split  
> the working group up from the start
> into SL-compatible and incompatible worlds" assumes that we can find  
> no common ground at all.
>
>
>
>

---

From: Jon Watte <[email-masked]>
Date: Fri, 27 Feb 2009 09:59:22 -0800

> of a given type (e.g. Second Life/OpenSIm compatible).

The charter for the group is vendor neutral interoperability. If you 
want to design a Second-Life-derived protocol under this group, then I 
cannot support the group, for pretty obvious reasons, and I believe it 
would reflect very negatively on the sponsors of the group to go against 
the charter.

Sincerely,

jw

---

From: Lawson English <[email-masked]>
Date: Fri, 27 Feb 2009 11:06:28 -0700

Jon Watte wrote:
> would reflect very negatively on the sponsors of the group to go 
> against the charter.
>

Hmmmm....

So you're insisting that we design a one-size fits all protocol. Does 
this mean that the OGP between SL and OpenSim can't be endorsed as a 
special case of the mmox interoperability protocols?

Lawson

---

From: Lawson English <[email-masked]>
Date: Fri, 27 Feb 2009 11:20:33 -0700

> would reflect very negatively on the sponsors of the group to go 

There are many possibilities here, IMHO:

at one extreme, there are worlds that can interop intimately with little 
modification, such as Second LIfe and OpenSIm, and at the other, there 
likely will be needed a lot more intermediate plumbing to make things work.

At the lowest level, the interop protocol of MMOX shouldn't assume how 
much, if any, plumbing is required and allow the client/Agent 
Domain/whatever to determine the specific needs for interop on-the-fly.

More specific protocols can be devised to handle general cases, specific 
cases, whatever, but to insist that one-size fits all beyond 
establishing a standard way to figure out what is needed for interop 
between any 2 specific worlds is to ignore that virtual worlds are 
rather varied in their implementation and functionality and some are 
more compatible than others.

Laawson

---

From: Ann Otoole <[email-masked]>
Date: Fri, 27 Feb 2009 10:49:24 -0800 (PST)

Perhaps the focus needs to be on public worlds and people with worlds that, by their very nature, will never interop anyway, really should back off unless their respective companies have at least one public access virtual world,. Why should this group involve itself with closed access worlds where no interop will ever happen anyway because of the danger of espionage?

The blade cuts both ways.

Just a thought.

From: Lawson English <[email-masked]>
To: Jon Watte <[email-masked]>
Cc: [email-masked]
Sent: Friday, February 27, 2009 1:06:28 PM
Subject: Re: [mmox] Chartering for requirements only

Jon Watte wrote:
> Lawson English wrote:
>> My own take is that fragmenting the working group at this point is counter-productive. We can
>> recognize several [types of] low-hanging fruit[s] that may apply to many worlds or just 2 or more
> The charter for the group is vendor neutral interoperability. If you want to design a Second-Life-derived protocol under this group, then I cannot support the group, for pretty obvious reasons, and I believe it would reflect very negatively on the sponsors of the group to go against the charter.
> 

Hmmmm....

So you're insisting that we design a one-size fits all protocol. Does this mean that the OGP between SL and OpenSim can't be endorsed as a special case of the mmox interoperability protocols?

Lawson

---

From: Jon Watte <[email-masked]>
Date: Fri, 27 Feb 2009 10:56:00 -0800

> why is it of no interest to achieve interoperability between 2 or more 

It is not of interest to a vendor neutral standard to achieve 
interoperability between two worlds that use a vendor-derived approach. 
It may be interesting as a case study, and it may be interesting in and 
of itself in a forum dedicated to such interoperability, but the 
explicit "vendor neutral" part of the charter seems like it would move 
such interoperability outside the purview of this group.

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Fri, 27 Feb 2009 11:03:57 -0800

> special case of the mmox interoperability protocols?

One-size-fits-all sounds rather loaded. I want a protocol that seeks a 
"common ground" model that is guaranteed to be able to interoperate to 
the level of capability that each virtual world may have. The problem 
with the Second Life protocol, and indeed OGP in general, is that it 
assumes the Second Life approach to simulation, avatar management, 
object representation, etc, which according to Second Life themselves is 
"different from how everyone else does it." (And I would agree). I can't 
see how that could be moved into a "common ground," open, vendor neutral 
standard.

Sincerely,

jw

---

From: "Robert Gehorsam" <[email-masked]>
Date: Fri, 27 Feb 2009 11:04:47 -0800

Ann,
 
I understand your concerns/fears, etc., but there's a larger context.
It's possible -- essential, really -- to envision worlds that are
private (meaning, run by companies for their own employees' utility)
that also need to connect to other private worlds....partners,
customers, industry/trade organizations, etc.  In fact, broadly
speaking, this may be the area where interoperability is most valuable.
Parts of the US or state or local governments would clearly have that as
well.  For example, the Department of Education may have its own virtual
world, and want to connect it to virtual worlds operated by the National
Science Foundation and the American Federation of Teachers.
 
This broad scenario is certainly the one that interests me the most.
 
So public worlds (meaning, really, "consumer" worlds) are just one
category of virtual worlds where interoperability is important.  But
private <---> private and private  <---->public are also critical
components.
 
Robert

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ann Otoole
Sent: Friday, February 27, 2009 1:49 PM
To: [email-masked]; Jon Watte
Cc: [email-masked]
Subject: Re: [mmox] Chartering for requirements only

Perhaps the focus needs to be on public worlds and people with worlds
that, by their very nature, will never interop anyway, really should
back off unless their respective companies have at least one public
access virtual world,. Why should this group involve itself with closed
access worlds where no interop will ever happen anyway because of the
danger of espionage?

Just a thought.

Hmmmm....

Lawson

---

From: Jon Watte <[email-masked]>
Date: Fri, 27 Feb 2009 11:15:03 -0800

Ann Otoole wrote:
> access virtual world,. Why should this group involve itself with 
> closed access worlds where no interop will ever happen anyway because 
> of the danger of espionage?

I seem to detect two assumptions here that I would disagree with. 
Correct me if I'm wrong.

First, you are assuming that someone is selling virtual worlds that will 
never have public access. I don't think anyone on this list is in that 
situation. Forterra Systems certainly isn't -- our first licensee was 
There.com, which has built a thriving set of branded and white-label 
virtual worlds for consumer access. Other licensees of ours are building 
worlds that are public to some degree or another -- some licensees 
currently have their worlds "public" only to their employees, others are 
intending to provide virtual-worlds based services such as online 
conferencing or distance education. While those are not "free trial" or 
"entertainment" based virtual worlds, I believe they serve a very 
important role in the general acceptance of virtual worlds beyond the 
early adopter fringe, and I believe all those cases would be well served 
by working interoperability.

Second, you are assuming that a virtual world that does not want to 
interoperate with the public, would not be served by interoperability. I 
think that's entirely wrong. In large systems acquisition, whether it be 
a platform for a company like General Electric, or the FBI, or some 
super-secret black ops laboratory, a final system is seldom built using 
components from only one vendor. Typically, a systems integrator (like 
Lockheed-Martin, Northrop-Grumman, SAIC etc) will source a number of 
pieces from a number of different vendors, and work to put them all 
together into a working solution. Even if that working solution will be 
locked in a mountain underground, with no cables in or out, the work of 
building that system is greatly simplified if there are working 
interoperability standards for the components in question. In the end, 
that ends up saving taxpayer money (in the case of systems built for the 
government).

I believe that a vibrant, working, vendor neutral interoperability 
protocol is key to making virtual worlds really competetive in many of 
these large markets, which in turn means that many vendors can be 
considered for programs where they currently can't be, for cost, 
integration or lock-in reasons. In that sense, everyone in the Virtual 
Worlds business wins.

The competition is not "Forterra vs Second Life" -- in fact, we're not 
in the business of leasing server time at all. The competition is 
"Virtual Worlds vs The Way We've Always Done It." I hope we on this list 
are all on the same side of that battle!

Sincerely,

jw

---

From: [email-masked]
Date: Fri, 27 Feb 2009 11:16:52 -0800 (PST)

I would hope that this group could adopt the best from the available unencumbered implementations and boil them down into an efficient protocol which provides a high quality service in as many conditions as possible, and then build upon that to correct any deficiencies. If parties adopt a "Not if it wasn't invented by us" approach, then I suspect achieving this group's goals will become quite difficult.

Best regards,
--Tom Hoff

--- On Fri, 2/27/09, Jon Watte <[email-masked]> wrote:

> From: Jon Watte <[email-masked]>
> To: "Meadhbh Hamrick (Infinity)" <[email-masked]>
> Cc: [email-masked], [email-masked]
> Date: Friday, February 27, 2009, 10:56 AM
> > why is it of no interest to achieve interoperability
> between 2 or more worlds of a given type?
> > 
> 
> 
> It is not of interest to a vendor neutral standard to
> achieve interoperability between two worlds that use a
> vendor-derived approach. It may be interesting as a case
> study, and it may be interesting in and of itself in a forum
> dedicated to such interoperability, but the explicit
> "vendor neutral" part of the charter seems like it
> would move such interoperability outside the purview of this
> group.
> 
> Sincerely,
> 
> jw
>

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Fri, 27 Feb 2009 11:20:24 -0800

i think you're conflating "vendor proposed" with "vendor neutral." OGP  
as it is proposed IS NOT the legacy Second Life protocol and we claim  
no proprietary interest in the protocol (thus our actions of  
publishing it with an IETF trust copyright.) Sure. we would balk at  
you if you tried to propose OLIVE(tm)'s communication protocols as a  
standard, but again.. OGP IS NOT the same thing as the Second Life  
legacy protocol. if _you_ made a proposal that was not the existing  
proprietary OLIVE(tm) communication protocol and disclaimed  
proprietary interest in it, we would be interested because we're  
generally interested in VW interoperability.

but to date, there are no other proposals on the table, so we're  
talking about OGP. if you want the discussion to include an OLIVE(tm)  
derived open protocol, please propose one.

On Feb 27, 2009, at 10:56 AM, Jon Watte wrote:

>> why is it of no interest to achieve interoperability between 2 or  
>> more worlds of a given type?
>>
>
>
> interoperability between two worlds that use a vendor-derived  
> approach. It may be interesting as a case study, and it may be  
> interesting in and of itself in a forum dedicated to such  
> interoperability, but the explicit "vendor neutral" part of the  
> charter seems like it would move such interoperability outside the  
> purview of this group.
>
> Sincerely,
>
> jw
>

---

From: Jon Watte <[email-masked]>
Date: Fri, 27 Feb 2009 11:31:56 -0800

Meadhbh Hamrick (Infinity) wrote:
> standard, but again.. OGP 

We've already been over that. OGP has two problems:
1) It assumes the Second Life way of doing things. It talks about 
rezzing and de-rezzing avatars, for example. That's something that I 
believe should be entirely implementation dependent for each virtual 
world system, and is one of the few things that do *not* need 
standardization.
2) As far as actual interoperability goes, it's just an empty pipe. 
Empty pipes where each technology will put their technology-specific 
bits in does not make for useful and usable vendor-neutral interoperability.

> IS NOT the same thing as the Second Life legacy protocol. if _you_ 
> made a proposal that was not the existing proprietary OLIVE(tm) 
> communication protocol and disclaimed proprietary interest in it, we 
> would be interested because we're generally interested in VW 
> interoperability.
>

I already posted a link to a sketch of such a protocol that I made 
almost two years ago, entirely based on my understanding of what the 
"common ground" of most protocols would be. That link was met with even 
more silence than my use cases.

However, I still maintain that it's too early to even talk about 
protocol specifics. We need to agree on requirements first. To get to 
requirements, we need to agree on use cases. If we cannot achieve that, 
we cannot achieve vendor neutral, working interoperability.

> derived open protocol, please propose one.

I have proposed one, but here's the catch: It's not OLIVE(tm) derived. 
It's not at all like what OLIVE does internally. It's something where I 
have sat down, looked at the interoperability we've done since 2005, 
looked at the systems we've previously integrated with, and looked at 
the technology of other vendors with open technology stacks (Multiverse, 
Wonderland, Kaneva, plus a bunch of the game engines of the world), and 
then synthesized that experience into a "middle ground" proposal.

I recently took what learning I've gained from the past 18 months 
(including this mailing list), and updated the proposal. If you want a 
protocol proposal, check out http://www.interopworld.com/mmox-less-protocol
I think you will find that it is both more vendor neutral, and would 
provide significantly richer interoperability than the currently visible 
OGP proposal. It is, however, not a complete protocol stack -- there's a 
whole set of metadata, negotiation, policy etc that needs to go around 
it. I have ideas about that as well, but haven't spent the time to write 
them down in detail, because I don't think we have consensus on 
requirements (or even use cases) yet.
In a sense, I'm posting this proposal because I want to avoid someone 
trying to ram-rod OGP through the group, which I think would be a 
miserable failure of the group charter. However, I'd much rather we 
first agreed on requirements.

Sincerely,

jw

---

From: Lawson English <[email-masked]>
Date: Fri, 27 Feb 2009 12:38:36 -0700

> derived open protocol, please propose one.

Perhaps, to clarify:

OGP is implemented in a special patch in the GPL Second CLient, and in 
libaries in the Apache V2 licensed pyogp client, and in special patches 
in certain proprietary Second Life beta grid simulators and as a BSD 
licensed patch for the OpenSim simulators.

AWG and Linden Lab made a good faith effort to make the OGP as generic 
as possible from the start with an eye to getting other virtual worlds 
vendors to use it.

However, as Zha Ewry (David Levine) pointed out today in the 
[email-masked] chat room, there's a lot of hidden SL-specific 
assumptions  in the OGP implementation that need to be abstracted to 
make it suitable for mmox, If anyone looks at today's transcript, I 
think they can find common ground for the beginnings of an abstracted 
interoperability strategy that can be embodied in appropriate 
vendor-neutral protocols--not just for Second Life/OpenSim.

http://jabber.ietf.org/logs/mmox/2009-02-27.txt   starting around 15:30

Lawson

---

From: Jon Watte <[email-masked]>
Date: Fri, 27 Feb 2009 11:55:06 -0800

> [16:00:55] <zha.ewry> Jon's somewhat blinded

I would very much like a little more detailed description, because if 
there's something I'm not getting, I need to fix that!

Meanwhile, I still think the discussion hasn't assimilated the actual 
requirements of vendor neutral interoperability. It still talks about 
things like "I inject my avatar into some arbitrary server." Here's 
what's wrong with that, in my (blinded?) view:
You can't do that in a generally interoperable way, because avatars are 
objects with behavior, and I thought we all agreed that we cannot 
reasonably standardize how behavior is implemented. Thus, I have to log 
in my avatar in a system that knows how to execute my avatar. That 
system can then peer my avatar over to another system -- but that's no 
different from peering any other object (such as a tree) -- and the acts 
of "teleport" or "login" are necessarily specific to my host system, and 
separated from the interoperability. That's just a logical consequence 
of not standardizing the execution environment.

It seems to me from that discussion that Linden is still intent on 
standardizing the execution environment, and in that case, standardizing 
it to the current Linden environment. VRML tried doing that in 1995, 
using a vendor neutral, standard execution environment. That didn't fly 
back then, and is even less likely to fly with a vendor-specific 
environment now.

Now, it may be that I'm missing something entirely, thus being "somewhat 
blinded," but nobody has shown me through factual argument how that's 
the case. I'm looking forward to it, though!

Sincerely,

jw

---

From: "Mystical Demina" <[email-masked]>
Date: Fri, 27 Feb 2009 14:56:20 -0500

Regarding there are no more proposals could you help me understand how this
process will work?  When is the time to send in an RFC?  What am I
specifically sending a RFC in about?  I may have some interest in writing up
some proposals but I am not sure when and how that process will work.

To me there are lots of situations the OGP protocol doesn't address and as
such until we define and abstract out the client to server, and server to
server relationship independent of technology and solution how can we say
any specific protocol is something we can support and write code to support.

Kevin Tweedy
SL: Mystical Demina
http://www.XRGrid.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Meadhbh Hamrick (Infinity)
Sent: Friday, February 27, 2009 2:20 PM
To: Jon Watte
Cc: [email-masked]; [email-masked]
Subject: Re: [mmox] Chartering for requirements only

---

From: "Hurliman, John" <[email-masked]>
Date: Fri, 27 Feb 2009 13:47:57 -0700

-----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Lawson English
> Sent: Friday, February 27, 2009 11:39 AM
> To: Meadhbh Hamrick (Infinity)
> Cc: [email-masked]; Jon Watte
>> no proprietary interest in the protocol (thus our actions of publishing
>> it with an IETF trust copyright.) Sure. we would balk at you if you
>> tried to propose OLIVE(tm)'s communication protocols as a standard, but
>> again.. OGP IS NOT the same thing as the Second Life legacy protocol.
>> if _you_ made a proposal that was not the existing proprietary
>> OLIVE(tm) communication protocol and disclaimed proprietary interest in
>> it, we would be interested because we're generally interested in VW
>> interoperability.
>> 
>> talking about OGP. if you want the discussion to include an
>> OLIVE(tm) derived open protocol, please propose one.
>> 
> 
> Perhaps, to clarify:
> 
> libaries in the Apache V2 licensed pyogp client, and in special
> patches in certain proprietary Second Life beta grid simulators and as
> a BSD licensed patch for the OpenSim simulators.
> 
> 
> interoperability strategy that can be embodied in appropriate vendor-
> neutral protocols--not just for Second Life/OpenSim.
> 

OGP establishes explicit (partial) trust maps between separate authorities to achieve interoperability. This is a special case of interoperability, similar to Apple letting you login to iTunes using either an Apple ID or an AOL ID. It is a separate case from interoperability in the sense of POP/IMAP or HTTP, where I can send e-mail to anyone on the web or visit any website without having to worry if the appropriate trust has been established by two service providers. Explicit trust maps between virtual worlds would have many useful applications, but it is not the ultimate goal when many MMOX participants talk about virtual world interoperability.

The problems arising from Second Life assumptions being baked into the current OGP discussion have already been discussed extensively. There is also a strong push from Meadhbh, as the co-chair of MMOX, to structure the discussion as OGP/LLSD-based, but open to the consideration of other proposals (http://www.ietf.org/mail-archive/web/mmox/current/msg00627.html). These alternative proposals should be structured in the context of an alternative to what Linden Lab already has working code for, and to consider Linden Lab's cost of switching to something different (http://www.ietf.org/mail-archive/web/mmox/current/msg00584.html).

Because of these large disconnects at both technical and policy levels, I support either renaming the MMOX group and changing the draft charter to an OGP/LLSD-centric group, or splitting off OGP/LLSD into a separate group.

John

---

From: Lawson English <[email-masked]>
Date: Fri, 27 Feb 2009 13:57:46 -0700

> Because of these large disconnects at both technical and policy levels, I support either renaming the MMOX group and changing the draft charter to an OGP/LLSD-centric group, or splitting off OGP/LL…
Read todays transcript, I take it....

L

---

From: Morgaine <[email-masked]>
Date: Fri, 27 Feb 2009 21:25:44 +0000

On Fri, Feb 27, 2009 at 3:51 PM, Lawson English <[email-masked]> wrote:

> others.

Indeed, but I have to reiterate that defining interop between two very
similar worlds is of no interest to anyone else.

> It seems to me that YOU are proposing an "all or none" solution here.

I would call it a "have your cake and eat it too" solution, since I've
suggested a way for both parties to make progress without impeding each
other.   Much closer to an "all or nothing" situation is the "LLSD/OGP or
nothing" impasse that we have now. ;-)

I can see three ways to help us work more cooperatively:

   1. Work in two streams, one explicitly OGP which is very targetted at a
   specific solution, and the other explicitly MMOX which is much wider, with
   people contributing to one or both.  If MMOX identifies other possible
   solutions then additional workgroups could be created to handle them.
   2. Remove the constraints (expressed as an
intention<http://www.ietf.org/mail-archive/web/mmox/current/msg00627.html>)
   imposed by LL on the solution space, so that MMOX can find common ground
   among VW architectures and then seek solutions without being placed in a
   straightjacket by Linden-only issues.  Notice that this may even lead to OGP
   being identified as a good solution.
   3. Unpack the OGP proposal in all its glory into all the
   {problem,solution} pairs that led up to it, and describe the details in a
   marathon session of explanation/indoctrination so that there can be broad
   buy-in to that technology from a large proportion of MMOX participants.  If
   they agree that LLSD/OGP can solve the interop problem for their own worlds
   equitably, then we might be onto a winner.

It's worth pointing out that we have spent 16 months in AWG talking about
OGP, so we have a good grasp of how it can be adapted for interop among very
diverse worlds.  A large proportion of MMOX participants do not have the
benefit of our deliberations, and so the lack of wide backing for what is
seen as "Linden Lab's solution" is not very surprising.  (And some
participants who are fully aware of OGP have questioned its appropriateness
too, so this issue is by no means settled.)

Something needs to be done, or the lack of even a rough consensus might
impact badly on our ability to form a workgroup after the BoF, let alone
actually get good work done.  I don't mind which path we take, as long as it
provides a means of cooperation in place of outright conflict.  (A bit of
conflict is of course both inevitable and useful.)

And flexibility is mandatory whichever path we take.  Tying the group down
to suit one particular vendor's business requirements is not satisfactory
for a group targetting a broad problem space.

Morgaine.

---

From: Jon Watte <[email-masked]>
Date: Fri, 27 Feb 2009 13:40:25 -0800

Morgaine wrote:
>
>    1. Work in two streams, one explicitly OGP which is very targetted
>       at a specific solution, and the other explicitly MMOX which is
>       much wider, with people contributing to one or both.  If MMOX
>       identifies other possible solutions then additional workgroups
>       could be created to handle them.
>    2. Remove the constraints (expressed as an intention
>       <http://www.ietf.org/mail-archive/web/mmox/current/msg00627.html>)
>       imposed by LL on the solution space, so that MMOX can find
>       common ground among VW architectures and then seek solutions
>       without being placed in a straightjacket by Linden-only issues. 
>       Notice that this may even lead to OGP being identified as a good
>       solution.
>       {problem,solution} pairs that led up to it, and describe the
>       details in a marathon session of explanation/indoctrination so
>       that there can be broad buy-in to that technology from a large
>       proportion of MMOX participants.  If they agree that LLSD/OGP
>       can solve the interop problem for their own worlds equitably,
>       then we might be onto a winner.
>

While this seems like possible ways to structure the groups, I still 
don't know what the groups are supposed to do.
What problem are we solving? Which requirements do we need to fill? What 
use cases led to those requirements?

>
> Something needs to be done, or the lack of even a rough consensus 
> might impact badly on our ability to form a workgroup after the BoF, 
> let alone actually get good work done.  I don't mind which path we 
> take, as long as it provides a means of cooperation in place of 
> outright conflict.  (A bit of conflict is of course both inevitable 
> and useful.)

 From my point of view, OGP seems to attempt to solve a problem that is 
not applicable to vendor-neutral interoperability. It tries to solve the 
problem of "entity X wants to instantiate an authoritative copy of 
object Y into server Z." I believe that instantiating authoritative 
objects (as opposed to showing ghost copies of them) is necessarily 
technology specific, and thus necessarily outside the scope of a vendor- 
and technology neutral interoperability protocol.

However, I don't know if that comment is even applicable, because we 
don't have any requirements yet.

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Fri, 27 Feb 2009 21:54:19 +0000

> why is it of no interest to achieve interoperability between 2 or more

By choosing to leave off my phrase "to the MMOX group *as a whole"*, you
created a question by omitting the answer already provided.  It should be
obvious that obtaining interop for only a fraction of all the parties in the
group is of no interest "to the MMOX group *as a whole".

*One-liner miss-representations and straw men are really not the way to
conduct a professional discussion.

Morgaine.
*
*

On Fri, Feb 27, 2009 at 5:41 PM, Meadhbh Hamrick (Infinity) <
[email-masked]> wrote:

> On Fri, Feb 27, 2009 at 12:27 PM, Lawson English <[email-masked]>wrote:
>
>>
>> Oh I'm fairly certain that we *CAN* find common ground in MMOX ---
> indeed, that's the whole reason we're here.  Unfortunately the effort is
> derailed when one party requires that that all the "common ground" has to be
> within their own solution space.
>
> The phrase "Where there's a will there's a way" is very germane here.
> Given the will to move off one's own turf opens up numerous avenues for
> finding common ground with others.
>
>
> Morgaine.
>
>
>
>
>
>
>
> On Fri, Feb 27, 2009 at 12:27 PM, Lawson English <[email-masked]>wrote:
>
>> Jesrad wrote:
>>

---

From: "Frisby, Adam" <[email-masked]>
Date: Fri, 27 Feb 2009 18:52:53 -0500

Honestly,

I think going back to the original use cases, and seeing what we need works best.

I also think that in the case of revising this - we need to revisit some of the central complaints. While OGP has been added to OpenSim (because it was relatively easy to do so and hence the barrier to entry was low), there's a number of serious technical flaws with the standard, and it only handles a tiny number of possible use cases properly at the moment.

I have a strong personal preference to attempting to reinvent as few standards as possible - leveraging outside sources where possible. IE - using say Kerberos for authentication, standard URI's (with a preference for HTTP) for use of asset delivery, etc.

The reasoning being that most of these are in production already and are well tested - right now almost all the virtual world standards have serious issues on a number of levels, from caching and multicasting, to complete disregard for security practices.

For that reason, I think we should go back to the original use cases, then think about them in the contexts of security, portability, ease of implementation, as well as the original design goals.

Regards.

Adam

> Jon Watte
> Sent: Friday, 27 February 2009 1:40 PM
> To: Morgaine

---

From: Charles Krinke <[email-masked]>
Date: Fri, 27 Feb 2009 16:30:03 -0800

One of the use cases for which most of us are familiar with is indeed the SL
use case. And it has other interop ramifications.

As we have others make compatible sim servers to the SL client, such as
OpenSim, we also have additional clients, such as Hippo, Xenkii, Rex,
OpenViewer, IdealistViewer to name a few.

One of the things I am concerned about is minimizing the changes to those
server and client interfaces to encourage the greatest interoperability
between the similar and "vendor neutral" sim servers and clients as we move
forward in trying to define some semblance of "interop"

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Fri, Feb 27, 2009 at 3:52 PM, Frisby, Adam <[email-masked]> wrote:

> I also think that in the case of revising this - we need to revisit some of
> the central complaints. While OGP has been added to OpenSim (because it was
> relatively easy to do so and hence the barrier to entry was low), there's a
> number of serious technical flaws with the standard, and it only handles a
> tiny number of possible use cases properly at the moment.
>
> I have a strong personal preference to attempting to reinvent as few
> standards as possible - leveraging outside sources where possible. IE -
> using say Kerberos for authentication, standard URI's (with a preference for
> HTTP) for use of asset delivery, etc.
>
> The reasoning being that most of these are in production already and are
> well tested - right now almost all the virtual world standards have serious
> issues on a number of levels, from caching and multicasting, to complete
> disregard for security practices.
>
> For that reason, I think we should go back to the original use cases, then
> think about them in the contexts of security, portability, ease of
> implementation, as well as the original design goals.
>
> Regards.
>
> Adam
>

--

---

From: Jon Watte <[email-masked]>
Date: Fri, 27 Feb 2009 22:37:11 -0800

Charles Krinke wrote:
> One of the things I am concerned about is minimizing the changes to 
> those server and client interfaces to encourage the greatest 
> interoperability between the similar and "vendor neutral" sim servers 
> and clients as we move forward in trying to define some semblance of 
> "interop"

Is it your assertion that a client, or server, that interoperates based 
on the Second Life protocol, and are largely based on the open sourced 
SL client, or the reverse-engineered protocol library, is "vendor neutral"?
If that is the case, I would have to respectfully disagree with your use 
of the term.

Sincerely,

jw