Subject: [mmox] Creating walled gardens considered harmful

From: Morgaine <[email-masked]>
Date: Wed, 25 Mar 2009 07:07:32 +0000

What an excellent BoF!

I believe that MMOX can validly claim a complete victory from the day's
events.

With so many excellent formal presentations and an astounding number of very
insightful contributions from the floor, ably mediated by very fair and
effective chairing, I think we were blessed to succeed, and we did.
Congratulations to everybody. :-)

On the substance, this will probably take many weeks of analysis, but I
would like to highlight here just one of the many insightful contributions
that were made.  (Unfortunately I cannot pin down exactly who said it.)

Splitting the work of MMOX into various implementation-oriented groups would
be an excellent way of making progress, but it carries a *severe danger*:  *it
could create several non-interoperating walled gardens*, if the groups work
independently without a common view and purpose.

While that might be better than no interop at all, it would be an
inappropriate result for a single MMOX workgroup to
*endorse*non-interoperation.  If we are to remain as one group, I
would propose that
there be an oversight team appointed as well, to ensure that sufficient
extensibility be built into each subgroup to avoid total segmentation into
walled gardens.

The requirements for this need not be onerous, as it could be achieved
through simple avoidance of all-or-nothing protocols.  As a specific example
arising from the Weblin presentation, an isolated ecosystem of Second
Life-like worlds should still be able to provide avatar data for use in
Weblin worlds, despite there being no full interop.  This could be achieved
quite simply by good decoupling of services and avoidance of service
bundling.

If we are consciously creating separate gardens, they should *not* be walled
off.  Let us work towards achieving *some degree of interop* even among our
subgroups, so that as a unified MMOX we can claim victory at the end as well
as at the start of this process.

Morgaine.

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 25 Mar 2009 09:29:16 -0700

Hi Morgaine,

As one of the people who highlighted the opportunity to break off
smaller pieces of work, I can add that I would also be concerned about
those areas working too independently.  When several efforts are all
IETF WG efforts, there's lots of opportunity for cross-over and
coordination, and we've done this many times before.  When there are
non-IETF efforts too, that gets even harder but not impossible.

As with so many things, successful coordination depends on individuals
--  WG chairs, editors, ADs but emphasizing participants who cross
over between efforts.

Lisa

2009/3/25 Morgaine <[email-masked]>:
> be an excellent way of making progress, but it carries a severe danger:  it
> could create several non-interoperating walled gardens, if the groups work
> inappropriate result for a single MMOX workgroup to endorse
> non-interoperation.  If we are to remain as one group, I would propose that
> If we are consciously creating separate gardens, they should not be walled
> off.  Let us work towards achieving some degree of interop even among our
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>
>

---

From: Lawson English <[email-masked]>
Date: Wed, 25 Mar 2009 10:06:05 -0700

> --  WG chairs, editors, ADs but emphasizing participants who cross
I think the best way to avoid this fragmentation is to simply "eat our 
own dogfood."

We made an attempt at that yesterday with the mashup of three SL worlds 
via a chatbridge, plus
the mp3 stream and jabber, but we need to do more.

However it fell short of what we could have done with a bit more work. 
We desparately need
regular teleconferencing via our various worlds, sharing as many data 
streams as possible, even
without any "virtual worlds" aspect to it.

Just a 2-way TV monitor on the wall would be fun. I don't expect 
holographic projections for a while,
though of course, that should come as well.

Lawsonm

---

From: Jon Watte <[email-masked]>
Date: Wed, 25 Mar 2009 10:17:28 -0700

Morgaine wrote:

Splitting the work of MMOX into various
implementation-oriented groups would be an excellent way of making
progress, but it carries a severe danger:  it could create
several non-interoperating walled gardens, if the groups work
independently without a common view and purpose.

One problem is that we don't even agree on what interop should be, and
what adds value to the growing global interconnected metaverse. I think
this is compounded by the fact that the group started out as a proposal
to standardize work done in the Second Life breed of virtual worlds,
without any particular consideration for the significant architectural
differences to almost all other platforms.

In fact, we don't even have representatives from most platforms in
this group, which I think is a real shame, and a problem if we want
broadly implemented interoperability. We may do well by trying some
more outreach.

For the non-virtual-world-savvy on the list: If I were to make a
cell phone analogy about the problem, it would go something like this:

The problem we want to solve is that I am on the Sprint network, and my
mom is on the AT&T network, and I want to call my mom.

The OGP proposal, in this analogy, wants to standardize how handsets
connect to carriers. Let's say it is somewhat similar in function for
virtual worlds to what GSM, or D-AMPS, or CDMA, or UMTS is for cell
phones.

The LESS proposal, in this analogy, wants to standardize how carriers
talk to other carriers. Let's say it is somewhat similar in function
for virtual worlds to what SS7, H.320, or SIP plus codecs are for phone
networks.

The interoperability provided by the OGP ("GSM") model is that I can
take one phone, and connect it to different carriers. If I want to talk
to my mom, I disconnect from Sprint, and re-connect to AT&T, and I
can talk to mom.

The interoperability provided by the LESS model does make it so that I
can call my mom through my existing carrier. However, it decides to
leave the handset standard (GSM vs CDMA) outside of interoperability,
both because building handset/base station suites is really expensive,
there are already lots of such stacks already available from different
providers, and because the basic functionality (talking across
different carriers) is actually a more enabling technology than
re-connecting your phone to a different carrier, while simultaneously
being cheaper to implement. There is, however, nothing remotely as well
accepted in virtual worlds as GSM, UMTS or even CDMA are in the cell
phone world. There is also nothing remotely as well accepted as SS7 or
H.320 or SIP.

Yes, this analogy can only be taken so far before it breaks down and
becomes a hinderance rather than a help, but I do think it does help
focus the discussion about charter: Does it really make sense to
discuss the "GSM/D-AMPS/CDMA/UMTS" question in the same working group
as the "SS7/H.320/SIP+codecs" question?

If OGP was a pure service broker protocol (similar to a service bus, or
OSIDs), then we could probably find common ground -- but then, why not
use OSID, or one of the dozen or so similar service broker technologies
already available? Or, in fact, why not just expose a XML-RPC or SOAP
interface that returns an XML blob of defined schema that lists
named/typed services as URLs, and we're done?

Once you start talking about higher-level functions like "OGP Teleport"
or having a client/viewer connect to simulation services, we
immediately run into significant political and technical challenges,
where I don't think there is actually a possibility of "one model fits
all" or even "one model fits most."

Sincerely,

jw

---

From: "Hurliman, John" <[email-masked]>
Date: Wed, 25 Mar 2009 11:26:26 -0600

Jon,

I think this does a great job at starting to explain the different approaches that have been taken toward virtual world interoperability. I look forward to having two or three clearly defined problem spaces mapped out so we can move forward with each one.

John

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Jon Watte
>Sent: Wednesday, March 25, 2009 10:17 AM
>To: Morgaine
>Cc: MMOX-IETF
>Subject: Re: [mmox] Creating walled gardens considered harmful
>
>Morgaine wrote:
>
>
>	Splitting the work of MMOX into various implementation-oriented
>groups would be an excellent way of making progress, but it carries a
>severe danger:  it could create several non-interoperating walled
>gardens, if the groups work independently without a common view and
>purpose.
>
>
>
>In fact, we don't even have representatives from most platforms in this
>group, which I think is a real shame, and a problem if we want broadly
>implemented interoperability. We may do well by trying some more
>outreach.
>
>
>For the non-virtual-world-savvy on the list: If I were to make a cell
>phone analogy about the problem, it would go something like this:
>
>talk to other carriers. Let's say it is somewhat similar in function for
>virtual worlds to what SS7, H.320, or SIP plus codecs are for phone
>networks.
>
>to my mom, I disconnect from Sprint, and re-connect to AT&T, and I can
>talk to mom.
>
>providers, and because the basic functionality (talking across different
>carriers) is actually a more enabling technology than re-connecting your
>phone to a different carrier, while simultaneously being cheaper to
>implement. There is, however, nothing remotely as well accepted in
>virtual worlds as GSM, UMTS or even CDMA are in the cell phone world.
>There is also nothing remotely as well accepted as SS7 or H.320 or SIP.
>
>
>focus the discussion about charter: Does it really make sense to discuss
>the "GSM/D-AMPS/CDMA/UMTS" question in the same working group as the
>"SS7/H.320/SIP+codecs" question?
>
>
>
>or having a client/viewer connect to simulation services, we immediately
>run into significant political and technical challenges, where I don't
>think there is actually a possibility of "one model fits all" or even
>"one model fits most."
>
>
>Sincerely,
>
>jw
>

---

From: "Mystical Demina" <[email-masked]>
Date: Wed, 25 Mar 2009 17:28:36 -0400

Perhaps there are some simpler specifications that could be done that could
start the process of making it possible to specify locations to teleport to
in different virtual worlds.

My thought is we could start an initiative to do or build on something like
what SLURL.com, OSURL.org, and some of the other URL based specifications
are doing and create a specification for a teleport location.

I suggest initially we keep it really simple and just have the client drop
its current connection and request a login to the new location retrieving
the grid info so that the user can then login to that new location without
having to close down the client.

I know this doesn't solve the complete interoperability issue but is a start
and would help some of the virtual worlds that are based on a common client
technology make a better experience for their users.

Then as we move forward and different client technologies are able to talk
to different server technologies we will have put in place a common teleport
location standard.

As an example if I am on Google and find a teleport URL I click on it and my
client for that virtual world starts, or if already running is directed to
that location and I am presented with a login request and I login.  If I
have logged in their previously seems we could have some kind of cookie
model that would allow me to be automatically be logged in without having to
type it in.  Then I find out about a training section in another virtual
world and click on the link and my client drops the connection to current
virtual world and presents a request to login to this new location.  If this
new location uses a different client it could launch this client.  In this
situation I will have had accounts in both places and if not would need to
make an account before I could login.

I would not carry any inventory, not carry over any identity, etc.  We don't
try to solve the single login scenario.  We keep it simple.

We could call this Virtual World Teleport Location Specification 1.0.  In
future versions we could request RFCs to add additional features and
capabilities to this standard.

If this a direction the group feels has value I would volunteer to
facilitate a working group for this specification.

Kevin Tweedy
SL: Mystical Demina

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hurliman, John
Sent: Wednesday, March 25, 2009 1:26 PM
To: Jon Watte; Morgaine
Cc: MMOX-IETF
Subject: Re: [mmox] Creating walled gardens considered harmful

Jon,

I think this does a great job at starting to explain the different
approaches that have been taken toward virtual world interoperability. I
look forward to having two or three clearly defined problem spaces mapped
out so we can move forward with each one.

John

---

From: Charles Krinke <[email-masked]>
Date: Wed, 25 Mar 2009 13:40:23 -0800

I think this makes a great deal of sense. In fact, I think Adam Frisby
suggesting something like this a week or so ago, so perhaps this idea is
gaining traction and "feels" like an altogether reasonable path.

There will undoubtedly be more then one path, but this seems like a good
one.

Charles Krinke
OpenSim Core Developer
OSGrid Director

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Christian Scholz <[email-masked]>
Date: Wed, 25 Mar 2009 22:42:52 +0100

Hi!

> named/typed services as URLs, and we're done?

That actually was part of my proposal in that we use a service discovery 
method as a foundation. This can be built using XRDS or similar means, 
the same thing OpenID already uses and which is planned for OAuth 
discovery (actually that's XRD but that's not yet published but should 
be similar).

This in fact gives you a simple XML document describing types (as URIs) 
and the service endpoints (URIs) for those types.

This document can then be either used to identify the services of a user 
(where is my profile, where is my friends list, where is my inventory) 
but also to identify the services supported by a individual virtual world.

> think there is actually a possibility of "one model fits all" or even 

This might be the case in some far future but I agree that it definitely 
is not the case right now. A flexible services discovery framework would 
allow for all these to be used though and maybe sometime one protocol 
will emerge as some winner. Or maybe not ;-)

But for common services such as identity, profiles, assets, IM and 
others we might be able to actually find suitable protocols even today. 
For everything 3D it might not be the case.

I think I will write a somewhat longer description of that with use 
cases someday later when I have more time.

-- Christian

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

---

From: Jon Watte <[email-masked]>
Date: Wed, 25 Mar 2009 18:02:26 -0700

Christian Scholz wrote:
> That actually was part of my proposal in that we use a service 
> discovery method as a foundation. This can be built using XRDS or 
> similar means, the same thing OpenID already uses and which is planned 
> for OAuth discovery (actually that's XRD but that's not yet published 
> but should be similar).

This gets my vote. It is small enough, de-coupled enough, and technology 
neutral enough to make sense for any vendor/platform/technology, despite 
vast technical implementation differences. It also neatly side-steps the 
need to define more technology specific aspects like a binary 
serialization format.

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Thu, 26 Mar 2009 13:38:47 +0000

On Wed, Mar 25, 2009 at 5:17 PM, Jon Watte <[email-masked]> wrote:

