Subject: [mmox] 3-world OGP interop scenario

From: Morgaine <[email-masked]>
Date: Thu, 12 Mar 2009 14:35:23 +0000

The following VW interop scenario is posed to find answers to Jon's
questions that I highlighted
here<http://www.ietf.org/mail-archive/web/mmox/current/msg01112.html>
.

Consider 3 virtual worlds, A, B and C.  World A has an account for a client
A1 associated with it, world B has an account for client B1, and C has an
account for C1.  World A's server(s) are connected for interop to those of
B, and B's server(s) are connected for interop to those of C.  A1 is
initially connected only to A, B1 only to B, and C1 only to C.

To simplify this scenario, I'm going to use "A1" to refer to many things:
the client itself, its user, its associated account in world A, its
agent/presence in any world, and its displayed avatar.  Use context to
disambiguate them please. :-)

A1 has an avatar wearing or carrying objects from world A.  A1 teleports
from world A into a region in world B.  From B, A1 walks over transparently
into a region in world C.  Within C, A1 purchases a dress C1D produced by
the user C1, wears it, and obtains a landmark to its source.  A1 then walks
or teleports back into world B and engages in polite conversation about
interop of dress graphics with catwalk organizer B1.

A1 then returns to A, notes that C1D looks beautiful in world A's lighting,
decides that she wants another C1D, and teleports to that region of C (to
which A is not connected) directly using the landmark.

For bonus points, let A1 also buy from C1 an object C1S containing scripted
behaviour, and transport it back to world A for use there.

Please explain to the list how all these elements might work in OGP, from
the perspective of protocol endpoints.

Morgaine.

---

From: Morgaine <[email-masked]>
Date: Thu, 12 Mar 2009 15:25:08 +0000

Lawson pointed out (in-world in SL) an important detail that I should have
mentioned explicitly:  the scenario was intended to illustrate OGP-based
interop *between diverse worlds* (which is an express claim for OGP, and
explicit in Jon's question).

Therefore I should have stated: * **"A, B and C do not run the same server
software"**.*

Thanks, Saijanai! :-)

Morgaine.

On Thu, Mar 12, 2009 at 2:35 PM, Morgaine <[email-masked]>wrote:

> questions that I highlighted here<http://www.ietf.org/mail-archive/web/mmox/current/msg01112.html>
> .
>
>

---

From: Jon Watte <[email-masked]>
Date: Thu, 12 Mar 2009 09:13:45 -0700

Morgaine wrote:
> A1 has an avatar wearing or carrying objects from world A.  A1 
> teleports from world A into a region in world B.  From B, A1 walks 
> over transparently into a region in world C.  Within C, A1 purchases a 
> dress C1D produced by the user C1, wears it, and obtains a landmark to 
> its source.  A1 then walks or teleports back into world B and engages 
> in polite conversation about interop of dress graphics with catwalk 
> organizer B1.

Thanks for the suggested use case!
Unfortunately, I can find very little support in OGP to make this happen 
end-to-end. For example, the assumption that client A can even talk to 
servers B and C seems to be totally implicit, but can't be assumed in 
the general world.
Is there a use case that maps to OGP without making large assumptions, 
such as that of a client being able to talk to all worlds involved in 
the transaction?

Sincerely,

jw

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Thu, 12 Mar 2009 09:57:42 -0700

yes. the designers of OGP assumed that clients can talk to servers.

there is support for this use case in the OGP/Teleport draft (which is  
yet to be published as an internet draft.)

On Mar 12, 2009, at 9:13 AM, Jon Watte wrote:

>> over transparently into a region in world C.  Within C, A1  
>> purchases a dress C1D produced by the user C1, wears it, and  
>> obtains a landmark to its source.  A1 then walks or teleports back  
>> into world B and engages in polite conversation about interop of  
>> dress graphics with catwalk organizer B1.
>
> Unfortunately, I can find very little support in OGP to make this  
> happen end-to-end. For example, the assumption that client A can  
> even talk to servers B and C seems to be totally implicit, but can't  
> be assumed in the general world.
> Is there a use case that maps to OGP without making large  
> assumptions, such as that of a client being able to talk to all  
> worlds involved in the transaction?
>
> Sincerely,
>
> jw
>
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox

---

From: Rob Lanphier <[email-masked]>
Date: Thu, 12 Mar 2009 10:05:35 -0700

On 3/12/09 9:13 AM, Jon Watte wrote:
> For example, the assumption that client A can even talk to servers B
> and C seems to be totally implicit, but can't be assumed in the
> general world.

Yes, one can assume client A can talk to servers B and C if we actually
go about the work of defining a standard client-server protocol spelling
out how the client is expected to behave in that transaction.

Rob

---

From: Jon Watte <[email-masked]>
Date: Thu, 12 Mar 2009 11:55:38 -0700

> out how the client is expected to behave in that transaction.

Do you seriously think it's a good idea to specify all the minutiae of 
how a server and client interact, as a standard protocol? Including how 
GUI is tied to local and remote capabilities, how a scene graph is 
constructed and animated, how version patching is done, how user control 
is forwarded, etc?
And all that work, just to be able to show up in world B instead of 
world A? What about objects you want to use cross worlds; are you saying 
you also want to specify the exact runtime requirements for objects 
(scripting language, physics interface, etc)?

Personally, I believe that trying to do that means that there will be no 
cross-world interoperability except for the worlds that share the same 
DNA (meaning SecondLife <-> OpenSim, and perhaps ActiveWorlds <-> 
Worlds.com, and perhaps OLIVE <-> There.com). I think that would be a 
huge loss. Additionally, I think that all of that effort will actually 
not solve any problem that users care about, because all it really 
solves is saving users from having to install an extra client. But even 
in the ActiveWorlds <-> Worlds.com scenario, or the OLIVE <-> There.com 
scenario, because the platforms share technology DNA, using OGP is 
probably more work than it's worth, because there is already an existing 
infrastructure that is less resistance, and achieves the same amount of 
interop. OGP doesn't help interop, in this case, except for the Second 
Life <-> Open Sim case.

Meanwhile, I believe that the real enabler of interop is to be able to 
merge the simulations of different worlds, something like LESS or MXP. 
If you think about it, that model actually provides the same benefit you 
seek: the user being able to visit other places. It even provides the 
benefit of the user not having to install more than one client, ever, as 
long as the user's "home" world (or "virtual world service provider" if 
you will) is interoperable. However, it also provides the benefit of 
being able to use a There.com car, while letting ActiveWorlds users see 
you do that (and perhaps even ride the car). Also, the LESS/MXP approach 
requires much less engineering to implement for the majority of world 
vendors. I know this from experience, having done it for different 
protocols in the past.

Thus, if the goal is general virtual world interoperability, I believe 
the OGP model does not achieve it, whereas the LESS and MXP model does.

If the goal is to make systems with Linden Labs DNA interoperate, such 
as Open Sim or RealXTend, then I suggest that you state that as an 
explicit goal. I believe the feedback you're getting right now is that 
OGP, as proposed, is not suitable for interop outside that technology 
sphere.

Sincerely,

jw

---

From: Ann Otoole <[email-masked]>
Date: Thu, 12 Mar 2009 12:09:05 -0700 (PDT)

This happens to also be where intellectual property licensing becomes a factor because the content acquired in C may not be licensed for cross server/grid/zone/whatever use. So the "protocol" or whatever you wish to call it will have to include the payload package for licensing data and all participating server/grid/zone/whatever agree to not allow instantiation of said content unless it is licensed for such propagation. 

Today people openly and blatantly use a product called Second Inventory (a client) to steal content by exporting it from Second Life and importing it into a different "grid" where there are no licensing schemes, exporting it back out, and then importing it back into Second Life as the sole creator for the express purpose of selling content without a license. I guess you could also call that a use case eh?

________________________________
From: Rob Lanphier <[email-masked]>
To: Jon Watte <[email-masked]>
Cc: MMOX-IETF <[email-masked]>
Sent: Thursday, March 12, 2009 1:05:35 PM
Subject: Re: [mmox] 3-world OGP interop scenario

Rob

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Thu, 12 Mar 2009 12:09:05 -0700

jon. yes, we do believe it's a good idea to specify interaction  
between hosts in a standard protocol.

no. we do not believe it is appropriate for a protocol to specify a  
GUI, which is why the OGP designers did not include a GUI in the  
specification. You will note that there are also no sections in the  
standard limiting end points to use a particular format for the  
creation of scene graphs, nor is there a specification for how version  
patching for executable is to be accomplished. nor is there a  
specification for mapping arrow keys to RPC calls.

sorry to lose you to this effort, we look forward to seeing your work  
with LESS and MXP.

-cheers
-meadhbh

On Mar 12, 2009, at 11:55 AM, Jon Watte wrote:

> Do you seriously think it's a good idea to specify all the minutiae  
> of how a server and client interact, as a standard protocol?  
> Including how GUI is tied to local and remote capabilities, how a  
> scene graph is constructed and animated, how version patching is  
> done, how user control is forwarded, etc?
> world A? What about objects you want to use cross worlds; are you  
> saying you also want to specify the exact runtime requirements for  
> objects (scripting language, physics interface, etc)?
>
> Personally, I believe that trying to do that means that there will  
> be no cross-world interoperability except for the worlds that share  
> the same DNA (meaning SecondLife <-> OpenSim, and perhaps  
> ActiveWorlds <-> Worlds.com, and perhaps OLIVE <-> There.com). I  
> think that would be a huge loss. Additionally, I think that all of  
> that effort will actually not solve any problem that users care  
> about, because all it really solves is saving users from having to  
> install an extra client. But even in the ActiveWorlds <-> Worlds.com  
> scenario, or the OLIVE <-> There.com scenario, because the platforms  
> share technology DNA, using OGP is probably more work than it's  
> worth, because there is already an existing infrastructure that is  
> less resistance, and achieves the same amount of interop. OGP  
> doesn't help interop, in this case, except for the Second Life <->  
> Open Sim case.
>
> Meanwhile, I believe that the real enabler of interop is to be able  
> to merge the simulations of different worlds, something like LESS or  
> MXP. If you think about it, that model actually provides the same  
> benefit you seek: the user being able to visit other places. It even  
> provides the benefit of the user not having to install more than one  
> client, ever, as long as the user's "home" world (or "virtual world  
> service provider" if you will) is interoperable. However, it also  
> provides the benefit of being able to use a There.com car, while  
> letting ActiveWorlds users see you do that (and perhaps even ride  
> the car). Also, the LESS/MXP approach requires much less engineering  
> to implement for the majority of world vendors. I know this from  
> experience, having done it for different protocols in the past.
>
> Thus, if the goal is general virtual world interoperability, I  
> believe the OGP model does not achieve it, whereas the LESS and MXP  
> model does.
>
> If the goal is to make systems with Linden Labs DNA interoperate,  
> such as Open Sim or RealXTend, then I suggest that you state that as  
> an explicit goal. I believe the feedback you're getting right now is  
> that OGP, as proposed, is not suitable for interop outside that  
> technology sphere.
>
> Sincerely,
>
> jw
>

---

From: Ann Otoole <[email-masked]>
Date: Thu, 12 Mar 2009 12:14:26 -0700 (PDT)

Actually this is all moot anyway since Worlds.com CEO Thom Kidrin is on a slash and burn Sherman March To The Sea lawsuit binge and there will be no 3D internet outside of Worlds.com if he wins. So the first order of business needs to be putting him out of business by defeating his patent or by moving this entire effort to a country that does not recognize U.S. Patent Law.

Re: http://www.massively.com/2009/03/12/world-of-warcraft-and-second-life-are-next-says-worlds-com-ceo/

________________________________
From: Jon Watte <[email-masked]>
To: Rob Lanphier <[email-masked]>
Cc: MMOX-IETF <[email-masked]>
Sent: Thursday, March 12, 2009 2:55:38 PM
Subject: Re: [mmox] 3-world OGP interop scenario

> out how the client is expected to behave in that transaction.

Do you seriously think it's a good idea to specify all the minutiae of how a server and client interact, as a standard protocol? Including how GUI is tied to local and remote capabilities, how a scene graph is constructed and animated, how version patching is done, how user control is forwarded, etc?
And all that work, just to be able to show up in world B instead of world A? What about objects you want to use cross worlds; are you saying you also want to specify the exact runtime requirements for objects (scripting language, physics interface, etc)?

Personally, I believe that trying to do that means that there will be no cross-world interoperability except for the worlds that share the same DNA (meaning SecondLife <-> OpenSim, and perhaps ActiveWorlds <-> Worlds.com, and perhaps OLIVE <-> There.com). I think that would be a huge loss. Additionally, I think that all of that effort will actually not solve any problem that users care about, because all it really solves is saving users from having to install an extra client. But even in the ActiveWorlds <-> Worlds.com scenario, or the OLIVE <-> There.com scenario, because the platforms share technology DNA, using OGP is probably more work than it's worth, because there is already an existing infrastructure that is less resistance, and achieves the same amount of interop. OGP doesn't help interop, in this case, except for the Second Life <-> Open Sim case.

Meanwhile, I believe that the real enabler of interop is to be able to merge the simulations of different worlds, something like LESS or MXP. If you think about it, that model actually provides the same benefit you seek: the user being able to visit other places. It even provides the benefit of the user not having to install more than one client, ever, as long as the user's "home" world (or "virtual world service provider" if you will) is interoperable. However, it also provides the benefit of being able to use a There.com car, while letting ActiveWorlds users see you do that (and perhaps even ride the car). Also, the LESS/MXP approach requires much less engineering to implement for the majority of world vendors. I know this from experience, having done it for different protocols in the past.

Thus, if the goal is general virtual world interoperability, I believe the OGP model does not achieve it, whereas the LESS and MXP model does.

