Subject: [mmox] Submission of the Virtual Presence Identity spec as draft

From: Heiner Wolf <[email-masked]>
Date: Wed, 4 Mar 2009 19:24:25 +0100

Hi,

Weblin uses a very light weight protocol for interoperability with
other virtual worlds and internally. It has been used by 3 Mio users
and 25 k concurrent clients. I reformatted and submitted the spec to
show, that the main point of interoperability, namely the
instantiation of avatars can be achieved with a very simple yet
powerful mechanism. It shall serve as a working showcase of light
weight interoperation and as a reference point for the discussion.
Please regard it as a minimum interop protocol to define the problem
space, not as my proposal for the final MMOX result.

Virtual Presence Identity:
http://www3.ietf.org/proceedings/staging/draft-wolf-vp-identity-00.txt

The protocol is Web/HTTP based, actually the transport is HTTP, the
container format is XML and avatar data can use any MIME type. The
architecture is inherently distributed by using basically XML to
organize asset URLs.

The protocol also offers a solution for the "foreign updates" problem,
where the avatar changes in one world and the change should be
displayed instantly in another world. Say your WoW avatar walks in SL
and an effect times out. That should be visible in SL with minimum
delay but also without maintaining long lists of subscriptions. The
protocol has a lean way to communicate changes.

The protocol addresses the "the low hanging fruit" of simulator
interoperability. But it is easily extensible, e.g. to virtual goods
("dragon heads"). It supports variants of avatar models if multiple
formats are required. It provides trust using XML Signature (not
specified here, but in use at Weblin). OAuth is the canonical choice
for access authentication and selective disclosure of identity data.

Best
hw
-- 
Dr. Heiner Wolf
[email-masked]

---

From: Jon Watte <[email-masked]>
Date: Wed, 04 Mar 2009 11:02:19 -0800

> powerful mechanism. It shall serve as a working showcase of light

So, here we disagree on scope and approach. I believe that an 
"interoperability" protocol that includes mechanisms for instantiating 
avatars (as opposed to presenting already-running avatars to the outside 
world) by necessity are technology specific, and by necessity cannot be 
interoperable across technologies.

This is why I think scope, and use cases, are the appropriate discussion 
at this point.

Sincerely,

jw

---

From: Dan Olivares <[email-masked]>
Date: Wed, 4 Mar 2009 14:11:23 -0500

Ok, we've got two wire protocols that are formally proposed to
accomplish this set of goals(goal & scope).   OGP/LLSD proposed by
Meadhbh Hamrick(Linden Lab), and vp-identity/XML(with XMPP presence)
proposed by Heiner Wolf.   Additionally, apparently this one is
implemented in 'weblin' and is 2 years old.  Thanks for proposing it!

Best Regards

Dan

On Wed, Mar 4, 2009 at 1:24 PM, Heiner Wolf <[email-masked]> wrote:
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>

---

From: Heiner Wolf <[email-masked]>
Date: Wed, 4 Mar 2009 23:13:08 +0100

Hi,

> interoperable across technologies.

I would also oppose discussing "mechanisms for instantiating avatars".
I am only talking about avatar data, e.g. 3D models, textures,
nickname. How the data is used is implementation specific. No "common
object model" here. Agreeable?

> This is why I think scope, and use cases, are the appropriate discussion at
> this point.

agreed

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

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Wed, 4 Mar 2009 14:29:52 -0800

yay! awesome!

welcome to the fray!

---

From: Jon Watte <[email-masked]>
Date: Wed, 04 Mar 2009 14:35:56 -0800

> object model" here. Agreeable?

Yes; I think those are necessary for interoperability, and should be 
discussed. Meanwhile, the OGP proposal doesn't talk about that, but 
talks about totally different, non-interoperable things -- like 
instantiating avatars.

In fact, the entire OGP model assumption (clients that understands the 
specific protocol of the exposed simulation server; objects that are all 
developed for the specific runtime model of the specific simulation 
server), in my opinion, may achieve interoperability within one 
particular technology sphere, but actually is a step backwards for the 
vendor neutral interoperability goal. I believe that adopting some 
protocol whose adoption would be detrimental to cross-technology 
interoperability through its very implementation model, would be unwise 
for a vendor neutral interoperability group.

Hence, while there may be "room for all," there isn't "room for 
everything." I honestly don't think there is room for the currently 
proposed OGP, while the charter is "vendor neutral virtual world 
interoperability." Thus, either OGP must change (a lot), or the charter 
must change. Note that the Linden Lab people have publicly said on this 
forum that what they wanted to standardize is a way for the external 
world close to the Second Life technology to interact with the Second 
Life grid. They have given no indication of being interested in the 
vendor neutral, cross-technology aspect, but instead have defended OGP 
as "what they set out to do."

Given that this forum has at least a 10:1 ratio between Second Life/Open 
Sim/RealXTend participants and participants from other technologies, we 
should think very hard about whether the charter is to "provide vendor 
neutral cross-technology interoperability" or to "provide a way for 
external entities to interact with the Second Life grid, and grids like 
it." I came here believing that it's the first. A lot of people came 
here believing that it's the second. I honestly think that the design 
decisions made in scope of the second are actually, at best, orthogonal 
to the first, and at worst, actively detrimental to the first.

Sincerely,

jw

Sincerely,

jw

---

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

then don't talk with us about the things you don't want to implement?

---

From: "Frisby, Adam" <[email-masked]>
Date: Wed, 4 Mar 2009 18:20:05 -0500

To be fair, I think there is some value in supporting non-avatar presences, ie - viewers and guests that don't have a inworld presence.

Adam

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Meadhbh Hamrick (Infinity)
> Sent: Wednesday, 4 March 2009 3:19 PM
> To: Jon Watte
> Cc: [email-masked]
> Subject: Re: [mmox] Submission of the Virtual Presence Identity spec as
> draft
>

---

From: Charles Krinke <[email-masked]>
Date: Wed, 4 Mar 2009 15:27:58 -0800

+1

There has been a siginficant number of requests for anon or guest logins as
we go forward into 2009. I believe that one of the important issues is going
to be how we handle guests or anon or "those without an account in or on a
particular virtual world".

To the extent we make it easy for new folks that are naive in the use of
virtual worlds to visit, view, chat and interact in some small manner, we
will find that the virtual worlds have greater acceptance.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Wed, Mar 4, 2009 at 3:20 PM, Frisby, Adam <[email-masked]> wrote:

> To be fair, I think there is some value in supporting non-avatar presences,
> ie - viewers and guests that don't have a inworld presence.
>
> Adam
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: "Robert Gehorsam" <[email-masked]>
Date: Wed, 4 Mar 2009 15:35:32 -0800

I agree with you, Adam.  There are clearly business use cases that
require this, as the mixed-media efforts (conference call bridges into
SL and/or OLIVE meetings and events, for example) are already
demonstrating.   Not hard to extend this to interop scenarios between
diverse worlds.

Robert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Frisby, Adam
Sent: Wednesday, March 04, 2009 6:20 PM
To: Meadhbh Hamrick (Infinity); Jon Watte
Cc: [email-masked]
Subject: Re: [mmox] Submission of the Virtual Presence Identity spec as
draft

To be fair, I think there is some value in supporting non-avatar
presences, ie - viewers and guests that don't have a inworld presence.

Adam

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Meadhbh Hamrick (Infinity)
> Subject: Re: [mmox] Submission of the Virtual Presence Identity spec 
> as draft
>

---

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

ugh. again with the debate over what "interoperable" means.

maybe we should define it in the charter?

i move that "interoperable" be defined to mean one of the two things:

a. "two genetically distinct implementations implement all or some of  
a defined protocol to implement all or some of the application's  
operational objectives."

or

b. "a system implements all of some of a protocol intended to allow  
communication between multiple, otherwise non-interoperable  
implementations."

On Mar 4, 2009, at 11:02 AM, Jon Watte wrote:

> "interoperability" protocol that includes mechanisms for  
> instantiating avatars (as opposed to presenting already-running  
> avatars to the outside world) by necessity are technology specific,  
> and by necessity cannot be interoperable across technologies.
>
> This is why I think scope, and use cases, are the appropriate  
> discussion at this point.
>
> Sincerely,
>
> jw
>
>

---

From: Jon Watte <[email-masked]>
Date: Wed, 04 Mar 2009 16:44:20 -0800

> then don't talk with us about the things you don't want to implement?

I want to talk about vendor neutral virtual world interoperability. If 
the charter of the group ends up not being that, I won't participate in 
the group. If that is the charter, however, then I believe the group 
should only talk about proposals that actually further the topic of 
vendor neutral interoperability. Simple as that!

Sincerely,

jw

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Thu, 5 Mar 2009 08:00:18 -0800