>
> Once you start talking about higher-level functions like "OGP Teleport" or
> having a client/viewer connect to simulation services, we immediately run
> into significant political and technical challenges, where I don't think
> there is actually a possibility of "one model fits all" or even "one model
> fits most."
>
>
 Jon, I think we need to go beyond the entrenched pre-BoF statement of
positions and telephone analogies if we are to get anywhere at all.  I
suggest that we leave the general presentations behind and talk about VW
specifics at a technical level, one at a time.

You claim some fundamental incompatibility introduced by the concept of
teleport, but I believe that that is unfounded.  Let's examine it more
deeply.

When a client A1 from world A in the OGP ecosystem requests a teleport to a
specified address in some other world B, three things happen at a conceptual
level that are entirely independent of the actual details of OGP (I'm going
to avoid OGP terminology):

   1. *Identity transfer is negotiated to provide continuity of identity
   across the change of environment.*  This is carried out by the identity
   provider of A contacting the identity provider of B if the two providers
   have an interop agreement, but if B is unknown to A then we do not yet have
   a scheme for this.  (The latter can be expected to be the majority case in
   an Internet-spanning metaverse.)  The 3-world interop
scenario<http://www.ietf.org/mail-archive/web/mmox/current/msg01114.html>captures
both cases.
   2. *Presence transfer is negotiated to discontinue presence in world A
   and commence presence in world B.*  This is mediated by the identity
   provider of A requesting termination of the old presence in A, and the
   identify provider of B requesting startup of the new presence at a specified
   location in B.  At the end of this process, the avatar in client A1 can now
   perceive that it is present in the environment of world B (but nobody else
   can).
   3. *Asset transfer is negociated in the A->B direction to allow assets
   from world A to appear in world B, or to deny the transfer where
   appropriate.*  This involves seeking authorization and transfer from the
   asset provider of A, which is conceptually a separate service from
   identity.  Since the avatar of A1 may be wearing or carrying items from many
   worlds, this operation is carried out by B for each asset provider
   involved.  At the end of this process, everyone else in B can also see A1's
   instantiated assets.

The above 3 things have to happen whatever the world architecture, otherwise
the real goal of interop *from the point of view of the user* has not been
achieved:  *to create a mashup in which the user's avatar is now in a new
world setting and visible to new people*.

This is equally applicable to architectures in which only the world servers
communicate among themselves.  "Teleport" just means changing the presence
from one shared space to another, and the only difference is in the words
used to describe the operation.  *Identity transfer* is still required or
there is no interop, although visible names may change of course.  *Presence
transfer* is still required otherwise an avatar would not be able to appear
in new environments.  *Asset transfer* is still required otherwise there
will be no new assets visible when avatars appear in new places.

All of these things are required for full-featured 3D world interop (2D
worlds and Limited Capability Clients require only a subset).  Where is the
problem with handling these requirements using server-server communications
alone?

Please be specific, post-BoF.

Morgaine.

On Wed, Mar 25, 2009 at 5:17 PM, Jon Watte <[email-masked]> wrote:

>  Morgaine wrote:
>
> Splitting the work of MMOX into various implementation-oriented groups
> would be an excellent way of making progress, but it carries a *severe
> danger*:  *it could create several non-interoperating walled gardens*, if
> the groups work independently without a common view and purpose.
>
>
> One problem is that we don't even agree on what interop should be, and what
> adds value to the growing global interconnected metaverse. I think this is
> compounded by the fact that the group started out as a proposal to
> standardize work done in the Second Life breed of virtual worlds, without
> any particular consideration for the significant architectural differences
> to almost all other platforms.
> In fact, *we don't even have representatives from most platforms in this
> group*, which I think is a real shame, and a problem if we want broadly
> implemented interoperability. We may do well by trying some more outreach.
>
>
> *For the non-virtual-world-savvy on the list*: If I were to make a cell
> The problem we want to solve is that I am on the Sprint network, and my mom
> is on the AT&T network, and I want to call my mom.
>
> virtual worlds to what GSM, or D-AMPS, or CDMA, or UMTS is for cell phones.
>
> The LESS proposal, in this analogy, wants to standardize how carriers talk
> to other carriers. Let's say it is somewhat similar in function for virtual
> worlds to what SS7, H.320, or SIP plus codecs are for phone networks.
>
> The interoperability provided by the OGP ("GSM") model is that I can take
> one phone, and connect it to different carriers. If I want to talk to my
> mom, I disconnect from Sprint, and re-connect to AT&T, and I can talk to
> mom.
>
> The interoperability provided by the LESS model does make it so that I can
> call my mom through my existing carrier. However, it decides to leave the
> handset standard (GSM vs CDMA) outside of interoperability, both because
> building handset/base station suites is really expensive, there are already
> lots of such stacks already available from different providers, and because
> the basic functionality (talking across different carriers) is actually a
> more enabling technology than re-connecting your phone to a different
> carrier, while simultaneously being cheaper to implement. There is, however,
> nothing remotely as well accepted in virtual worlds as GSM, UMTS or even
> CDMA are in the cell phone world. There is also nothing remotely as well
> accepted as SS7 or H.320 or SIP.
>
>
> becomes a hinderance rather than a help, but I do think it does help focus
> the discussion about charter: *Does it really make sense to discuss the
> "GSM/D-AMPS/CDMA/UMTS" question in the same working group as the
> "SS7/H.320/SIP+codecs" question?*
>
>
>
> OSIDs), then we could probably find common ground -- but then, why not use
> OSID, or one of the dozen or so similar service broker technologies already
> available? Or, in fact, why not just expose a XML-RPC or SOAP interface that
> returns an XML blob of defined schema that lists named/typed services as
> URLs, and we're done?
>
> Once you start talking about higher-level functions like "OGP Teleport" or
> having a client/viewer connect to simulation services, we immediately run
> into significant political and technical challenges, where I don't think
> there is actually a possibility of "one model fits all" or even "one model
> fits most."
>
>
> Sincerely,
>
> jw
>
>

---

From: Jon Watte <[email-masked]>
Date: Thu, 26 Mar 2009 10:51:03 -0700

Morgaine wrote:
> The above 3 things have to happen whatever the world architecture, 
> otherwise the real goal of interop /from the point of view of the 
> user/ has not been achieved:  *to create a mashup in which the user's 
> avatar is now in a new world setting and visible to new people*.
>

I agree, and if the OGP model was designed to solve those problems in an 
otherwise context-free manner, it might be a good starting point for a 
standard that many virtual worlds could adopt. But then, why define 
something new, when extending something like XRDS seems simpler and more 
straightforward, in the larger scope of existing standards re-use?

> Please be specific, post-BoF.

If you could articulate what you specifically mean by the statement 
"post-BoF" I believe I could adjust the discussion to match.
I don't believe any particular approach was decided in the meeting -- 
the biggest argument was one of "why don't we define what problem we're 
going to solve, for whom," but even that didn't get full consensus. If 
you believe the meeting actually decided on a specific course of action, 
I would be interested in reading about that.

Something I want to avoid is defining a standard that doesn't matter to 
most virtual world technologies.

For example, XMPP is a well-defined, open standard for IM-style text 
chat. However, the adoption and use of XMPP, even though Google Talk may 
use it, is still probably below 1% of the total IM market, compared to 
AIM, Yahoo and MSN (plus enterprise-specific solutions). I don't think a 
standard is a success until it is actually adopted and implemented by a 
majority of actors in the market, no matter how flexible, useful or open 
it is. Thus, I think concerns about the bang-for-buck for the potential 
implementors is crucial, because that drives adoption, which drives success.

Which leads us back to the problem that we very poor representation of 
many of the technologies in the market in this group. Personally, I have 
spent significant time analyzing many of the different technologies for 
commonality and differences (Darkstar, Croquet, Multiverse, Quake, 
Half-life, Unreal, EverQuest, WoW, etc). However, in the end, even if I 
formulate a proposal by synthesizing all of that analysis, I can't speak 
for any of the other actors, and if they don't care and don't adopt, 
then whatever standard is likely to be about as relevant as XMPP is to 
AIM, MSN and Yahoo. That would be bad.

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Fri, 27 Mar 2009 05:23:00 +0000

On Thu, Mar 26, 2009 at 5:51 PM, Jon Watte <[email-masked]> wrote:

> "post-BoF" I believe I could adjust the discussion to match.

Thank you. :-)

I'm hoping that the BoF marked a turning point in MMOX discussions.

In the months leading up to the BoF, I think it's fair to say that the same
invariant positions were re-stated repeatedly, over and over, culminating
with those positions being presented formally (and very nicely and
effectively) at the BoF.

I would like to think that post-BoF, now that everyone has pinned their
colours to the various corners of the ring, everyone will instead gather in
the centre and help in the job of problem analysis, dealing with issues one
at a time in an engineering manner.

It is only after we have dismantled the problem space into its many
necessary components that we'll be able to start synthesizing solutions out
of them that can lead to useful interop for all.  Restating one's allegiance
to a corner (a single approach) will not accomplish that, and doing so *ad
infinitum* just ensures total failure.

This applies to all of us.

I'm seeking that we narrow the scope of discussions from huge monolithic
corner positions to individual components of the problem space, as we did to
agree on *teleport*.  One step at a time we can converge on engineering
solutions, whereas the corner positions are forever irreconcilable.

Morgaine.

On Thu, Mar 26, 2009 at 5:51 PM, Jon Watte <[email-masked]> wrote:

>> otherwise the real goal of interop /from the point of view of the user/ has
>> not been achieved:  *to create a mashup in which the user's avatar is now in
>> a new world setting and visible to new people*.
>>
>>
> I don't believe any particular approach was decided in the meeting -- the
> biggest argument was one of "why don't we define what problem we're going to
> solve, for whom," but even that didn't get full consensus. If you believe
> the meeting actually decided on a specific course of action, I would be
> interested in reading about that.
>
> For example, XMPP is a well-defined, open standard for IM-style text chat.
> However, the adoption and use of XMPP, even though Google Talk may use it,
> is still probably below 1% of the total IM market, compared to AIM, Yahoo
> and MSN (plus enterprise-specific solutions). I don't think a standard is a
> success until it is actually adopted and implemented by a majority of actors
> in the market, no matter how flexible, useful or open it is. Thus, I think
> concerns about the bang-for-buck for the potential implementors is crucial,
> because that drives adoption, which drives success.
>
> Which leads us back to the problem that we very poor representation of many
> of the technologies in the market in this group. Personally, I have spent
> significant time analyzing many of the different technologies for
> formulate a proposal by synthesizing all of that analysis, I can't speak for
> any of the other actors, and if they don't care and don't adopt, then
> whatever standard is likely to be about as relevant as XMPP is to AIM, MSN
> and Yahoo. That would be bad.
>
> Sincerely,
>
> jw
>
>

---

From: Morgaine <[email-masked]>
Date: Fri, 27 Mar 2009 06:04:12 +0000

On Thu, Mar 26, 2009 at 5:51 PM, Jon Watte <[email-masked]> wrote:

>> otherwise the real goal of interop *from the point of view of the user*has not been achieved:
>> *to create a mashup in which the user's avatar is now in a new world
>> setting and visible to new people*.
>>
>>
> standard that many virtual worlds could adopt.

I am very happy to see that, after dissecting what teleport actually means,
you found it easy to agree that its component parts are applicable to
everyone.  I hope that teleport as a concept is no longer a barrier.  That's
how we can make progress, one issue at a time.  No running back to the
corner of the ring.

Re OGP ... Linden goals were, by their own very frank and open admission,
originally focused on a somewhat narrow goal.  I hope that it's clear from
their BoF presentations that that view is history:  they have embraced a
broader future.  I was enormously impressed.  I am not impressed by
repetition of inflexible corner positions.

The fact that OGP is barely 10% defined (and only as an initial draft)
should make it plain that nothing substantial is hardwired into OGP:  it's
really just a rather nice framework for decoupled REST services.  That
framework can be used for pretty much every architecture under the VW sun,
including c-s, s-s, and c-c approaches.

While the original idea came from Linden Lab, that is no stumbling block:
every idea has to originate somewhere.  OGP has the great merit of being
all-embracing as a concept, once you see that certain ideas like *teleport*and
*client endpoint* are actually much more flexible than they might at first
appear.  *Client endpoints* on an OLIVE server could "easily" allow Second
Life clients to interoperate with OLIVE clients.

Everything is possible in this space, it just needs flexibility from
everybody concerned.  The flexibility of OGP is not an issue at all, since
it's mostly undefined. ;-)  [This is no joke.]

PS.  I have said it before but there is no harm in saying it again:  I have
no vested interest and certainly no fanboyism in OGP, nor in SL despite
living virtually in SL.  After a year and a half of talking and arguing
heatedly about it in AWG, I do see that OGP has the *potential* to deliver
interop between many totally diverse worlds, not just those of the SL
ecosystem.  We will have to put our thinking caps on to achieve that though.

I think we can do it.

Morgaine.

---

From: Charles Krinke <[email-masked]>
Date: Fri, 27 Mar 2009 06:05:43 -0800

