Subject: Re: [mmox] Chartering for requirements only

From: Meadhbh Hamrick (Infinity) <[email-masked]>
Date: Mon, 2 Mar 2009 09:04:16 -0800

allow me to breathe a bit of fresh air into this discussion...

again, let me point out that OGP is NOT derived from the existing  
Second Life protocol. I understand why it is in your best interest to  
convince people of this, but at the end of the day it is not true.  
saying OGP is derived from the Second Life legacy protocol is like  
saying HTTP derives from GOPHER because they both use the same request- 
response interaction model. OGP is defined in terms of LLSD, and some  
portions of the Second Life legacy protocol use LLSD/XML over HTTP.  
OGP is intended to refer protocol endpoints to many of the same types  
of resources: textures, prims, avatar information, etc. but again,  
saying that OGP is derived from the Second Life protocol because they  
both find utility in effecting the transfer of similar data resources  
is like saying HTTP derives from GOPHER because they both support text  
documents.

what _is_ true about the relationship between Second Life and OGP is  
we have over five years of experience at developing and operating a  
high-concurrency non-user-partitioned world. we've done a number of  
things right, and we've done a number of things wrong. OGP is our  
attempt to define a protocol that allows us to express systems "done  
right." in other words, as we remove the problematic legacy components  
from our infrastructure, we're defining a new protocol that along with  
our interoperability profile defines how we connect our systems and  
those of our business partners together. in short, we've made some  
mistakes with our existing protocol. mea culpa. we're trying to get  
away from a number of those mistakes as fast as possible.

our objectives in introducing OGP into an IETF process was to a)  
solicit input from the internet community as a whole, b) define an  
interoperable protocol that defines how services might interact with  
our highly concurrent virtual world, and c) publish enough of a  
protocol so that routers and firewalls could easily identify our  
traffic. additionally, we're defining protocols in a very generic  
manner. we have been careful to ensure that the existing architecture  
that implements our service is not "enshrined" in OGP. in most places,  
we use the term "service endpoint" or "protocol endpoint" because we  
envision this protocol being used in environments distinct from our  
existing architecture. in short, we don't want to define a protocol  
that mandates a particular architecture. (within limits. we _do_  
assume an architecture where most of the "domain intelligence" is in  
the network and not in the nodes.)

but in terms of mandating a mapping between one processor core and one  
256m x 256m simulation region? no. it's not going into the protocol.  
(it will go into an interoperability profile so people who build third  
party viewers will know they can assume such a mapping when connecting  
to our service.) mandating that agent services be implemented on a  
different host than region / simulation services? no, it's not in the  
protocol, but implementers of services would be well advised to note  
that service locations are defined by opaque URIs, related services  
could be on the same host, or they could be on different hosts.

again, our objectives here are to expose OGP to a larger community and  
allow that community to suggest alternate mechanisms for achieving  
particular communication tasks. we have no proprietary interest in the  
protocol we define (though obviously we have interests in the services  
that are delivered over the protocol.) because we have no proprietary  
interest in the protocol, we would be excited if other organizations  
used portions of it for their own purposes. this would help foster an  
ecosystem of tools that would benefit all users of the protocol. OGP  
is being presented in this forum to use the IETF process as a  
framework for discussion of the protocol.

On Feb 27, 2009, at 10:06 AM, Lawson English wrote:

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

---

From: "Hurliman, John" <[email-masked]>
Date: Mon, 2 Mar 2009 10:53:25 -0700

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Meadhbh Hamrick
>Sent: Monday, March 02, 2009 9:04 AM
>To: [email-masked]
>Cc: [email-masked]; Jon Watte
>Subject: Re: [mmox] Chartering for requirements only
>
> ...
>

I think this is great material for the charter. If the focus of MMOX could be rewritten to describe defining an interoperable protocol that defines how services might interact with Second Life, how to easily identify that traffic at the router/firewall level, and solicit input from the wider community on this effort, it would reduce a lot of confusion about the purpose of this group.

John

---

From: Jon Watte <[email-masked]>
Date: Mon, 02 Mar 2009 10:54:07 -0800

Meadhbh Hamrick (Infinity) wrote:
> saying OGP is derived from the Second Life

> framework for discussion of the protocol.

I would like your response to the comment that OGP seems to still assume 
a Second Life way of doing things.

As an example, I believe that "rezzing" avatars is not something that 
could or should be part of an interoperability standard, because the 
simulation model (execution environment) for an avatar is too tightly 
coupled to the particular technology platform that the avatar is 
implemented on. Thus, the process of "logging on" to a particular 
platform, and "rezzing" your avatar, is a technology specific action, 
and does not belong in an interop protocol. To me, the currently 
presented OGP proposal seems like an attempt to standardize some future 
Second Life implementation internals.

Similarly, the way OGP is currently defined, the client necessarily must 
understand the native communications protocol of the target server where 
the avatar or other content is "injected." Again, because client/server 
communication is tightly coupled, this only makes sense in a 
technology-specific implementation, and thus does not belong inside the 
interoperability standard.

Once you are logged on, your avatar presentation can be presented to 
other systems through some common animated/simulated object presentation 
abstraction. That is where an interoperability protocol (or rather, 
suite of protocols) starts making sense. I just don't see OGP, as 
currently presented, solving any of those actual interoperability problems.

Perhaps you can explain your view on these concerns?

Sincerely,

jw

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Mon, 2 Mar 2009 11:37:27 -0800