my point is, if you don't want to place an avatar in a virtual world  
whose protocol defines a technique for placing avatars in virtual  
worlds, then don't exercise that protocol.

for example, just because HTTP supports a DELETE method does not mean  
that your browser MUST support it. in fact, many browsers do not  
generate DELETE requests. but we don't say that browsers are non- 
interoperable and we don't say that HTTP is not an interoperability  
protocol.

perhaps it is possible to define a protocol with options. perhaps one  
option would be "place an avatar in this virtual world." another  
option might be "place a object update observer (camera) in this  
virtual world." because you have separated the two into two different  
actions does not mean OGP is NOT an interoperability protocol.

i don't understand why jon has a problem with this.

-cheers
-meadhbh

On Mar 4, 2009, at 3:35 PM, Robert Gehorsam wrote:

> Of
> as

---

From: David W Levine <[email-masked]>
Date: Thu, 5 Mar 2009 15:03:27 -0500

Over the past few days, people have been tossing around a number of 
phrases, in what I can best describe as a 
frustrating fashion. Of these, "Vendor neutral interoperability" has been 
one of the most problematic. Its has 
been coupled with the phrase "technology specific" solution, which is also 
problematic, in similar ways. 

Roughly speaking I see these phrases being invoked as saying  "This 
proposed solution does not address the
full range of interoperability use cases that might be considered, 
therefore it is not vendor neutral,"

I find this disturbing, because it cloaks a legitimate concern "This 
solution doesn't address all the use cases
we might want to address" with an air of  "and therefore is unfair, or 
invalid, or something we shouldn't do, on the
basis of "not vendor neutral" rather than because of the technical 
concern, or the intersection of the technical 
concern with various people's needs from the process. 

In my thinking, vendor neutral is about "can multiple vendors implement 
this" and "Is it covered by IPR" and "does it unfairly
lock out various participants in the space." These are all valid concerns. 
But, they are also narrow and specific,
and separable from the technical questions of "What does this enable, and 
what does this do." They are also
separable from the question of  "Is this a useful thing to do."  "Is it 
the only useful thing we can do" and "Here is another
useful thing we can do." 

Unclear language  is problematic in several ways. It complicates, and 
distorts our discussion by using a phrase which with
we all largely agree (we like vendor neutral solutions) when the actual 
concern is "This solution is not broad
enough" and perhaps, implicitly, doesn't address a set of issues the 
speaker considers crucial. It is hard enough 
to form consensus across a large number of players. Its much harder when 
we complicate the issues in this
fashion. 

The second concern I see, especially, when tied to "technology specific" 
sets a number of implicit 
requirements, and doesn't put them on the table. The vast majority of 
interoperability specifications
are "technology specific." We strive, as technologists to build broad, 
widely applicable standards, but
we also strive, just as hard to keep the scope of our work manageable. 
Virtual Worlds Interoperability,
taken at its broadest is a huge remit. To make a cogent parallel, there 
are dozens of popular, successful
document interchange formats which provide valuable real world 
interoperability without coming close 
to solving the broad problem of allowing every single document to be 
described with a single specification.
Likewise, there are uncountable specifications for managing images. Very 
real, practical interoperability is
enabled although the vast majority of the specifications are tuned to a 
specific need. 

I am delighted at the range of participants who are expressing ideas here, 
tho, its a tiny fraction of the possible
participants. I think we're starting to ask good questions, raise some 
good issues, and hopefully see some
common threads of interest. At the same time, I don't see how we can make 
progress if the existence
of a broad remit becomes a requirement to solve world hunger, when, we can 
do good, useful things by
seeing if we can feed a few hundred thousand people first. 

I am very strongly supportive of a big tent for this working group, and 
believe we can both focus on concrete
specific interoperability work, of interest to substantial numbers of 
participants, while also looking to the broader
technology space. I'm much less supportive of pushing off work on 
concrete, real steps, while we attempt to
boil the ocean or solve world hunger. I also strongly encourage people to 
chose constructive, inclusive language, and
speak as directly to the concerns at hand as possible. 

- David W. Levine 
~ Zha Ewry (ISL)

---

From: Jon Watte <[email-masked]>
Date: Thu, 05 Mar 2009 12:09:16 -0800

> i don't understand why jon has a problem with this.

I have tried explaining this, but will try again:
My problem is that it tries to standardize almost exactly the wrong 
thing for achieving any reasonable cross-technology interoperability 
scenario. It's a problem of the model, not of the specifics of the protocol.
The model currently enshrined into OGP is one where there is only a 
single technology stack involved in the object/simulation/client 
triangle. The model also enchrines the fact that the viewer/client, and 
the simulator/server, need to understand each other for 
"interoperability" to occur.
I believe that a model that enshrines a "single technology triangle at a 
time" assumption is actually a movement backwards for vendor neutral 
interoperability. It certainly enshrines the idea of a "universal 
client" for virtual worlds, which I believe (and have seen posted on 
this list by others) is a bad idea.

Is that short enough? Is there anything unclear?

Sincerely,

jw

---

From: Charles Krinke <[email-masked]>
Date: Thu, 5 Mar 2009 12:43:11 -0800

I believe it is important to consider the client<->server relationship
interoperability for those virtual spaces/worlds that already have multiple
clients and simulators working with various degrees of interoperability.

In the case of OpenSim and SecondLife and the RexServer, there are already
several different clients, such as:

1. SecondLife offical client
2. Hippo client
3. AjaxLife
4. OpenViewer
5. Xenkii
6. IdealistViewer
7. RexViewer

All of these are active projects and used by thousands of folks currently.
And, I believe that some of those folks look to this group to watch out for
their interoperability interests and not be excluded also.

Charles Krinke
OpenSim Core Developer
OSGrid Director

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

>> my point is, if you don't want to place an avatar in a virtual world whose
>> protocol defines a technique for placing avatars in virtual worlds, then
>> don't exercise that protocol.
>>
>>
> My problem is that it tries to standardize almost exactly the wrong thing
> for achieving any reasonable cross-technology interoperability scenario.
> It's a problem of the model, not of the specifics of the protocol.
> The model currently enshrined into OGP is one where there is only a single
> technology stack involved in the object/simulation/client triangle. The
> model also enchrines the fact that the viewer/client, and the
> simulator/server, need to understand each other for "interoperability" to
> occur.
> interoperability. It certainly enshrines the idea of a "universal client"
> for virtual worlds, which I believe (and have seen posted on this list by
> others) is a bad idea.
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Jon Watte <[email-masked]>
Date: Thu, 05 Mar 2009 12:59:18 -0800

Charles Krinke wrote:
> All of these are active projects and used by thousands of folks 
> currently. And, I believe that some of those folks look to this group 
> to watch out for their interoperability interests and not be excluded 
> also.

I understand that it's important to the users of that particular 
software stack. The question is one of charter, and scope.
If I'm in this group specifically to work on cross-technology 
interoperability, and there are a bunch of technology-specific protocols 
also discussed, then wouldn't I be expected to endorse and comment on 
protocols that I don't use and are of no interest to me?

It seems to me that we need differently scoped groups, with different 
charters.

Sincerely,

jw

---

From: Charles Krinke <[email-masked]>
Date: Thu, 5 Mar 2009 13:06:51 -0800

> In this case, I believe the answer is yes. We should all be expected to
consider the community and rise above our own interests. This is bigger then
any one company.

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: David W Levine <[email-masked]>
Date: Thu, 5 Mar 2009 16:11:50 -0500

So... this is an interesting topic.

Interop, in the large, is clearly bounded by places where various elements 
diverge.  In the current collection of virtual worlds implementations,
we have model divergence in a huge number of areas. These include what 
types of 3d objects we model, how we manage the distribution of
state within our worlds, how we off-load various tasks to different parts 
of the computer infrastructure, and a list which covers pretty much
every design choice possible when assembling a virtual immersive space. 

A number of proposals are on the table to bridge various parts of these 
model differences. Each and every one requires some overlap
in core models to be able to generate interop, and the various existing 
worlds differ enough that they will inhibit using one approach, or 
another,
or in some cases, many of the approaches which have been discussed. 

Jon observes that, with an OGP like approach, you need to have clients 
which are compatible with the set of content, and delivery style 
shared by the regions you wish to connect to.  Yes. Tho, one can observe 
that the OGP documents describe sets of services, and you can
factor and deploy these services in a number of ways, which are 
significantly more flexible than the current model used within OpenSim and
SecondLife. If you look at the overall set of services described in OGP, 
it describes a model for signaling between simulations
and, to an extent, describes *one* model for signaling between clients and 
simulations.  There is a great deal of room for web style content 
negotiation
and there is also very little said about what might happen at the client 
side of the experience when handing off between virtual spaces. It would 
not
be hard, at all, for the new region to signal to a client 'Here is the 
type of simulator I am, you'll need to handle this" 