Well said, Morgaine. It has been hurting my heart for a month to read these
posts where some folks are just repeating their positions over and over.
This does not make any progress at all. It really does not matter what our
positions are and is completely distracting.

What does matter, however, is that we find, one at a time, those areas where
we can interop between existing virtual worlds implementations, and teleport
is a good one, along with identity.

Charles Krinke
OpenSim Core Developer
OSGrid Director

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

> all-embracing as a concept, once you see that certain ideas like *teleport
> * and *client endpoint* are actually much more flexible than they might at
> first appear.  *Client endpoints* on an OLIVE server could "easily" allow
> Second Life clients to interoperate with OLIVE clients.
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Jon Watte <[email-masked]>
Date: Fri, 27 Mar 2009 09:42:28 -0700

Morgaine wrote:
> I would like to think that post-BoF, now that everyone has pinned 
> their colours to the various corners of the ring, everyone will 
> instead gather in the centre and help in the job of problem analysis, 
> dealing with issues one at a time in an engineering manner.

That sounds fine.

When I learned engineering (a long time ago, admittedly), we always 
started with requirements, which in software engineering often ends up 
being use cases. I believe that the use case closest to the "teleport" 
feature that we're discussing is use case 1 from the list of use cases I 
previously posted, but that fell off the agenda at the BoF.

Is it reasonable to start with that use case as a basis for requirements?

(For reference, the link is: 
http://tools.ietf.org/html/draft-jwatte-mmox-use-cases-00 )

Also, if this work is going to be driven by representatives from Second 
Life, Open Sim, XR and OLIVE only, then we have two problems wrt. 
generally applicable standards:

1) Only two technology bases are covered -- what we do is not very 
likely to be applicable to any other technology, unless we do a lot of 
research on what the technology of other people is, too.
2) There's a very skewed ratio of participants between the two 
technology bases.

Do we want to solve or mitigate those problem, and if so, how?

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Fri, 27 Mar 2009 10:00:13 -0700

Morgaine wrote:
>
> While the original idea came from Linden Lab, that is no stumbling 
> block:  every idea has to originate somewhere.  OGP has the great 
> merit of being all-embracing as a concept, once you see that certain 
> ideas like /teleport/ and /client endpoint/ are actually much more 
> flexible than they might at first appear.  /Client endpoints/ on an 
> OLIVE server could "easily" allow Second Life clients to interoperate 
> with OLIVE clients.
>

So, now for the less rosy situation:

Even with the definition of the three services that you enumerated:

   1. /Identity transfer is negotiated to provide continuity of identity
      across the change of environment./
   2. /Presence transfer is negotiated to discontinue presence in world
      A and commence presence in world B./
   3. /Asset transfer is negociated in the A->B direction to allow
      assets from world A to appear in world B, or to deny the transfer
      where appropriate./

There is no actual interoperability achieved if those are standardized. 
For a user of any other virtual world platform than SecondLife/OpenSim, 
these services would give them zero value. Thus, for virtual world 
platforms other than SecondLife/OpenSim, there is close to zero 
incentive to implement these services. And, because there is close to 
zero incentive to implement these services, there is close to zero 
incentive to participate in the standardization effort.

I think that this is a problem. I'd like to understand how others feel 
about the same thing. I could see a number of different standpoints:

1. "It doesn't matter if some platforms won't participate in this model; 
we only care about the ones who do." (This leads to the self-selecting 
clique problem, which leads to isolated islands of separate 
interoperability)
2. "We need reasonably broad adoption for a standard to matter, so we 
have to change the problem statement until there is value in the 
standard for a reasonably broad set of platforms." (This leads to the 
"re-define what we are doing" problem)
3. "If we start here, then we can build on that in the future, until 
such time as more platforms will get benefits from the standard." (This 
leads to the problem of building things intended to be used by others 
without any input on what their constraints are)

I currently am of opinion 2. I perceived the initial standpoint by the 
AWG contribution as 1. If you are of opinion 3, how are you going to get 
the requirements right?

I think that it's important that everyone who will contribute to this 
work actually clarifies what their assumptions are in this regard (as 
well as the use case/requirements regard).

Sincerely,

jw

---

From: "James Kempf" <[email-masked]>
Date: Fri, 27 Mar 2009 15:05:42 -0500

Hi Jon,

I was at the BOF on Tues. You probably don't know me but I worked in
IETF for around 10 years, recently I haven't been attending IETF but I'd
like to offer my opinion on your email and the prospect of any work on a
virtual worlds interoperability standard succeeding in IETF. I also have
had some experience with virtual worlds, I did some work with Second
Life shortly after the client went OpenSource, and I'm involved with a
small group in Silicon Valley (FountainBlue) that is trying to organize
events to foster networking among entrepenurs, investors, and
technologists interested in virtual worlds.

My opinion is that any such effort will take years, and it will by and
large be out of date from a market standpoint by the time it is
completed. In other words, by any reasonable definition of success, it
will fail. Your email below is an initial indication of why.

Basically your company (OLIVE?)and Second Life/OpenSIM are competitors.
There are many others out there that compete with Second Life/OpenSIM.
In situations like that, where there is one company or group of
companies that want a standard and no basic agreement with other
competitors for the need of interoperability to their business,
standardization efforts in IETF invariably drag on, since the IETF rules
that everybody gets their say allow competitors whose technology is not
up for standardiztion to disrupt the proceedings. This is not a question
of morality or anything, it is just good business sense, and everybody
does it. Nobody wants a competitor's technology to get the "Good
Housekeeping Seal of Approval" that a standard confers. 

An example of the exact opposite - where competitors have collaborated
to achieve a successful standard - is MPLS, which was described last
night at the technical plenary. But MPLS was addressing an industry that
already had maybe 20 years of technical/business development, where the
business roles of service providers, vendors, and customers were more
clearly defined. Virtual worlds are considerably less mature (even given
the abortive work in the early/mid 90's on dedicated VR systems). So the
competitive posturing among VW companies is naturally more intense.

My opinion on what you guys should do is the following:

1) The SL/OpenSIM/IBM people ought to go off and form an industry
consortium and recruit some experienced protocol and distributed systems
engineers to help them design OGP. IBM certainly has many such folks
working for with experience in IETF, protocol engineering, and
distributed systems design. Once they have their interoperability
protocol done, they can publish it as an "informational RFC" if they
want, this is something any individual or group can do and it does not
constitute an "Internet Standard". 
2) You and anyone else in the OLIVE(?) community should get together and
work on the kind of interoperability protocol that addresses the system
architecture and business ecosystem that you want to develop. You, too,
can publish your work as an informational RFC.
<This will allow both you and the SL/OpenSIM folks to focus on
interesting technical issues and the particulars of your individual
systems, rather than fighting each other on IETF mailing lists and
generating carbon emissions flying to meetings that don't really decide
anything>
3) By the time these parallel tracks are complete, it will be 3-5 years
on (instead of 7-9, if that, which an IETF standardization effort would
take) and the technology and business of virtual worlds will be much
further along. At that time, there might be more clarity whether a
commonality of business interests exists between multiple groups of
virtual worlds which would allow them to supress their competitive
postures and collaborate on a Internet-wide standard.

Finally, putting on my volunteer hat, my feeling is that there are some
serious, unresolved technical challenges involved in making VW a
mass-market product. My feeling is that interoperability between VWs is
only peripherally important. Having some kind of tacit agreement within
the VW technical community about what those issues are, having academics
working on research solutions, and having companies, too, implementing
and deploying competing solutions which could prove themselves in the
marketplace would be much more productive than fighting about an
interoperability standard.

			jak

PS: FountainBlue is sponsoring a virtual worlds event in Sept. at which
companies can come and put up tables with information about what they
are doing. If anyone is interested in participating, please send me
email off-list.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jon Watte
> Sent: Friday, March 27, 2009 10:00 AM
> To: Morgaine
> Cc: MMOX-IETF

---

From: Morgaine <[email-masked]>
Date: Fri, 27 Mar 2009 21:03:43 +0000

That's a very well reasoned post, James.

What do other people think about this?

Shall we go back to our individual small-scale interop projects, see what
develops, and publish Informational RFCs based on actual working interop?
And then in 5-10 years' time, after one or more de facto standards have
emerged, come back older and wiser and try for an Internet Standard to unify
the segmented metaverse?

James is very right that it would take many years of effort to do it now,
and also right that our work could be obsolete before it even nears
completion.  I'm sure that nobody relishes the prospect of wasting years of
arduous effort for nothing.

For my part, I believe that doing *something* now has great practical value,
even if only for the incidental side effect that it pushes the envelope of
what virtual worlds can handle and achieve.  But James' advice is worth
noting.  The price may be too high at this time.

Morgaine.

---

From: Charles Krinke <[email-masked]>
Date: Fri, 27 Mar 2009 14:52:19 -0800

OpenSim *is* an interop project. It started out as an interoperability
project with SecondLife and has gained a significant amount of momentum over
the last two years. Contrary to the mis-conceptions sent to this list,
OpenSim is not a SecondLife clone, but rather an interoperable simulator.

To date, the AWG (Architecture Working Group) of SecondLife has implemented
this OGP and demonstrated interoperability with both OpenSim standalone
regions and regions on one or more OpenSim grids, such as OSGrid.

HyperGrid is also an implemented interop protocol and allows
interoperability between grids using OpenSim and is deployed and in daily
use.

There is also MXP, another interoperability protocol, recently announced and
is now implemented in OpenSim.

So, OpenSim is *significantly* about interoperability and will encourage
contributions of source for the benefit of all. And I hope to see
contributions of implementations of other notions of interop as time goes on
and less posturing about how a simulation should or should not be designed.
The simulations *are* designed, implemented and deployed.

In order to move forward, I believe we need to concentrate on how to
interoperate between the existing implemented and deployed systems and get
past whether one architecture is better or worse then another.

Personally, I look at this group and hope we can get past all this posturing
and more into *how* interoperate more completely between various virtual
worlds.

If SecondLife happens to be leading this charge on this group, fine. If
someone else wants to show an implemented and functional interop protocol
that folks can test and use, fine.

Lets just move forward, not sidewise. Otherwise, this will be a waste of a
number of folks time, and that would be a great shame.

Charles Krinke
OpenSim Core Developer
OSGrid Director

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

> For my part, I believe that doing *something* now has great practical
> value, even if only for the incidental side effect that it pushes the
> envelope of what virtual worlds can handle and achieve.  But James' advice
> is worth noting.  The price may be too high at this time.
>
> Morgaine.
>
>
>
>
>
>
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Morgaine <[email-masked]>
Date: Sat, 28 Mar 2009 01:46:45 +0000

I agree entirely Charles.  I see Opensim moving forward with various
different forms of interop at a very fast rate and without requiring any
kind of IETF standardization.

This is why I think that James Kempf's cautionary post needs to be
considered:  perhaps we should follow Opensim's lead and work on interop
directly and practically as you are doing, instead of potentially wasting
years of our lives developing a standard that could be made obsolete by
practical work such as yours even before we are finished.

It needs to be considered so that if we decide to reject the advice, we do
so with our eyes wide open and fully aware of the odds we face.

Your practical approach to interop may be better use of our time, so James'
advice to work out interop practically before seeking IETF standardization
deserves some thought.

For me, I think it hinges on whether we can get people in MMOX to cooperate
on finding common ground.  It has been an uphill struggle so far.  I will
spend more time on it, but there is a limit.

Morgaine.

PS. Your mention of OGP interop in Opensim is greatly overstated though.
Opensim *does* implement what there is of OGP, but there is extremely
little, and the little there is (login and teleport) works in one direction
only from Second Life.

On Fri, Mar 27, 2009 at 10:52 PM, Charles Krinke
<[email-masked]>wrote:

> There is also MXP, another interoperability protocol, recently announced
> and is now implemented in OpenSim.
>
> Personally, I look at this group and hope we can get past all this
> posturing and more into *how* interoperate more completely between various
> virtual worlds.
>

---

From: Charles Krinke <[email-masked]>
Date: Fri, 27 Mar 2009 18:10:37 -0800

Dear Morgaine:

Oh, I am definitely familiar with the limitations of OGP currently, but am
bending over backwards to be fair. I respect and admire the Lindens, as I do
most on this list.

I truly do not know what form interop will eventually settle down with. Lots
of folks tell me what the future is going to look like for virtual worlds,
and as someone that is right in the middle of a couple of interesting and
dynamic parts, I am here to say that "No One Knows What The Future Will Be
Like".

As I expressed to the Lindens a while back, I see interop being more of a
"passport control metaphor", sort of like the gate at an airport with a
flight (or teleport) between sovereign countries. The metaphor has a number
of implications, some technical such as the "how", some political such as
"the rules in the new country", some practical such as "what may be carried
in baggage", that sort of thing.

I do hope LESS is implemented. I hope a number of ideas are implemented.
Then the community will decide which is the best by virtue of using these
protocols.

Personally, I see a lot of activity in HyperGrid and find it useful,
interesting, and fascinating. This paradigm has captured a number of hearts.
The others have more or less users right now.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Fri, Mar 27, 2009 at 5:46 PM, Morgaine <[email-masked]>wrote:

> On Fri, Mar 27, 2009 at 10:52 PM, Charles Krinke <[email-masked]
> > wrote:
>
>> To date, the AWG (Architecture Working Group) of SecondLife has
>> implemented this OGP and demonstrated interoperability with both OpenSim
>> standalone regions and regions on one or more OpenSim grids, such as OSGrid.
>>

--

---

From: Morgaine <[email-masked]>
Date: Sat, 28 Mar 2009 02:40:24 +0000

Charles, thanks for your reply, but what are your thoughts on the main
subject in my post, namely James Kempf's advice?   Should we work on
practical interop as you are doing, or spend some years creating an Internet
Standard which may be obsoleted by practical work such as yours before we
are even finished?

It's a difficult question, but it should not be avoided. ;-)

Perhaps we can do both at the same time and avoid becoming obsolete by being
agile.  Do you think that MMOX would be able to work on a protocol and then
change direction in response to de facto standards emerging from successful
interop experiments by Opensim and others?

Morgaine.

On Sat, Mar 28, 2009 at 2:10 AM, Charles Krinke <[email-masked]>wrote:

> I truly do not know what form interop will eventually settle down with.
> Lots of folks tell me what the future is going to look like for virtual
> worlds, and as someone that is right in the middle of a couple of
> interesting and dynamic parts, I am here to say that "No One Knows What The
> Future Will Be Like".
>
>> Your practical approach to interop may be better use of our time, so
>> James' advice to work out interop practically before seeking IETF
>> standardization deserves some thought.
>>
>> For me, I think it hinges on whether we can get people in MMOX to
>> cooperate on finding common ground.  It has been an uphill struggle so far.
>> I will spend more time on it, but there is a limit.
>>
>>
>> Morgaine.
>>
>> On Fri, Mar 27, 2009 at 10:52 PM, Charles Krinke <
>> [email-masked]> wrote:
>>
>>> Lets just move forward, not sidewise. Otherwise, this will be a waste of
>>> a number of folks time, and that would be a great shame.
>>>
>>> Charles Krinke
>>> OpenSim Core Developer
>>> OSGrid Director
>>>
>>>> Shall we go back to our individual small-scale interop projects, see
>>>> what develops, and publish Informational RFCs based on actual working
>>>> interop?  And then in 5-10 years' time, after one or more de facto standards
>>>> have emerged, come back older and wiser and try for an Internet Standard to
>>>> unify the segmented metaverse?
>>>>
>>>> James is very right that it would take many years of effort to do it
>>>> now, and also right that our work could be obsolete before it even nears

---

From: Charles Krinke <[email-masked]>
Date: Fri, 27 Mar 2009 18:52:39 -0800

Well, I went back and read James post a second time and at this point my
opinion would be "do both". Personally, I am on this list in order to try to
help add a little sanity now and again. I do have to admit my heart is in
OpenSim, but there are one or two things we seem to be doing right.

One thing that is right is to encourage multiple implementations of any
modules. That applies to physics, scripting, interop and others. Some
modules end up with a significant following and blossom, others wither into
obscurity.

As I look at the MMOX efforts, and since I know many of you, I also know
that all of us have strong feelings that what we are working on is the right
answer. But,... the right answer will still be determined by the folks that
use the technology.

I think back to the VHS vs Beta videotape time. VHS, an inferior technology
won over the superior technology. And, lots of folks argued long and hard
for years about the deficiencies of VHS, but in the end, consumers choose
which technology blossomed and which withered. Maybe a similar thing will
happen with differing interop protocols. I truly dont know.

The ideas of server-server communication have merit, as do the ideas of
client-server communication as it applies to interop.

I think Dave Crocker's comment that communication between subgroups, should
this group decide to form subgroups will be the ultimate key to success or
failure.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Fri, Mar 27, 2009 at 6:40 PM, Morgaine <[email-masked]>wrote:

> Perhaps we can do both at the same time and avoid becoming obsolete by
> being agile.  Do you think that MMOX would be able to work on a protocol and
> then change direction in response to de facto standards emerging from
> successful interop experiments by Opensim and others?
>
>
> Morgaine.
>
>
>
>
>
>
>
>> On Fri, Mar 27, 2009 at 5:46 PM, Morgaine <[email-masked]
>> > wrote:
>>
>>> It needs to be considered so that if we decide to reject the advice, we
>>> do so with our eyes wide open and fully aware of the odds we face.
>>>
>>>>> On Fri, Mar 27, 2009 at 8:05 PM, James Kempf <[email-masked]
>>>>> > wrote:
>>>>>
>>>>>> Hi Jon,
>>>>>>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Morgaine <[email-masked]>
Date: Sat, 28 Mar 2009 03:47:05 +0000

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

>  3. /Asset transfer is negociated in the A->B direction to allow assets
> appropriate./
> There is no actual interoperability achieved if those are standardized. *For
> a user of any other virtual world platform than SecondLife/OpenSim, these
> services would give them zero value.*
>

I don't understand your last sentence at all, and therefore the remainder of
your post was lost on me.  The above 3 points apply identically to every
virtual world under the sun, and you agreed to that
previously<http://www.ietf.org/mail-archive/web/mmox/current/msg01216.html>
.

Morgaine.

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

>> all-embracing as a concept, once you see that certain ideas like /teleport/
>> and /client endpoint/ are actually much more flexible than they might at
>> first appear.  /Client endpoints/ on an OLIVE server could "easily" allow
> There is no actual interoperability achieved if those are standardized. For
> a user of any other virtual world platform than SecondLife/OpenSim, these
> services would give them zero value. Thus, for virtual world platforms other
> than SecondLife/OpenSim, there is close to zero incentive to implement these
> services. And, because there is close to zero incentive to implement these
> services, there is close to zero incentive to participate in the
> standardization effort.
>
> 1. "It doesn't matter if some platforms won't participate in this model; we
> only care about the ones who do." (This leads to the self-selecting clique
> problem, which leads to isolated islands of separate interoperability)
> 2. "We need reasonably broad adoption for a standard to matter, so we have
> to change the problem statement until there is value in the standard for a
> reasonably broad set of platforms." (This leads to the "re-define what we
> are doing" problem)
> 3. "If we start here, then we can build on that in the future, until such
> time as more platforms will get benefits from the standard." (This leads to
> the problem of building things intended to be used by others without any
> input on what their constraints are)
>
> I currently am of opinion 2. I perceived the initial standpoint by the AWG
> contribution as 1. If you are of opinion 3, how are you going to get the
> requirements right?
>
> I think that it's important that everyone who will contribute to this work
> actually clarifies what their assumptions are in this regard (as well as the
> use case/requirements regard).
>
> Sincerely,
>
> jw
>
>

---

From: Jon Watte <[email-masked]>
Date: Fri, 27 Mar 2009 22:53:55 -0700

Charles Krinke wrote:
> I think back to the VHS vs Beta videotape time. VHS, an inferior 
> technology won over the superior technology. And, lots of folks argued 
> long and hard for years about the deficiencies of VHS, but in the end, 
> consumers choose which technology blossomed and which withered. Maybe 
> a similar thing will happen with differing interop protocols. I truly 
> dont know.

And, to be fair to Beta, it evolved and ended up being the format of 
choice for professional production all the way until digital replaced it.
(A flashback to my sordid past)

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Fri, 27 Mar 2009 23:16:26 -0700

Jon wrote:

    There is no actual interoperability achieved if those are
    standardized. /For a user of any other virtual world platform than
    SecondLife/OpenSim, these services would give them zero value./

Morgaine wrote:
> I don't understand your last sentence at all, and therefore the 
> remainder of your post was lost on me.  The above 3 points apply 
> identically to every virtual world under the sun, and you agreed to 
> that previously 
> <http://www.ietf.org/mail-archive/web/mmox/current/msg01216.html>.

Yes, they are necessary, but not sufficient, to provide any kind of 
useful interop. I thought I made that pretty clear, but I assume in good 
faith that you're somehow not seeing it. Let's try again. The logic is 
simple economics:

Because they are not sufficient in themselves, there is no incentive for 
vendors who don't have all the other pieces also in place, to implement 
those three, because it's costly work with no actual benefit. (Not even 
Open Source engineering is free, because there is always opportunity 
cost for the project in question.)

Thus, even if those things were standardized, there would be no 
incentive for Multiverse.net to implement them, or for Proton Media, or 
for Qwaq, or for Habbo Hotel, or for Forterra. There would only be 
incentive to implement them for Open Sim and Second Life, because they 
already have enough interoperability (thanks to the goals of Open Sim 
itself). Think about it -- if those three were standardized, then the 
proposal to most virtual world vendors in the world would be:
"Here are three things you can implement. Once you have implemented 
them, there is no additional visible capability for your platform or 
your users, unless you also implement a bunch of other, un-standardized 
things that have to do with simulation and state replication."
If you had a virtual world platform, and you could direct your engineers 
to spend time on that, or spend time on something that actually 
delivered a feature that your end users would see and appreciate, which 
would you choose?

So, if there was a standard that standardized those three things, but 
nothing else, then the only platforms that would adopt those standards 
would be the ones that already proposed OGP out of the Second Life AWG, 
because they already have interop in the other parts. The IETF 
standardization effort would then be pretty much a big no-op (compared 
to staying in the Second Life specific AWG), assuming that the goal of 
going to the IETF to provide standardization that is adopted by a 
broader group.

It may be that I'm missing something. It may be that the users of Areae, 
or CokeWorld, or Avatar Reality would actually gain something tangible 
from those worlds implementing the three services in question, and I 
just haven't been able to see the use case that would be enabled. If 
that is the case, perhaps you could help me by describing a detailed use 
case of what is actually being enabled by standardizing only those three 
services.

I think that is about as clearly and to the point I can describe the 
problem.

Let me know if there is something else I can do to put this point in a 
different light, because I think it is important, and speaks to the 
question about whether we even should try to do something the IETF way. 
If we're not willing to sit down and hammer out something that, if 
implemented, would provide value to the users of most virtual world 
platforms without relying on large amounts of other, out-of-band 
engineering to go with it, then whatever we do will be in vain.

Sincerely,

jw

---

From: Charles Krinke <[email-masked]>
Date: Sat, 28 Mar 2009 08:20:28 -0800

I would think that we would get further by concentrating on what the
technical details of login sequences are for more virtual worlds then we
currently address.

Perhaps Jon could help us out by describing the logon sequence of Fortrerra.
Additionally, I believe there are Croquet users on this list, perhaps they
could describe the logon sequence of Croquet. And I would suggest a similar
thing for any other technically knowledgeable virtual world person on this
list.

It just seems to me that whether virtual world A is a better or worse
architecture then virtual world B is not moving us forward. So, lets try to
concentrate on the similarities and find ways to move forward.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Fri, Mar 27, 2009 at 10:16 PM, Jon Watte <[email-masked]> wrote:

>> I don't understand your last sentence at all, and therefore the remainder
>> of your post was lost on me.  The above 3 points apply identically to every
>> virtual world under the sun, and you agreed to that previously <
>> http://www.ietf.org/mail-archive/web/mmox/current/msg01216.html>.
>>
>
> Yes, they are necessary, but not sufficient, to provide any kind of useful
> interop. I thought I made that pretty clear, but I assume in good faith that
> you're somehow not seeing it. Let's try again. The logic is simple
> economics:
>
> those three, because it's costly work with no actual benefit. (Not even Open
> Source engineering is free, because there is always opportunity cost for the
> project in question.)
>
> Thus, even if those things were standardized, there would be no incentive
> for Multiverse.net to implement them, or for Proton Media, or for Qwaq, or
> for Habbo Hotel, or for Forterra. There would only be incentive to implement
> them for Open Sim and Second Life, because they already have enough
> interoperability (thanks to the goals of Open Sim itself). Think about it --
> if those three were standardized, then the proposal to most virtual world
> vendors in the world would be:
> "Here are three things you can implement. Once you have implemented them,
> there is no additional visible capability for your platform or your users,
> unless you also implement a bunch of other, un-standardized things that have
> to do with simulation and state replication."
> If you had a virtual world platform, and you could direct your engineers to
> spend time on that, or spend time on something that actually delivered a
> feature that your end users would see and appreciate, which would you
> choose?
>
> nothing else, then the only platforms that would adopt those standards would
> be the ones that already proposed OGP out of the Second Life AWG, because
> they already have interop in the other parts. The IETF standardization
> effort would then be pretty much a big no-op (compared to staying in the
> Second Life specific AWG), assuming that the goal of going to the IETF to
> provide standardization that is adopted by a broader group.
>
> It may be that I'm missing something. It may be that the users of Areae, or
> CokeWorld, or Avatar Reality would actually gain something tangible from
> those worlds implementing the three services in question, and I just haven't
> been able to see the use case that would be enabled. If that is the case,
> perhaps you could help me by describing a detailed use case of what is
> actually being enabled by standardizing only those three services.
>
> different light, because I think it is important, and speaks to the question
> about whether we even should try to do something the IETF way. If we're not
> willing to sit down and hammer out something that, if implemented, would
> provide value to the users of most virtual world platforms without relying
> on large amounts of other, out-of-band engineering to go with it, then
> whatever we do will be in vain.
>
>
> Sincerely,
>
> jw
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Jon Watte <[email-masked]>
Date: Sat, 28 Mar 2009 10:18:20 -0700