If the goal is to make systems with Linden Labs DNA interoperate, such as Open Sim or RealXTend, then I suggest that you state that as an explicit goal. I believe the feedback you're getting right now is that OGP, as proposed, is not suitable for interop outside that technology sphere.

Sincerely,

jw

---

From: "Mystical Demina" <[email-masked]>
Date: Thu, 12 Mar 2009 18:37:19 -0400

Here is what I predict.

I would submit that any company that opens up its computer to external
access is going to require you to accept a terms and agreement that states
anything you bring and use on their computer that you have ownership of or
at least license to make copies and the company hosting the virtual world
will not trust a protocol to define that.  They may agree that this content
is only cached and will be removed when you leave unless other terms are
arranged.  Additionally they would make you accept that they are not liable
for any use of it and can not be held liable in any damages that may occur
and you are accepting all such responsibility.  This means they would need
to know who you are to hold you responsible, which means you will probably
have to make an account and log in.

At least if it is my company and my virtual world that is what I would
require.

On the other hand once companies can move across virtual world boundaries
and sales people can visit different virtual worlds of other companies to
show products there will be a huge amount of free content as each company
creates virtual versions of their products and uses them for advertising
which will increase supply of available content.  But also driving down the
prices of content and killing most of the market.

Ultimately I believe it will be up to the person to make a decision as to if
I have rights to use this content in that place, or do I have rights to copy
this content to that place as we do with any software license we buy or any
digital item we purchase or download off of the internet.

I could be wrong.

Kevin Tweedy

SL Mystical Demina

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ann
Otoole
Sent: Thursday, March 12, 2009 3:09 PM
To: MMOX-IETF
Subject: Re: [mmox] 3-world OGP interop scenario

This happens to also be where intellectual property licensing becomes a
factor because the content acquired in C may not be licensed for cross
server/grid/zone/whatever use. So the "protocol" or whatever you wish to
call it will have to include the payload package for licensing data and all
participating server/grid/zone/whatever agree to not allow instantiation of
said content unless it is licensed for such propagation. 

Today people openly and blatantly use a product called Second Inventory (a
client) to steal content by exporting it from Second Life and importing it
into a different "grid" where there are no licensing schemes, exporting it
back out, and then importing it back into Second Life as the sole creator
for the express purpose of selling content without a license. I guess you
could also call that a use case eh?

  _____  

Rob

---

From: Morgaine <[email-masked]>
Date: Fri, 13 Mar 2009 11:51:19 +0000

On Thu, Mar 12, 2009 at 5:05 PM, Rob Lanphier <[email-masked]> wrote:

>
> Yes, one can assume client A can talk to servers B and C if we actually go
> about the work of defining a standard client-server protocol spelling out
> how the client is expected to behave in that transaction.
>
>
>
That sounds very reasonable to me Rob.  It is after all the job of protocol
makers to define means of machine interaction for pathways that may not have
existed before.

I would go further and say that this is even compatible with Jon's models,
given a willingness to be flexible.  Current OLIVE clients may not be able
to talk to other systems, but this is no bar to new clients of OLIVE being
able to do so.

In particular, the open source community is very good at capturing existing
network protocols and building them into new libraries and applications, so
an OLIVE client that works with more than just OLIVE could certainly be
envisaged.  All it would take is one open source developer who also uses
OLIVE to feel the need and be willing to scratch it.  Whether the OLIVE
organization would allow this or not is immaterial to us here --- we are in
the business of defining mechanisms, not policies.

And there are other solutions as well.  Nothing precludes OLIVE servers from
performing the role of a client in an OGP endpoint.  Some detailed analysis
of inbuilt assumptions would be required to be sure that this can work, but
in principle an OLIVE (or LESS) server could obtain all the necessary data
in this way from which to build a local simulation for its clients.

Morgaine.

---

From: Charles Krinke <[email-masked]>
Date: Fri, 13 Mar 2009 08:12:12 -0800

I have seen OGP work. I have also heard from a couple of folks that LL has
stopped the test with the betagrid. If this is not true, please correct me.
If it is true, may I suggest it might be to LL's advantage to start it up
again and let folks use it.

I receive regular reports of hundreds of HyperGrid uses each week, so this
one appears to have legs, and that is good.

I have seen two reports of MXP usage, which is minimal, but at least some
momentum is gaining.

If someone would like to contribute a LESS module to OpenSim, then I believe
my peers would be happy to accept it and testing could begin with LESS. That
would help it to gain momentum and credibility.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Fri, Mar 13, 2009 at 3:51 AM, Morgaine <[email-masked]>wrote:

> And there are other solutions as well.  Nothing precludes OLIVE servers
> from performing the role of a client in an OGP endpoint.  Some detailed
> analysis of inbuilt assumptions would be required to be sure that this can
> work, but in principle an OLIVE (or LESS) server could obtain all the
> necessary data in this way from which to build a local simulation for its
> clients.
>
>
> Morgaine.
>
>
>
>
>
>
>
>
>
>
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Bill Humphries <[email-masked]>
Date: Fri, 13 Mar 2009 10:21:06 -0700

> again and let folks use it.

Charles,

Linden Lab has been keeping the OGP agent server and regions up, but  
not doing active development.

---
Whump Linden is Bill Humphries || [email-masked] || http://secondlife.com/

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Fri, 13 Mar 2009 10:34:44 -0700

which is to say... we're not adding new features to the OGP test grid,  
and probably won't 'til we more fully specify them and get feedback  
from our beta testers.

during the course of last summer's beta, we learned a lot and received  
a fair amount of community input. submitting OGP to the IETF  
standardization process is part of the process of continuing OGP  
development. in short... we think the protocol for auth, teleport and  
event queue are fully baked. but... we want to get more input from the  
community ( especially from people who participate in last summer's  
beta and IETF "regulars" who may have more experience wedging things  
like OAuth / OpenID into existing protocols. ) and we want this  
process to take place in an IETF managed venue. and we're thinking  
that before we assign resources to add new features to the OGP test  
grid, we want to have a better idea of the end definition of these  
services.

to recap... we want to get another round of commentary on the existing  
OGP drafts before adding new bits of code to the grid and to the  
viewer. and we want to have enough time for everyone (OpenSim, PyOGP,  
viewer developers, etc.) to receive and integrate new protocol  
definitions.

-cheers
-meadhbh

---

From: Charles Krinke <[email-masked]>
Date: Fri, 13 Mar 2009 10:19:28 -0800

Thank you for correcting my mis-perception, Meadhbh (Infinity) that OGP is
alive and well on the Linden end. I would urge folks to use it and test its
capabilities and limits on an ongoing basis.

Any implementations that are being used helps gain momentum and confidence
in any implemented solution for interop so all of this is to our mutual
advantage.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Fri, Mar 13, 2009 at 9:34 AM, Meadhbh Hamrick (Infinity) <
[email-masked]> wrote:

> which is to say... we're not adding new features to the OGP test grid, and
> probably won't 'til we more fully specify them and get feedback from our
> beta testers.
>
> during the course of last summer's beta, we learned a lot and received a
> fair amount of community input. submitting OGP to the IETF standardization
> process is part of the process of continuing OGP development. in short... we
> think the protocol for auth, teleport and event queue are fully baked.
> but... we want to get more input from the community ( especially from people
> who participate in last summer's beta and IETF "regulars" who may have more
> experience wedging things like OAuth / OpenID into existing protocols. ) and
> we want this process to take place in an IETF managed venue. and we're
> thinking that before we assign resources to add new features to the OGP test
> grid, we want to have a better idea of the end definition of these services.
>
> to recap... we want to get another round of commentary on the existing OGP
> drafts before adding new bits of code to the grid and to the viewer. and we
> want to have enough time for everyone (OpenSim, PyOGP, viewer developers,
> etc.) to receive and integrate new protocol definitions.
>
> -cheers
> -meadhbh
>
>
>> Linden Lab has been keeping the OGP agent server and regions up, but not
>> doing active development.
>>
>> ---

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: David W Levine <[email-masked]>
Date: Fri, 13 Mar 2009 14:40:48 -0400

I'm also in the process of shaking out the bugs in a OGP complient AD for 
the OpenSim codebase. (built as an opensim servcie, cloned off of the user 
service) This will give us a second complete example of the design as well 
as a place to experiment with variations.

- David W. Levine
~ Zha Ewry (ISL)

Charles Krinke <[email-masked]> 
Sent by: [email-masked]
03/13/2009 02:19 PM

To
"Meadhbh Hamrick (Infinity)" <[email-masked]>
cc
MMOX-IETF <[email-masked]>
Subject
Re: [mmox] 3-world OGP interop scenario

Thank you for correcting my mis-perception, Meadhbh (Infinity) that OGP is 
alive and well on the Linden end. I would urge folks to use it and test 
its capabilities and limits on an ongoing basis.

Charles Krinke
OpenSim Core Developer
OSGrid Director

during the course of last summer's beta, we learned a lot and received a 
fair amount of community input. submitting OGP to the IETF standardization 
process is part of the process of continuing OGP development. in short... 
we think the protocol for auth, teleport and event queue are fully baked. 
but... we want to get more input from the community ( especially from 
people who participate in last summer's beta and IETF "regulars" who may 
have more experience wedging things like OAuth / OpenID into existing 
protocols. ) and we want this process to take place in an IETF managed 
venue. and we're thinking that before we assign resources to add new 
features to the OGP test grid, we want to have a better idea of the end 
definition of these services.

to recap... we want to get another round of commentary on the existing OGP 
drafts before adding new bits of code to the grid and to the viewer. and 
we want to have enough time for everyone (OpenSim, PyOGP, viewer 
developers, etc.) to receive and integrate new protocol definitions.

-cheers
-meadhbh

I have seen OGP work. I have also heard from a couple of folks that LL has
stopped the test with the betagrid. If this is not true, please correct 
me.
If it is true, may I suggest it might be to LL's advantage to start it up
again and let folks use it.

Charles,

---
Whump Linden is Bill Humphries || [email-masked] || 
http://secondlife.com/

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director_______________________________________________
mmox mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmox

---

From: Charles Krinke <[email-masked]>
Date: Fri, 13 Mar 2009 10:47:00 -0800

Thats great. I think we need all the running implementations we can get. To
me, actually using an implementation is very meaningful.

The other thing that I think this group is going to be concerned with is
describing a set of 'well-known" ports for clients and servers.

One of the things I notice is a significant problem in folks getting clients
and servers setup with various firewalls and as I understand it, the IETF is
concerned with making recommendations for "well-known" ports. This very well
may mean a change in some or all of the virtual worlds as we move forward in
defining a common set of ports for this work.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Fri, Mar 13, 2009 at 10:40 AM, David W Levine <[email-masked]> wrote:

>  *Charles Krinke <[email-masked]>*
> On Fri, Mar 13, 2009 at 9:34 AM, Meadhbh Hamrick (Infinity) <*
> [email-masked]* <[email-masked]>> wrote:
> Whump Linden is Bill Humphries || [email-masked]*<[email-masked]>||
> *http://secondlife.com/* <http://secondlife.com/>
>
> mmox mailing list*
> [email-masked]* <[email-masked]>*
> **https://www.ietf.org/mailman/listinfo/mmox*<https://www.ietf.org/mailman/listinfo/mmox>
>
> mmox mailing list*
> [email-masked]* <[email-masked]>*
> **https://www.ietf.org/mailman/listinfo/mmox*<https://www.ietf.org/mailman/listinfo/mmox>
>
>
>
> --
> Charles Krinke
> OpenSim Core Developer

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Latha Serevi <[email-masked]>
Date: Fri, 13 Mar 2009 12:16:24 -0700

I'm trying to read all of the MMOX internet-drafts and work out my own
perspective on them, before the meeting.   Perhaps we can do that together.
(I consider myself a neutral participant in MMOX who hopes to see a
WG formed that can build some protocol pieces that we all can use.)

In this installment:  my initial take on OGP Base (Foundation),
 http://www.ietf.org/internet-drafts/draft-lentczner-ogp-base-00.txt
I would appreciate your thoughts on the document; please keep
this thread strictly for discussion of our understanding of this one
document, and our BRIEF reactions to it.

Summary of section 2, which is where the protocol contributions are.
OGP Base makes use of:  HTTP, REST, LLSD, LLIDL, XML, JSON.
OGP Base defines:  named resources; capabilities; seed capability;
event_queue/get and its flow (which defines a mechanism for streaming
events from an entity to the viewer at the request of the viewer).

Commentary on section 2.  The word "events" seems to be shorthand
for "resource invocations that the entity wants performed on the viewer".
The viewer is a particular kind of protocol endpoint.  I don't see why
this mechanism shouldn't be defined between more general endpoints.
Overall, though, this all seems fairly straightforward and potentially 
useful.

Summary of section 1, which tries to define the overall
structure of the OGP protocol.   Section 1 loosely
defines the terms:  viewer; agent;  virtual world; region.
It introduces the entities "region domain" and "agent domain".
It states that the "basic flow of the protocol" is for a human to
use a viewer to instantiate an agent (via an agent domain)  in
a region (via a region domain), thereby setting up an interaction
where the viewer is streamed object updates from the (authoritative)
region, and the region is streamed avatar update requests from the viewer.

Commentary on section 1.   It seems as though the most common
OGP use case is being defined as the required structure of the protocol.
Is it really required that there MUST be a human in the loop?  The region
is always authoritative?  Requests from the human to the region must
go via the agent domain?

I think there's a strong need for such motivating use cases, but I think
the author shoots himself in the foot by putting it in the first chapter
of the document to which every compliant implementation MUST conform.
Instead, I'd like to see this document use more general definitions and
relate them to use cases defined elsewhere.