I observe further, that a great many very successful specifications fall 
very much into this shape. HTTP is used exactly this way throughout the
web. There is no assurance, whatsoever, that a URL will deliver content 
viewable by all users. In fact, quiet the contrary. We often find a URL
leads us to an item which cannot be rendered by our browser, because we 
are missing a plug-in, or we don't support a feature, such as ActiveX
or Javascript. In the web, we may be turned away at the door by an HTTP 
server, if we do not have a matching certificate, or support a certain 
style of
authentication. 

Different approaches at solving model mismatches let us solve different 
sets of problems. None is a panacea. Co-simulating an OpenSim style region 
with rich
second life style content with an OLIVE region will not let the OLIVE 
users see the content which exploits SL specific affordances on the SL 
client, unless there
are matching affordances, and a mechanism to express those matches. If 
virtual A uses avatars with skeletons based on one scheme, and they are 
presented by
that world's client, then users co-simulating in virtual world B, will be 
unable to properly see the avatars, unless, again, the client they are 
running has the ability to present similar
skeleton based avatars, and the model mismatches are bridged. 

Worlds which perform entirely client side physics won't be helped directly 
by cosimuation with worlds which perform entirely host side physics. 

Croquet depends on low level capabilities in its t-object model to 
generate certain effects. People wishing to interoperate with such spaces, 
will have to
bridge into that model. 

I think it is premature to say any one model solves more or less problems. 
I know it is premature to say an approach which has not been implemented 
solves
problems when half an hour of thoughtful consideration raises dozens of 
issues which the approach would have to manage. 

I am very supportive of broad, inclusive discussions of these issues. I 
have learned a lot about various approaches in the past week and I look 
forward to learning much more. 

- David W. Levine
~ Zha Ewry (ISL)

---

From: Charles Krinke <[email-masked]>
Date: Thu, 5 Mar 2009 14:34:23 -0800

I need to amplify this a little bit as the guy on point between
interoperability and compatibility between OpenSim and the various client
currently being used. Each day, I answer dozens of E-mails and IRC's about
functionality (or lack thereof) of testing between OpenSim, the SL client
(currently 1.21.6), the Hippo client, IdealistViewer, RexClient and the
others.

To the extent these various clients interop with OpenSim, things go
smoothly. To the extent, they dont interop completely, things go poorly.

So, I would suggest that there is a significant part of the community that
is interested in interop between various clients and various sims similar to
SecondLife, OpenSim and some derivatives like 3Di, RexServer and others.

I believe we would be doing a dis-service to not include this
client<->server interop at least in our discussions as 1) They exist. 2)
They are in use by thousands or hundreds of thousands of folks 3)
Development, testing and deployment is ongoing.

Charles

---

From: Jon Watte <[email-masked]>
Date: Thu, 05 Mar 2009 15:03:04 -0800

Charles Krinke wrote:
>     interoperability, and there are a bunch of technology-specific
>     protocols also discussed, then wouldn't I be expected to endorse
>     and comment on protocols that I don't use and are of no interest
>     to me?
>
>
> In this case, I believe the answer is yes. We should all be expected 
> to consider the community and rise above our own interests. This is 
> bigger then any one company.