Charles Krinke wrote:
> architecture then virtual world B is not moving us forward. So, lets 
> try to concentrate on the similarities and find ways to move forward.

I don't think anyone is proposing that any particular virtual world is 
better or worse. It's a question of impedance matching, not capability.

The question is: would you want to work on a standard, if you knew that 
the standard would only be adopted by 3 out of 50 virtual world 
platforms in the world?

For a standard to be adopted by a platform, that standard has to provide 
real and concrete benefits to the users of that platform. (If the 
platform is something done for the fun of it, then the concrete benefit 
might be the enjoyment of implementing the standard, but most platform 
vendors are not in that position).

I have yet to see a use case that shows that implementing the three 
points that were isolated would provide any real and concrete benefit to 
users of worlds other than Open Sim / Second Life. Assuming there is 
such a benefit, then coming up with a use case tied to the technology 
can't be that hard, can it? And, if it is, then what is the benefit of 
working on that standard?

Or are you suggesting that vendors should implement a standard on faith, 
as an investment, that there will, sometime in the future, maybe be some 
concrete benefit to the users?

I don't want to talk about technology until I undestand what purpose 
that technology serves the users of that technology.

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Sat, 28 Mar 2009 17:48:56 +0000

On Sat, Mar 28, 2009 at 6:16 AM, Jon Watte <[email-masked]> wrote:

> you're somehow not seeing it.

Of course they're not sufficient!  They're not meant to be.  We're in the
process of breaking down the problem space, and each component of that space
is in itself not sufficient.  Putting all the required components together
later will yield a sufficient solution.  That's the engineering process in
action.

This is why continually retreating back to the monolithic corner positions
is a disaster for our work --- it derails all the engineering progress we
have achieved so far in problem decomposition.  We *know* those positions
already, from pre-BoF, they don't need to be restated.

Having sorted out *teleport* and shown it not to be an area of
incompatibility, we can now proceed to the next area of difficulty.  Moving
one step at a time we can solve this problem.  Just proclaiming that each
small step does not solve the end goal achieves nothing and sets back the
analysis.

Instead, please make sure that all the component parts required by your use
cases are in our problem space, and then we can handle the issues one at a
time.

Morgaine.

---

From: Morgaine <[email-masked]>
Date: Sat, 28 Mar 2009 17:57:09 +0000

On Sat, Mar 28, 2009 at 5:18 PM, Jon Watte <[email-masked]> wrote:

>
> The question is: would you want to work on a standard, if you knew that the
> standard would only be adopted by 3 out of 50 virtual world platforms in the
> world?
>
>
We're not working on a standard for 3/50.  Instead, we're placing the
requirements of the 50 platforms (or as many as we can) into the problem
space, and analysing each one separately into components so that we can
either find commonalities or else keep the requirements disjoint.  And then,
once we see the whole problem space as a set of necessary component
requirements, we can finally synthesize solutions that meet 50/50, or at
least a high number.

Morgaine.

On Sat, Mar 28, 2009 at 5:18 PM, Jon Watte <[email-masked]> wrote:

> The question is: would you want to work on a standard, if you knew that the
> standard would only be adopted by 3 out of 50 virtual world platforms in the
> world?
>
> real and concrete benefits to the users of that platform. (If the platform
> is something done for the fun of it, then the concrete benefit might be the
> enjoyment of implementing the standard, but most platform vendors are not in
> that position).
>
> I have yet to see a use case that shows that implementing the three points
> that were isolated would provide any real and concrete benefit to users of
> worlds other than Open Sim / Second Life. Assuming there is such a benefit,
> then coming up with a use case tied to the technology can't be that hard,
> can it? And, if it is, then what is the benefit of working on that standard?
>
> Or are you suggesting that vendors should implement a standard on faith, as
> an investment, that there will, sometime in the future, maybe be some
> I don't want to talk about technology until I undestand what purpose that
> technology serves the users of that technology.
>
> Sincerely,
>
> jw
>
>

---

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

Last week, I receive an IM while inworld on OSGrid testing some scripts and
it came from an iPhone. This is the video showing this IM as it occurred.

http://www.techcrunch.com/2009/03/22/sparkle-the-iphone-gets-its-first-virtual-world-and-its-3d/

So, Genkii has gone ahead with some interop from the iPhone viewpoint and is
moving forward.

As Croquet, Wonderland and others can chat with us here on this group, we
can increase the activity of this interop and bootstrap implementations as
they come online and keep MMOX in the mainstream if we wish.

That is our challenge.

Not to bemoan how the world is, but rather, to embrace the technology as it
evolves and stay abreast of it and participate in its evolution.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Sat, Mar 28, 2009 at 9:57 AM, Morgaine <[email-masked]>wrote:

>> the standard would only be adopted by 3 out of 50 virtual world platforms in
>> the world?
>>
>>
>> the standard would only be adopted by 3 out of 50 virtual world platforms in
>> the world?
>>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Jon Watte <[email-masked]>
Date: Sat, 28 Mar 2009 23:54:22 -0700

Morgaine wrote:
> On Sat, Mar 28, 2009 at 5:18 PM, Jon Watte <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>      
>     The question is: would you want to work on a standard, if you knew
>     that the standard would only be adopted by 3 out of 50 virtual
>     world platforms in the world?
>
>
> requirements of the 50 platforms (or as many as we can) into the 
> problem space, and analysing each one separately into components so 
> that we can either find commonalities or else keep the requirements 
> disjoint.  And then, once we see the whole problem space as a set of 
> necessary component requirements, we can finally synthesize solutions 
> that meet 50/50, or at least a high number.

That's great!

I think that it's reasonable to believe that the 50 different 
technologies will not each go back and re-implement the entire 
client/server simulation/graphics communication stack. Thus, I think 
that requirement should be placed into the problem space.
Do you agree?

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Sun, 29 Mar 2009 08:38:12 +0000

On Sun, Mar 29, 2009 at 6:54 AM, Jon Watte <[email-masked]> wrote:

>
> I think that it's reasonable to believe that the 50 different technologies
> will not each go back and re-implement the entire client/server
> simulation/graphics communication stack.

We're certainly making a protocol suite that all interoperating parties are
expected to implement.  That's our entire purpose here.  However, that does
not mean that all elements of it need to be implemented by everyone ---
that's a local policy decision, and not our call.  We are not really at the
point yet where we can narrow down a "core", because all the elements are
not yet on the table.

It will be a measure of our success or failure to what degree we can
decouple the underlying services, since it is this decoupling plus
flexibility in media handling that will give implementers an effective
design space.  For example, not everyone will want to implement identity
services, or object storage services, or world simulation services.  As we
have already seen in practice, for some parties *interop* will mean no more
than gaining access to avatar data for local 2D projection, so they would
implement only the relevant sections.

With regard to the three elements you mention:

   1. The "client" of the protocol is actually a *client endpoint*, so in
   your context the protocol(s) would have no relevance to your actual clients
   because the *client endpoints* of the protocol would be on your servers.
   2. World simulation is not part of the interop protocol at all, nor can
   it be because every world may implement a completely different simulation.
   On the partially related topic of object behaviour (because this interacts
   with world simulation), I refer you to this discussion on object
models<http://www.ietf.org/mail-archive/web/mmox/current/msg00982.html>
   .
   3. Most graphics would be handled only as extensible media types for
   transport.  For those graphic elements that have associated behaviour,
   subsequently event traffic (ie. telemetry) would also be carried by the
   protocol.  Both avatars and transportable world objects fall into this
   category.

There are many parts to the puzzle, but participants need implement only
those parts of relevance to them.  For example, Limited Capability Clients
that are interested only in text chat would clearly implement only a very
small part of the overall protocol(s).

> Thus, I think that requirement should be placed into the problem space.  Do
> you agree?
>
>
Requirements should definitely be placed in the problem space!  Note however
that requirements are often broad and phrased in incompatible language, and
therefore need decomposition into smaller more tractable elements that are
fully understood before they can be used to synthesize a cohesive protocol.
I've been trying to do that.

Morgaine.

On Sun, Mar 29, 2009 at 6:54 AM, Jon Watte <[email-masked]> wrote:

> Morgaine wrote:
>
>> On Sat, Mar 28, 2009 at 5:18 PM, Jon Watte <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
> I think that it's reasonable to believe that the 50 different technologies
> will not each go back and re-implement the entire client/server
> simulation/graphics communication stack. Thus, I think that requirement
> should be placed into the problem space.
> Do you agree?
>
> Sincerely,
>
> jw
>
>

---

From: Kajikawa Jeremy <[email-masked]>
Date: Sun, 29 Mar 2009 19:13:47 +0900

Thank you Thank you Thank you,

Ive been braindumping trying to get something kickstarted like this
myself to see
  if anything Ive been thinking about is at all useful in this problem
space or able
  to be broken down further...

I personally see objects and parts of objects as a recursive item...
  and something like an XRDS description of an object (pen or chair) as
being a lot of
  parts (like lego building blocks to make a life-size chair from
mini-parts)...

glad to see someone getting some forward motion...

JW: I agree that LESS has potential and Server<->Server will be
required...
  but I disagree on disconnecting the clients out of the equation
entirely...

Eventually Client programs for end-users will need to know something
simplistic
  to be aware of region/service/... changes

How does LESS as a whole break into parts and what do the parts deal
with?

MXP ?

SecondLife Protocol ?

Croquet?

others?

having an idea of how all 50 systems are seperated for the tech stacks
will at least let
  us all find the breadcrumbs of similarities...

someone entering WoW only needs to confirm authentication and change
End-User
 program...  Guild Wars will be similar...

But I know for a fact that "BloodFrontiers" (available on SourceForge)
openly uses
  IRC as the chat mechanism and allows for players in-world to also chat
using a
  specific channel over Freenode IRC ...

is there anything similar for gateways between *parts* of a world...

talking by text from SecondLife out to OpenSIM or Croquet or Jabber?

is there any basic cross-connecting mechanism or would it specifically
need a region
  on the 3D system to have a "microphone" object to reflect messages to
the other
  server "room"s for the non-3D system people to listen?

How would that use case be covered?  MXP / LESS / HTTP polling of a
custom server?

what does the protocol that we are trying to declare *absolutely
needing*...
  beyond that we can leave as open for extension later...

we have already Identified the "Teleport" function...
  this needs to have a basic mapper for different services...
  and Im recalling Adam proposing a "service://server/region/x/y" URI
scheme
  that is usable for this...

what about a "service://server/" scheme default for anyone to support an
external
  service login?

Ive also seen mention of "whitelist"ing and "blacklist"ing by
services...

What policy options are we needing to look at for security ?

"Allow ALL" (anyone can connect with a valid server?)
"Whitelist"  (deny unless listed)
"Blacklist"  (permit unless listed)
"Deny ALL" (no one can connect without being a proper client...)

I see the "Deny ALL" rule above being broken by anyone making a custom
proxy
  which fakes being the original client software just enough for the
services provided.

Which runs into Server as client-endpoint security issues...

We need a social fabric to grow around the problem as well...

I recognise there is already various opinions that differ on this
list...

Sorry for the long message...  I started braindumping again...

Jeremy

On Sun, 2009-03-29 at 08:38 +0000, Morgaine wrote:
>         client/server simulation/graphics communication stack.
> 
> 
> We're certainly making a protocol suite that all interoperating
> parties are expected to implement.  That's our entire purpose here.
> However, that does not mean that all elements of it need to be
> implemented by everyone --- that's a local policy decision, and not
> our call.  We are not really at the point yet where we can narrow down
> a "core", because all the elements are not yet on the table.
> 
> design space.  For example, not everyone will want to implement
> identity services, or object storage services, or world simulation
> services.  As we have already seen in practice, for some parties
> interop will mean no more than gaining access to avatar data for local
> 2D projection, so they would implement only the relevant sections.
> 
>      1. The "client" of the protocol is actually a client endpoint, so
>         in your context the protocol(s) would have no relevance to
>         your actual clients because the client endpoints of the
>         protocol would be on your servers.
>      2. World simulation is not part of the interop protocol at all,
>         nor can it be because every world may implement a completely
>         different simulation.  On the partially related topic of
>         object behaviour (because this interacts with world
>         simulation), I refer you to this discussion on object models.
>      3. Most graphics would be handled only as extensible media types
>         for transport.  For those graphic elements that have
>         associated behaviour, subsequently event traffic (ie.
>         telemetry) would also be carried by the protocol.  Both
>         avatars and transportable world objects fall into this
>         category.
> 
> There are many parts to the puzzle, but participants need implement
> only those parts of relevance to them.  For example, Limited
> Capability Clients that are interested only in text chat would clearly
> implement only a very small part of the overall protocol(s).
> 
> 
>         
>         Thus, I think that requirement should be placed into the
>         problem space.  Do you agree?
>         
> 
> Requirements should definitely be placed in the problem space!  Note
> however that requirements are often broad and phrased in incompatible
> language, and therefore need decomposition into smaller more tractable
> elements that are fully understood before they can be used to
> synthesize a cohesive protocol.  I've been trying to do that.
> 
> 
> 
> Morgaine.
> 
> 
> 
> 
> 
> 
> 
> 
>                 On Sat, Mar 28, 2009 at 5:18 PM, Jon Watte
>                 <[email-masked] <mailto:[email-masked]>> wrote:
>                 
>                 We're not working on a standard for 3/50.  Instead,
>                 we're placing the requirements of the 50 platforms (or
>                 as many as we can) into the problem space, and
>                 analysing each one separately into components so that
>                 we can either find commonalities or else keep the
>                 requirements disjoint.  And then, once we see the
>                 whole problem space as a set of necessary component
>                 requirements, we can finally synthesize solutions that
>                 meet 50/50, or at least a high number.
>         
>         
>         That's great!
>         
>         client/server simulation/graphics communication stack. Thus, I
>         think that requirement should be placed into the problem
>         space.
>         Do you agree?
>         
>         Sincerely,
>         
>         jw
>         
>