right. we assume that there is a machine somewhere on the network that  
provides simulation services. and we assume that things (objects and  
avatars) can be instantiated into the simulation, and that the  
authoritative representation of that object exists (or can exist)  
somewhere else.

that is to say, OGP/teleport as it is currently written assumes a  
"location affinity" for simulators and not an "object affinity" for  
simulators.

so yes.. virtual worlds that work differently may wish to deploy a  
different rezzing / instantiation protocol.

still... there are no proposals on the table for a virtual world that  
behaves differently. if you want to add an OLIVE(tm) derived protocol  
or if someone in the croquet community wants to propose something  
based on object-based partitioning for simulation... sure... we can  
put this on the list of topics.

On Mar 2, 2009, at 10:54 AM, Jon Watte wrote:

>> Second Life protocol. I understand why it is in your best interest  
>> to convince people of this, but at the end of the day it is not  
>> true. saying OGP is derived from the Second Life
>
>> again, our objectives here are to expose OGP to a larger community  
>> and allow that community to suggest alternate mechanisms for  
>> achieving particular communication tasks. we have no proprietary  
>> interest in the protocol we define (though obviously we have  
>> interests in the services that are delivered over the protocol.)  
>> because we have no proprietary interest in the protocol, we would  
>> be excited if other organizations used portions of it for their own  
>> purposes. this would help foster an ecosystem of tools that would  
>> benefit all users of the protocol. OGP is being presented in this  
>> forum to use the IETF process as a framework for discussion of the  
>> protocol.
>
>
> I would like your response to the comment that OGP seems to still  
> assume a Second Life way of doing things.
>
> As an example, I believe that "rezzing" avatars is not something  
> that could or should be part of an interoperability standard,  
> because the simulation model (execution environment) for an avatar  
> is too tightly coupled to the particular technology platform that  
> the avatar is implemented on. Thus, the process of "logging on" to a  
> particular platform, and "rezzing" your avatar, is a technology  
> specific action, and does not belong in an interop protocol. To me,  
> the currently presented OGP proposal seems like an attempt to  
> standardize some future Second Life implementation internals.
>
> Similarly, the way OGP is currently defined, the client necessarily  
> must understand the native communications protocol of the target  
> server where the avatar or other content is "injected." Again,  
> because client/server communication is tightly coupled, this only  
> makes sense in a technology-specific implementation, and thus does  
> not belong inside the interoperability standard.
>
> other systems through some common animated/simulated object  
> presentation abstraction. That is where an interoperability protocol  
> (or rather, suite of protocols) starts making sense. I just don't  
> see OGP, as currently presented, solving any of those actual  
> interoperability problems.
>

---

From: Jon Watte <[email-masked]>
Date: Mon, 02 Mar 2009 11:56:39 -0800

> put this on the list of topics.

The LESS protocol clearly delineates this affinity. The model of LESS is 
that multiple hosts may all provide simulation services for the same 
location; however, objects have affinity for their "own" kind of hosts. 
The hosts peer information about the outcome/presentation of simulation, 
not the objects themselves.

Given that it makes no sense to try to "inject" or "control" an object 
unless you know that the object is compatible with the execution 
environment assumed by the object, I think object injection onto servers 
(as opposed to peer-based object observation) belongs clearly among 
system implementation details, not in an interop protocol.

Unless what you want to standardize is the implementation details of 
Second Life, of course. If that's what you want to do, please express 
that in the charter, and remove the "vendor neutral" language from the 
charter, so we can discuss neutral interoperability in some better 
forum. (Although naming the Second Life internals standard "MMOX" seems 
a little disingenuous at that point).

Sincerely,

jw

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Mon, 2 Mar 2009 12:32:44 -0800

sorry... shoulda been more specific. as i said, there are no proposals  
on the table in this forum for a virtual world that behaves  
differently. if you want to add an OLIVE(tm) derived protocol or if  
someone in the croquet community wants to propose something based on  
object-based partitioning for simulation, or if someone wants to  
sponsor an effort to publish LESS as an IETF standard... sure... we  
can put this on the list of topics.

On Mar 2, 2009, at 11:56 AM, Jon Watte wrote:

>> still... there are no proposals on the table for a virtual world  
>> that behaves differently. if you want to add an OLIVE(tm) derived  
>> protocol or if someone in the croquet community wants to propose  
>> something based on object-based partitioning for simulation...  
>> sure... we can put this on the list of topics.
>
> The LESS protocol clearly delineates this affinity. The model of  
> LESS is that multiple hosts may all provide simulation services for  
> the same location; however, objects have affinity for their "own"  
> kind of hosts. The hosts peer information about the outcome/ 
> presentation of simulation, not the objects themselves.
>
> Given that it makes no sense to try to "inject" or "control" an  
> object unless you know that the object is compatible with the  
> execution environment assumed by the object, I think object  
> injection onto servers (as opposed to peer-based object observation)  
> belongs clearly among system implementation details, not in an  
> interop protocol.
>
> Second Life, of course. If that's what you want to do, please  
> express that in the charter, and remove the "vendor neutral"  
> language from the charter, so we can discuss neutral  
> interoperability in some better forum. (Although naming the Second  
> Life internals standard "MMOX" seems a little disingenuous at that  
> point).
>
> Sincerely,
>
> jw
>

---

From: Jon Watte <[email-masked]>
Date: Mon, 02 Mar 2009 12:54:31 -0800

> can put this on the list of topics.