Right. So if there is a technology specific protocol that I believe:
1) Only benefits one particular technology, and
2) Actually drives the method and approach for cross-vendor 
interoperability in the wrong direction
wouldn't I then have to actually be opposed to that protocol?
Wouldn't it be better if the single-technology protocols were done in a 
different forum, for both me (who only care about cross-technology 
technologies), and for those interested in that particular technology 
(who don't need to hear opposition from people like me).

Note that this has nothing to do with which particular technology it is. 
It has to do with the proposed model moving the cause of 
cross-technology interop backwards, by entrenching a 
non-cross-technology worldview in a standard protocol. This is the 
reason I'm not offering up existing OLIVE protocols in this group, 
because I don't think it makes sense to standardize a protocol that 
currently believes that there will only be one technology base involved.

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Thu, 05 Mar 2009 15:17:57 -0800

David W Levine wrote:
> SecondLife. If you look at the overall set of services described in 
> OGP, it describes a model for signaling between simulations
> and, to an extent, describes *one* model for signaling between clients 
> and simulations.  There is a great deal of room for web 

I believe that attempting to standardize a client/server signaling 
protocol for cross-vendor interop is harmful.

> type of simulator I am, you'll need to handle this"

Leading to a requirement for each client to handle all possible 
protocols. I believe this is a harmful direction.

> I observe further, that a great many very successful specifications 
> fall very much into this shape. HTTP is used exactly this way 
> throughout the
> web. There is no assurance, whatsoever, that a URL will deliver 
> content viewable by all users. In fact, quiet the contrary. We 

I believe HTTP is not a good analogy, because simulation is quite 
different from serving web apps and static pages, at the core. A better 
analogy would be streaming web video.
The streaming video vendors could not agree, so I have to have four 
different plug-ins installed on my machine, and I can't build mash-ups 
that pull video from two different sources, because FLV isn't compatible 
with ASF isn't compatible with QuickTime isn't compatible with Real.
It would be really sad if that turned out to be the case for virtual 
worlds, too. If I have to enter a Microsoft world, or an Apple world, 
and I can't get to one from the other, because they each have their 
totally vertically integrated stacks. OGP, by the way, makes the 
assumption of a vertically integrated stack. I believe that assumption 
is harmful.

> virtual A uses avatars with skeletons based on one scheme, and they 
> are presented by
> that world's client, then users co-simulating in virtual world B, will 
> be unable to properly see the avatars, unless, again, the client they 
> are running has the ability to present similar

Yes; it's up to us to define what the commonality interop formats look 
like. Solving "what does an animated mesh look like" is comparatively 
easy, because there are already standards we can use. COLLADA, X3D or 
MPEG-4 meshes come to mind.

I agree that no single proposal will expose everything to everyone. But 
that's not what we're trying for, is it?. What I believe we're trying 
for is a 90/10 solution that enables true cross-technology interop, so 
that "which vertically integrated technology stack are you using" 
doesn't have to be asked when users A and B want to meet, or do 
something common together. Sure, if you want to actually build UGC, or 
compete in a fast-paced shooting game, or something similar and 
world-specific, you'll need tighter coupling -- but that's the 10% case, 
not the 90% case.

Also, I keep saying this, and people keep accusing me of being tied to 
some vast right-wing conspiracy of the military-industrial complex: 
Simulation interop is not new. There's lots of experience to be had, if 
you can just stomach the fact that perhaps someone else already solved a 
similar problem before. What I've found, through research and actual 
integration in the past, is that the DIS model works. The HLA model 
doesn't work. LESS is more like DIS. OGP is more like HLA. (the 
comparisons aren't perfect at the technical level) Shouldn't we learn 
from that?

Sincerely,

jw

---

From: Kajikawa Jeremy <[email-masked]>
Date: Fri, 06 Mar 2009 10:43:23 +0900

Would having a list of *recommendable* material for inclusion into an
implimentation
  allowing for an openly interoperable connection point be useful?

as I am aware of the telepathy stack and it may be useful as an example
for plugging
  multiple similar protocols together...

Would a similar multiprotocol "hub" location be useful between VW's ?

Im trying to think of some kind of bubble inside bubble idea here...
  similar to how LESS plugs a module of one VW into another host VW
  for a limited "shard of shared space" inside the hosted area...

Im more seeing OGP as being a Client<->Server model and
  LESS as Server<->Server and matching...

allow an optional "ignorable" for clients to know "shared" regions and
"cross"
  the bubble?,  dont limit crossing VWs to requiring a teleport... how
about
  a transparent "cross the border" like crossing from one region to
another
  in SL terminology.
  that way there is no need for Stargate/Teleporter/ or other "device"
concepts...
  just walking like crossing the street between city blocks...
  Walk from the "mall"(SL?) to a Corporate Park(custom?) followed by
entering
  a specific "Corporate park building" and entering a specific business
office space...

I know of a couple of places where this can occur in the real world and
I am 
  trying to think of a means of modelling such in VW spaces.

Jeremy

On Thu, 2009-03-05 at 15:03 -0500, David W Levine wrote:
> frustrating fashion. Of these, "Vendor neutral interoperability" has
> been one of the most problematic. Its has 
> been coupled with the phrase "technology specific" solution, which is
> also problematic, in similar ways. 
> 
> In my thinking, vendor neutral is about "can multiple vendors
> implement this" and "Is it covered by IPR" and "does it unfairly 
> lock out various participants in the space." These are all valid
> concerns. But, they are also narrow and specific, 
> and separable from the technical questions of "What does this enable,
> and what does this do." They are also 
> separable from the question of  "Is this a useful thing to do."  "Is
> it the only useful thing we can do" and "Here is another 
> useful thing we can do." 
> 
> we all largely agree (we like vendor neutral solutions) when the
> actual concern is "This solution is not broad 
> to form consensus across a large number of players. Its much harder
> when we complicate the issues in this 
> fashion. 
> 
> The second concern I see, especially, when tied to "technology
> specific" sets a number of implicit 
> taken at its broadest is a huge remit. To make a cogent parallel,
> there are dozens of popular, successful 
> Likewise, there are uncountable specifications for managing images.
> Very real, practical interoperability is 
> enabled although the vast majority of the specifications are tuned to
> a specific need. 
> 
> I am delighted at the range of participants who are expressing ideas
> here, tho, its a tiny fraction of the possible 
> common threads of interest. At the same time, I don't see how we can
> make progress if the existence 
> of a broad remit becomes a requirement to solve world hunger, when, we
> can do good, useful things by 
> I am very strongly supportive of a big tent for this working group,
> and believe we can both focus on concrete 
> boil the ocean or solve world hunger. I also strongly encourage people
> to chose constructive, inclusive language, and

---

From: Charles Krinke <[email-masked]>
Date: Thu, 5 Mar 2009 18:15:30 -0800

Dear John:

We are here to consider all the implications of virtual world
interoperability. There are many implications and considerations. The notion
of how clients talk to servers is an interesting, important and valid part
of interopability and is analagous to "flat web" browsers like Firefox and
IE interoperating with web servers like Apache and IIS.

As we move from the "flat web" and off to the 3D web, we need to work out
the details of how the various clients and servers evolve so we do not end
up in our seperate "balkanized" areas.

One of the things we will be judged on is our ability to find a vision for
moving forward into the 3D web. So, lets find a way to work together and not
at cross-purposes, please.

Charles Krinke
OpenSim Core Developer
OSGrid Director

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

> Do you honestly believe that the implementation internals of one particular
> technology stack should be mixed with the discussion of vendor-neutral,
> cross-technology interoperability?
> In what forum has that ever worked out?
>
> Sincerely,
>
> jw
>
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Kajikawa Jeremy <[email-masked]>
Date: Fri, 06 Mar 2009 13:00:53 +0900

My thoughts on this is more to specifically stating when Client<->Server
  interop is seperated from Server<->Server Interop...

Additional to that...

 When relocating across VW areas (SL region->region) or wandering an
MMORPG...

Is there any room for change of VW hosting the presence during its
wandering
  across VW boundaries ?

because I was considering the use case where you enter an MMORPG like
entering
  a themepark in the middle of an SL "town" landscape...

Or enter a business complex from the edge of the "town" landscape above
and
  need to change authentication to the new area...

Is there anything like this on the table as a use-case ?

instead of modelling a *fixed* location... I want to question how
interop may be used
  for having an MMORPG "gateway" accessible within another environment.
  for having a Business "gateway" providing authentication change and
client change
  without loss of connection.

some kind of Interop where Web/SecondLife/GuildWars/WoW is able to have
a
  plugin or *optional* connection to a cross-connectivity stack of some
kind.

Instead of Teleporting or having another quickchange between
environments...
  How would a *smooth* transition or translation occur?

or is that the primary focus of this entire interop effort?

For each "system-connect" provide to the user for the following use case
--brief--
"Login" to Home Location,  and "movement" from that home location
  (Private VW server?) into a "common area" which may be an explicit
change,
  followed by flight or other "movement" into a gaming or business
environment.
--brief--
Is the game an MMORPG?("WoW"/"GW"/or other system?) or
  "Shooting Range"(UnrealTournament / Hex / Quake series / ... )

In the case of each game an in-world "gateway" or "airport" scenario
would be
  plausible for keeping some kind of seperation (limited-shared-space
for change
  of authentication/connection details?)...

Existing clients are currently within the SL scope have partial
capabilities for the
  above scenario...

Im deliberately trying to form an abstraction that makes sense towards
defining
  what is common to the user experience and not common to the systems
  development requirements.

My knowledge of Virtual Worlds does not include "Snowcrash" and I know
  I would consider any immersive capable environment changes jarring if
there\
  is not some *clear* delimiter markings on area borders ...

What about triggering as part of a "region crossing" or other entry into
a
  "shared space" which involves 2 or more inter-op servers the
capability
  for the client to "cross" to any VW system connected by the shared
space
  where the user has credentials or existing credentials provide
permissions.

This indicates to me needing both a defined Client<->Server Interop
abstraction,
  for a "Universal Client" to at least be capable of limited entry and
also
  for a Server<->Server Interop protocol stack that includes some kind
of
  query/response for capabilities of the two servers that will "bubble"
a mirror of
  each other for a "simplex view" of the alternate VW environment
area...

When alice followed the white rabbit,  there was the hole
  (the hole itself may be a shared region), ...

in the Stargate movies and TV series... the Stargate itself has a
limited "Wormhole"
  view of spacetime (similar to the "warp effect" in star trek series
for the starscape)

to my knowledge there is always going to be need of some kind of systems
  bridging between any VW areas... so recognition of different models
and allowing
  for groups of messagetypes based on any given combination being
bridged...

Whats needed for the bridging systems?

System to System chat...MSN/Jabber/SL/other? ...
  common message to all protocols?
  sender has transport associated with receiver?
  Do we need chat as part of Interop? or only "presence online" for
awareness?

Do areas of VW space provide common communications in addition to a
  shared workspace?

Workers in the same company may have a shared VW workarea in addition to
  VW Officespace...

What happens if two depts use seperate VW tech for such mechanisms...
  do we *need* anything more than something akin to an RSS feed for
contact list
  changes?

Im just trying to get a working concept of what the use cases defined
*need*
  and what else may be *useful* so that other people can also experiment
with
  connecting non-same VW systems.

Jeremy

 Thu, 2009-03-05 at 14:34 -0800, Charles Krinke wrote:
> interoperability and compatibility between OpenSim and the various
> client currently being used. Each day, I answer dozens of E-mails and
> IRC's about functionality (or lack thereof) of testing between
> OpenSim, the SL client (currently 1.21.6), the Hippo client,
> IdealistViewer, RexClient and the others.
> 
> So, I would suggest that there is a significant part of the community
> that is interested in interop between various clients and various sims
> similar to SecondLife, OpenSim and some derivatives like 3Di,
> RexServer and others. 
> 
> client<->server interop at least in our discussions as 1) They exist.
> 2) They are in use by thousands or hundreds of thousands of folks 3)

---

From: Morgaine <[email-masked]>
Date: Fri, 6 Mar 2009 04:45:50 +0000

Very well put:

On Thu, Mar 5, 2009 at 4:00 PM, Meadhbh Hamrick (Infinity) <
[email-masked]> wrote:

> for example, just because HTTP supports a DELETE method does not mean that
> your browser MUST support it. in fact, many browsers do not generate DELETE
> requests. but we don't say that browsers are non-interoperable and we don't
> say that HTTP is not an interoperability protocol.
>
> option would be "place an avatar in this virtual world." another option
> might be "place a object update observer (camera) in this virtual world."
> because you have separated the two into two different actions does not mean
> OGP is NOT an interoperability protocol.
>
>

I agree with Infinity's point here 100%.  It's a key aspect of
interoperability that interoperating partners get to choose their common
ground.  Without that, one would be MANDATING a common architecture, and
that's completely the opposite of being vendor and architecture neutral.

Morgaine.

On Thu, Mar 5, 2009 at 4:00 PM, Meadhbh Hamrick (Infinity) <
[email-masked]> wrote:

> for example, just because HTTP supports a DELETE method does not mean that
> your browser MUST support it. in fact, many browsers do not generate DELETE
> requests. but we don't say that browsers are non-interoperable and we don't
> say that HTTP is not an interoperability protocol.
>
> option would be "place an avatar in this virtual world." another option
> might be "place a object update observer (camera) in this virtual world."
> because you have separated the two into two different actions does not mean
> OGP is NOT an interoperability protocol.
>

---

From: Kajikawa Jeremy <[email-masked]>
Date: Fri, 06 Mar 2009 14:26:59 +0900

Thats why I am trying to consider the entire colloborative effort
involved here
  as being *optional* for any VW systems interconnection...

Shall we define a simple "presence awareness" protocol mechanism ?

or should be define some *example* uses of existing protocols usable for
  this effort?

as I am personally seeing a LOT over overlap from existing protocols
that can
  be re-used as "binding" material for VW "presence" or other...

beyond tying an Identity to being present at a given location that may
have
  2 or more VW systems "sharing" the location presentation...

What are the existing "styles" of system stacks... and what do they
*need* for
  ghosting across "presence" of objects in the "shared space" presented
from
  outside.

THAT appears to be the primary use-case here...

  first,  presenting a combined "shared space" thats composite from two