---

From: Larry Masinter <[email-masked]>
Date: Sun, 29 Mar 2009 10:25:11 -0700

If you start horizontally, you might get significant value
without having to overcome some really difficult problems
of interaction between incompatible world models.

Object interoperability is hard, because every world has
a different model for objects, geography, movement, physics
and so forth.

Communication interoperability seems quite feasible:
chat using extensions to XMPP/Jabber, voice using SIP,
location using extensions to Geopriv, etc.

I could see also agreeing on a form of GUIDs for object
references and a way of discovering metadata about
objects as well as content negotiation for object
representations.

It's interesting to think about world<->world communication
as an extension of in-world <->  real-world communication,
e.g., to google-talk to avatars using Jabber.

Many people seem to have flickr/facebook/etc. identities
for their avatars independently of the ones for their
"real" selves, so this isn't too far-fetched a concept.

Getting some success on inter-world communication,
even if it is for a narrow application like "chat",
will help enormously in establishing the credibility
of any standards effort.

(historical reference: 
http://larry.masinter.net/MOOGopher.pdf  )

(IMHO caveat always applies)

Larry
--
http://larry.masinter.net

---

From: Charles Krinke <[email-masked]>
Date: Sun, 29 Mar 2009 09:43:16 -0800

I would concur. Making in-roads in getting chat working between more virtual
worlds is to everyone's advantage.

In general, the progression for implementation seems to follow :

1. Chat first
2. Some sort of presence perhaps as a still or moving picture
3. Some sort of avatar presence.
4. Some sort of object presence.

It just seems to me that making progress on this list in about this order
with additional virtual worlds is a win for MMOX.

Charles Krinke
OpenSim Core Developer
OSGrid Director

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Morgaine <[email-masked]>
Date: Sun, 29 Mar 2009 18:59:30 +0000

Larry, I agree entirely with your suggestion that an early focus on
inter-world communications would be an easy win, and also with Charles'
followup which added further incremental wins.

This is why I am focussed so strongly on service decoupling.  When services
are hardwired within a world, they typically become ever more non-standard
and non-interoperable with every new world-specific feature that is added.

In contrast, when services are decoupled then the need for compatibility
with 3rd party services not only creates stability but also allows interop
to bloom without prior planning.  And while not a technical point, the
increased room for competition always helps growth in the area too.

Although OGP is only a threadbare framework at the moment, one of its major
selling points is service decoupling.  It has only decoupled two services at
this time, the agent identity service and world region service, so there is
a long way to go yet, but it's a start.

You have highlighted *communications* as another area that is an extremely
strong candidate for service decoupling, and in another thread we have been
discussing the need for a decoupled *asset storage
service<http://www.ietf.org/mail-archive/web/mmox/current/msg01243.html>
* as well, given that one's inventory will comprise objects from an
arbitrary number of worlds and therefore should not be tied to an identity
provider.  Charles alluded to avatar and object presence in his points 3 and
4, and decoupling object/asset storage services would make those a lot
easier to achieve as well.

I hope that we can express our thoughts about early wins in terms of such
services, because the web provides a very strong precedent that we can
leverage in this area, and the large number of supporting frameworks for
services can facilitate progress immeasureably.

Morgaine.

---

From: Charles Krinke <[email-masked]>
Date: Sun, 29 Mar 2009 11:42:21 -0800

Lets view this as the evolution of the
telegraph->telephone->television->holographicProjection->StarTrekTransporter
all speeded up over the course of a year or so.

That is:

Telegraph: Some modest messages via prims or objects passing messages from
one virtual world to another via a third party web site using http request
and http_response

Telephone: Some amount of textual of video chat between objects in different
virtual worlds.

holographicProjection: Some way to present a 3D representation of an avatar
in one virtual world in another virtual world.

StarTrekTransporter: Some way to transfer the presence of an avatar from one
virtual world to another.

In taking the problem apart, one can easily imagine these steps occuring as
a series of evolutions in MMOX. *Whatever* we wish to call them is fine and
doesnt matter very much. The point is that progressing through this
evolution gives this group a way to perceive of the steps and negotiate them
between various virtual worlds as evolution occurs. And, I would go so far
as to predict, that this evolution will tend to happen very quickly over the
next year or so.

Charles Krinke
OpenSim Core Developer
OSGrid Director

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

> discussing the need for a decoupled *asset storage service<http://www.ietf.org/mail-archive/web/mmox/current/msg01243.html>
> On Sun, Mar 29, 2009 at 5:25 PM, Larry Masinter <[email-masked]>wrote:
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Jon Watte <[email-masked]>
Date: Sun, 29 Mar 2009 16:45:34 -0700

Morgaine wrote:
> only those parts of relevance to them.

I agree. However, that side-steps the problem a little bit. My feedback 
is that we should make the implementation as cheap as possible to get 
some end-user visible benefit for virtual world interoperability, so 
that we can get lots of worlds on board. Agreed?

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Sun, 29 Mar 2009 16:50:05 -0700

Charles Krinke wrote:
> I would concur. Making in-roads in getting chat working between more 
> virtual worlds is to everyone's advantage.

Well, theoretically that is already solved by XMPP, right?

Also, it turns out that OLIVE is very not focused on text chat at all; 
it is almost entirely designed for voice comms. Of course, we already do 
SIP interoperability, so it's unclear whether there's much to do that, 
either.

If a virtual world exposed a XMPP chat service, and SIP endpoints for 
each avatar, using the protocols that already exist, then what else is 
there to do to declare this working? What, specifically, are the 
unsolved problems with regards to using XMPP and SIP in the context of 
virtual worlds?

The only one I can think of is properly tying presence into the SIP 
call, such that the voice comes from the right 3D location (we use an 
out-of-bound message for that right now).

Sincerely,

jw

---

From: Larry Masinter <[email-masked]>
Date: Sun, 29 Mar 2009 17:08:38 -0700

> there to do to declare this working?
...
> out-of-bound message for that right now).

Is there a standard way of relating avatar identity and personal
identity? Should these be distinct? Are the states of present/idle/location
from XMPP appropriate for avatar-in-world? Are there special
in-world states that would need to be mapped into XMPP presence
information ("in-world but dead" in a combat world, for example.)
Are there any issues with synchronizing XMPP messages and in-world
events?

I think to "declare this working", you'd have a document that described
how this would work, and multiple independent interoperable implementations,
with satisfactory interoperability.

Since I've not seen any jabber-with-avatar services actually working,
there are probably other technical questions that would arise during
the course of implementation.

And, of course, you'd have to decide as a group to settle on
XMPP and not IRC, not something based on OGP, (some profile of) 
SIP and not some other voice server, sharing service, etc.

It's always good to start with something you think is easy.

Larry

---

From: Charles Krinke <[email-masked]>
Date: Sun, 29 Mar 2009 16:54:39 -0800

Matters not. Some folks prefer typing, some prefer voice. Either or both
options are reasonable and supported by many virtual worlds, including the
ones currently supporting interop.

The key is to move forward in a logical, step by step manner in implementing
more interop.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Sun, Mar 29, 2009 at 3:50 PM, Jon Watte <[email-masked]> wrote:

> Also, it turns out that OLIVE is very not focused on text chat at all; it
> is almost entirely designed for voice comms. Of course, we already do SIP
> interoperability, so it's unclear whether there's much to do that, either.
>
> If a virtual world exposed a XMPP chat service, and SIP endpoints for each
> avatar, using the protocols that already exist, then what else is there to
> do to declare this working? What, specifically, are the unsolved problems
> with regards to using XMPP and SIP in the context of virtual worlds?
>
> The only one I can think of is properly tying presence into the SIP call,
> such that the voice comes from the right 3D location (we use an out-of-bound
> message for that right now).
>
> Sincerely,
>
> jw
>
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Jon Watte <[email-masked]>
Date: Sun, 29 Mar 2009 18:57:25 -0700

What, if anything, needs to be done if we were to look at XMPP and SIP 
for VW communication interop?

If someone wants to try a SIP session between OLIVE and some other 
virtual world, could you contact me off-list, and perhaps we can just 
try it out and see if it's good enough or not?

Sincerely,

jw

Charles Krinke wrote:
> Matters not. Some folks prefer typing, some prefer voice. Either or 
> both options are reasonable and supported by many virtual worlds, 
> including the ones currently supporting interop.
>
> The key is to move forward in a logical, step by step manner in 
> implementing more interop.

>     If a virtual world exposed a XMPP chat service, and SIP endpoints
>     for each avatar, using the protocols that already exist, then what
>     else is there to do to declare this working? What, specifically,
>     are the unsolved problems with regards to using XMPP and SIP in
>     the context of virtual worlds?
>
>     The only one I can think of is properly tying presence into the
>     SIP call, such that the voice comes from the right 3D location (we
>     use an out-of-bound message for that right now).
>

---

From: Morgaine <[email-masked]>
Date: Mon, 30 Mar 2009 02:42:10 +0000

On Sun, Mar 29, 2009 at 11:45 PM, Jon Watte <[email-masked]> wrote:

My feedback is that we should make the implementation as cheap as possible
> to get some end-user visible benefit for virtual world interoperability, so
Not agreed at all actually. :-)  Although we haven't got around to talking
about the parameters of our solution space yet, I think it's always a good
time to reflect on the IETF's mission
statement<http://www.ietf.org/rfc/rfc3935.txt>,
because this sets our solution parameters as well:

In attempting to resolve the question of the IETF's scope, perhaps the
fairest balance is struck by this formulation: "*protocols and practices for
which secure and scalable implementations are expected to have wide
deployment and interoperation on the Internet, or to form part of the
infrastructure of the Internet*."

Our work here is completely for nothing if it doesn't scale for wide
deployment on the Internet.  Anyone can knock up a simple bit of interop for
an easy perceived win, but success would then be an illusion that shatters
as soon as the number of users grows.

It can be hard to impress upon people the extreme difficulties that arise
when services are scaled into the millions of users and beyond without an
adequate design in place, but once you've experienced it once then you know
you don't ever want to experience it again.   A technically cheap design is
very often a non-scalable one which puts you on a "*You can't get there from
here*" dead-end road when you start hitting its scalability limits.  If
there is a single thing that we must do right in MMOX, it's to not propose
cheap but non-scalable solutions.

Linden Lab has a registered user base of over 16 million users and well over
80 thousand users online concurrently, so it won't surprise anyone that
scalability became an issue a long time ago.  Indeed, the AWG was founded
with scalability as a primary requirement on day 1, and when LL+IBM brought
this effort to the IETF, it was with very large numbers in mind for the
interoperating metaverse of worlds.

In this context, proposing a technically cheap solution that has not been
assessed for scalability has somewhat limited interest.  Interop has the
natural and expected consequence of growth in numerous dimensions (eg. user
population, concurrent users online, concurrent communication channels,
number of worlds, people within a single region, number of objects, etc),
and our solutions must reflect that.  The design of OGP was predicated on
it.

This may mean that some easy solutions are given the thumbs down in our
context, but that's not really a problem:  you don't need a *Massively
Multi-participant* IETF standard if you just want a cheap, low-scalability
solution.

Of course, if you can find a cheap solution that also happens to scale well,
all the better!  But usually, TANSTAAFL applies.

Morgaine.

On Sun, Mar 29, 2009 at 11:45 PM, Jon Watte <[email-masked]> wrote:

>> those parts of relevance to them.
>>
>
> I agree. However, that side-steps the problem a little bit. My feedback is
> that we should make the implementation as cheap as possible to get some
> end-user visible benefit for virtual world interoperability, so that we can
> get lots of worlds on board. Agreed?
>
> Sincerely,
>
> jw
>
>

---

From: Jon Watte <[email-masked]>
Date: Mon, 30 Mar 2009 07:33:42 -0700