Please help me understand what I've missed and where I'm off base.

Latha Serevi (SL)

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Fri, 13 Mar 2009 13:50:05 -0700

On Mar 13, 2009, at 12:16 PM, Latha Serevi wrote:

> Overall, though, this all seems fairly straightforward and  
> potentially useful.

yup. this is intended to be used when any two endpoints wanna send  
event notifications. endpoints can be servers, proxies or clients. if  
you're reading it to mean "events" only apply to server -> client  
communications, maybe we need to tighten up the verbiage to make it  
clear.

> relate them to use cases defined elsewhere.

good feedback. i think the way i would put it is, "our primary use  
case involves humans, but there's no requirement that a human be  
involved." in other words, if we have a solution that works for the  
"non-human" use case but not for the "human" use case, then the  
solution would be (from our perspective) less desirable than a  
solution that works equally well in both human and non-human use cases.

  that being said... some virtual worlds may view bots as a violation  
of their terms of service, but there's a wide range of applications  
that don't involve a human controlling an avatar in a virtual world.  
so from a protocol perspective, we shouldn't imply that non-human  
client applications are verboten.

during the PyOGP development, a lot of us referred to the thing we  
used to call the viewer as the "client application." i wonder if it's  
appropriate to do a search and replace on "viewer" for "client  
application" and then add a section describing the explicit viewer use  
case.

---

From: Jon Watte <[email-masked]>
Date: Fri, 13 Mar 2009 18:45:42 -0700

Morgaine wrote:
> I would go further and say that this is even compatible with Jon's 
> models, given a willingness to be flexible.  Current OLIVE clients may 
> not be able to talk to other systems, but this is no bar to new 
> clients of OLIVE being able to do so.
>

So, if no users want to pay money for the convenience of not having to 
install two separate clients, exactly why would any profit-seeking 
company implement a second protocol in their client?
Note that there is significant economic incentive to implement 
server-side interop -- and separately, strong economic incentive to 
*not* implement client interop. In general, standards tend to be adopted 
when they make business sense, and not adopted when they don't.

>
> And there are other solutions as well.  Nothing precludes OLIVE 
> servers from performing the role of a client in an OGP endpoint.  Some 
> detailed analysis of inbuilt assumptions would be required to be sure 
> that this can work, but in principle an OLIVE (or LESS) server could 
> obtain all the necessary data in this way from which to build a local 
> simulation for its clients.

Except that, if I implement OGP today, I get exactly zero available 
interop, because the circuit of other needed protocols is very large. 
Specifically, the only people who can get interop from OGP today is the 
people who already speak the same client protocol, and use the same 
server-side object execution environment -- which means Second Life and 
Open Sim. If you actually expect acceptance from other vendors, and 
actually are interested in interoperating outside that circle, OGP isn't 
the way to go. If you don't care, then of course you'll standardize what 
you already have.

Sincerely,

jw

---

From: Charles Krinke <[email-masked]>
Date: Fri, 13 Mar 2009 18:18:07 -0800

I think the point is that there are several operational implementations
curently and they include OGP, MXP and HyperGrid, amongst others. The folks
who have invested their time in both writing and now using these
implementations certainly have vested interests. Some of which are monetary,
some not.

However, I see a lot of altruism and desire to interop further with the
folks on this group, so I see them as open to additional implementations.

I would even go so far as to suggest that *whatever* this group comes up
with that it be flexible enough to *not* preclude anyone's wild ideas. In
point of fact, it is the users of virtual worlds by their very use (or lack
thereof) that will ultimately determine what protocols/schemes/technologies
survive and bloom, or wither away.

So, with that in mind, lets try to work together to find ways to create
something interesting and unique.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Fri, Mar 13, 2009 at 5:45 PM, Jon Watte <[email-masked]> wrote:

> install two separate clients, exactly why would any profit-seeking company
> implement a second protocol in their client?
> Note that there is significant economic incentive to implement server-side
> interop -- and separately, strong economic incentive to *not* implement
> client interop. In general, standards tend to be adopted when they make
> business sense, and not adopted when they don't.
>
>
>
> server-side object execution environment -- which means Second Life and Open
> Sim. If you actually expect acceptance from other vendors, and actually are
> interested in interoperating outside that circle, OGP isn't the way to go.
> If you don't care, then of course you'll standardize what you already have.
>
> Sincerely,
>
> jw
>
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: [email-masked]
Date: Fri, 13 Mar 2009 21:23:12 -0700 (PDT)

As a user, I would prefer a client which could connect to multiple services, and I would partially base my decision on which services were desirable to subscribe to by how capable and reusable is the client software they provide. A service may market itself as a compelling experience and provide some incentives to get me to try it out, but if I don't find the service continues to maintain my interest, I will no longer use that service and will likely remove the associated client software from my computer to maintain space for more suitable services. If I need to install new, potentially spyware or malware infested software to try new services, then I consider that a barrier to my trying the service. Likewise I consider having to register a new account, risking my personal information to yet another company, another barrier to entry. While I probably would not be willing to pay extra for a client which could function with multiple worlds, companies that
 allow the use of interop-capable viewer software and some level of credential/authorization sharing stand a greater chance of attracting me as a customer as I could test drive their service with less effort on my part. Likewise, they stand little chance of keeping my business if they cease to provide a compelling experience and the software required to access that service consumes my computing resources without perceived benefit in return.

Experiences such as these suggest that there are additional costs involved for any business which demands a single service capable client and these costs may deserve consideration when attempting to account for the potential profitability of efforts towards interoperability.

Best Regards,
--Tom Hoff

----- Original Message ----
From: Jon Watte <[email-masked]>
To: Morgaine <[email-masked]>
Cc: MMOX-IETF <[email-masked]>
Sent: Friday, March 13, 2009 6:45:42 PM
Subject: Re: [mmox] 3-world OGP interop scenario

Morgaine wrote:
> I would go further and say that this is even compatible with Jon's models, given a willingness to be flexible.  Current OLIVE clients may not be able to talk to other systems, but this is no bar to new clients of OLIVE being able to do so.
> 

So, if no users want to pay money for the convenience of not having to install two separate clients, exactly why would any profit-seeking company implement a second protocol in their client?
Note that there is significant economic incentive to implement server-side interop -- and separately, strong economic incentive to *not* implement client interop. In general, standards tend to be adopted when they make business sense, and not adopted when they don't.

> 
> And there are other solutions as well.  Nothing precludes OLIVE servers from performing the role of a client in an OGP endpoint.  Some detailed analysis of inbuilt assumptions would be required to be sure that this can work, but in principle an OLIVE (or LESS) server could obtain all the necessary data in this way from which to build a local simulation for its clients.

Except that, if I implement OGP today, I get exactly zero available interop, because the circuit of other needed protocols is very large. Specifically, the only people who can get interop from OGP today is the people who already speak the same client protocol, and use the same server-side object execution environment -- which means Second Life and Open Sim. If you actually expect acceptance from other vendors, and actually are interested in interoperating outside that circle, OGP isn't the way to go. If you don't care, then of course you'll standardize what you already have.

Sincerely,

jw

---

From: "Mystical Demina" <[email-masked]>
Date: Sat, 14 Mar 2009 01:13:50 -0400

I think this early in the game I would be surprise we can get the whole
world to agree to one protocol or message format to the degree HTML was able
to achieve.  Also is a more challenging problem and will require a degree of
semantics that hasn't really happened yet in the Internet.  As such I would
believe there will be many protocols and solutions in this space and that it
will take at least 5 or more to start seeing what will be the dominant
solution.  Also I would expect clients to open up and have capability to add
drivers and new features in a way similar to how the browser let's new
capabilities to be implemented.  So the concept of universal browser is
maybe the wrong way to look at it.  It will be more like the client that can
handle the most plug-ins and hacks, hehe.

As such it seems to me the prudent approach is to target the most used and
most popular features first which off hand I think is teleporting, meshing
(mixing data from multiple sources into one virtualization) and data format
support.

Kevin Tweedy
SL: Mystical Demina

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Saturday, March 14, 2009 12:23 AM
To: MMOX-IETF
Subject: Re: [mmox] 3-world OGP interop scenario

As a user, I would prefer a client which could connect to multiple services,
and I would partially base my decision on which services were desirable to
subscribe to by how capable and reusable is the client software they
provide. A service may market itself as a compelling experience and provide
some incentives to get me to try it out, but if I don't find the service
continues to maintain my interest, I will no longer use that service and
will likely remove the associated client software from my computer to
maintain space for more suitable services. If I need to install new,
potentially spyware or malware infested software to try new services, then I
consider that a barrier to my trying the service. Likewise I consider having
to register a new account, risking my personal information to yet another
company, another barrier to entry. While I probably would not be willing to
pay extra for a client which could function with multiple worlds, companies
that
 allow the use of interop-capable viewer software and some level of
credential/authorization sharing stand a greater chance of attracting me as
a customer as I could test drive their service with less effort on my part.
Likewise, they stand little chance of keeping my business if they cease to
provide a compelling experience and the software required to access that
service consumes my computing resources without perceived benefit in return.

Experiences such as these suggest that there are additional costs involved
for any business which demands a single service capable client and these
costs may deserve consideration when attempting to account for the potential
profitability of efforts towards interoperability.

Best Regards,
--Tom Hoff

----- Original Message ----
From: Jon Watte <[email-masked]>
To: Morgaine <[email-masked]>
Cc: MMOX-IETF <[email-masked]>
Sent: Friday, March 13, 2009 6:45:42 PM
Subject: Re: [mmox] 3-world OGP interop scenario

Except that, if I implement OGP today, I get exactly zero available interop,
because the circuit of other needed protocols is very large. Specifically,
the only people who can get interop from OGP today is the people who already
speak the same client protocol, and use the same server-side object
execution environment -- which means Second Life and Open Sim. If you
actually expect acceptance from other vendors, and actually are interested
in interoperating outside that circle, OGP isn't the way to go. If you don't
care, then of course you'll standardize what you already have.

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Sat, 14 Mar 2009 10:05:38 +0000

Jon, I'm trying to understand a sentence you've used a few times now ---
here are a couple of instances:

On Sat, Mar 14, 2009 at 1:45 AM, Jon Watte <[email-masked]> wrote:

*So, if no users want to pay money for the convenience of not having to
install two separate clients, exactly why would any profit-seeking company
implement a second protocol in their client?*

And another:

On Wed, Mar 11, 2009 at 17:46:17 -0700, Jon Watte <[email-masked]> wrote:

*In fact, I doubt you could even get very many people to pay a single dollar
for the convenience of not having to install two clients to be able to visit
two different worlds*

I don't fully understand what the highlighted phrases mean.  On the face of
it, your words "*two clients ... two different worlds*" seem to suggest that
you're advocating that users should have one client per virtual world, but
since we're envisaging a metaverse of millions of worlds and thousands of VW
providers, that can't be what you mean, because thousands of clients on a
desktop is, well, bizarre.

What's more, you've previously suggested that VWs should interoperate
through their servers, as per the OLIVE and LESS models, so multiple clients
do not arise there.  And as you know, the OGP model also uses the single
client model, speaking a common protocol and using cross-world object
representations, so multiple clients do not arise there either.

For interop to happen, all parties are going to have to develop new
interfaces *somewhere*, either in their servers or their clients or both,
but it's their own choice where.  In your case the new interfaces seem
likely to appear in OLIVE or LESS servers, as that is the model you prefer.

Since nobody is advocating multiple clients then, why do you keep mentioning
"*not having to install two clients"?
*
This has confused me on various occasions so I've found it hard to follow
your line of reasoning.  Could you elaborate please?

Morgaine.

---

From: Jon Watte <[email-masked]>
Date: Sat, 14 Mar 2009 12:02:22 -0700

[email-masked] wrote:
> As a user, I would prefer a client which could connect to multiple services, and I would partially base my decision on which services were desirable to subscribe to by how capable 

It's great that you prefer this! To get a measurement (of a sample of 
one), could you answer this question?
How much, in dollars, would you pay for this client, as opposed to 
downloading separate clients to separate worlds?

>  another company, another barrier to entry. While I probably would not be willing to pay extra for a client which could function with multiple worlds, companies that
>   

So the answer is zero dollars? That means that your preference is quite 
weak, almost not measurable (economically speaking).

Sincerely,

jw

---

From: Ann Otoole <[email-masked]>
Date: Sat, 14 Mar 2009 12:26:30 -0700 (PDT)

If you are thinking anyone is going to pay for a client you are out of touch with reality anyway. 
How much are you paying for IE or firefox? How is Netscape doing these days?

People pay for content and hosting. 
They pay for a connection to the internet. 
The days of paying for software to access the internet ended years ago lol.

Can we discontinue the money talk and stick to the protocol discussion? 

kthxbai.

To: [email-masked]
Sent: Saturday, March 14, 2009 3:02:22 PM

> As a user, I would prefer a client which could connect to multiple services, and I would partially base my decision on which services were desirable to subscribe to by how capable 

It's great that you prefer this! To get a measurement (of a sample of one), could you answer this question?
How much, in dollars, would you pay for this client, as opposed to downloading separate clients to separate worlds?

>  another company, another barrier to entry. While I probably would not be willing to pay extra for a client which could function with multiple worlds, companies that

So the answer is zero dollars? That means that your preference is quite weak, almost not measurable (economically speaking).

Sincerely,

jw

---

From: [email-masked]
Date: Sat, 14 Mar 2009 12:27:59 -0700 (PDT)