You are saying that the current OGP proposal is "sponsored" for this 
group, but alternative proposals, like LESS, are not "sponsored" for 
this group, even if expressed as edits/replacements for the OGP 
proposal. Is this a correct statement?

Do you accept the conclusion that OGP, as currently presented, 
necessarily requires the execution environment and client protocol to be 
technology specific, and thus the OGP protocol, as currently presented, 
will not lead to widespread virtual world interoperability outside of 
the Second Life derived sphere?

I draw from this statement the conclusion that what you want to 
standardize is the (future) implementation details of Second Life. If 
that's what you want to do, please express that in the charter, and 
remove the "vendor neutral" language from the charter, so we can discuss 
neutral interoperability in some better forum.

Sincerely,

jw

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Mon, 2 Mar 2009 13:26:03 -0800

yes. a LESS-like proposal has not been submitted as a draft.

no. i do not accept that OGP as currently presented requires  
technology specificity. it requires no licensed IPR from Linden.  
neither the OGP specifications nor the implementations were developed  
exclusively by linden employees (though i think the specs were  
actually typed mostly by lindens.) you could probably shoehorn object- 
affinity into the message flows as they currently stand, but that is  
not a proposed work item because no one has shown up with a proposal  
or a requirement for supporting it.

if you want a LESS-like proposal to be included in the charter... type  
one up and submit it as a draft.

On Mar 2, 2009, at 12:54 PM, Jon Watte wrote:

>> sorry... shoulda been more specific. as i said, there are no  
>> proposals on the table in this forum for a virtual world that  
>> behaves differently. if you want to add an OLIVE(tm) derived  
>> something based on object-based partitioning for simulation, or if  
>> someone wants to sponsor an effort to publish LESS as an IETF  
>> standard... sure... we can put this on the list of topics.
>
> necessarily requires the execution environment and client protocol  
> to be technology specific, and thus the OGP protocol, as currently  
> presented, will not lead to widespread virtual world  
> interoperability outside of the Second Life derived sphere?
>
> standardize is the (future) implementation details of Second Life.  
> If that's what you want to do, please express that in the charter,  
> and remove the "vendor neutral" language from the charter, so we can  
> discuss neutral interoperability in some better forum.
>
> Sincerely,
>
> jw
>

---

From: Jon Watte <[email-masked]>
Date: Mon, 02 Mar 2009 13:27:58 -0800

Meadhbh Hamrick (Infinity) wrote:
> technology specificity. it requires no licensed IPR from

So what do you do about the fact that "avatar rezzing" is part of the 
protocol?
Does that not require the rezzer and rezzee to agree on the execution 
environment of such rezzing?

Sincerely,

jw

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Mon, 2 Mar 2009 13:48:04 -0800

no. there are no semantics regarding the execution environment in this  
protocol save that both ends of the protocol respond to protocol  
messages. this is a _wire_ protocol. it does not require you to model  
avatars or objects using any particular technology. it does, however,  
require that the system responsible for causing an object or avatar to  
appear in a virtual world alert the system or systems responsible for  
maintaining the state of that world.

so in that sense, yes, it presupposes a state-full virtual world  
distinct from any one single client system.

to date, there have been no proposals in this forum for adding "object  
affinity" support to the protocol. if you would like to participate in  
this effort, i would recommend you produce such a proposal.

as far as i know, there are no implementations that support anything  
like this, so you would be on your own in:
	* adding it to PyOGP or OpenSIm,
	* getting a community of people interested in developing code to  
support such a proposal
	* adding support for it in OLIVE(tm)
	* adding support for it in Croquet

but jon, to date, there has been _no_ proposal in this forum for  
adding "object affinity" to the protocol.

-cheers
-meadhbh

On Mar 2, 2009, at 1:27 PM, Jon Watte wrote:

> So what do you do about the fact that "avatar rezzing" is part of  
> the protocol?
> Does that not require the rezzer and rezzee to agree on the  
> execution environment of such rezzing?
>
> Sincerely,
>
> jw
>

---

From: Jon Watte <[email-masked]>
Date: Mon, 02 Mar 2009 16:56:52 -0800

> this effort, i would recommend you produce such a proposal.

Here you go: A full protocol description, that is provably technology 
neutral, and will achieve significant virtual world interoperability, as 
per the five use cases I have already posted:

http://www.ietf.org/internet-drafts/draft-jwatte-less-protocol-00.txt

>     * adding support for it in Croquet

Those four would have to be supported by the developers of each of those 
products, right? Last I checked, I'm only responsible for one of them. 
It seems, from your post, as if you believe that "interoperability" is 
actually "formalizing what Second Life already does or intends to do in 
the future," which to me seems like the antithesis to technology neutrality.

Now, I have not seen any use cases of what user-visible, 
cross-technology (or technology neutral) interoperability would be 
achieved through the implementation of OGP. Thus, I don't see how you 
can claim that it is a technology neutral interoperability protocol. 
It's quite likely I'm missing something -- so it would be very useful 
for me, as well as others who are not part of the Second Life sphere, to 
see those use cases clearly spelled out. I'm not the only one who asks 
for use cases on this list. Can you please provide clear, step-by-step, 
use cases, similar to those at http://www.interopworld.org/mmox-use-cases ?

Here is what I understand about OGP, at a very broad level:

1) A user authenticates to an authentication domain. This is typically 
some server operated by some vendor somewhere.
2) The authentication domain now needs to figure out where the user is, 
or wants to go. It then uses OGP to contact a simulation server (Region 
domain) of some sort, to inject the user avatar, or other objects, onto 
that server.
3) The authentication domain tells the user's client where to connect to 
to "experience" and control the avatar in question.

I thus draw the conclusion that OGP, as currently proposed, would 
require that the execution environment would be shared between the 
object managed by the authentication domain (and injected through OGP), 
and the actual simulation server. Thus, you could not use this for 
object injection cross technologies -- you couldn't have an OpenSim OGP 
initiator inject an avatar into a Metaverse server, unless Metaverse and 
OpenSim somehow implemented the same avatar execution model.

Further, I draw the conclusion that the user's client must understand 
the state protocol that's used on the server onto which the user avatar 
is injected, else such injection isn't very meaningful in the vast 
majority of cases. Thus, the user's client, and the simulation server, 
and the object repository all need to belong to the same technology family.

So, how does OGP achieve any useful degree of vendor neutral 
interoperability? If I implemented OGP into OLIVE tomorrow, who could I 
interoperate with, that I cannot interoperate with today, and what could 
my users actually accomplish that they can't accomplish today?

Now, if you want to achieve that kind of interoperability across the 
narrow SecondLife/RealXTend/OpenSim cloud, where the servers and clients 
all share similar execution environments, which is all Second Life 
related technology, that's a fine goal. However, trying to slap the 
label "vendor neutral" on that is, at best, falling very short of the 
goal, and at worst, seems like trying to manipulate the IETF process for 
marketing purposes. If what you want to do is to work on OGP for use 
cases similar to what I have outlined above, simply re-state the charter 
in terms of what you actually want to do, and I will move true 
vendor-neutral interoperability to another discussion medium.

I did not sign up to have any opinion on Second Life internals, or the 
internals of technologies closely derived from Second Life. I signed up 
expecting work on true, cross-vendor, cross-technology virtual world 
interoperability, as achieved by the DoD with DIS in the 1980's, but 
moved to cheaper technology with vastly more widespread and varied use. 
If you carefully read my protocol proposal, you would see that it 
actually achieves that goal. If that goals is not what you believe this 
forum is chartered to do, then we should clarify the charter.

Sincerely,

jw

---

From: Charles Krinke <[email-masked]>
Date: Tue, 3 Mar 2009 02:01:35 +0000

Looks very similar to the OGP_LLSD_Draft3 proposal at:

http://wiki.secondlife.com/wiki.OGP_LLSD_Draft_3

Perhaps Meadhbh (Infinity) or JHurliman could correct me if I have a
mis-conception.

If I am correct, and I would encourage a third party, preferable independent
to check this premise, then it seems to me we merely move forward with the
OGP_LLSD_Draft3 and start discussing more substantial issues then whether we
call this protocol LESS, MORE, OGP or OTHER.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Tue, Mar 3, 2009 at 12:56 AM, Jon Watte <[email-masked]> wrote:

>> affinity" support to the protocol. if you would like to participate in this
>> effort, i would recommend you produce such a proposal.
>>
>>
> neutral, and will achieve significant virtual world interoperability, as per
> the five use cases I have already posted:
>
>  as far as i know, there are no implementations that support anything like
>> this, so you would be on your own in:
> products, right? Last I checked, I'm only responsible for one of them. It
> seems, from your post, as if you believe that "interoperability" is actually
> "formalizing what Second Life already does or intends to do in the future,"
> which to me seems like the antithesis to technology neutrality.
>
> Now, I have not seen any use cases of what user-visible, cross-technology
> (or technology neutral) interoperability would be achieved through the
> implementation of OGP. Thus, I don't see how you can claim that it is a
> technology neutral interoperability protocol. It's quite likely I'm missing
> something -- so it would be very useful for me, as well as others who are
> not part of the Second Life sphere, to see those use cases clearly spelled
> out. I'm not the only one who asks for use cases on this list. Can you
> please provide clear, step-by-step, use cases, similar to those at
> http://www.interopworld.org/mmox-use-cases ?
>
> 1) A user authenticates to an authentication domain. This is typically some
> server operated by some vendor somewhere.
> 2) The authentication domain now needs to figure out where the user is, or
> wants to go. It then uses OGP to contact a simulation server (Region domain)
> of some sort, to inject the user avatar, or other objects, onto that server.
> 3) The authentication domain tells the user's client where to connect to to
> "experience" and control the avatar in question.
>
> I thus draw the conclusion that OGP, as currently proposed, would require
> that the execution environment would be shared between the object managed by
> the authentication domain (and injected through OGP), and the actual
> simulation server. Thus, you could not use this for object injection cross
> technologies -- you couldn't have an OpenSim OGP initiator inject an avatar
> into a Metaverse server, unless Metaverse and OpenSim somehow implemented
> the same avatar execution model.
>
> Further, I draw the conclusion that the user's client must understand the
> state protocol that's used on the server onto which the user avatar is
> injected, else such injection isn't very meaningful in the vast majority of
> cases. Thus, the user's client, and the simulation server, and the object
> repository all need to belong to the same technology family.
>
> interoperate with, that I cannot interoperate with today, and what could my
> users actually accomplish that they can't accomplish today?
>
> Now, if you want to achieve that kind of interoperability across the narrow
> SecondLife/RealXTend/OpenSim cloud, where the servers and clients all share
> similar execution environments, which is all Second Life related technology,
> that's a fine goal. However, trying to slap the label "vendor neutral" on
> that is, at best, falling very short of the goal, and at worst, seems like
> trying to manipulate the IETF process for marketing purposes. If what you
> want to do is to work on OGP for use cases similar to what I have outlined
> above, simply re-state the charter in terms of what you actually want to do,
> and I will move true vendor-neutral interoperability to another discussion
> medium.
>
> interoperability, as achieved by the DoD with DIS in the 1980's, but moved
> to cheaper technology with vastly more widespread and varied use. If you
> carefully read my protocol proposal, you would see that it actually achieves
> that goal. If that goals is not what you believe this forum is chartered to
> do, then we should clarify the charter.
>
>
> Sincerely,
>
> jw
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: David W Levine <[email-masked]>
Date: Mon, 2 Mar 2009 21:09:46 -0500