Morgaine wrote:
> On Sun, Mar 29, 2009 at 11:45 PM, Jon Watte <[email-masked] 
>     My feedback is that we should make the implementation as cheap as
>     possible to get some end-user visible benefit for virtual world
>     interoperability, so that we can get lots of worlds on board. Agreed?
>
>
> Not agreed at all actually. :-)
>
> In this context, proposing a technically cheap solution that has not 
> been assessed for scalability has somewhat limited interest.

I did not propose a non-scalable solution. I fully understand 
scalability regarding virtual worlds, and other systems.

I simply propose that we make ease of adoption for a wide community an 
explicit goal, because if something is hard to adopt, it will not be 
adopted, and thus the standard is more likely to fail. The reason I want 
it to be an explicit guiding principle is that it's one of those things 
that may otherwise be overlooked when a few people with some particular 
background come up with a particular solution.

Sincerely,

jw

---

From: James Stallings II <[email-masked]>
Date: Mon, 30 Mar 2009 10:54:03 -0500

Getting  back to Morgaine's question, thank you James Kempf for the
injection of sanity to the process :) you really put the truth in palatable
language, but I think maybe a few folks on the list might still have missed
the point:
The course of action you suggest *is* 'doing something about the problem'.

What's more, I think that if we were to see your recommendations in
practice, it would look a lot like what is happening with OpenSim and LL wrt
AWG/OGP.

So perhaps what is going 'wrong' with the MMOX effort is not so much about
whether the right thing is being done, as whether it is recognized that the
right thing is, by and large, already being done.

I don't know that any of the participants are particularly ready to produce
work that addresses the requirements of an IETF standard; but I do know that
this discussion is bearing certain fruit and should be continued, as it will
inform future work along these lines.

On what would seem to be the more mainstream topic of the use-case, I think
Jon left off perhaps the most fundamental interop capability of all from his
list: that of exchange of text communications ("chat") between endusers.
Without this, there really isnt any advantage in doing the three things he
lists; but as soon as user<->user communications across diverse worlds is
possible, the other three things he lists immediately begin to produce value
for the endusers of said divergent worlds.

OpenSim already has a reference technology in place that accomplishes such
an interoperation with IRC; a simulator may be given an 'identity' on an IRC
network (which then establishes it's own IRC channel), at which time all
public simulator chat is relayed to the IRC channel, and all IRC channel
user's chat from that channel relayed to the open chat in the simulator.

This allows users of IRC clients to participate in communications occurring
on the sim, as well as sim users to participate in the sim's IRC channel.

We have found it very usefull in a number of instances.

I might also point out that this interop requires absolutely no references
to objects, worlds, primitives or render-specific technologies.

Cheers :)

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

> Morgaine wrote:
>
>> On Sun, Mar 29, 2009 at 11:45 PM, Jon Watte <[email-masked] <mailto:
>> assessed for scalability has somewhat limited interest.
>>
>
>
> I did not propose a non-scalable solution. I fully understand scalability
> regarding virtual worlds, and other systems.
>
> adopted, and thus the standard is more likely to fail. The reason I want it
> to be an explicit guiding principle is that it's one of those things that
> may otherwise be overlooked when a few people with some particular

-- 
===================================
http://osgrid.org
http://del.icio.us/SPQR
http://twitter.com/jstallings2
http://www.linkedin.com/pub/5/770/a49

---

From: Jon Watte <[email-masked]>
Date: Mon, 30 Mar 2009 14:56:46 -0700

James Stallings II wrote:
> On what would seem to be the more mainstream topic of the use-case, I 
> think Jon left off perhaps the most fundamental interop capability of 
> all from his list: that of exchange of text communications ("chat") 
> between endusers.

I think those three things were Morgaines. My use cases are, as always, 
here:

http://tools.ietf.org/html/draft-jwatte-mmox-use-cases-00

The three capabilities I quoted from Morgaine's e-mail aren't use cases; 
they are possible capabilities. And, interestingly, those capabilities 
by themselves do not deliver any actual use case to the end user (as we 
agreed: necessary but not sufficient).

I suggest you read up on the five use cases listed in the above link. If 
there is something you think should be delivered before that, or instead 
of that, then please formulate them as actual end user use cases! (I've 
been asking for that for a while, to the point where it's starting to 
sound repetetive, yet there are no other use cases of record)

> I might also point out that this interop requires absolutely no 
> references to objects, worlds, primitives or render-specific technologies.

It does require a user-to-user text chat capability, which some of those 
virtual worlds that have evolved to be voice based don't actually have :-)

Sincerely,

jw

---

From: Kari Lippert <[email-masked]>
Date: Mon, 30 Mar 2009 17:59:37 -0400

<clearing throat>

I've been lurking for some time now and reading and trying to understand the
basic user requirement that is driving this work. I have to admit this is as
close as I've seen.

I understand "teleport" (and believe if you can define it well enough, smart
people can make it so) but it leaves me asking why? Why would a user desire
to "teleport" from one VWE to another? The answer to this will, I believe,
help you focus on what needs to be included in the definition of what it
means to "teleport", and what can be safely set aside for the moment.

Kari

2009/3/30 James Stallings II <[email-masked]>

---

From: Morgaine <[email-masked]>
Date: Mon, 30 Mar 2009 23:04:09 +0000

2009/3/30 Kari Lippert <[email-masked]>

>
> I understand "teleport" (and believe if you can define it well enough,
> smart people can make it so) but it leaves me asking why? Why would a user
> desire to "teleport" from one VWE to another?
>

Given this interop
scenario<http://www.ietf.org/mail-archive/web/mmox/current/msg01114.html>,
which reflects the normal way in which humans organize their lives around
travel between different places, a reasonable answer to your question is
probably that our various forms of inter-VW travel (continguous handover,
portal crossings, and discontiguous transitions) are a natural extrapolation
of our everyday experience.

In the real world, we're rather limited in the methods by which we can move
between distant lands.  The nearest thing to an instantaneous teleport
between London and Boston is to get on a jet plane, go to sleep for several
hours, and wake up in a different place.  Virtual worlds are of course much
more flexible, so because we *can* teleport instantaneously, we *do*.  It's
only one of several methods, though.

Of course, instantaneous travel is not to everyone's taste, but nor is
lengthy and laborious contiguous travel to everyone's taste.  In any case,
VWs differ in their topological connectivity to other worlds and therefore
no single approach is possible, nor desireable.

Fortunately, these are matters of policy, whereas our interests here is
providing mechanisms that can support a wide range of policies.  The
three underlying
components of teleport<http://www.ietf.org/mail-archive/web/mmox/current/msg01208.html>are
applicable to a very wide range of VWs indeed.

Morgaine.

2009/3/30 Kari Lippert <[email-masked]>

> <clearing throat>
>
> I've been lurking for some time now and reading and trying to understand
> the basic user requirement that is driving this work. I have to admit this
> is as close as I've seen.
>
> I understand "teleport" (and believe if you can define it well enough,
> smart people can make it so) but it leaves me asking why? Why would a user
> desire to "teleport" from one VWE to another? The answer to this will, I
> believe, help you focus on what needs to be included in the definition of
> what it means to "teleport", and what can be safely set aside for the
> moment.
>
> Kari
>
>
>> think Jon left off perhaps the most fundamental interop capability of all
>> from his list: that of exchange of text communications ("chat") between
>> endusers. Without this, there really isnt any advantage in doing the three
>> things he lists; but as soon as user<->user communications across diverse
>> worlds is possible, the other three things he lists immediately begin to
>> produce value for the endusers of said divergent worlds.
>>
>>
>

---

From: Jon Watte <[email-masked]>
Date: Mon, 30 Mar 2009 16:04:44 -0700

Kari Lippert wrote:
> <clearing throat>
>
> I've been lurking for some time now and reading and trying to 
> understand the basic user requirement that is driving this work. I 
> have to admit this is as close as I've seen.
>
> smart people can make it so) but it leaves me asking why? Why would a 
> user desire to "teleport" from one VWE to another? The answer to this 
> will, I believe, help you focus on what needs to be included in the 
> definition of what it means to "teleport", and what can be safely set 
> aside for the moment.
>
> Kari

I think "teleport" is an implementation detail. Does this use case seem 
like a good description of what you consider a "teleport"?

      2.1. Friend Invite

        2.1.1. Description

   1.  User A uses virtual world system A that complies with MMOX
       interoperability.
   2.  User B uses virtual world system B that complies with MMOX
       interoperability.
   3.  User A wants user B to visit him/her in system/world A, and gets
       a suitable URL from his/her system (A), and sends this to user B
       using any transport (mail, IM, integrated communication, carrier
       pigeon, ...)
   4.  User B clicks/activates this link.
   5.  After a brief "loading" screen, user B sees user A in user A's
       environment, including a representative form of any simulated
       object in that environment.
   6.  User B can interact at some level with the objects from user A.
   7.  Objects that user B take out of inventory show up in some
       representative form for both user A and user B.
   8.  User A can interact at some level with any objects that user B
       bring out of inventory.

Note that I assumed that if you have avatars and objects, you also have 
text/speech, but that's a poor assumption -- it should go as line 5.5 in 
this use case, I guess.

Sincerely,

jw

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 30 Mar 2009 16:57:41 -0700

How about a very persona-oriented (specific) use case...

Lisa has a house in one virtual world, with virtual rooms that she
frequently hangs out in, that friends might find her at.  One day she
goes to a party in another virtual world.  She leaves behind a note on
her virtual door or bulletin board (she has control over the
presentation, it could be a spinning hovering party hat or a blue
police phone booth if the home world allows that).  The note has a
link to the party world because it's an open party.  Lisa's friends
can now find her, and the more seamless their experience in getting
from the first virtual world to the second, the more likely they are
to enjoy the experience, follow through, and see her.

Seamless is a goal, but might involve:
 - Not launching a new client, if possible, and if it is
      - A transition that is not too jarring, minimizing reload
screens, blank screens, dialog boxes, choices
 - Low time consumption for transport, including time navigating from
an initial destination to a final destination, if allowed by the
destination world
 - Avoiding a registration step if possible, and if it is
      - Lisa can recognize her friends under the moniker she'd
normally see them under
 - Keeping avatar consistency to the extent possible, for recognition
as well as seamlessness

For bonus points, Lisa can open a door from her house into the party,
and visitors can get a glimpse of what's beyond, then just walk
through.

Lisa

On Mon, Mar 30, 2009 at 4:04 PM, Jon Watte <[email-masked]> wrote:
> I think "teleport" is an implementation detail. Does this use case seem like
> a good description of what you consider a "teleport"?
>
>
>     2.1. Friend Invite
>
>
>       2.1.1. Description
>
>
>

---

From: Jon Watte <[email-masked]>
Date: Mon, 30 Mar 2009 17:35:06 -0700

Thanks for referencing that use case. It's interesting that the answer 
to those questions hasn't actually been posted yet...

What if the destination is a for-profit world, and the reason you could 
get there in the first place was that some paying customer invited you? 
Then when you want to return, there is no paying customer to share the 
"cost" (loosely defined).

Do we really want to use the term "landmark" in interop speak? That 
sounds a little too SL specific? Else, would you define what a 
"landmark" really means?

Sincerely,

jw

Morgaine wrote:
> 2009/3/30 Kari Lippert <[email-masked] 
> <mailto:[email-masked]>>
>
>
>     I understand "teleport" (and believe if you can define it well
>     enough, smart people can make it so) but it leaves me asking why?
>     Why would a user desire to "teleport" from one VWE to another?
>
>
>
> Given this interop scenario 
> <http://www.ietf.org/mail-archive/web/mmox/current/msg01114.html>, 
> which reflects the normal way in which humans organize their lives 
> around travel between different places, a reasonable answer to your 
> question is probably that our various forms of inter-VW travel 
> (continguous handover, portal crossings, and discontiguous 
> transitions) are a natural extrapolation of our everyday experience.
>
> In the real world, we're rather limited in the methods by which we can 
> move between distant lands.  The nearest thing to an instantaneous 
> teleport between London and Boston is to get on a jet plane, go to 
> sleep for several hours, and wake up in a different place.  Virtual 
> worlds are of course much more flexible, so because we /can/ teleport 
> instantaneously, we /do/.  It's only one of several methods, though.
>
> lengthy and laborious contiguous travel to everyone's taste.  In any 
> case, VWs differ in their topological connectivity to other worlds and 
> therefore no single approach is possible, nor desireable.
>
> Fortunately, these are matters of policy, whereas our interests here 
> is providing mechanisms that can support a wide range of policies.  
> The three underlying components of teleport 
> <http://www.ietf.org/mail-archive/web/mmox/current/msg01208.html> are 
> 2009/3/30 Kari Lippert <[email-masked] 
> <mailto:[email-masked]>>
>
>     <clearing throat>
>
>     I understand "teleport" (and believe if you can define it well
>     enough, smart people can make it so) but it leaves me asking why?
>     Why would a user desire to "teleport" from one VWE to another? The
>     answer to this will, I believe, help you focus on what needs to be
>     included in the definition of what it means to "teleport", and
>     what can be safely set aside for the moment.
>
>     Kari
>      
>
>     2009/3/30 James Stallings II <[email-masked]
>     <mailto:[email-masked]>>
>
>
>
>         On what would seem to be the more mainstream topic of the
>         use-case, I think Jon left off perhaps the most fundamental
>         interop capability of all from his list: that of exchange of
>         text communications ("chat") between endusers. Without this,
>         there really isnt any advantage in doing the three things he
>         lists; but as soon as user<->user communications across
>         diverse worlds is possible, the other three things he lists
>         immediately begin to produce value for the endusers of said
>         divergent worlds.
>
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Dan Olivares <[email-masked]>
Date: Mon, 30 Mar 2009 21:24:46 -0400