VW stacks,
  Second,  object notifications,  update of state,  is this to even
occur beyond
  "view" and an objects "location" information if it is an AV?

Is this anything like what you had in mind ?

Jeremy

On Fri, 2009-03-06 at 04:45 +0000, Morgaine wrote:
> Very well put:
> 
> On Thu, Mar 5, 2009 at 4:00 PM, Meadhbh Hamrick (Infinity)
> <[email-masked]> wrote:
> 
>         my point is, if you don't want to place an avatar in a virtual
>         world whose protocol defines a technique for placing avatars
>         in virtual worlds, then don't exercise that protocol.
>         
>         for example, just because HTTP supports a DELETE method does
>         not mean that your browser MUST support it. in fact, many
>         browsers do not generate DELETE requests. but we don't say
>         that browsers are non-interoperable and we don't say that HTTP
>         is not an interoperability protocol.
>         
>         perhaps it is possible to define a protocol with options.
>         perhaps one option would be "place an avatar in this virtual
>         world." another option might be "place a object update
>         observer (camera) in this virtual world." because you have
>         separated the two into two different actions does not mean OGP
>         is NOT an interoperability protocol.
>           
> 
> 
> interoperability that interoperating partners get to choose their
> common ground.  Without that, one would be MANDATING a common
> architecture, and that's completely the opposite of being vendor and
> architecture neutral.
> 
> 
> Morgaine.
> 
> 
> 
> 
> 
> 
> 
> 
> On Thu, Mar 5, 2009 at 4:00 PM, Meadhbh Hamrick (Infinity)
> <[email-masked]> wrote:
>         my point is, if you don't want to place an avatar in a virtual
>         world whose protocol defines a technique for placing avatars
>         in virtual worlds, then don't exercise that protocol.
>         
>         for example, just because HTTP supports a DELETE method does
>         not mean that your browser MUST support it. in fact, many
>         browsers do not generate DELETE requests. but we don't say
>         that browsers are non-interoperable and we don't say that HTTP
>         is not an interoperability protocol.
>         
>         perhaps it is possible to define a protocol with options.
>         perhaps one option would be "place an avatar in this virtual
>         world." another option might be "place a object update
>         observer (camera) in this virtual world." because you have
>         separated the two into two different actions does not mean OGP
>         is NOT an interoperability protocol.
>         
>                 From: [email-masked]
>                 [mailto:[email-masked]] On Behalf Of
>                 Frisby, Adam

---

From: Morgaine <[email-masked]>
Date: Fri, 6 Mar 2009 08:05:36 +0000

I liked that post, Zha.  I think it will help us focus.

Phrases like "vendor-neutral" are powerful because everyone agrees with the
message they carry, but that also makes them dangerous and unhelpful if used
as placeholders for a more specific argument with which not everyone may
agree.  This makes your exhortation to "address the real issue" rather than
to pin up *motherhood and apple pie* labels an important one.

I would like to add one more distinction that is often lost:
"vendor-neutral/specific" and "technology-neutral/specific" often get mixed
up with "architecture-neutral/specific" too, and this sows further
confusion.

For example, if SL and Opensim were to become fully interoperable, then
their interop protocol would no longer be vendor-specific (assuming no IPR
intrudes), but it is easy to see that such interop *might* very well be
architecture-specific and hence not successful beyond certain architectural
assumptions.

Whether such interop would be technology-specific or not depends entirely on
the technology being discussed at the time:  for example it would be highly
technology-specific at the app/transport level in using HTTP/TCP/IP alone
(to which I've not heard any objections), hopefully less technology-specific
if it relaxes its dependency on JPEG2000 for textures (given the numerous
objections), while being technology-neutral at the implementation level
through LL using C++ and Opensim using C#.  So it depends on the details.

Such generic labels don't help.  Being skilled technical people and not
soundbite politicians, we should say what we actually mean.

Just to show my even-handedness though, I'll take you to task for using the
phrases "solve world hunger" and "[not] boil the ocean".  They too are
*motherhood
and apple pie* labels, and not helpful. :-)  We should be specific on the
areas to include and exclude.  Indeed, it will be one of our most important
tasks to define this in the months ahead, far more concretely than in the
brief charter.

Morgaine.

On Thu, Mar 5, 2009 at 8:03 PM, David W Levine <[email-masked]> wrote:

> basis of "not vendor neutral" rather than because of the technical concern,
> or the intersection of the technical
> separable from the question of  "Is this a useful thing to do."  "Is it the
> only useful thing we can do" and "Here is another
> useful thing we can do."
>
> to form consensus across a large number of players. Its much harder when we
> complicate the issues in this
> fashion.
>
> taken at its broadest is a huge remit. To make a cogent parallel, there are
> dozens of popular, successful
> participants. I think we're starting to ask good questions, raise some good
> issues, and hopefully see some
> technology space. I'm much less supportive of pushing off work on concrete,
> real steps, while we attempt to

---

From: Morgaine <[email-masked]>
Date: Fri, 6 Mar 2009 10:31:23 +0000

That was a very interesting post Jeremy, and it made me think a lot about
movement and transitions between and through virtual world spaces.

The main thing that I abstracted from it is that the diversity of mechanisms
that trigger or enable movement or transitions is unbounded, and that the
perceived result ranges from none at all (smooth continuity), through to the
horrible experience we know today as "zoning".

Given the open-ended diversity of virtual worlds, I am torn between not
addressing the issue of world transitions at all in the protocol, and
providing adequate support for it in an extensible way:  for example, by
making scenegraphs addressable (at least 1..2) so that updates can be
double-buffered if a discontinuity is forthcoming to avoid the miserable
zoning experience.

This is another area that needs to be examined for technology-specificity:
if a particular region mechanism forbids access to the objects of two
different regions concurrently, then it is hardwiring in one particular
choice of transition technology, which we would need to oppose.   After all,
VWs employing region virtualization may have no need for discontinuous
transitions whatsoever, and therefore making such transitions non-optional
in the protocol would be totally incorrect.

This is sure to become relevant when the time arrives to examine the
implementation requirements of the protocols that are on the table.

Morgaine.

---

From: Kajikawa Jeremy <[email-masked]>
Date: Fri, 06 Mar 2009 20:46:51 +0900

Well that is the ultimate vision I have for when the VW interop is
beyond simply
  "IM presence" style notification of contact listings regardless of
system.

What I have in mind is the requirement of a "doubled-boundary" condition
implicit
  for the most smooth transitions...requiring both client AND server
interop support.

a "Generic Client" stack with *basic* support for many systems... and
"Server" stack
  where each system can have plugins for the "open" systems available.

my thoughts lead me towards the first foundation of anything being the
recognition
  of *transitory* users "presenting" within a fixed region in any VW...

these "fixed regions" are Host VW "bubbles" of a non-Host-system VW
"gateway"
  and will need to be hosting a double-system...

an example would be a Croquet / SecondLife(OSgrid) region
"connection"...

at such a boundary I consider entry to the region requiring an "interop"
capability
  recognised from both the Croquet and SecondLife/OpenSIM servers
presenting
  the "shared space" or "shared boundary"... this would require a region
that is
  served in Croquet by a Croquet server alongside a mirror using
OpenSIM,

as such my thoughts are that entry into that server trigger a client
notification of
  "interop" is present... allowing the client to "login" to the
additional area by some
  change of protocol module (the Free/Open Software OGP client stack)...
  so either we "bubbleboy" each AV at the "last mile"... or provide for
"bubbleboy"
  and have the originating server showing a proxy representation of
non-client media.

J.Waite is proposing LESS towards a Service provided "proxy bubble"
approach and
  I am seconding that proposal for the beginnings of interop... (we
*will require this),
  alongside having the *option* of a trigger to enable change-of-client
or hosting ID.

Allow for the capability where a client can accept and transition the
user OR where
  the server may require to "bubblewrap" the client for viewing
additional media.

When I am refering to change of client... I am considering the
following...
  and please excuse the tech-centric terms here...since Im using
experiences I know.

I log-in online,  Open my web browser and also SecondLife client
connecting to
  OSgrid.org...additionally opening "pidgin" or "empathy" for
IM/Chat/VoIP...

Walking around I go to the "Guild Wars" or "SecondLife" gateways...

Entering the "SecondLife" gate-region I can at that time *opt* as a user
  to either "continue" to the LL SecondLife or NCsoft "Guild Wars"
system,...

choosing to Enter "Guild Wars" I would require to change from the
SecondLife
  client-tech to the "Guild Wars" custom client, ... 
  can I perform the transition ?

OSgrid.org to SecondLife... an OGP client can simply walk across needing
a "new"
  temporary avatar showing my username and originating system
 ("Freija [email-masked]")...