Granted my preferences as stated here: http://www.ietf.org/mail-archive/web/mmox/current/msg01140.html are a sample of one and I made no attempt to exagerate them. However your statement that my preference is weak may be a false assumption unless you have marketing studies to back it up. Larger companies have the benefit of being able to afford to conduct studies which measure preferences such as these quite accurately, and accountants who are trained in methods of assigning value to "intangibles". It's the small business who cant afford these studies who must resort to shooting from the hip to answer questions such as these, and unfortunately leave the fate of their businesses to the will of chance.

Best Regards,
-Tom Hoff

----- Original Message ----
From: Jon Watte <[email-masked]>
To: [email-masked]
Cc: MMOX-IETF <[email-masked]>
Sent: Saturday, March 14, 2009 12:02:22 PM
Subject: Re: [mmox] 3-world OGP interop scenario

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Sat, 14 Mar 2009 12:43:24 -0700

Morgaine wrote:
> I don't fully understand what the highlighted phrases mean.  On the 
> face of it, your words "/two clients ... two different worlds/" seem 
> to suggest that you're advocating that users should have one client 
> per virtual world, but since we're envisaging a metaverse of millions 
> of worlds and thousands of VW providers, that can't be what you mean, 
> because thousands of clients on a desktop is, well, bizarre.
>

It seems that you have not yet grokked the operating principle of LESS. 
Think of it as cell phones: you have one cell phone, that works with one 
carrier. However, you can call people on any other network, and it is 
transparent to you, because your carrier/operator makes the translation 
for you. That's the model I see working with LESS -- the different 
virtual worlds translate for you.

Thus, if you only have a Second Life client, and you click on a link to 
go visit a location that's hosted by an OLIVE server, what will 
technically happen is that a Second Life sim sets aside a little bit of 
"empty space," puts your avatar in that space, and connects that empty 
space with the location hosted by OLIVE. Any objects that you introduce 
in your space (including your avatar) get peered to the location host. 
And objects from the location host get peered to your system. You view 
the outcome of the simulation of all objects (hosted on OLIVE, or hosted 
on Second Life) through your Second Life client, because the peering 
gateway on the Second Life side translates from LESS to the Second Life 
native technology. Similarly, the OLIVE user views the outcome of all 
the objects from the Second Life side through the OLIVE client, because 
the OLIVE gateway translates from LESS to the OLIVE native technology. 
Note that only the presentation of the object needs to be transmitted 
(Second Life style), not the behavior, scripting, or internal ownership 
details of the object. (This should make people who worry about IP happy).

This way, you only ever use one client -- the client of the operator of 
your choice. This is very similar to how you select a cell phone and a 
carrier. Operators may support multiple clients, but the protocol 
between client and operator does not need to be standardized. It could 
be a separate standard, of course, but the technology involved is so 
complex that getting success in the market with this model is next to 
impossible.

Now, why is the cell phone model better than the web browser model for 
virtual worlds? I think there are two reasons:
1) It's about real-time interactivity, not asynchronous interactivity. 
You find that all interactive systems actually end up with the 
client/server customer/provider paradigm. This goes for Instant 
Messaging, or online games, or regular old phone service as well -- even 
for e-mail, which actually isn't real-time. You could say that the HTTP 
web model is the odd man out -- it works very well for asynchronous, 
not-very-complex data, but as soon as you need more complex data (Flash 
games, streaming video, etc) you end up with a number of competing 
tightly integrated client/server set-ups (QuickTime vs Real vs Flash vs 
Microsoft for video, for example).

> interfaces /somewhere/, either in their servers or their clients or 
> both, but it's their own choice where.  In your case the new 
> interfaces seem likely to appear in OLIVE or LESS servers, as that is 
> the model you prefer.
>

I hope I made a case for why that's actually the only model that I see 
as commercially viable for the greater world of virtual worlds. 
Implementing LESS peering between servers would be an order of magnitude 
less work than re-implementing an entire client/server architecture, 
unless you keep dual architectures in the client (one "simple" for 
interop, and one "native" for some "home" system -- but down that path 
lives madness). Note that the OLIVE internal system is nothing at all 
like LESS -- in fact, LESS is a lot more like the Second Life protocol 
than like the OLIVE protocol. The reason LESS is designed the way it is, 
is that we (at Forterra) have implemented virtual world interoperability 
at the physics and semantic level between disparate technologies since 
2005, and have learned a lot about what is easiest to do to accomplish 
the most. We do, in fact, have an interoperability gateway on our price 
list -- but it doesn't use LESS; it uses DIS, or HLA, or a protocol 
proprietary to OLIVE. I'd like to get away from that, to a standard that 
everyone can use, and just plug bits together when building the systems 
that run the worlds.

> Since nobody is advocating multiple clients then, why do you keep 
> mentioning "/*not having to install two clients*"?
> /