FYI, I've gone through the exercise of putting my scope/problem document 
up as a formal IETF document, which can be located at:
http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.txt 
or
http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.xml 

This merely makes it a formal input that we may expect IETF members 
interested in the problem space to read prior to the March 24th BOF. 

- David W. Levine
~Zha Ewry (In Second Life)

---

From: Jon Watte <[email-masked]>
Date: Mon, 02 Mar 2009 18:37:10 -0800

David W Levine wrote:
>
> FYI, I've gone through the exercise of putting my scope/problem 
> document up as a formal IETF document, which can be located at:
> _http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.txt_
> or
> _http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.xml_
>

I think this is a fairly good statement of the highest-level overview of 
the various parts of vendor neutral (cross-vendor) interoperability. I 
also think it's nowhere near what the initial charter for the group was :-)

The one thing missing is a way to determine how something is included or 
excluded from consideration. For example, if a protocol is open, but 
does not enable any actual cross-technology interoperability scenario, 
is it still an interoperability protocol, and is it still within scope?

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Tue, 3 Mar 2009 11:40:07 +0000

Zha, your document<http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.txt>ticks
all of the boxes necessary for our work I think, both in respect of
our methodology and our end goals:

   - intentionally broad name and scope
   - vendor neutrality
   - addressing the diversity of virtual worlds
   - services-oriented viewpoint
   - protocol decoupled from implementations
   - scalability arising from the above two
   - no mandated world architecture
   - no mandated a priori solutions
   - protocol extensibility for diverse payloads
   - addressing security though recognized standards

(Among many others.)  That's a very good set of boxes for MMOX, and I think
it could take us far.

Morgaine.

On Tue, Mar 3, 2009 at 2:09 AM, David W Levine <[email-masked]> wrote:

>
> FYI, I've gone through the exercise of putting my scope/problem document up
> as a formal IETF document, which can be located at:
> *http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.txt*<http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.txt>
> or
> *http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.xml*<http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.xml>
>

---

From: Heiner Wolf <[email-masked]>
Date: Tue, 3 Mar 2009 14:35:01 +0100

Very good document. Could be the cornerstone of a requirements RFC.

--
Dr. Heiner Wolf
Tassadar (in weblin)

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

---

From: Charles Krinke <[email-masked]>
Date: Tue, 3 Mar 2009 07:36:28 -0800

I have gone back and read David's (Zha's) document three times now and it
seems most appropriate for the point we are currently at. I would urge
others to read it also.

+1

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Tue, Mar 3, 2009 at 5:35 AM, Heiner Wolf <[email-masked]>wrote:

> up

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Dan Olivares <[email-masked]>
Date: Tue, 3 Mar 2009 12:30:07 -0500

A couple of technical nit picky Items that need to be fixed in the draft.

Item 3.5 has a typo.  Change spaace to space.

In 3.6, you do use 'Region', in the note you say you're avoiding using it.

In the third paragraph in 6, the sentence doesn't end, "such as when
two different approaches have radically different"

Also, In the note in 4, "You may have to shutdown your client on one
system and start another.", doesn't that break the 'eXperience'?
If we're going for eXperience, doesn't that mean that we should do
what we can to ensure that the immersion in the eXperience isn't
broken?

Best Regards

Dan

---

From: "Hurliman, John" <[email-masked]>
Date: Tue, 3 Mar 2009 10:33:22 -0700