OSgrid.org/SecondLife to "Guild Wars" this is a "hard" boundary
requiring a program
  change...can this be done during crossing the "gate server" ?

OSgrid.org crossing to a Croquet hosted system... do we keep am OpenSIM
instance
  for showing the "croquet" content by plugging a "croquet" translator
to it ?

these are the types of scenarios from the use cases I am seeing...

Im not seeing use cases for "specific" system events like simulating a
hospital for
  emergency response planning...

but more for "open landscape" zones...

look at the real world and mirror...  how would you break an area into
something a computer can simulate?

we dont have to consider ALL the VW spaces to be bounded the same as
real spaces
  as a "Klein bottle" landscape CAN be applied for an "indefinite
length" field...
  it only requires the simulation to provide the region border
connections or
  mapping service support.

Which brings up another consideration...

  How does each system "map" locality (AV relative placement within a
scene)...

each simulation will require a "scale" as part of the interop...

so defining a "zone of gate region" and common scale agreement when the
people
  for the system define the connecting policy...  do they provide for a
client capability?
  or "bubbleboy" visitors?

Just some more food for thought,

  Jeremy

On Fri, 2009-03-06 at 10:31 +0000, Morgaine wrote:
> That was a very interesting post Jeremy, and it made me think a lot
> about movement and transitions between and through virtual world
> spaces.
> 
> The main thing that I abstracted from it is that the diversity of
> mechanisms that trigger or enable movement or transitions is
> unbounded, and that the perceived result ranges from none at all
> (smooth continuity), through to the horrible experience we know today
> as "zoning".
> 
> Given the open-ended diversity of virtual worlds, I am torn between
> not addressing the issue of world transitions at all in the protocol,
> and providing adequate support for it in an extensible way:  for
> example, by making scenegraphs addressable (at least 1..2) so that
> updates can be double-buffered if a discontinuity is forthcoming to
> avoid the miserable zoning experience.
> 
> This is another area that needs to be examined for
> technology-specificity:  if a particular region mechanism forbids
> access to the objects of two different regions concurrently, then it
> is hardwiring in one particular choice of transition technology, which
> we would need to oppose.   After all, VWs employing region
> virtualization may have no need for discontinuous transitions
> whatsoever, and therefore making such transitions non-optional in the
> protocol would be totally incorrect.
> 
>         > smoothly. To the extent, they dont interop completely,
>         things go
>         > poorly.
>         >

---

From: Charles Krinke <[email-masked]>
Date: Fri, 6 Mar 2009 06:50:58 -0800

Actually, Jereme, there have been a lot of posts about "ghostly presence" of
avatars from one point of view.

There are those of us who feel that an interop consists of the avatar moving
(or teleporting) from one virtual world to another. Along with that comes a
number of other things such as interaction with that world. So, I would say
that "ghostly presence" as described by LESS is, well, less then I would see
we are certainly capable of. Some might say it is a "mere shadow" of what we
can do.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Thu, Mar 5, 2009 at 9:26 PM, Kajikawa Jeremy <[email-masked]>wrote:

> >                         [mailto:[email-masked]] On Behalf

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Charles Krinke <[email-masked]>
Date: Fri, 6 Mar 2009 09:45:20 -0800

There has been a bit of mis-understanding leading folks to lump SecondLife
and OpenSim servers into the same "pot" and I think at this point it would
help for us to understand that they are different.

They are different code bases written in different languages. The OpenSim
sim server strives to be compatible with the SecondLife servers as one of
its use cases, but, again, they are different.

I applaud your post, Jereme, and dont want to rain on the logical parade at
all, but merely to try to dispell some of the FUD a bit as we consider
interop between various examples.

Charles Krinke
OpenSim Core Developer
OSGrid Director

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

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

> Is there any room for change of VW hosting the presence during its

The presence hosting remains at the MMOX endpoint, regardless of the
client-server details. There is no way we can get all the very
different internal structures of VWs to conform enough to each other
that every possible case will fit in the protocol. Instead, it makes
more sense to abstract it away uniformly.

For example, your SL avatar's presence resides in the region simulator
in the current SL implementation. That makes this region sim the
MMOX-layer endpoint for cross-VW presence: when your avatar "wanders
off world" it is still the region simulator your client remains
connected to that will manage your presence, as far as the other VWs
are concerned. The SL viewer client will see nothing of it and won't
have to manage an exotic connection with a foreign (=non-SL) server.
The region sim, as the MMOX endpoint relevant for this service,
manages the presence for you and exchanges common representation data
with the outer VW, maintaining a shared simulation state on behalf of
your SLviewer: presence of other "avatars" from the foreign VW is sent
to the region sim, and converted into the SL-specific sim-viewer
information that corresponds to such a presence.

If you TP to an OpenSim server, which has the SL-specific sim-viewer
capability necessary, then the entire presence session is handed over
to the new OpenSim server, but that happens outside of MMOX and is
platform-specific. At most, the MMOX protocol will only serve for
signalling that such a "bypass" is possible (the SL Region Sim
contacts the OpenSim server through MMOX for opening a Presence
service exchange, and they then realize they both "speak SL" in this
regard, and happily proceed to connecting to each other through the
SL-specific way instead).

Further, let's say your avatar is standing in the SL region Everlite,
and that region is topologically-connected to a non-SL node called
"Evernite", from a (fictitious) P2P VW called Manyverse. This "alien"
location is represented in the region by a large floating platform.
You walk your avatar onto it: Everlite@SL locally caches the topology
service (= it knows it's connected to Evernite@MV, and how to address
it) - I think the authority for topology, in the SL implemention, is
the Space Server, but otherwise Everlite@SL is the MMOX endpoint for
presence, object representation and simulation, and chat, while the SL
Session Server (I'm stretching my meager knowledge of SL
implementation here) is the MMOX endpoint for identity, IM, inventory
; and the SL viewer is the MMOX endpoint for Audio+Video Streaming
(this is for illustration).

So when your avatar enters in "mutual presence" contact with Evernite,
here's what supposedly happen:
The SL session server connects to Evernite's identity, IM, inventory
MMOX interfaces if they exist (the IM and identity interfaces exist
and respond, the inventory interface is accessible only to the owner
of Evernite and the connection is denied).
Everlite connects to Evernite's presence, object representation and
simulation MMOX interfaces.
Your viewer connects to Evernite's Audio and Video streaming MMOX interfaces.

(The important thing to remember is that an open connection between
two MMOX nodes means there is congruency/interaction/mutual presence
between those two nodes: the state of the connection encodes the state
of mutual simulation sharing. No connection = no sharing of
simulation, connection over the presence domain = mutual presence,
connection over the messaging domain = intermessaging.

In this example, both Everlite and Evernite share topological - one
might say geographical - simulation space and thus they maintain a
topological connection. This topological connection is of the "is
contained within" sort because that's the only one I can imagine an SL
region server enact without a major reworking of SL that I do not want
to unroll here, but other sorts may exist like "is contiguous to",
"contains", "portals to", etc. The other services can refer to this
topological link as needed: chat, script RPC, 3D representation,
dynamics, etc. they all have topological underpinnings so they cast
across all topologically-relevant entities reachable across MMOX. In
simpler words, if you enter chat "next to" an "alien" avatar running
on the other side of an MMOX connection, it wants to be able to hear
it, so the chat MMOX PDUs follow the topological connection if it is
relevant (if the topological "joint" is within 20 meters ?).)

Evernite does not have video streaming, but it has audio streaming: it
sends to your viewer the MMOX PDU for the new audio streaming URL to
use, and null for the video one (or it specifies the absence of video
streaming during connection negociation). Your SL viewer is still
connected to the SL session server and the Everlite region sim as far
as the other services go, through the SL-specific protocols for these
services.

(note: each connection over a domain is authenticated, presumably with
an auth token passed down from the session server to the region and to
the slviewer when you logged into SL)

Everlite receives the MMOX PDU for presence, representation and
simulation relevant for Evernite, and extracts the relevant parts to
pass down to the SL viewer as per SL client-server protocol. My avatar
is present there, and so is a scripted table. Let's say MMOX has a
common representation format for all those things and the SL Region
simulator can make it into a SL representation for your viewer: that
is what it feeds your client, and there my avatar and the table are on
your screen. The data goes the other way too: Evernite receives MMOX
presence PDU from Everlite, then the accompanying representation data,
and that's how I get to see your avatar. I type "Hi!" in the chat, the
data is encoded in a MMOX chat/general messaging and sent to the
endpoint for that service on your side: the Everlite region sim, which
then notifies your viewer so you can read it.