It's a necessary logical conclusion from the model of a client that can 
connect to different kinds of worlds. Let me spell it out:
Today, you can download and install two different clients, to connect to 
two different worlds. That's the status quo. Those worlds may use OpenID 
if you want a "single sign-on" -- that technology already exists. */Any 
standards proposal must be viewed against this back-drop/*, to measure 
how far it advances the state of the art.

If we introduce a "multi-world" capable client, then you can choose to 
connect to world A, or to world B, from the same client. The gain, for 
you, is that you don't have to switch clients when moving to different 
worlds -- you don't have to install two clients to visit two different 
worlds.

However, what */you do not gain is the ability to mash up objects/* from 
world A with objects from world B. You have to choose: do I visit world 
A, or do I visit world B? Even if you log in to both at the same time, 
the users in world A do not see the users you see in world B, and vice 
versa. You need server peering for that to work. Which is what LESS is 
intended to provide.

What you also do */not/* get from a multi-capable client is */the 
ability for users in world B to see and interact with objects that you 
may own and use in world A/*. That requires a single, standardized 
object execution environment, kind-of like saying that all web servers 
should use ASP.NET for servlets. It also requires transfer of the entire 
object (scripting and other internals) to the second system. Or it 
requires server peering -- which is what LESS is intended to provide.

In fact, */you may not even get the ability to keep the same avatar/* 
looks and clothes between the systems -- that would require the systems 
to implement the same user interaction methods and protocols, as well as 
highly technical details like how to customize and build up an avatar 
out of smaller pieces of data. In LESS, the owning system provides a 
unified "cooked" presentation of your avatar, and is responsible for 
making it look right. Thus, technology-specific changes are applied 
before the data even leaves the originating system.

When implementing the LESS model, you get all the benefits that you want 
to provide in a multi-capable/generic/universal client model:

1. a seamless click-to-teleport experience, no matter where the destination
2. keeping a single client maintained, rather than a bunch of disparate 
clients

You also get the following benefits, which a 
multi-capable/universal/generic client will not give you:

3. keeping a unified avatar, with a single avatar identity and 
consistent visual
4. keeping a unified inventory with all your usable objects
5. interacting between users from world A and world B in a single space
6. using objects from world A and world B together in a single space

All of this, at an (estimated) 1:10th the implementation cost of a 
multi-capable/universal/generic client equivalent to the native clients 
we have today. To my mind, this is how to get the best bang for the 
least buck in virtual world interoperability, if you actually care about 
interoperating between technologies.
If you want to build a generic client, you can always build on top of 
the server<->server peering protocol at some later time -- but the 
server<->server peering still needs to be there to provide benefits 3..6 
above.

> This has confused me on various occasions so I've found it hard to 
> follow your line of reasoning.  Could you elaborate please?

I appreciate that you're asking for clarification, and I hope that I've 
explained the reasoning in sufficiently detailed steps. If there is 
something that still doesn't make sense, or some conclusion you disagree 
with based on some facts that I may have missed, I'd be very interested 
in hearing about it!

Sincerely,

jw

PS: The LESS protocol is a skeleton to build on: there are lots of bits 
and pieces that need to be defined. like how servers find each other; 
specific data formats for object presentation graphics data; what the 
specific sets of interactions should be; what the specific well-defined 
property semantics should be; etc -- much of which probably can be 
grouped into lower-to-higher profiles as well, to support 
limited-capacity clients and the like. Hopefully, the protocol 
description at least calls these out for further clarification.

---

From: "Mystical Demina" <[email-masked]>
Date: Sat, 14 Mar 2009 17:35:12 -0400

Although for the most part I agree, at least I believe most servers will be
willing to give away clients.  I do believe there will be some market for
add and premium components although probably more for businesses than
typical consumer market.

Kevin Tweedy

SL: Mystical Demina

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ann
Otoole
Sent: Saturday, March 14, 2009 3:27 PM
To: MMOX-IETF
Subject: Re: [mmox] 3-world OGP interop scenario

If you are thinking anyone is going to pay for a client you are out of touch
with reality anyway. 
How much are you paying for IE or firefox? How is Netscape doing these days?

kthxbai.

  _____  

[email-masked] wrote:
> As a user, I would prefer a client which could connect to multiple
services, and I would partially base my decision on which services were
desirable to subscribe to by how capable 

It's great that you prefer this! To get a measurement (of a sample of one),
could you answer this question?
How much, in dollars, would you pay for this client, as opposed to
downloading separate clients to separate worlds?

>  another company, another barrier to entry. While I probably would not be
willing to pay extra for a client which could function with multiple worlds,
companies that

Sincerely,

jw

---

From: Charles Krinke <[email-masked]>
Date: Sat, 14 Mar 2009 16:56:46 -0800

As long as this group adopts ports and protocols that do not preclude OGP,
HyperGrid, MXP or other, I see no reason why LESS could not become viable.

As we know, it will be the users of our virtual worlds technologies that
will ultimately determine the viability (or lack thereof) of
interoperability.

It seems to me that concentrating on a flexible enough protocol to allow all
the ideas described (and more) to bloom is a reasonable solution.

At the very least, there need to be two competing protocols, should this
group feel bound for more definition to allow the users and the market to
decide what is good or not.

But, my feeling is flexibility to allow all the ideas and more presented
makes a compelling argument.

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Kajikawa Jeremy <[email-masked]>
Date: Sun, 15 Mar 2009 08:35:56 +0900

I agree with Charles in this... the more choice we offer the more will
be adoptable
 in one manner or another...

I see OGP for the Client<->Environment connection and
 LESS as being the Server<->Server connection.

I dont see these directly competing but actually becoming to *require*
the other
 so what makes them directly competitive?

just my current semi-ignorant view of things...
  Jeremy 

On Sat, 2009-03-14 at 16:56 -0800, Charles Krinke wrote:
> As long as this group adopts ports and protocols that do not preclude
> OGP, HyperGrid, MXP or other, I see no reason why LESS could not
> become viable.
> 
> As we know, it will be the users of our virtual worlds technologies
> that will ultimately determine the viability (or lack thereof) of
> interoperability. 
> 
> It seems to me that concentrating on a flexible enough protocol to
> allow all the ideas described (and more) to bloom is a reasonable
> solution.
> 
> At the very least, there need to be two competing protocols, should
> this group feel bound for more definition to allow the users and the
> market to decide what is good or not.
> 
> But, my feeling is flexibility to allow all the ideas and more
> presented makes a compelling argument.
> 
> -- 
> Charles Krinke
> OpenSim Core Developer
> OSGrid Director

---

From: Morgaine <[email-masked]>
Date: Sun, 15 Mar 2009 11:41:03 +0000

On Sat, Mar 14, 2009 at 7:43 PM, Jon Watte <[email-masked]> wrote:

> transparent to you, because your carrier/operator makes the translation for
> you. That's the model I see working with LESS -- the different virtual
> worlds translate for you.

That's exactly how I believe everyone has understood LESS to work, ie. the
servers do the translations, thanks for confirming it.  The purpose of my
post was to show that nobody is proposing a proliferation of clients, and
your explanation confirms what I wrote myself, that it's not required by
LESS.

So that just leaves us with what's required by the OGP approach, and this is
where your understanding is breaking down and leading you to false
conclusions.

> world A with objects from world B. You have to choose: do I visit world A,
> or do I visit world B? Even if you log in to both at the same time, the
> users in world A do not see the users you see in world B, and vice versa.
> You need server peering for that to work. Which is what LESS is intended to
> provide.
>
> What you also do */not/* get from a multi-capable client is */the ability
> for users in world B to see and interact with objects that you may own and
> use in world A/*. That requires a single, standardized object execution
> environment, kind-of like saying that all web servers should use ASP.NET<http://asp.net/>for servlets. It also requires transfer of the entire object (scripting and
> other internals) to the second system. Or it requires server peering --
> which is what LESS is intended to provide.
>

That is entirely incorrect.  I gave the picture that applies to the OGP
model in my 3-world OGP interop
scenario<http://www.ietf.org/mail-archive/web/mmox/current/msg01114.html>.
Everything you say about the model is wrong --- its whole purpose is to do
exactly what you claim it does not do.  In every situation after the initial
conditions, A1 appears in worlds B and C creating object mashups.

>
> In fact, */you may not even get the ability to keep the same avatar/* looks
> and clothes between the systems -- that would require the systems to
> implement the same user interaction methods and protocols, as well as highly
> technical details like how to customize and build up an avatar out of
> smaller pieces of data. In LESS, the owning system provides a unified
> "cooked" presentation of your avatar, and is responsible for making it look
> right. Thus, technology-specific changes are applied before the data even
> leaves the originating system.
>

It is up to each world itself to decide if you get to use your avatar from
another place in their world or not.  It may not be appropriate for a
laser-blasting space farer or a cell-shaded cartoon character or a
pin-striped businessman to appear in their world of orcs and dwarves.  Other
worlds will of course welcome avatar
diversity<http://www.ietf.org/mail-archive/web/mmox/current/msg01020.html>.
We are in the business of supplying mechanisms to allow it when it is
desired, not mandating any specific policy.

> <Morgaine>: This has confused me on various occasions so I've found it hard
>> to follow your line of reasoning.  Could you elaborate please?
>>
>
> with based on some facts that I may have missed, I'd be very interested in
> hearing about it!
>
>
You have not given even a single line of explanation of your "*not having to
install two clients*" phrase in the contexts I
quoted<http://www.ietf.org/mail-archive/web/mmox/current/msg01142.html>(paying
for clients), and  therefore I conclude that it had no basis in
reality nor addresses any known issue.  Such phrases are best avoided as
they create a false impression of intent.

It is entirely up to each world provider to decide whether to implement
interop protocols in servers, clients, or both.  While OGP does refer
explicitly to clients or viewers, this role would be played by a LESS server
in your world, which would provide a proxy presence in the remote world and
translate the object representations for the benefit of its clients.

Morgaine.

On Sat, Mar 14, 2009 at 7:43 PM, Jon Watte <[email-masked]> wrote:

> Morgaine wrote:
>
>> I don't fully understand what the highlighted phrases mean.  On the face
>> of it, your words "/two clients ... two different worlds/" seem to suggest
>> that you're advocating that users should have one client per virtual world,
>> but since we're envisaging a metaverse of millions of worlds and thousands
>> of VW providers, that can't be what you mean, because thousands of clients
>> on a desktop is, well, bizarre.
>>
>>
> transparent to you, because your carrier/operator makes the translation for
> you. That's the model I see working with LESS -- the different virtual
> worlds translate for you.
>
> Thus, if you only have a Second Life client, and you click on a link to go
> visit a location that's hosted by an OLIVE server, what will technically
> happen is that a Second Life sim sets aside a little bit of "empty space,"
> puts your avatar in that space, and connects that empty space with the
> location hosted by OLIVE. Any objects that you introduce in your space
> (including your avatar) get peered to the location host. And objects from
> the location host get peered to your system. You view the outcome of the
> simulation of all objects (hosted on OLIVE, or hosted on Second Life)
> through your Second Life client, because the peering gateway on the Second
> Life side translates from LESS to the Second Life native technology.
> Similarly, the OLIVE user views the outcome of all the objects from the
> Second Life side through the OLIVE client, because the OLIVE gateway
> translates from LESS to the OLIVE native technology. Note that only the
> presentation of the object needs to be transmitted (Second Life style), not
> the behavior, scripting, or internal ownership details of the object. (This
> should make people who worry about IP happy).
>
> carrier. Operators may support multiple clients, but the protocol between
> client and operator does not need to be standardized. It could be a separate
> standard, of course, but the technology involved is so complex that getting
> success in the market with this model is next to impossible.
>
> 1) It's about real-time interactivity, not asynchronous interactivity. You
> find that all interactive systems actually end up with the client/server
> customer/provider paradigm. This goes for Instant Messaging, or online
> games, or regular old phone service as well -- even for e-mail, which
> actually isn't real-time. You could say that the HTTP web model is the odd
> man out -- it works very well for asynchronous, not-very-complex data, but
> as soon as you need more complex data (Flash games, streaming video, etc)
> you end up with a number of competing tightly integrated client/server
> set-ups (QuickTime vs Real vs Flash vs Microsoft for video, for example).
>
>> interfaces /somewhere/, either in their servers or their clients or both,
> I hope I made a case for why that's actually the only model that I see as
> commercially viable for the greater world of virtual worlds. Implementing
> LESS peering between servers would be an order of magnitude less work than
> re-implementing an entire client/server architecture, unless you keep dual
> architectures in the client (one "simple" for interop, and one "native" for
> some "home" system -- but down that path lives madness). Note that the OLIVE
> internal system is nothing at all like LESS -- in fact, LESS is a lot more
> like the Second Life protocol than like the OLIVE protocol. The reason LESS
> is designed the way it is, is that we (at Forterra) have implemented virtual
> world interoperability at the physics and semantic level between disparate
> technologies since 2005, and have learned a lot about what is easiest to do
> to accomplish the most. We do, in fact, have an interoperability gateway on
> our price list -- but it doesn't use LESS; it uses DIS, or HLA, or a
> protocol proprietary to OLIVE. I'd like to get away from that, to a standard
> that everyone can use, and just plug bits together when building the systems
> that run the worlds.
>
>
> two different worlds. That's the status quo. Those worlds may use OpenID if
> you want a "single sign-on" -- that technology already exists. */Any
> standards proposal must be viewed against this back-drop/*, to measure how
> far it advances the state of the art.
>
> connect to world A, or to world B, from the same client. The gain, for you,
> is that you don't have to switch clients when moving to different worlds --
> you don't have to install two clients to visit two different worlds.
>
> world A with objects from world B. You have to choose: do I visit world A,
> or do I visit world B? Even if you log in to both at the same time, the
> users in world A do not see the users you see in world B, and vice versa.
> You need server peering for that to work. Which is what LESS is intended to
> provide.
>
> What you also do */not/* get from a multi-capable client is */the ability
> for users in world B to see and interact with objects that you may own and
> use in world A/*. That requires a single, standardized object execution
> environment, kind-of like saying that all web servers should use ASP.NETfor servlets. It also requires transfer of the entire object (scripting and
> other internals) to the second system. Or it requires server peering --
> which is what LESS is intended to provide.
>
> In fact, */you may not even get the ability to keep the same avatar/* looks
> and clothes between the systems -- that would require the systems to
> implement the same user interaction methods and protocols, as well as highly
> technical details like how to customize and build up an avatar out of
> smaller pieces of data. In LESS, the owning system provides a unified
> "cooked" presentation of your avatar, and is responsible for making it look
> right. Thus, technology-specific changes are applied before the data even
> leaves the originating system.
>
> When implementing the LESS model, you get all the benefits that you want to
> provide in a multi-capable/generic/universal client model:
>
> 3. keeping a unified avatar, with a single avatar identity and consistent
> visual
> multi-capable/universal/generic client equivalent to the native clients we
> have today. To my mind, this is how to get the best bang for the least buck
> in virtual world interoperability, if you actually care about interoperating
> between technologies.
> If you want to build a generic client, you can always build on top of the
> server<->server peering protocol at some later time -- but the
> with based on some facts that I may have missed, I'd be very interested in
> hearing about it!
>
> Sincerely,
>
> jw
>
>
>
> PS: The LESS protocol is a skeleton to build on: there are lots of bits and
> pieces that need to be defined. like how servers find each other; specific
> data formats for object presentation graphics data; what the specific sets
> of interactions should be; what the specific well-defined property semantics
> should be; etc -- much of which probably can be grouped into lower-to-higher
> profiles as well, to support limited-capacity clients and the like.
> Hopefully, the protocol description at least calls these out for further
> clarification.
>
>

---

From: Jon Watte <[email-masked]>
Date: Sun, 15 Mar 2009 13:12:19 -0700

Morgaine wrote:
> That's exactly how I believe everyone has understood LESS to work, ie. 
> the servers do the translations, thanks for confirming it.  The 
> purpose of my post was to show that nobody is proposing a 
> proliferation of clients, and your explanation confirms what I wrote 
> myself, that it's not required by LESS.
>

Actually, I have seen the Open Sim people propose and argue for the 
"generic client" concept. Note that the proliferation of clients is the 
current state of the world -- it's not something someone is arguing for; 
it's what we have now.

> So that just leaves us with what's required by the OGP approach, and 
> this is where your understanding is breaking down and leading you to 
> false conclusions.
>
>
>
>     However, what */you do not gain is the ability to mash up
>     objects/* from world A with objects from world B. You have to
>     choose: do I visit world A, or do I visit world B? Even if you log
>     in to both at the same time, the users in world A do not see the
>     users you see in world B, and vice versa. You need server peering
>     for that to work. Which is what LESS is intended to provide.
>
>     ability for users in world B to see and interact with objects that
>     you may own and use in world A/*. That requires a single,
>     standardized object execution environment, kind-of like saying
>     that all web servers should use ASP.NET <http://asp.net/> for
>     servlets. It also requires transfer of the entire object
>     (scripting and other internals) to the second system. Or it
> That is entirely incorrect.  I gave the picture that applies to the 
> OGP model in my 3-world OGP interop scenario 
> <http://www.ietf.org/mail-archive/web/mmox/current/msg01114.html>.  
> Everything you say about the model is wrong --- its whole purpose is 
> to do exactly what you claim it does not do.  In every situation after 
> the initial conditions, A1 appears in worlds B and C creating object 
> mashups.
>  

Not by just implementing OGP, it doesn't. As I said, for that to happen, 
you need at least two other things to be true:
1) For the client to understand that communications protocol of all the 
involved servers (the equivalent of a generic client), and
2) For all the servers to provide the same execution environment for 
objects (the equivalent of forcing all web servers to use J2EE)

1) is businesswise impossible, because it's way too expensive with too 
little benefit for most world vendors out there
2) is politically not feasible

Both are also a bad idea technically, because it means that specifically 
tuned clients for specific situations (learning vs entertainment vs 
narrow-band vs LAN etc) are left out of the equation.

>
> It is up to each world itself to decide if you get to use your avatar 
> from another place in their world or not.  It may not be appropriate 
> for a laser-blasting space farer or a cell-shaded cartoon character or 
> a pin-striped businessman to appear in their world of orcs and 
> dwarves.  Other worlds will of course welcome avatar diversity 
> <http://www.ietf.org/mail-archive/web/mmox/current/msg01020.html>.  We 
> are in the business of supplying mechanisms to allow it when it is 

OGP supplies no such mechanism, unless you mandate the execution 
environment of objects on the servers, which is politically not feasible.

>
>
> You have not given even a single line of explanation of your "/*not 
> having to install two clients*/" phrase in the contexts I quoted 
> <http://www.ietf.org/mail-archive/web/mmox/current/msg01142.html> 
> (paying for clients), and  therefore I conclude that it had no basis 
> in reality nor addresses any known issue.  Such phrases are best 
> avoided as they create a false impression of intent.
>

Today, with customers and vendors paying zero dollars, you can achieve a 
certain kind of interop: being able to visit different, separate worlds. 
The user experience cost is to install two clients, and switch between 
them. For anything to be an improvement over what we already have, then 
the benefit to the user of the improvement must be such that it at least 
pays for the investment for the worlds providing that benefit, or the 
"improvement" is actually a loss.

> It is entirely up to each world provider to decide whether to 
> implement interop protocols in servers, clients, or both.  While OGP 
> does refer explicitly to clients or viewers, this role would be played 
> by a LESS server in your world, which would provide a proxy presence 
> in the remote world and translate the object representations for the 
> benefit of its clients.

This leaves aside the point that OGP isn't even implementable from spec 
as it is currently written up, much less actually useful to anyone other 
than Second Life interoperating with Open Sim. If that's all you want to 
accomplish, that's fine, but then you should not claim that your goal is 
vendor neutral interop. It's really a question of what we want to do in 
this group:

Correct me if I'm wrong, but here is my current take on the positions of 
the parties, based on statements made by representatives on this list:

1) Linden Lab has publicly stated that they are only interested in 
specifying how third parties, such as Open Sim, can interoperate with 
the Linden public grids. They have not shown any interest in 
interoperability on neutral ground with a large number of different 
technologies.

2) OpenSim and RealXTend representatives have stated that they want to 
help Linden Labs in those goals, but they are open to also doing other 
things regarding interoperability.

3) Forterra has publicly stated that we are interested in neutral-ground 
cross-technology interoperability. We have also stated that there is no 
way that OGP can deliver any kind of usable interoperability to our 
users, and from my analysis, no other virtual world technology not 
derived from the Linden/OpenSim DNA would have any benefit either. I 
have not heard any vendor outside the Linden/OpenSim sphere say that OGP 
would deliver anything of interest to them, either.

4) Various users are contributing their requirements for the evolution 
of virtual worlds, having to do with seamless travel, IP protection, the 
ability to control their own data, etc.

I was attracted to this group because I thought that the goal really was 
widespread, vendor neutral, cross-technology interoperability. It seems 
that most of the participants on the list actually aren't interested in 
that, but are interested in something much more narrow. At that point, I 
suggest the right solution is to re-charter to make the charter match 
the narrow desires, and move the broader discussion somewhere else. 
Alternatively, keep the broad charter of this group, but move the narrow 
desire somewhere else.