It does not appear to be similar at all to me. I wrote a post on interoperability (slightly too long for an e-mail) that details out why OGP is dodging the interoperability problem with explicit trust maps (http://software.intel.com/en-us/blogs/2009/02/18/approaching-virtual-world-interoperability/). LESS is still essentially a virtual world gateway service, like those gateways that connect AIM and Jabber, but at least you don't have to have a business partnership (trust agreement) with the worlds you are gatewaying to.

In addition to having less use cases, I detailed out the problems with OGP in MMOX in a previous e-mail (http://www.ietf.org/mail-archive/web/mmox/current/msg00821.html). If it's too early for protocol talk, I would modify your statement to "we merely move forward with the LESS_PROTOCOL_00 and start discussing more substantial issues then whether we call this protocol LESS, MORE, OGP, or OTHER."

John

>Sent: Monday, March 02, 2009 6:02 PM
>To: Jon Watte
>Cc: [email-masked]; [email-masked]
>If I am correct, and I would encourage a third party, preferable
>independent to check this premise, then it seems to me we merely move
>forward with the OGP_LLSD_Draft3 and start discussing more substantial
>issues then whether we call this protocol LESS, MORE, OGP or OTHER.
>
>Charles Krinke
>OpenSim Core Developer
>OSGrid Director
>
>
>		to date, there have been no proposals in this forum for
>adding "object affinity" support to the protocol. if you would like to
>participate in this effort, i would recommend you produce such a
>proposal.
>
>
>
>
>	Here you go: A full protocol description, that is provably
>technology neutral, and will achieve significant virtual world
>interoperability, as per the five use cases I have already posted:
>
>		as far as i know, there are no implementations that support
>anything like this, so you would be on your own in:
>		   * getting a community of people interested in developing
>code to support such a proposal
>	Those four would have to be supported by the developers of each of
>those products, right? Last I checked, I'm only responsible for one of
>them. It seems, from your post, as if you believe that
>"interoperability" is actually "formalizing what Second Life already
>does or intends to do in the future," which to me seems like the
>antithesis to technology neutrality.
>
>	Now, I have not seen any use cases of what user-visible, cross-
>technology (or technology neutral) interoperability would be achieved
>through the implementation of OGP. Thus, I don't see how you can claim
>that it is a technology neutral interoperability protocol. It's quite
>likely I'm missing something -- so it would be very useful for me, as
>well as others who are not part of the Second Life sphere, to see those
>use cases clearly spelled out. I'm not the only one who asks for use
>cases on this list. Can you please provide clear, step-by-step, use
>cases, similar to those at http://www.interopworld.org/mmox-use-cases ?
>
>	1) A user authenticates to an authentication domain. This is
>typically some server operated by some vendor somewhere.
>	2) The authentication domain now needs to figure out where the
>user is, or wants to go. It then uses OGP to contact a simulation server
>(Region domain) of some sort, to inject the user avatar, or other
>objects, onto that server.
>	3) The authentication domain tells the user's client where to
>connect to to "experience" and control the avatar in question.
>
>	Further, I draw the conclusion that the user's client must
>understand the state protocol that's used on the server onto which the
>user avatar is injected, else such injection isn't very meaningful in
>the vast majority of cases. Thus, the user's client, and the simulation
>server, and the object repository all need to belong to the same
>technology family.
>
>	Now, if you want to achieve that kind of interoperability across
>the narrow SecondLife/RealXTend/OpenSim cloud, where the servers and
>clients all share similar execution environments, which is all Second
>Life related technology, that's a fine goal. However, trying to slap the
>in terms of what you actually want to do, and I will move true vendor-
>neutral interoperability to another discussion medium.
>
>	I did not sign up to have any opinion on Second Life internals, or
>the internals of technologies closely derived from Second Life. I signed
>up expecting work on true, cross-vendor, cross-technology virtual world

---

From: Jon Watte <[email-masked]>
Date: Tue, 03 Mar 2009 11:00:21 -0800

Hurliman, John wrote:
> OGP is dodging the interoperability problem with explicit trust maps (http://software.intel.com/en-us/blogs/2009/02/18/approaching-virtual-world-interoperability/). 

I think the difference is deeper than that. In OGP, as far as I can 
tell, three entities all need to share a known representation of objects:
The object implementation (avatar, etc) as it comes from the object 
repository
The simulation server, where the object is injected
The client, that observes the simulation and presents it to the user

In this model, even if I implement OGP on the OLIVE side, OLIVE cannot 
interoperate with anything else. The only interoperability you get is if 
your client, server and object execution environment happens to be 
compatible with whatever target system you are attempting to 
interoperate with. In practice, this is only the case for Second 
Life-derived technologies in their own sphere, Unreal3-derived 
technologies in their own sphere, OLIVE-derived technologies in their 
own sphere, etc. Thus, no cross-technology interoperability is actually 
achieved, and thus I think it is misleading to label OGP a vendor 
neutral interoperability protocol. When actually implemented, it does 
not provide vendor neutral interoperability, it only provides vendor 
specific interoperability.

Additionally, the model of OGP does not scale well for larger 
interoperability scenarios, where multiple users from multiple different 
systems all want to interoperate, because all those users need to be 
injected on the same host. The LESS approach is one of bridging separate 
simulation servers into the same physical space, and thus scales a lot 
further.

It's unfortunately not very explicit in version 00 of the LESS 
description (http://tools.ietf.org/html/draft-jwatte-less-protocol-00), 
but the model is this:

1) User A logs on to system A (say, OpenSim) and invites user B using 
undefined means
2) User B logs on to system B (say, OLIVE) and accepts the invitation 
using undefined means
3) The B system sets aside some "empty space" on a simulator, places 
user B there, and then starts peering with system A
4) The environment and objects from system A, as well as user A himself, 
is peered to system B using LESS.
5) The objects and user from system B is peered to system A using LESS.

This means that both users see a collective simulation, where some 
objects are homed on A, some objects are homed on B, and they all 
interact. The nice property of this system is that it will scale very 
far, because objects are only simulated on their home systems. Further, 
it requires no changes to any clients of any participating system, 
because the presentation from system to client can be whatever it 
already is, as translation happens on the server-side LESS 
implementation level. (For p2p systems, view them as servers with a 
display stuck into the brain stem :-)

Please feel free to ask for clarification if there's something in this 
model that you find confusing. I have described this model several 
times, but each time I describe it, some new person tells me something 
along the lines of "Oh, now I get it -- that seems simple and useful. I 
hadn't thought in those terms before." I figure if I describe it often 
enough, in terms varied enough, perhaps in the end almost everyone will 
actually understand what I'm saying :-/

Sincerely,

jw

---

From: Jesrad <[email-masked]>
Date: Wed, 4 Mar 2009 12:54:25 +0100