The table reacts to the presence through its scripting and IMs you
with a welcome message (it's a very polite table). The MMOX endpoint
for IM on your side is the SL session server, that's where the MMOX IM
PDU lands, and the data is transferred in the SL-specific way to your
viewer from there.

(As you can see, Evernite treats the whole SL grid as a peer through
the MMOX protocol, because it has MMOX endpoints at many different
levels.)

Your avatar is wearing a scripted attachment, but Evernite is a
Manyverse simulation, very different from SL in the way it works, and
as such it only runs and represents local objects in the native
format, serving their Irrlicht 3D models and running their Lua scripts
- it only caches MMOX representation and presence data from non-MV
worlds for the purpose of MMOX compliance. At this point, either your
attachment remains "rezzed" and running in the SL Region sim (using
data obtained through MMOX, for example there may be a common "Sensor"
or "GroundLevel" RPC function the LSL VM can call across MMOX on
behalf of the script ?), visible to me through the MMOX exchange of
presence and representation data between Everlite and Evernite, or the
attachment is only visible to me and not "running" anything in my view
if there is no RPC possible between the execution environments of
Everlite and Evernite.

Let's say you set your new home location to that place, but that Home
Location is a service not included in MMOX. IIRC it is the SL Session
server that keeps track of your home location, so it'll have to either
reject your request, or record it in a way that makes sense so that
the next time you login to SL your avatar is run by a SL simulator
that is connected to Evernite (that'll be the neighbouring Everlite,
again).

Let's recapitulate the span of MMOX connections exemplified here:

SLViewer <-(prims and textures)-> [Region Sim <-(MMOX representation
data)-> Manyverse node] (3D representation)

SLViewer <-(SL-IM)-> [SL Session Server <-(MMOX-IM)-> MV node] (IM)

[SLViewer <-(MMOX-AudioStream)-> MV Node] (Audio streaming)

See ? The cross-VW exchange of data only concerns the entity of the VW
that is the endpoint for that particular service. That's an important
concept to understand.

Other important concept: the type of topological link. In the example
I've chosen to put Evernite "inside" Everlite because the SL Region
Simulator does not expect to run and represent data that sits outside
its 256x256 ground area, yet is the MMOX endpoint for this running and
representing. Some other VWs also have this limitation, and some don't
tie the representation to the localization - sorry I don't have
precise examples - so they can run and offer representation outside of
their designated volume. This is an important consideration because it
determines "where" the shared virtual simulation resides in each VW's
own space.

---

From: Charles Krinke <[email-masked]>
Date: Fri, 6 Mar 2009 12:14:29 -0800

Dear Jesrad:

Thank you for the thoughtful and logical description. That makes sense to me
and I can only say three things about it: "+1",, "woot" and "ftw".

Going through this progression with Croquet, Wonderland and others should
lead to the set of steps necessary to go from "I want to go there" to "I am
there".

We will find that some of these steps cannot be accomplished in some virtual
worlds due to their current evolutionary state. But, if we can make a good
logical case for a reasonable mmox protocol, then we can evolve various
virtual worlds in a complementary direction.

As we know, we have to go through steps like:

1. Initial query from worldA to worldB indicating an interop via mmox is
desired.
2. *Some* prescence is established from "chat" on the low end to "full
handoff" on the high end.
3. Other features of the world we are interopping "to" are enabled as a
result of query/reply, POST/GET, RPC or similar to perform a sufficient
handshake.

Charles Krinke
OpenSim Core Developer
OSGrid Director

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Jesrad <[email-masked]>
Date: Fri, 6 Mar 2009 22:29:03 +0100

Thanks for the detailed explanation, Jon. I think it makes your point
and position so far much clearer.

> Leading to a requirement for each client to handle all possible protocols. I
> believe this is a harmful direction.

Seconded. We're aiming at cross-VW interoperability, not
cross-implementations interoperability, and these are very different
beasts, as you explained. And translating to and from a single common
language (like english) is easier and more reliable than having a
translator for each case (japanese-french, german-italian, etc.).

As long as the MMOX endpoint can extract a simulation state from a
common representation format, and can understand the updates coming
from the other endpoints well enough to keep the local version of the
shared simulation state consistent (even though it does not
necessarily contain the entirety of the shared sim info transported)
then we have working interoperability. That's your main point, is it
right ? I'm not so sure we can avoid at least *some* vendor partiality
in determining a good common format, but then I'm not particularly
interested in vendor-neutrality save for actual interoperability's
sake. I don't care if our "english" looks suspiciously like dutch, as
long as I can read the words that count and get sense from it.

I can see your approach allowing to quickly get some low-hanging
fruits, too. Let's say the SL grid MMOX endpoint for the "Agent
Domain" is the agent session server, and the partly MMOX-compliant
implementation can read IM and identity data from the common
representation of that data (Jabber+OpenID/OAuth ?). At that level,
that means the SL grid is capable of getting IMs to and from other
VWs, and I can chat with, say, a (MMOX-compliant) Croquet user from
within SL. I'm not a programmer but I guess this would be fairly easy
to implement. The work of getting the rest of the services
interoperable could be done in gradual steps. Sorry if this is a
repeat of previous messages, this is meant for structuring thought.

However it implies that those services are stacked in independant
bundles: furthering this example, in SL the expected MMOX endpoint for
3D representation and object simulation is not the agent session
server but the region simulator, so these services are necessarily
discovered, opened, routed and transmitted independantly from the IM
and identity services, at the MMOX layer. Hence the proposed seven
domains from Morgaine. And a given VW's MMOX endpoint for any such
domain can be centralized or distributed depending on that VW design
(SL distributes the 3D representation and object sim across the region
servers, EVE online does not AFAIK, SL centralizes IM while Solipsis
or Manyverse do not, etc.), hence my earlier point that any common
representation format for each of these domains, or bundles of
services, must be P2P.

This then means servers within a given P2P-oriented VW will be talking
to each other through either the native P2P protocol or the MMOX P2P
protocol depending on how they discover each other. It would make a
lot of sense that MMOX endpoints of the same "family", who have at
their disposal a common native protocol for a given service domain,
can use it directly instead of composing to and extracting from the
MMOX common representation format. In other words, it makes sense that
two italian speakers can recognize each other as italian-speakers, and
converse in italian between themselves even when the whole conference
around them is meant to be in english. I fully agree on determining
common representation formats for all the identified Domains of VW
services, but would like a bypass for using shared native formats
between endpoints.

Now that brings another thing: there's not just data format to a
network service. Discovery, connection, caching, routing and transport
(I'm putting encryption in the transport) all matter, too (am I
missing something here ?). Fortunately encapsulating and packetizing
data is rather straight-forward, so transport format we can presumably
tackle on later. Every VW service is expected, from what I can read in
the discussions so far, to be authenticated with the same mechanism.
We've not yet discussed about discovery, but at the moment I see
nothing that would make it differ from authentication in this regard,
so I expect it to be uniform for all the Domains too. That means
connection, discovery, routing, and possibly transport will be uniform
between all the MMOX endpoints within each Domain of VW services,
regardless of the actual data formats contained therein. However
shared native protocols covering those Domains may have significantly
different routing, caching, transport and connection modes, so any
switch to those will be done at the discovery or connection step.

So we'll have a default MMOX format and either treat every other
format as optional, determining which to use at the connection step,
or include a mechanism for forwarding a given Domain service request
to any native shared protocol at either discovery or connection steps.
Is there something like that in DIS ? Also, doesn't DIS benefit from
its quite uniform and limited domain (physical simulation), when it
comes to the routing, discovery, etc. ?

Sincerely,
--
Jesrad Seraph

On Fri, Mar 6, 2009 at 12:17 AM, Jon Watte <[email-masked]> wrote:
>> simulations.  There is a great deal of room for web
>
> I believe that attempting to standardize a client/server signaling protocol
> for cross-vendor interop is harmful.
>
>>
> Leading to a requirement for each client to handle all possible protocols. I
> believe this is a harmful direction.
>
>> viewable by all users. In fact, quiet the contrary. We
>
> I believe HTTP is not a good analogy, because simulation is quite different
> from serving web apps and static pages, at the core. A better analogy would
> be streaming web video.
> different plug-ins installed on my machine, and I can't build mash-ups that
> pull video from two different sources, because FLV isn't compatible with ASF
> isn't compatible with QuickTime isn't compatible with Real.
> It would be really sad if that turned out to be the case for virtual worlds,
> too. If I have to enter a Microsoft world, or an Apple world, and I can't
> get to one from the other, because they each have their totally vertically
> integrated stacks. OGP, by the way, makes the assumption of a vertically
> integrated stack. I believe that assumption is harmful.
>
>
> Yes; it's up to us to define what the commonality interop formats look like.
> Solving "what does an animated mesh look like" is comparatively easy,
> because there are already standards we can use. COLLADA, X3D or MPEG-4
> meshes come to mind.
>
> that's not what we're trying for, is it?. What I believe we're trying for is
> a 90/10 solution that enables true cross-technology interop, so that "which
> vertically integrated technology stack are you using" doesn't have to be
> asked when users A and B want to meet, or do something common together.
> Sure, if you want to actually build UGC, or compete in a fast-paced shooting
> game, or something similar and world-specific, you'll need tighter coupling
> -- but that's the 10% case, not the 90% case.
>
> Also, I keep saying this, and people keep accusing me of being tied to some
> vast right-wing conspiracy of the military-industrial complex: Simulation
> interop is not new. There's lots of experience to be had, if you can just
> stomach the fact that perhaps someone else already solved a similar problem
> before. What I've found, through research and actual integration in the
> past, is that the DIS model works. The HLA model doesn't work. LESS is more
> like DIS. OGP is more like HLA. (the comparisons aren't perfect at the
> technical level) Shouldn't we learn from that?
>
> Sincerely,
>
> jw
>

---

From: Morgaine <[email-masked]>
Date: Sat, 7 Mar 2009 12:26:57 +0000

On Thu, Mar 5, 2009 at 9:11 PM, David W Levine <[email-masked]> wrote:

> which are compatible with the set of content, and delivery style shared by
> the regions you wish to connect to.  Yes. Tho, one can observe that the OGP
> documents describe sets of services, and you can  factor and deploy these
> services in a number of ways, which are significantly more flexible than the
> current model used within OpenSim and  SecondLife. If you look at the
> overall set of services described in OGP, it describes a model for signaling
> between simulations  and, to an extent, describes *one* model for
> signaling between clients and simulations.  There is a great deal of room
> for web style content negotiation
> side of the experience when handing off between virtual spaces. It would not
> be hard, at all, for the new region to signal to a client 'Here is the type
> of simulator I am, you'll need to handle this"
>
>
I agree, and I would expect the group to be able to analyse the differences
between platforms in that light to find areas in the problem and solution
spaces where interop could be achieved.  Instead, the discussion has taken a
rather strange form, something along the lines of:

*Systems A and B are significantly different in areas X.  Protocol P is
being designed to provide compatibility with system A.  Therefore protocol P
cannot provide compatibility with system B.
*

In the absence of further analysis (which I have not yet seen done
adequately), the above form of argument is flawed on at least two counts:

   1. First of all, providing compatibility with A does not necessarily
   preclude providing compatibility with B --- you have to examine the problem
   carefully and search for solutions before you can give up and assert the
   negative.
   2. And secondly, the negative conclusion presupposes that P is immutable,
   whereas the reality is that P is still being defined and therefore can be
   modified for compatibility with B.

In my opinion, the state of our analysis so far is so minimal that any claim
of non-interoperability is entirely premature.

>From what I've read so far, I believe that there is ample room for
compatibility between the two models in the presence of both content and
signaling diversity, because we have many, very powerful methods at our
disposal:

   - we can search for subsets of direct commonality (which in computing
   systems are *always* present),
   - we can create superset mechanisms that unify incompatible approaches
   (as I did with the two object execution models),
   - we can create mechanisms that are *extensible* to handle content
   diversity,
   - we can use negotiation to select interoperable feature sets out of a
   much larger palette of options,
   - we can use negotiation to switch between entirely different signaling
   methods,

and probably many other methods as well.  We have no shortage of tools to
bear on the problem.

It does of course require a willingness to examine the options and to accept
that significant change will need to be accommodated, on all sides, but that
is presupposed anyway in an IETF group that seeks to create non-proprietary
standards with Internet-wide applicability.

I propose that we examine the perceived differences one at a time to
understand the problem space better (which is appropriate at this stage of
the IETF process anyway), and while acknowledging that there are large gaps
to bridge, that we actually look for ways to bridge them.

Morgaine.

On Thu, Mar 5, 2009 at 9:11 PM, David W Levine <[email-masked]> wrote:

> worlds differ enough that they will inhibit using one approach, or another,
> SecondLife. If you look at the overall set of services described in OGP, it
> describes a model for signaling between simulations
> side of the experience when handing off between virtual spaces. It would not
> be hard, at all, for the new region to signal to a client 'Here is the type
> of simulator I am, you'll need to handle this"
>
> leads us to an item which cannot be rendered by our browser, because we are
> missing a plug-in, or we don't support a feature, such as ActiveX
> server, if we do not have a matching certificate, or support a certain style
> of
> authentication.
>
> second life style content with an OLIVE region will not let the OLIVE users
> see the content which exploits SL specific affordances on the SL client,
> unless there
> Croquet depends on low level capabilities in its t-object model to generate
> certain effects. People wishing to interoperate with such spaces, will have
> to
> bridge into that model.
>

---

From: Jon Watte <[email-masked]>
Date: Mon, 09 Mar 2009 11:49:09 -0700

Morgaine wrote:
> For example, if SL and Opensim were to become fully interoperable, 
> then their interop protocol would no longer be vendor-specific 
> (assuming no IPR intrudes), but it is easy to see that such interop 
> /might/ very well be architecture-specific and hence not successful 
> beyond certain architectural assumptions.
>

That is not "vendor neutral," because it means that all vendors that do 
not use the SL architecture are excluded. That's in fact the specific 
situation I want to avoid. A vendor neutral approach means an approach 
that does not require a specific architecture or technology stack to 
achieve interop.

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Mon, 09 Mar 2009 12:08:25 -0700

Charles Krinke wrote:
> There are those of us who feel that an interop consists of the avatar 
> moving (or teleporting) from one virtual world to another. Along with 
> that comes a number of other things such as interaction with that 
> world. So, I would say that "ghostly presence" as described by LESS 
> is, well, less then I would see we are certainly capable of. Some 
> might say it is a "mere shadow" of what we can do.

How is the LESS protocol a "ghostly" presence? The model allows avatars 
from different systems to interact with objects from different systems. 
If I have a virtual vehicle in one world (There.com, say), and a virtual 
boombox in another world (Second Life, say), then how would teleporting 
from one to the other allow me to use both in the same time (to play 
tunes while cruising in my car)?
That's what the LESS model solves -- letting different systems 
contribute different pieces to one unified world, where you merge worlds 
into the union of all the capabilities, rather than transport between 
them, getting only the particular capabilities of the destination world 
on arrival.

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Mon, 09 Mar 2009 12:18:47 -0700

> that is the endpoint for that particular service. That's an important

Jesrad,

I don't know if you realized it, but this is a great description of one 
possible implementation of the kind of interop that LESS is designed to 
achieve.

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Mon, 9 Mar 2009 19:29:23 +0000

On Mon, Mar 9, 2009 at 6:49 PM, Jon Watte <[email-masked]> wrote:

>
> That is not "vendor neutral," because it means that all vendors that do not
> use the SL architecture are excluded. That's in fact the specific situation
> I want to avoid. A *vendor neutral* approach means an approach that does
> not require a specific architecture or technology stack to achieve interop.
>

If you mean *architecture-independent/neutral*, then you must say that.

Vendor-dependency is very different to architecture-dependency.  Two
entirely different vendors may base their interop on a specific
architectural model, which would make their approach architecture-specific,
without necessarily being vendor-specific.  For example, a multiplicity of
vendors currently use Opensim server software for interop among themselves,
so clearly it is not vendor-specific.

By all means analyse and highlight any *architectural* dependencies that you
may see, so that we can address them.

Or are you referring to *control* of architecture?  That is yet again a
separate matter.

We cannot overcome problems unless we know exactly what issues we are
talking about, and speak about them with precision.  In this
problem-identification phase of our work, that is crucially important.

Morgaine.

On Mon, Mar 9, 2009 at 6:49 PM, Jon Watte <[email-masked]> wrote:

>> intrudes), but it is easy to see that such interop /might/ very well be
> That is not "vendor neutral," because it means that all vendors that do not
> use the SL architecture are excluded. That's in fact the specific situation
> I want to avoid. A vendor neutral approach means an approach that does not
> require a specific architecture or technology stack to achieve interop.
>
> Sincerely,
>
> jw
>
>

---

From: Jon Watte <[email-masked]>
Date: Mon, 09 Mar 2009 12:33:04 -0700

Morgaine wrote:
> On Mon, Mar 9, 2009 at 6:49 PM, Jon Watte <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>      
>     That is not "vendor neutral," because it means that all vendors
>     that do not use the SL architecture are excluded. That's in fact
>     the specific situation I want to avoid. A *vendor neutral*
>     approach means an approach that does not require a specific
>     architecture or technology stack to achieve interop.
>
>
>
> If you mean /architecture-independent/neutral/, then you must say that.

My point is that they end up having equivalent meanings.

- Some vendors use different architectures to implement virtual worlds.
- If a given interop protocol does not allow those vendors to 
interoperate their virtual worlds, then the protocol is not neutral with 
respect to (the combination of) those vendors.

Sincerely,

jw