Trying to keep both the narrow desire, and the broad desire, in the same 
group, is a bad idea, because it leads to situations where people who 
don't care about some particular topic are still required to participate 
and endorse proposals within that topic. It also leads to discussions 
between the people with different goals, that are motivated not by 
technical requirements (what's allegedly what drives IETF standards), 
but by fundamentally incompatible basis for analysis.

Sincerely,

jw

---

From: Charles Krinke <[email-masked]>
Date: Sun, 15 Mar 2009 12:29:02 -0800

As has been stated by the chairs several times, we are all individuals in
our opinions on this group regardless of our group or company affiliations.
So, your opinion, my opinion, all the other opinions are individuals and not
representative of any company regardless of what we may say or not say.

There are some in the OpenSim group that support OGP, others may not. Some
feel that LLSD is good, some do not.

This MMOX group is here to currently work out a charter and state the
problem. Until the problem can be stated in a reasonable manner that all can
agree with, jumping ahead to saying that solutionX, Y or Z is the only
*true* solution is premature.

I rather suspect that this group needs to come to grips with a reasonable
charter and move forward in the framework of the IETF to make
recommendations on ports, data formats and the like.

I also rather suspect that multiple forms of interop will prevail and it is
to the advantage of this group to encourage creativity and innovation.

Personally, I tend to give more credence to logical ideas that are
implemented and testable. And, currently, these are OGP, MXP and HyperGrid,
but not LESS.

Should LESS become implemented so that two or more virtual worlds may test
its premises, then so much the better.

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Morgaine <[email-masked]>
Date: Sun, 15 Mar 2009 22:57:56 +0000

On Sun, Mar 15, 2009 at 8:12 PM, Jon Watte <[email-masked]> wrote:

> "generic client" concept.

You still haven't absorbed the full implications of the 7 points given
here<http://www.ietf.org/mail-archive/web/mmox/current/msg01016.html>.
  Generic clients are completely inevitable, whether you or anyone else
likes them or not.  The reason why nobody is even bothering to make a formal
case for them is that they're already here in our midst, and sweeping back
the tide is a waste of everybody's time.  I would have hoped that is clear.

> Note that the proliferation of clients is the current state of the world --
> it's not something someone is arguing for; it's what we have now.

But we are talking about clients involved in interoperating worlds, not the
total number of clients in existence.  Since worlds of different types do
not currently interoperate, talking about the clients they use doesn't seem
very relevant.  Looking at the Opensim grids that do currently interoperate,
the majority of them work with any client of the SL family, and there are
many dozens of those (as is typical with open source software).

You can view this as client proliferation (they're all different) or as
clients coallescing and tending towards a single generic client (they're all
based on a similar model), but however you view it, both the genericity and
the proliferation are here to stay. ;-)

Morgaine.

On Sun, Mar 15, 2009 at 8:12 PM, Jon Watte <[email-masked]> wrote:

>  So that just leaves us with what's required by the OGP approach, and this
>> is where your understanding is breaking down and leading you to false
>> conclusions.
>>
>>
>>
>> model in my 3-world OGP interop scenario <
>> http://www.ietf.org/mail-archive/web/mmox/current/msg01114.html>.
>> worlds will of course welcome avatar diversity <
>> http://www.ietf.org/mail-archive/web/mmox/current/msg01020.html>.  We are
>> in the business of supplying mechanisms to allow it when it is desired, not
>> mandating any specific policy.
>>
>>
>> You have not given even a single line of explanation of your "/*not having
>> to install two clients*/" phrase in the contexts I quoted <
>> http://www.ietf.org/mail-archive/web/mmox/current/msg01142.html> (paying
>> for clients), and  therefore I conclude that it had no basis in reality nor
>> addresses any known issue.  Such phrases are best avoided as they create a
>> false impression of intent.
>>
>>
> certain kind of interop: being able to visit different, separate worlds. The
> user experience cost is to install two clients, and switch between them. For
> anything to be an improvement over what we already have, then the benefit to
> the user of the improvement must be such that it at least pays for the
> investment for the worlds providing that benefit, or the "improvement" is
> actually a loss.
>
> This leaves aside the point that OGP isn't even implementable from spec as
> it is currently written up, much less actually useful to anyone other than
> Second Life interoperating with Open Sim. If that's all you want to
> vendor neutral interop. It's really a question of what we want to do in this
> group:
>
> specifying how third parties, such as Open Sim, can interoperate with the
> Linden public grids. They have not shown any interest in interoperability on
> neutral ground with a large number of different technologies.
>
> 2) OpenSim and RealXTend representatives have stated that they want to help
> Linden Labs in those goals, but they are open to also doing other things
> regarding interoperability.
>
> cross-technology interoperability. We have also stated that there is no way
> that OGP can deliver any kind of usable interoperability to our users, and
> from my analysis, no other virtual world technology not derived from the
> Linden/OpenSim DNA would have any benefit either. I have not heard any
> vendor outside the Linden/OpenSim sphere say that OGP would deliver anything
> of interest to them, either.
>
> 4) Various users are contributing their requirements for the evolution of
> virtual worlds, having to do with seamless travel, IP protection, the
> widespread, vendor neutral, cross-technology interoperability. It seems that
> most of the participants on the list actually aren't interested in that, but
> are interested in something much more narrow. At that point, I suggest the
> right solution is to re-charter to make the charter match the narrow
> desires, and move the broader discussion somewhere else. Alternatively, keep
> the broad charter of this group, but move the narrow desire somewhere else.
>
> group, is a bad idea, because it leads to situations where people who don't
> care about some particular topic are still required to participate and
> endorse proposals within that topic. It also leads to discussions between
> the people with different goals, that are motivated not by technical
> requirements (what's allegedly what drives IETF standards), but by
> fundamentally incompatible basis for analysis.
>
> Sincerely,
>
> jw
>
>

---

From: Jon Watte <[email-masked]>
Date: Sun, 15 Mar 2009 21:11:26 -0700

Charles Krinke wrote:
> problem. Until the problem can be stated in a reasonable manner that 
> all can agree with, jumping ahead to saying that solutionX, Y or Z is 
> the only *true* solution is premature.
>

I'm not saying there's a *true* solution. I'm saying that there are 
reasons why I don't think certain solutions are cost effective in 
bringing the world towards a true, merged, interoperable metaverse, and 
why other solutions probably are cost effective, based on experience.

> I rather suspect that this group needs to come to grips with a 
> reasonable charter and move forward in the framework of the IETF to 
> make recommendations on ports, data formats and the like.
>

The problem is that we seem to be pretty far apart when it comes to 
defining "reasonable charter." For example, if the charter is such that 
too broad a scope is selected ("include everything"), then a lot of 
people will be put off because each member is supposed to contribute to 
each of the accepted proposals through the group. Meanwhile, if the 
charter is narrowed down to any particular proposal, and that proposal 
in reality only helps out a few of the participants, then the other 
participants probably will have to go elsewhere.

Do you believe the group could be successful, and attract members from 
the wider virtual world community (not just the people currently in the 
group), if the charter was "include everything"?
Similarly, do you think that those who are outside the Second Life / 
OpenSim sphere would be interested in participating in defining a 
standard that, realistically, only applies to systems designed based on 
that DNA?

> implemented and testable. And, currently, these are OGP, MXP and 
> HyperGrid, but not LESS.

LESS is designed to take advantage of learning we have gathered over the 
years, as well as being formulated to be easily accepted by a wide 
variety of virtual world architectures.

It sounds on you as if you would actually have been happier if I had 
submitted the OLIVE-specific, proprietary, 
not-designed-as-a-middle-ground protocol we use for interop in our 
current interop gateway, just because it's already implemented. Is this 
what you are advocating?

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Sun, 15 Mar 2009 21:30:41 -0700

Morgaine wrote:
> On Sun, Mar 15, 2009 at 8:12 PM, Jon Watte <[email-masked] 
> <mailto:[email-masked]>> wrote:
>  
>
>     Actually, I have seen the Open Sim people propose and argue for
>     the "generic client" concept.
>
>
>
> Generic clients are completely inevitable

That is your opinion, but you seem to present it like scientific fact. 
There are some generic clients, for some worlds. If I understand you 
correctly, you believe that there will be one or more clients that will 
actually connect to most virtual worlds in existence. Am I understanding 
you correctly?

I think that generic clients that connect to many different kinds of 
virtual worlds are not only a bad idea. They are way too expensive 
considering that they solve only a pretty trivial problem (the problem, 
in the status quo, that you need to switch clients when switching 
worlds). Note that generic clients do not give you the mash-up 
capability of using objects that come from two separate worlds in a 
common space. Only one of the two options of "dictate the server 
execution environment" or "server <-> server interoperability" gives you 
that (unless you're aware of some model I'm not, but are holding back). 
That's a problem I think adds tremendous value, and moves the metaverse 
substantially forward.

> that they're already here in our midst

If I understand you correctly: You believe that a client that can only 
talk to Second Life derived virtual worlds is "generic"? That's what I'm 
hearing.
Do you also believe that the Metaverse.net client is "generic," because 
it can talk to all the difference virtual worlds built on the Metaverse 
platform?
Do you believe that the OLIVE client is "generic" because it can talk to 
all of the virtual worlds built on the OLIVE platform?
If you mean something else, please point me at concrete examples.

>
> But we are talking about clients involved in interoperating worlds, 
> not the total number of clients in existence.  Since worlds of 
> different types do not currently interoperate, talking about the 
> clients they use doesn't seem very relevant.  Looking at the

I think it is very relevant! It's simple economics:

Broad adoption of a standard only happens when it significantly improves 
the status quo, such that the engineering necessary to adhere to the 
standard costs less than the benefit of adhering to the standard. If the 
status quo means that you can visit different worlds, and the adoption 
of a standard means that you can visit different worlds, faster, but 
otherwise changes nothing, then the value of that standard is the value 
for the users in being able to switch between worlds faster.

My argument is that that's pretty low value, and thus will not incite 
broad adoption. My argument is also that if you're to build a generic 
client that reaches even 50% of all the virtual worlds out there, you 
have to either incorporate a large number of different protocols, OR you 
have to convince a large number of virtual world vendors to re-do their 
client/server communications stack to a common format. Both of those 
alternatives have a very high cost associated with them.

Note that I'm not talking about broad adoption among "Second Life Users" 
or even "World of Warcraft Users" (a group 10x the size of the former) 
-- I'm talking about adoption within governments, companies, 
non-profits, churches, countries and everyone else who is currently 
virtual world illiterate. Our job is to make sure that using virtual 
worlds makes sense for those people; that it can transform the way they 
live their lives and do their work for the better.

> You can view this as client proliferation (they're all different) or 
> as clients coallescing and tending towards a single generic client 
> (they're all based on a similar model), but however you view it, both 
> the genericity and the proliferation are here to stay. ;-)

Let me see if I understand you correctly:
You believe that the Second Life model is actually superior, and will 
prevail over all other virtual world models?
That's what the above sounds like you're saying to me, but I want to 
make sure I understand you clearly.
In my view, nobody but the Second Life / OpenSim sphere is trending 
towards a common generic client, and the reason that Second Life / 
OpenSim are "trending" towards that direction is that they all started 
out from the same place to begin with.

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Mon, 16 Mar 2009 12:15:50 +0000

On Mon, Mar 16, 2009 at 4:30 AM, Jon Watte <[email-masked]> wrote:

>
>> <Morgaine>: Generic clients are completely inevitable
>>
>

It is not scientific fact, it is just practical fact.  When I ask you to
consider the 7 reasons why generic clients are here to
stay<http://www.ietf.org/mail-archive/web/mmox/current/msg01016.html>(and
there are many more than 7), it is only to recommend that you do not
attempt to sweep back the tide.  But I can only take this so far before I
and everybody else gets bored with it.  Ultimately if you wish to deny
yourself interop until you have successfully swept out the tide, that is
your right, but I doubt that many people wish to wait that long.

> actually connect to most virtual worlds in existence. Am I understanding you
> correctly?

You have *almost* correctly expressed the goal of MMOX:  to create a
protocol or protocol suite that will allow most worlds (current and future)
to talk to each other and thereby achieve a useful measure of "interop", ie.
sharing of world concepts, *as perceived in their clients*.  Notice that
word, *clients*.

The client is an inseparable part of this because the sole purpose of
interop is to gives *users* (operators of clients) the perception of a
mashup.  Everything else (for example servers) is a means to an end, an
important means but just a means nevertheless.  The servers could disappear
entirely and interop would still be possible, but not the other way around.

I strongly recommend that this discussion about whether clients are relevant
to interop be brought to an end, because it serves no purpose and just
delays progress.  If you don't wish to place a protocol endpoint on a
client, then don't.  Everything else still applies.

Morgaine.

On Mon, Mar 16, 2009 at 4:30 AM, Jon Watte <[email-masked]> wrote:

> Morgaine wrote:
>
>> On Sun, Mar 15, 2009 at 8:12 PM, Jon Watte <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
> actually connect to most virtual worlds in existence. Am I understanding you
> correctly?
>
> considering that they solve only a pretty trivial problem (the problem, in
> the status quo, that you need to switch clients when switching worlds). Note
> that generic clients do not give you the mash-up capability of using objects
> that come from two separate worlds in a common space. Only one of the two
> options of "dictate the server execution environment" or "server <-> server
> interoperability" gives you that (unless you're aware of some model I'm not,
> but are holding back). That's a problem I think adds tremendous value, and
> moves the metaverse substantially forward.
>
> If I understand you correctly: You believe that a client that can only talk
> to Second Life derived virtual worlds is "generic"? That's what I'm hearing.
> Do you also believe that the Metaverse.net client is "generic," because it
> can talk to all the difference virtual worlds built on the Metaverse
> platform?
>> But we are talking about clients involved in interoperating worlds, not
>> the total number of clients in existence.  Since worlds of different types
>> do not currently interoperate, talking about the clients they use doesn't
>> seem very relevant.  Looking at the
>>
>
> status quo means that you can visit different worlds, and the adoption of a
> standard means that you can visit different worlds, faster, but otherwise
> changes nothing, then the value of that standard is the value for the users
> in being able to switch between worlds faster.
>
> My argument is that that's pretty low value, and thus will not incite broad
> adoption. My argument is also that if you're to build a generic client that
> reaches even 50% of all the virtual worlds out there, you have to either
> incorporate a large number of different protocols, OR you have to convince a
> large number of virtual world vendors to re-do their client/server
> communications stack to a common format. Both of those alternatives have a
> very high cost associated with them.
>
> Note that I'm not talking about broad adoption among "Second Life Users" or
> even "World of Warcraft Users" (a group 10x the size of the former) -- I'm
> talking about adoption within governments, companies, non-profits, churches,
> countries and everyone else who is currently virtual world illiterate. Our
> job is to make sure that using virtual worlds makes sense for those people;
> that it can transform the way they live their lives and do their work for
> the better.
>
> That's what the above sounds like you're saying to me, but I want to make
> sure I understand you clearly.
> In my view, nobody but the Second Life / OpenSim sphere is trending towards
> a common generic client, and the reason that Second Life / OpenSim are
> "trending" towards that direction is that they all started out from the same
> place to begin with.
>
> Sincerely,
>
> jw
>
>