Heh,

Debating the word landmark seems a little silly.   Call it 3D
hyperlink, or..    portal link..  or whatever :)  The point is that
you make an action using it :).  Generally..  I use the term Landmark
to refer to objects along the way that I can recognize to help me get
somewhere.

Best Regards

Dan

On Mon, Mar 30, 2009 at 8:35 PM, Jon Watte <[email-masked]> wrote:
> Thanks for referencing that use case. It's interesting that the answer to
> those questions hasn't actually been posted yet...
>
> What if the destination is a for-profit world, and the reason you could get
> there in the first place was that some paying customer invited you? Then
> when you want to return, there is no paying customer to share the "cost"
> (loosely defined).
>
> Do we really want to use the term "landmark" in interop speak? That sounds a
> little too SL specific? Else, would you define what a "landmark" really
> means?
>
> Sincerely,
>
> jw
>
>
> Morgaine wrote:
>>
>> <http://www.ietf.org/mail-archive/web/mmox/current/msg01114.html>, which
>> reflects the normal way in which humans organize their lives around travel
>> between different places, a reasonable answer to your question is probably
>> that our various forms of inter-VW travel (continguous handover, portal
>> crossings, and discontiguous transitions) are a natural extrapolation of our
>> everyday experience.
>>
>> move between distant lands.  The nearest thing to an instantaneous teleport
>> more flexible, so because we /can/ teleport instantaneously, we /do/.  It's
>> providing mechanisms that can support a wide range of policies.  The three
>> underlying components of teleport

---

From: Charles Krinke <[email-masked]>
Date: Mon, 30 Mar 2009 18:00:30 -0800

I would suppose we can also consider "Landmark" in a different sense in that
objects themselves in many virtual worlds can run scripts. That means that
objects can communicate to external web servers or other virtual worlds, so
that a "wormhole" or "stargate" or "fargate" becomes practical for interop.

I can easily see some interop going on as "wormholes" or "fargates" with
scripted objects communicating with either external web servers or other
virtual worlds.

This avenue of interop is interesting in itself as it means no changes to
the underlying VW architecture, but rather, the use of "scripted objects" as
"Landmarks"

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Mon, Mar 30, 2009 at 5:24 PM, Dan Olivares <[email-masked]> wrote:

> get
> sounds a
> which
> teleport
> case,
> three

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Larry Masinter <[email-masked]>
Date: Mon, 30 Mar 2009 19:33:01 -0700

> http://tools.ietf.org/html/draft-jwatte-mmox-use-cases-00

"  The point is
   that interoperability does not require the source and the destination
   to be from the same technology family, use the same simulation
   technology, or even that the clients must understand protocols other
   than those native to the respective simulation system."

I don't understand how most of those use cases can be managed if
the source & destination have different simulation models, skeleton
structions, scripting languages, physics models, rendering engines,
etc.

>   The benefit is that users of different virtual worlds can invite and
>  communicate with each other using the virtual world metaphore,
>   regardless of the particular virtual world technology used for their
>   "home base" virtual world.

I think this is "if you can do A, then you can do A". Why would anyone
 want to do that, and how would it help them?

In section 2.2.1, the integration of a "plant" and a "city" requires
so many seams to be knit, I wonder how feasible it really is. Even
between virtual worlds with the same underlying infrastructure, welding
a "building" into a city requires a lot of work aligning, wouldn't it?

Just wondering how practical these use cases are.

Larry

---

From: Morgaine <[email-masked]>
Date: Tue, 31 Mar 2009 02:44:44 +0000

Lisa, I liked your "persona-oriented" angle for a virtual travel/teleport
use case.

It conveys the "user experience" aspect of interop, and so it reminds us
that our rather complex technical goals are all just a means to an end, that
of providing the user with an effective virtual experience.  That is a
social goal, and success requires making it seamless with respect to its
social elements:  in this case, homes, party places, friends, and easy
travel or access.

Individual worlds try to provide this already of course.  Our goal in
interop is to let it happen between worlds, to the greatest extent possible,
by designing a communications infrastructure that can carry the common
social and perceptual elements between the worlds in question.  It won't
always be possible to make the experience seamless, but where it is
possible, we should strive to allow it.

Morgaine.

On Mon, Mar 30, 2009 at 11:57 PM, Lisa Dusseault
<[email-masked]>wrote:

> user
> like

---

From: "Mystical Demina" <[email-masked]>
Date: Mon, 30 Mar 2009 23:09:36 -0400

My thought about an approach is we think more abstract and set up the tools
that can be used to integrate virtual worlds.  To me this means we think in
terms of sessions, coordinate systems and objects.  These are the building
blocks that people can then use to do things like teleporting, walking
around in another virtual world, etc.

1. Sessions
Any two computers that are going to talk to each other need to be able to
establish a connection and understand what services are available on the
other system. Probably need some kind of service discovery which probably
includes authentication and authorization although anonymous may be allowed
and full authorization may be given anyway.  Perhaps we say authentication
is below this layer and we don't get into it but authorization seems to be
involved here so we can discover what we are allowed to do.

2. Coordinate space
As part of the session the virtual world identity interface needs to exist
so that the type of coordinate space and units of measure can be defined.
The coordinate space will need to have a create object interface so that an
object of some given type can be created in this other space.  Coordinate
spaces probably have cameras to deal with, how they are defined.

3. Objects
Objects of given types, vertex based like OBJs, or type base like prims and
transformations that can be performed on them.  Objects then will have to
have interfaces to support additional actions.

To me teleporting is a macro process that will be made up of these
processes.  Like TCP/IP and HTML allowed the web pages of the internet to be
made seems these Sessions, Coordinate spaces and Objects are the things that
virtual worlds will be made from.

I believe all virtual words can be defined as sessions, coordinate spaces
and objects and as such OGP, LESS and any of the standards that we are
working with can be broken down to creating a sessions, defining a
coordinate space and creating an object of a give format there with
intefaces/motheds/events it supports.

If objects move between virtual worlds to me what is really happening is the
parent object is changing and as such an event of ParentChanged may need to
be handled to update the coordinate system as well as other details like
communications.  Do objects really know what virtual world they are in? Or
do they just know who their parent interface to interact with is.

I think for virtual worlds to be MMOX they will need to support a set of
object formats like OBJ or an agreed upon set of object types like prims and
the transformations as well as the textures or shaders to provide their
surfaces.

So perhaps the focus isn't on how to we teleport but on how do we define a
set of compatible sessions, coordinate spaces and objects that any
technology can implement.

Kevin Tweedy
SL: Mystical Demina

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Larry Masinter
Sent: Monday, March 30, 2009 10:33 PM
To: Jon Watte; James Stallings II
Cc: MMOX-IETF
Subject: Re: [mmox] Creating walled gardens considered harmful

"  The point is

Larry

---

From: Morgaine <[email-masked]>
Date: Tue, 31 Mar 2009 04:02:40 +0000

> when you want to return, there is no paying customer to share the "cost"

We're only supplying a control mechanism for the movement between worlds.  I
think it's far beyond our remit to get involved in costs or cost
distribution, although teleport grant or denial might validly be considered
part of the "mechanism" of teleport.

>
>
> Do we really want to use the term "landmark" in interop speak? That sounds
> a little too SL specific? Else, would you define what a "landmark" really
> means?
>

The term "landmark" is in extremely wide use in many applications that
involve maps or addresses, as well as in real life, so it's certainly not
SL-specific.  Since we haven't yet tied down its meaning for interop (if
any), for now it probably just means "address within a world" for us.

Addresses we can certainly expect to be transportable (as readable N-tuples
which have meaning only within their respective worlds), but how addresses
are presented in any given world is very world-specific.  For example, in SL
a "landmark" is a special inventory item which can be placed in objects and
manipulated by scripts, but which does not have in-world visibility.  That
sounds too architecture-specific for an object in an interop protocol, it
seems to me.  Perhaps plain addresses will be sufficient at the protocol
level.

Morgaine.

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

> Do we really want to use the term "landmark" in interop speak? That sounds
> a little too SL specific? Else, would you define what a "landmark" really
> means?
>
> Sincerely,
>
> jw
>
>
> Morgaine wrote:
>
>> 2009/3/30 Kari Lippert <[email-masked] <mailto:
>> [email-masked]>>
>>
>>
>> Given this interop scenario <
>> http://www.ietf.org/mail-archive/web/mmox/current/msg01114.html>, which
>> underlying components of teleport <
>> http://www.ietf.org/mail-archive/web/mmox/current/msg01208.html> are
>> 2009/3/30 Kari Lippert <[email-masked] <mailto:
>> [email-masked]>>
>>
>>    <clearing throat>
>>

---

From: Jon Watte <[email-masked]>
Date: Tue, 31 Mar 2009 08:21:12 -0700

> structions, scripting languages, physics models, rendering engines,

It's being done all the time in the DIS simulation model, and has been 
since the 1980s. You simply send the presentation information about the 
object. For an avatar, you present a mesh in some known format (COLLADA, 
X3D, etc), one or more textures in some known format (DDS, JPEG, etc), 
and one or more animations that are targeted to the mesh (again, 
COLLADA, X3D, BHV, etc). When that avatar moves, the "playing animation" 
property changes, and the observers can run the walk cycle animation if 
they care. The "velocity" and "position" properties will also change, 
and the observers can update the position of the entity, typically using 
dead reckoning.

All the physics, simulation, skeleton etc gets operated on in the host 
system, so the fact that they are heterogenous doesn't matter. All a 
remote peer needs to understand is how to load and present assets in 
some common format.

The key here is that the property names "current animation," "position" 
and "velocity" are well-known. In traditional simulation interop 
protocols (DIS, HLA, TENA etc), those map to numeric fields at some 
offset in some PDU. In order to make the system scale across different 
clients (cell phones, conference phones, full-immersion CAVEs, etc), 
separating the properties you're interested in, and identifying them by 
name, seems like a good idea -- look at the LESS protocol for an 
illustration of how this can be done.

>  want to do that, and how would it help them?

Very simple: When I meet you, I can still use my inventory objects, and 
you can still use your inventory objects. Depending on the degree of 
interaction translation in the host systems, I may even be able to use 
your inventory objects, and vice versa. (Simple things like "activate" 
or "view heritage" or whatever are almost gimmies; harder things like 
"riding shotgun" may or may not be supported by any particular platform)

> Just wondering how practical these use cases are.

We are already doing these things using proprietary protocols, and using 
open, but military-centric protocols. I would be very happy if there was 
an extensible, adopted open standard protocol that we could do all this 
over, because then we wouldn't have to code up a new point solution for 
each new system that we encounter. (Of course, if those other systems 
didn't adopt the protocol, then that wouldn't help much)
I predict that integration between virtual worlds will be very important 
a few years from now, so if there's already a well-known language for 
them to speak, that work will be easy. If there isn't, it won't :-)

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Tue, 31 Mar 2009 08:27:25 -0700

Morgaine wrote:
> On Tue, Mar 31, 2009 at 12:35 AM, Jon Watte <[email-masked] 
> teleport grant or denial might validly be considered part of the 
> "mechanism" of teleport.
>
>

Fair enough.

>
>     Do we really want to use the term "landmark" in interop speak?
>     That sounds a little too SL specific? Else, would you define what
>     a "landmark" really means?
>      
>
>
> involve maps or addresses, as well as in real life

I know of no serious GIS application that uses the term.

But the use in the real world is very different. In the real world, the 
Coit Tower cannot move. In the virtual world, that's just a few mouse 
clicks. If I had a delicious hot dog right next to the Coit Tower, and 
the Coit Tower then moved, in real-world speak, the Coit Tower landmark 
is no longer near anything it was near when I set that as a Landmark.

In general, I like the term "address" more, because it's more akin to, 
say, GPS coordinates. Also, when using Google Maps (arguably the most 
used GIS system ever), they are called Favorites.

But this brings up another use case point: Is the "landmark" referencing 
an object (that can move), or an address (that can't)? And does it even 
matter? Maybe these location favorites can simply be URLs with a known 
type, and the actual words of the URL are specific to the system that 
minted them. Then the only information that is important to the 
destination system is:
1) Knowing that this is a location URL, and not some other kind of URL
2) Some user-visible description (icon, title, movie, sound, whatever) 
for presentation
3) The process by which one of these URLs get turned into an established 
session

Sincerely,

jw