Indeed, this is a very good document.

... reading it, it appears that one can liken the interoperability
problem to building a common virtual world for virtual worlds. I mean,
when residents of Croquet and SL meet online, they make SL and Croquet
parts of a bigger virtual world. Experiences that happen across VWs
may persist or propagate in this "super-VW", beyond just SL and
Croquet. That makes MMOX a full-blown VW protocol by necessity, and
not just a wire protocol, whether it rests on top of existing VW
protocols, leverages existing conversion tools or introduces its own
solutions as intermediate gateways. Compliant VWs will have to
simulate more than just their side of interoperability, or maybe I'm
wrong ?

Regarding 4. (Micropayement): information on cost alone is not enough
for a transaction, the exact scope of what this cost applies to is
required. We're expecting cross-VW transactions here so the exchanged
assets are to be completely defined at the MMOX-layer, that should
make it trivial to specify such a scope then.

Regarding 5. (solution space): the way the shared simulation is
internally distributed between each virtual space server probably
matters: some VWs seperate it topologically (each server handling a
definite area of the combined virtual geography), while some seperate
it functionnally (after the network's topology or some fixed
hierarchy), yet others seperate it dynamically (Voronoi-based
distribution of load in Solipsis) and I partly remember of one that
seperates the "shards" of the virtual world on an ownership/identity
basis (each node belongs to a user that simulates the VW elements that
are attributed to that user, independantly of topology).

This has an impact on MMOX, it must accomodate all those distribution
models, so it may be worth expliciting that the protocol abstract the
distribution model by not making assumptions about it and by entirely
relying on the endpoint for anything related to it. For example, we
cannot assume that the topological neighbour of a given endpoint is
necessarily the next endpoint to connect to when changing "region", it
must be asked of the current "region". I use the concept of region
(substitute "bubble" or "shard" as you like) here for lack of
knowledge of what representation the cross-VW will take in practice
(topological connection with seamless geography ? Cross-TP capability
? Portal junction ? depends on the representation of the distribution
in use in the concerned VW ?).

---

From: Jon Watte <[email-masked]>
Date: Wed, 04 Mar 2009 10:29:00 -0800

> (substitute "bubble" or "shard" as you like) here for lack of

Why should interoperability care about implementation details like 
regions or shards?

In my mind, those are different for each system. I think it's much 
better if interoperability simply tells us how systems connect together, 
and agree on some shared playbox/space/planet; how each system then 
contributes objects to that shared space is up to that system (within 
the bounds of interoperability). How the system displays the objects 
from itself and other systems to the clients of that system is also up 
to that system, entirely separate from interoperability.

That would be a lot simpler to implement, at least as a first step, too :-)

Sincerely,

jw

---

From: "Frisby, Adam" <[email-masked]>
Date: Wed, 4 Mar 2009 13:34:47 -0500

As I said before - I think we're talking multiple standards here. Some on this list want to talk about standardising the World protocols, some identity and authentication protocols, some presence protocols. I think recognizing this is going to make life easier - as each of the suite complement and don't overlap each other.

Adam

> Jon Watte
> Sent: Wednesday, 4 March 2009 10:29 AM
> To: Jesrad
> Cc: [email-masked]
> Subject: Re: [mmox] Submission of scope/problem draft as IETF
> document..
>
> Jesrad wrote:

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Wed, 4 Mar 2009 15:06:45 -0800

right. but we're still in the exploratory phase and we have only a  
DRAFT charter (and one that's going to see a lot of reworking at that.)

so... the world is big... let's get opinions, work items, drafts,  
comments, etc. on the table before claiming victory or defeat (or even  
trying to claim we have a coherent, widely-supported  charter.)

On Mar 4, 2009, at 10:34 AM, Frisby, Adam wrote:

> As I said before - I think we're talking multiple standards here.  
> Some on this list want to talk about standardising the World  
> protocols, some identity and authentication protocols, some presence  
> protocols. I think recognizing this is going to make life easier -  
> as each of the suite complement and don't overlap each other.
>
> Adam
>
>> That would be a lot simpler to implement, at least as a first step,  
>> too
>> :-)
>>
>> Sincerely,
>>
>> jw
>>

---

From: Jesrad <[email-masked]>
Date: Thu, 5 Mar 2009 11:00:04 +0100

I'm not sure my message was clear enough, but that is exactly the
point I was trying to make: because there are different existing
implementations for the interconnection and distribution of parts of
the shared simulation, the protocol cannot make assumptions about it a
priori and must rely on the endpoint for getting a reference to
another part of the same VW.

Anyway, I'm glad we completely agree here. I'll try to write more
clearly from now on.

On Wed, Mar 4, 2009 at 7:29 PM, Jon Watte <[email-masked]> wrote:
> Why should interoperability care about implementation details like regions
> or shards?
>
> In my mind, those are different for each system. I think it's much better if
> interoperability simply tells us how systems connect together, and agree on
> some shared playbox/space/planet; how each system then contributes objects
> to that shared space is up to that system (within the bounds of
> interoperability). How the system displays the objects from itself and other
> systems to the clients of that system is also up to that system, entirely
> separate from interoperability.
>

---

From: Morgaine <[email-masked]>
Date: Thu, 5 Mar 2009 13:10:53 +0000

On Thu, Mar 5, 2009 at 10:00 AM, Jesrad <[email-masked]> wrote:

because there are different existing implementations for the interconnection
> and distribution of parts of the shared simulation, the protocol cannot make
> assumptions about it a priori and must rely on the endpoint for getting a
> reference to another part of the same VW.
>
>
>
Indeed.  A while back I attempted a rough
decomposition<http://www.ietf.org/mail-archive/web/mmox/current/msg00750.html>of
services into functional "Domains" that might be relevant in a
well-connected metaverse, and I came up with a shortlist of 7 Domains.
(OGP currently only has the AD and RD defined, but there may well be more
forthcoming;  this notion is not in any way specific to OGP though.)   There
I assigned terrain and topology services to a notional Geographical Domain,
so in your scenario, there would be no natural adjacency between the regions
of an SL-style 2D grid:  map services would be a duty of the GD, so either
directly or indirectly it would have to be consulted.

However, there's a danger in this kind of decomposition.  Why should we
assume that a VW exposes this kind of information?  It may well use a GD
internally (and other Domains too), but this is entirely separate from the
question of whether it chooses to expose them --- that's a matter of design
policy.  I'll have to check whether the draft OGP hardwires in the design
policy that regions will be exposed, which is an SL implementation detail.
Hopefully it doesn't, so that an OGP system could be implemented using
completely virtualized regions.

These are the kind of questions that we'll be asking when the top level
parts of an interop protocol start to be examined, since policy is not
something that we want to hardwire in accidentally.

Morgaine.

On Thu, Mar 5, 2009 at 10:00 AM, Jesrad <[email-masked]> wrote:

> regions

---

From: thomas kirk <[email-masked]>
Date: Fri, 6 Mar 2009 10:39:02 -0500

a couple of proposals for additions and tweaks to your scope/problem draft:

In the list of interoperability goals, some of the objectives 
can be usefully generalized beyond MMOX spaces. For instance, both 
inter-VW presence and inter-VW messaging can be defined in such 
a way to include interoperation with non-VW presence and messaging 
services. A sentence in the previous section of your draft implies 
that we're interested in lowering boundaries not only between VWs, 
but also between VWs and the rest of the web/internet -- it's 
worthwhile to make this explicit among the goals where it makes sense. 
Generalizing these things doesn't entail solving a larger problem, 
just recognition that some goals are part of a broader problem space. 
(and presence and messaging are among the low-hanging fruit you 
talk about, in the sense that they're relatively uncontroversial, 
and obviously useful even to those with only nominal interest 
in interoperability).

Another worthwhile goal may be to define (or generalize) interfaces 
that enable MMOX spaces to expose views into their native object/asset 
stores (metadata, at least) to external tools and services 
(in particular, including non-MMOX entities). This will enable 
the creation of 3rd-party tools for navigation and manipulation of 
in-world data (e.g. web-based inventory management services), as well 
as indexing of VW content -- in a vast, distributed, diverse world 
of MMOX spaces, we'll have all the problems of finding stuff that 
we have with the web, so allowing external services to build indexes 
and relations across VW content is fairly important. The metadata 
standards defined for these interfaces will also inform approaches 
for non-native storage of objects, i.e. enabling one to store 
and address content outside of any particular VW's internal database.

---

From: Jesrad <[email-masked]>
Date: Fri, 6 Mar 2009 20:36:25 +0100

> (in particular, including non-MMOX entities).

I always assumed MMOX would use URIs for reference passing.

On Fri, Mar 6, 2009 at 4:39 PM, thomas kirk <[email-masked]> wrote:
>  > FYI, I've gone through the exercise of putting my scope/problem document
>  > up as a formal IETF document, which can be located at:
>  > http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.txt
>  > or
>  > http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.xml
>  >
>  > This merely makes it a formal input that we may expect IETF members
>  > interested in the problem space to read prior to the March 24th BOF.
>  >
>  > - David W. Levine
>  > ~Zha Ewry (In Second Life)
>  >

---

From: Christian Scholz <[email-masked]>
Date: Fri, 06 Mar 2009 20:52:35 +0100

+1

And I would add that there are solutions out there already which might 
just be adjusted a bit to make them VW compatible.

I think there are some areas:

  - identity/authentication
  - profile data
  - friends list
  - presence
  - instant messaging
  - not so instant messaging

> and address content outside of any particular VW's internal database. 

+1 again.

I was also thinking along such lines as there might be a very general 
RESTful API which lets you manage your inventory. To some services those 
binary blob might mean something, others might simply use the attached 
metadata. Such a thing might be useful for 3D objects but also simply 
for photos, text messages, videos and so on.

-- Christian

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

---

From: Christian Scholz <[email-masked]>
Date: Fri, 06 Mar 2009 20:56:13 +0100

> I always assumed MMOX would use URIs for reference passing.

Maybe (OGP at least does) ;-) But using URIs does not really mean that 
you are automatically compatible. Common metadata formats and some 
definition of e.g. a RESTful interface might play a role here, too.

E.g. if you look at the capability system in OGP then this wouldn't 
directly be compatible with more general web services. They'd rather use 
some header for authorization I'd think (e.g. with OAuth you can put it 
in the URL but you can also use a header IIRC).

-- Christian

---

From: thomas kirk <[email-masked]>
Date: Fri, 6 Mar 2009 15:50:35 -0500

> definition of e.g. a RESTful interface might play a role here, too.

exactly so. certainly the interface must include URIs or something equivalent 
for addressing objects, but also means for query and retrieval (at least), 
and a commonly understood format for representing content. expressing this as 
a REST interface is a good fit.