---

From: Morgaine <[email-masked]>
Date: Mon, 16 Mar 2009 12:44:34 +0000

Once we get to the stage of examining and improving protocol drafts, I
suggest that any protocol description that mentions viewers or clients be
given a paragraph along the lines of:

The term "client" denotes a particular *role* in the protocol, one of the
two endpoints in a client-server relationship.  The protocol does not
proscribe where this role is implemented.  While the most common
implementation of the *client role* is likely to be within a user
application, nothing precludes that role being implemented within a server,
such as a worlds-interface server or a proxy for more distant clients.

Or something like that. ;-)

The goal is simply to get us beyond the current pro-client/anti-client
discussion, which like almost all polarized pro/anti discussions, is rarely
constructive.

Morgaine.

---

From: Kajikawa Jeremy <[email-masked]>
Date: Mon, 16 Mar 2009 23:14:25 +0900

Dont need to dictate the server environment...

only need for any given server to provide means of an object
  being "representable" on a second server with "event forwarding" of
  whatever happens to one copy being propogated forward.

the only issue becoming "tracking" the disparate objects....

Ive actually gone ahead and tried to model a mechanism for such things
  and have actually run into a quirk of the way a couple of MMO systems
work.

anything with a distinct backend database can run local event tracking
and will
  be treated as a single-"server role"-entity serving a given MMO
content.

while a second system will need to provide or be provided some kind
  of secure(?) mechanism for a shared-object-key to be used in
  "update" messages.

My own view of any object whether in 2D/3D or OOP environment,
  is along the lines of "X exists",  lvalue=X::get(attr); / X::set(attr,
lvalue);

and the only things needing to be shared would be scripting being able
 to handle an "extern message" for "extern_send()" or "extern_recv()"
 event handling.

do the disparate replications? of the object HAVE to be in perfect sync?
  doubt it,  why bother?  only when the object is statefull does it need
sync,
  and then that would be arms to an octopus
  (object in DB with state-engine and representations are the
tentacles).

I am personally treating the "rendered space" as the user view,
  the "relational space" as mapped by the region/physics engine,
  "object scripting & storage"( DB + script servers).

DB( object data ) this is "area" of the object itself

SCRIPT( object event processing ) this is object specific programming

SPATIAL( object mapping ) events are triggered through this relational
mapping
PHYSICS( object motion/opacity ) anything happening to one or more
objects
  spatial and physics I see as being two halves of a whole (no spatial =
no physics),

RENDERED( object display for users )

I know I am describing pretty much a generic model of the servers
already available
  regardless of server.

right now I am seeing the problem as this...

How are we going to have 1 or more services "share" spatial and physics
mapping,

the use case I have in mind is this...
  object X is being shown to N users across M "services"...

X is originating from service M(0) and also displaying on M(P) M(Q) and
M(R),

  M(P) M(Q) and M(R) need to propogate events back to M(O) and receive
  updates in state from M(O) but this runs into a heirarchy problem of
concurrency.

  I see this as being described by JW,

I also see the following use-case,  
  object("something") is created by User("creatoid"),
  User("creatoid") sells User("Random.Joe") object("something").

  User("creatoid") is normally on a private server but is using a store
on a
  shared-space system and User("Random.Joe") is from a public service.

Does the object he purchased transfer FROM "creatoid"s private server
provision of
  storage and scripting?  or does creatoid need to program for a
  "storage and scripting" service thats independant of both services ?

In the above... I see "Creatoid" as creating on his home private system,
  and programming the object after transfer to a seperate service for
  storage & scripting before selling on  the shared spaces.

maybe Im being stupid,  but I am considering the protocol we are
developing
  as providing "event trigger" messages with some requiring "best
effort" like UDP
  and others requiring "MUST HAPPEN" meaning it has to be heard for
state.

I personally think use of RHTTP for some things would work nicely,
  for others it will require some kind of custom server for showing an
API
  to accept LESS,

But in ALL shared-space areas... there will eventually need to be
support for any
  system to either "proxy" their own client into an alternate
service...(server expensive)
  or provide means for any of the "generic" clients which support both
spaces
  to make a transition.

Right now we need the former so the latter can be developed.

But there is always going to be a "generic client",

right now do we need to care about the clients so much?
  probably not,

Do we have the mechanisms for later generic clients to work?
  doesn't matter as the generic clients WILL find a means to work

I dont see any world specific client backing off if a central "client
library"
  becomes available similar to how libpurple provides adium/pidgin and
  also how the "telepathy stack" supports the "empathy" client for
IM/IRC/VoIP,

Whats to stop "telepathy" having SecondLife or OLIVE or another "world
protocol"
  being added to the stack with a 3D world browser as well?

the "Web Browser" is now considered a "standard feature" as part of a
computer
  being "Installed" from blank slate,  it is now that ubiquitous,  why
block the same?
  or optionally,  block being browsed by user-clients?

Im still looking forward to when ALL the various services have
cross-connects
  and I can walk/fly/run/swim and otherwise travel between systems
without
  need of using a teleport of any kind.

as for "mapping"... any world only needs to map itself to its own
boundaries,

  just because you walk forwards through the portal to "zone" from one
area
  to the next does not mean walking backward through the same portal
  will put you back where you came from...

If I ever try to be a GM and RP this group... I would seriously through
everyone
  here through a mental wringer since I would definitely portal people
  along with "shard" the landscape so that areas that are close are not
  and areas that are not close actually are....

I can map things that way for myself,  but I dont actually expect anyone
here
 to grok the map :)

 Jeremy

---

From: Jon Watte <[email-masked]>
Date: Mon, 16 Mar 2009 08:10:20 -0700

Morgaine wrote:
> discussion, which like almost all polarized pro/anti discussions, is 
> rarely constructive.

The reason we ended up here was because I said OGP will not be widely 
adopted outside the Second Life / OpenSim sphere, because it requires 
significant engineering in the client/server connection to achieve any 
kind of interop through OGP, for any kind of cross-technology interop.
In the OGP model, currently, if Open Sim wants to connect to OLIVE, they 
need to implement the OLIVE protocol. If OLIVE wants to connect to 
Metaverse, they need to implement the Metaverse protocol. I consider 
that broken.
You suggest that this problem will be solved by engineering a standard 
client/server protocol. I point at the history of synchronous 
interactive online systems (note: web is not synchronous, and hardly 
interactive), and say that I don't believe such a standard is feasible 
(politically or technically).
Thus, I believe that an "interop" protocol that requires all technology 
clients to be able to talk to all other technology clients to not 
actually deliver feasible interop (nevermind that it doesn't solve the 
world mash-up problem).
While there may be, in your words, "generic" clients within a specific 
technology domain, that doesn't mean much for cross-technology interop.

Note: because words seem to be mis-understood, in the above comments, 
when I say "technology," I mean "virtual world platform DNA" -- 
Multiverse is a technology; OLIVE is a technology, Second Life is a 
technology, Unreal 3 is a technology. When it comes to client/server, 
interop between different worlds using the same technology is easy (at 
least if the technology makes it so); it's interop between different 
technologies that needs standardization to happen.

Sincerely,

jw

---

From: "Frisby, Adam" <[email-masked]>
Date: Mon, 16 Mar 2009 18:38:09 -0400

I've been avoiding this list lately since I've not had the time to read the (very) significant number of posts made in recent history, however I am going to chime in here again and say we should be utilizing URI-style constructs as much as possible.

I believe we [may] have a rough consensus that there are elements we want to standardise, this being authentication and identity circuits. However there is no reason why the client<->region connection needs to be fixed as a specific protocol, simply the result from the authentication mechanism can return a URI.

For instance,

MMOX defines a auth protocol, client makes attempt to connect to a environment via this auth protocol, is returned a URI with "mxp://ip/regionID/", or a "olive://ip/region", or a "secondlife://region/x/y/z". (or perhaps a combination of the above for servers capable of handling more than one [eg opensim].)

This then allows others to pitch client<->region standards and let the market weed out what is deemed to be effective / noneffective. It would still then be entirely in the remit of this group to propose a standard for the above too - however by utilizing the URI schema, it does not force implementers into using it (only recommends it as a 'common reference point').

Adam

> Jon Watte
> Sent: Monday, 16 March 2009 8:10 AM
> To: Morgaine
> Cc: MMOX-IETF
> Subject: Re: [mmox] One more time: The LESS model vs the Generic Client
> model
>
> Morgaine wrote:

---

From: Morgaine <[email-masked]>
Date: Tue, 17 Mar 2009 07:38:15 +0000

That's an interesting new angle, Adam.

So if I understand you correctly, the first port of call when worlds
interoperate should be to decide which protocol to use, as a sort of
pre-protocol or meta-protocol.

Notice that in principle, OGP allows selection of LLSD serialization to be
negotiated at the start, although I don't think that this is in operation
yet.  That doesn't seem the right place for your non-OGP options to be
offered though, since choice of OGP is already decided at that point.

Perhaps the opposite might be cleaner:  add the OGP+LLSD serialization
options to your meta-protocol instead?

Morgaine.

On Mon, Mar 16, 2009 at 10:38 PM, Frisby, Adam <[email-masked]>wrote:

> I've been avoiding this list lately since I've not had the time to read the
> (very) significant number of posts made in recent history, however I am
> going to chime in here again and say we should be utilizing URI-style
> constructs as much as possible.
>
> I believe we [may] have a rough consensus that there are elements we want
> to standardise, this being authentication and identity circuits. However
> there is no reason why the client<->region connection needs to be fixed as a
> specific protocol, simply the result from the authentication mechanism can
> return a URI.
>
> For instance,
>
> MMOX defines a auth protocol, client makes attempt to connect to a
> environment via this auth protocol, is returned a URI with
> "mxp://ip/regionID/", or a "olive://ip/region", or a
> "secondlife://region/x/y/z". (or perhaps a combination of the above for
> servers capable of handling more than one [eg opensim].)
>
> This then allows others to pitch client<->region standards and let the
> market weed out what is deemed to be effective / noneffective. It would
> still then be entirely in the remit of this group to propose a standard for
> the above too - however by utilizing the URI schema, it does not force
> implementers into using it (only recommends it as a 'common reference
> point').
>
> Adam
>

---

From: Charles Krinke <[email-masked]>
Date: Tue, 17 Mar 2009 08:53:18 -0800

I have the greatest of respect for Adam's ideas and I believe the point is
one of allowing various interop schemes to be nurtured and allow the
community to then decide which one is the most efficient for their
interconnected systems.

No matter what one of us says to sell our vision of how the Metaverse should
evolve, there will be others that say 'No, thats wrong, *my* vision is the
correct vision'.

So, why not encourage the various different schemes with a way to allow the
MMOX protocol to define ways for the negotiation between two virtual worlds
to work out similarities (and differences).

Charles Krinke
OpenSim Core Developer
OSGrid Director

2009/3/16 Morgaine <[email-masked]>

>> I've been avoiding this list lately since I've not had the time to read
>> the (very) significant number of posts made in recent history, however I am

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Mark Lentczner <[email-masked]>
Date: Tue, 17 Mar 2009 16:24:38 -0700

> of how a server and client interact, as a standard protocol?
Yes.
Telnet, FTP, IMAP & 2822, HTTP & HTML, XMPP, to name a few past  
examples.

> done, how user control is forwarded, etc?
Yes insofar as the semantics of the capabilities are defined, but not  
the precise UI.  HTML & CSS specify quite a bit about the semantics of  
the presentation - and often dictate quite precise presentation.  But  
browsers are pretty free to create GUI as they see fit.
No to version patching. Updating the client is beyond the scope of the  
protocol.

> world A?
Yes.

> What about objects you want to use cross worlds; are you saying you  
> also want to specify the exact runtime requirements for objects  
Yes.
2822 & MIME, HTML & CSS & JavaScript, ODF to name a few past examples.

> I believe that the real enabler of interop is to be able to merge  
> the simulations of different worlds
Ah - here we disagree.  I think this is a non-starter for the vast  
majority of users and use cases. Whereas I think users really care  
about using a single client, and a single virtual identity to roam the  
wide-open spaces of the metaverse.

> So, if no users want to pay money for the convenience of not having  
> to install two separate clients, exactly why would any profit- 
> seeking company implement a second protocol in their client?
Is it just a convenience that you don't have to download and run a  
different browser-like client applications for your bank, for Netflix,  
for Wikipedia, and for Google? I am old-enough to remember an Internet  
where each of those would have been independent protocols, with  
independent clients. While I as a user consider the single, universal  
web browser of great value - and would pay for it (I own a retail copy  
of Netscape Navigator!) - every other segment of the computer industry  
benefits so greatly by this architecture, that the browser has become  
free.

Fundamentally - I think the scenario that Morgaine started this thread  
with points to an architecture that what many people want and  
satisfies many use cases.

	- Mark

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[email-masked]

Zero Linden
[email-masked]

---

From: Morgaine <[email-masked]>
Date: Wed, 18 Mar 2009 14:11:30 +0000

On Tue, Mar 17, 2009 at 11:24 PM, Mark Lentczner <[email-masked]>wrote:

>
> Fundamentally - I think the scenario that Morgaine started this thread with
> points to an architecture that what many people want and satisfies many use
> cases.
>
>
>
That's good to hear from you, Mark.  The 3-world
scenario<http://www.ietf.org/mail-archive/web/mmox/current/msg01114.html>is
deliberately simple, yet it captures the central goal of interop:   to
provide *users* with an interactive mashup composited out of elements taken
from multiple, diverse worlds.  Everything else is a means to that end.

In these few days remaining before the BoF and perhaps for a short while
after that, it is a key element of our work to define the problem space
(along with a few tentative solutions), since it is on that basis that a WG
will be approved or denied.

I believe that the given scenario defines the core of the *problem
space*with good coverage, although of course not total coverage.  Very
importantly, it says NOTHING about the *solution space*:  anyone who is
strongly averse to adding MMOX protocol handling to their clients should
note that the scenario does NOT say that A1's client has connected to B nor
to C during the avatar's virtual travels to those worlds.  That would be a
solution-space detail.

I hope that this can be a common denominator between us all.

Morgaine.

On Tue, Mar 17, 2009 at 11:24 PM, Mark Lentczner <[email-masked]>wrote:

> Do you seriously think it's a good idea to specify all the minutiae of how
>> a server and client interact, as a standard protocol?
>>
> Yes.
> Telnet, FTP, IMAP & 2822, HTTP & HTML, XMPP, to name a few past examples.
>
>  Including how GUI is tied to local and remote capabilities, how a scene
>> graph is constructed and animated, how version patching is done, how user
>> control is forwarded, etc?
>>
> Yes insofar as the semantics of the capabilities are defined, but not the
> precise UI.  HTML & CSS specify quite a bit about the semantics of the
> presentation - and often dictate quite precise presentation.  But browsers
> are pretty free to create GUI as they see fit.
>  And all that work, just to be able to show up in world B instead of world
>> A?
>>
> Yes.
>
>  What about objects you want to use cross worlds; are you saying you also
>> want to specify the exact runtime requirements for objects (scripting
>> language, physics interface, etc)?
>>
> Yes.
>  I believe that the real enabler of interop is to be able to merge the
>> simulations of different worlds
>>
> Ah - here we disagree.  I think this is a non-starter for the vast majority
> of users and use cases. Whereas I think users really care about using a
> single client, and a single virtual identity to roam the wide-open spaces of
> the metaverse.
>
> different browser-like client applications for your bank, for Netflix, for
> Wikipedia, and for Google? I am old-enough to remember an Internet where
> each of those would have been independent protocols, with independent
> clients. While I as a user consider the single, universal web browser of
> great value - and would pay for it (I own a retail copy of Netscape
> Navigator!) - every other segment of the computer industry benefits so
> greatly by this architecture, that the browser has become free.
>
> Fundamentally - I think the scenario that Morgaine started this thread with
> points to an architecture that what many people want and satisfies many use
> cases.
>
>        - Mark
>
> Mark Lentczner
> Sr. Systems Architect
> Technology Integration
> Linden Lab
>
> [email-masked]
>
> Zero Linden

---

From: Charles Krinke <[email-masked]>
Date: Wed, 18 Mar 2009 07:56:24 -0800

One thing that sticks in my mind is experiencing some of the script-based
HyperGrid teleports on OSGrid recently.

Since those are using llHTTPRequest/http_response, it seems to me that
ensuring that whatever is adopted by this group considers enough flexibility
to allow folks to script the opening of gateways or wormholes or whatever to
other virtual worlds yet to be heard from.

Having enough flexibility so that a script-type of language using simple
http calls and responses seems like a powerful and compelling feature to
ensure we dont loose.

Charles Krinke
OpenSim Core Developer
OSGrid Director

2009/3/18 Morgaine <[email-masked]>

>> with points to an architecture that what many people want and satisfies many
>> use cases.
>>
>>
>>
> That's good to hear from you, Mark.  The 3-world scenario<http://www.ietf.org/mail-archive/web/mmox/current/msg01114.html>is deliberately simple, yet it captures the central goal of interop:   to
> provide *users* with an interactive mashup composited out of elements
> taken from multiple, diverse worlds.  Everything else is a means to that
> end.
>
> I believe that the given scenario defines the core of the *problem space*with good coverage, although of course not total coverage.  Very
>> majority of users and use cases. Whereas I think users really care about
>> using a single client, and a single virtual identity to roam the wide-open
>> spaces of the metaverse.
>>
>> with points to an architecture that what many people want and satisfies many
>> use cases.
>>
>>        - Mark
>>
>> Mark Lentczner
>> Sr. Systems Architect
>> Technology Integration
>> Linden Lab
>>
>> [email-masked]
>>
>> Zero Linden

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Jon Watte <[email-masked]>
Date: Wed, 18 Mar 2009 08:59:51 -0700

Thank you for your constructive answer! See below.

> Telnet, FTP, IMAP & 2822, HTTP & HTML, XMPP, to name a few past examples.

None of which deal with real-time synchronous interaction (except XMPP 
-- but it turns out that AIM, MSN and Yahoo have overwhelming majority 
in that business). In real-time, synchronous interaction systems (cell 
phones, web video, etc) it doesn't seem like vendors settle on a single 
standard. Note that HTTP/HTML is a much simpler model than a virtual 
world, by a factor of one or even two orders of magnitude.

> 2822 & MIME, HTML & CSS & JavaScript, ODF to name a few past examples.

But objects run code. I think server-side technologies like J2EE, 
ASP.NET, LAMP (which P?), WebLogic, Domino etc are a much closer analog 
to running virtual world objects. Web technology languages have not 
converged on a single language/technology. I don't think virtual world 
simulation will, either. However, I strongly believe we need to support 
mash-ups of worlds.

> wide-open spaces of the metaverse.

If you look closely at the model of LESS (which uses mash-ups of 
multiple worlds), the user gets exactly that capability, including only 
having to worry about a single client -- but actually gets a lot more, 
such as the ability to interact with objects and users from multiple 
different systems at the same time.

Now, considering the cost of re-tooling an entire client/server chain, I 
don't think virtual world vendors will adopt a single system. You seem 
to think differently. Or, to phrase it another way, it seems as if I'm 
arguing for a system that lets diverse technologies solve the different 
problems they each are good at, and let them talk to each other. You 
seem to be arguing for everyone doing things the same way -- and, I 
would presume, preferably the Second Life way.

In my opinion, if you want interoperability across technologies, forcing 
everyone to do everything a single way is unlikely to gain traction 
among other vendors. If all you want is interoperability across systems 
that already do things the same way (like Second Life / OpenSim), then 
doing it your way makes sense. That's why I think that getting the 
charter right is important -- either we work on a system that truly 
enables cross-technology interoperability and integration, or we (or, 
rather, you) work on a system that is only suitable for OpenSim and 
Second Life derived technology. Whichever we do, it ought to be clearly 
stated in the charter, to avoid confusion.

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Wed, 18 Mar 2009 17:38:14 +0000

I agree completely Charles.  Few things are more relevant to interop between
worlds than actually "moving" (in the widest possible sense) between them.

Teleports, direct region adjacency, gateways, wormholes, and joint
visualization of shared spaces are all within our scope.  And to ensure that
it doesn't fall off our radar, I would like to mention Croquet's portals
between worlds (I don't know their actual name in Croquet) which allow you
to see a remote world as if through a mirror with full perspective, before
hopping through it.

Our protocol work needs to support all of these concepts and more.
Fortunately, that is easy to do, simply by focusing not on their in-world
representations but on their underlying requirements.  These are minimal:

   - Access to world data decoupled from any notion of an agent or avatar
   travelling there (otherwise you would never be able to see what's on the
   other side of a portal or boundary before travelling).
   - World transitions decoupled from any geographical layout or topology
   (otherwise you would never be able to teleport by landmark or address).

We don't mandate any specific *policy* of course, so a particular world may
allow only one particular method of entry.  The protocol itself however does
need to provide the above two functions as *decoupled mechanisms*, otherwise
more general movement between worlds is blocked.

Morgaine.

On Wed, Mar 18, 2009 at 3:56 PM, Charles Krinke <[email-masked]>wrote:

>>>> how a server and client interact, as a standard protocol?
>>>>
>>> Yes.

---

From: Charles Krinke <[email-masked]>
Date: Wed, 18 Mar 2009 13:31:31 -0800

Yes, I believe so. It would seem to me that defining ports, UDP vs TCP, and
the minimum possible on top of UDP and/or TCP is probably the first step. As
we move through that, leaving the maximum flexibility for evolution with
other virtual worlds whose login sequences are currently mysterious to us
seems like the safest path.

As we move forward, various virtual worlds should be able to build upon a
reasonable foundation laid brick by careful brick.

I think the current issue is defining the first set of bricks so that no one
is precluded from evolving his or her vision into the MMOX protocol as time
moves forward.

There are lots of strong opinions on how virtual worlds should operate. But,
I submit that none of that matters.

It only matters that we can move forward to allow some of the visions
expressed to become realizable while at the same time trying to not preclude
any particular vision.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Wed, Mar 18, 2009 at 9:38 AM, Morgaine <[email-masked]>wrote:

> I agree completely Charles.  Few things are more relevant to interop
> between worlds than actually "moving" (in the widest possible sense) between
> them.
>
> We don't mandate any specific *policy* of course, so a particular world
> may allow only one particular method of entry.  The protocol itself however
> does need to provide the above two functions as *decoupled mechanisms*,
> otherwise more general movement between worlds is blocked.
>
>
> Morgaine.
>
>
>
>
>
>
>
>
>
>>> I believe that the given scenario defines the core of the *problem space
>>> * with good coverage, although of course not total coverage.  Very
>>>> the precise UI.  HTML & CSS specify quite a bit about the semantics of the
>>>>> also want to specify the exact runtime requirements for objects (scripting

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

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

Hi!

Frisby, Adam wrote:
> I've been avoiding this list lately since I've not had the time to
> read the (very) significant number of posts made in recent history,
> however I am going to chime in here again and say we should be
> utilizing URI-style constructs as much as possible.

+1

> I believe we [may] have a rough consensus that there are elements we
> want to standardise, this being authentication and identity circuits.
> However there is no reason why the client<->region connection needs
> to be fixed as a specific protocol, simply the result from the
> authentication mechanism can return a URI.

That might be bascially what I am proposing in the draft I've written:

http://www.ietf.org/internet-drafts/draft-cscholz-mmox-architecture-00.txt

Basically what it means is the following:

1. Client wants to connect to region X
2. Client retrieves the XRDS file of region X (stored under a URL)
3. Client checks the XRDS file for services it understands

An XRDS file basically stores types of services as URIs and attached the
service endpoints to it (again URIs), e.g.

    <Service>
      <Type>http://ns.opensocial.org/2008/opensocial/people</Type>
      <URI>http://api.myspace.com/v2/people/</URI>
    </Service>

This would say that it can find the OpenSocial profile API at
http://api.myspace.com/v2/people

This format is already in use for OpenID and the experimental OAuth
discovery. At the IETF meeting there should also be some talk about
service discovery in general (I heard Eran was asked to talk about it at
the App Area meeting).

> "secondlife://region/x/y/z". (or perhaps a combination of the above
> for servers capable of handling more than one [eg opensim].)

So in this case with XRDS you would simply provide 2 <Service> elements.

> This then allows others to pitch client<->region standards and let
> the market weed out what is deemed to be effective / noneffective. It
> would still then be entirely in the remit of this group to propose a
> standard for the above too - however by utilizing the URI schema, it
> does not force implementers into using it (only recommends it as a
> 'common reference point').

+1. And you are flexible to exchange, add or remove protocols in
questions whenever you need to.

It also would allow us to start with some bits of interoperability which
we can expand on later (e.g. 2D realm with identification, profile,
friends, IM, inventory management for now, 3D stuff later).

-- Christian

> 
> Adam
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Jon Watte Sent: Monday,
>> 16 March 2009 8:10 AM To: Morgaine Cc: MMOX-IETF Subject: Re:
>> [mmox] One more time: The LESS model vs the Generic Client model
>> 
>> Morgaine wrote:
>>> discussion, which like almost all polarized pro/anti discussions,
>>> is rarely constructive.
>> The reason we ended up here was because I said OGP will not be
>> widely adopted outside the Second Life / OpenSim sphere, because it
>> requires significant engineering in the client/server connection to
>> achieve any kind of interop through OGP, for any kind of
>> cross-technology interop. In the OGP model, currently, if Open Sim
>> wants to connect to OLIVE, they need to implement the OLIVE
>> protocol. If OLIVE wants to connect to Metaverse, they need to
>> implement the Metaverse protocol. I consider that broken. You
>> suggest that this problem will be solved by engineering a standard 
>> interactive online systems (note: web is not synchronous, and
>> hardly interactive), and say that I don't believe such a standard
>> is feasible (politically or technically). Thus, I believe that an
>> "interop" protocol that requires all technology clients to be able
>> to talk to all other technology clients to not actually deliver
>> feasible interop (nevermind that it doesn't solve the world mash-up
>> problem). While there may be, in your words, "generic" clients
>> within a specific technology domain, that doesn't mean much for
>> cross-technology interop.
>> 
>> Note: because words seem to be mis-understood, in the above
>> comments, when I say "technology," I mean "virtual world platform
>> DNA" -- Multiverse is a technology; OLIVE is a technology, Second
>> Life is a technology, Unreal 3 is a technology. When it comes to
>> client/server, interop between different worlds using the same
>> technology is easy (at least if the technology makes it so); it's
>> interop between different technologies that needs standardization
>> to happen.
>> 
>> Sincerely,
>> 
>> jw
>> 
>> _______________________________________________ mmox mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/mmox
> _______________________________________________ mmox mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/mmox

-- 
Christian Scholz                          Homepage: http://comlounge.net
COM.lounge GmbH                              blog: http://mrtopf.de/blog
Hanbrucher Str. 33                                       Skype: HerrTopf
52064 Aachen                             Video Blog: http://comlounge.tv
Tel: +49 241 400 730 0                           E-Mail [email-masked]
Fax: +49 241 979 00 850                               IRC: MrTopf, Tao_T

neuer Podcast: Der OpenWeb-Podcast (http://openweb-podcast.de)
new podcast: Data Without Borders (http://datawithoutborders.net)