Subject: [mmox] 3 Work Areas - 1 WG

From: Heiner Wolf <[email-masked]>
Date: Fri, 27 Mar 2009 10:55:45 -0700

Hi,

at the BOF I said, that there a (at least) 3 different sets of
assumptions and expectations what the WG should do.
In short:
A) authentication, teleport and switching region domains
B) remove simulation with server-server peering
C) avatar interop and import

Different sub sets of people want to do one or the other and oppose
one or the other, because it is not in their primary interest. I am
coming to the conclusion, that this list of 3 topics are just 3 work
areas of our WG. They are all part of virtual world interop. There is
no single work, that can solve VW interop for all uses cases.

If someone says "Standardising A this is not worth a dime for me, I
rather would standardize B", then I get a clear signal, that A and B
are independent work areas.So, we should work on all of them. Sub sets
of people should engage the field of their interest and expertise and
leave other topics to other people.

There won't be just one WG result. We can expect drafts in these 3
work areas and probably more.

To name some names:
A) OGP authors would work on authentication and teleport
B) LESS authors would work on remove simulation
C) others would work on avatar interop

Naming even more names:
SL could profit from LESS if someone cares to support it.
I bet Weblin will use OGP if a Web-URL maps to an OGP region instead
of an XMPP room
OLIVE could use avatar interop, but maybe not OGP teleport.

Jon: this is not a free lunch for OGP with regard to display-simulator
connections. There ought to be input from other worlds, especially
other large VW biosystems like the Multiverse platform.

OGP people: please forgive me my short description of your work. I
know there is more. Lets discuss details later.

My statement is:
Its not about this OR that work area. There will be independent but
related work areas, like in many other WGs.

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

---

From: Jon Watte <[email-masked]>
Date: Fri, 27 Mar 2009 15:03:33 -0700

> C) others would work on avatar interop
Actually, LESS will need some kind of avatar interop to be useful, so 
those two goals could be merged (or maybe first do C and then B).

> other large VW biosystems like the Multiverse platform.

I absolutely agree! It's too bad that there are only two technology 
bases represented in the discussion in this group.
With the weird relation that OpenSim is a separate code base, but one 
that was born as a reverse-engineering of the Second Life code base, and 
hence inherently mostly compatible.

Sincerely,

jw

---

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

Perhaps you could donate an implementation of LESS to OpenSim, or motivate
someone else to write one. Then everyone may use the BSD licensed code base
for further work on interop with no strings attached.

Given a functioning implementation, LESS starts getting a lot more
interesting, and I would urge you to work in that direction as it is a place
of increased credibility for LESS.

Charles Krinke
OpenSim Core Developer
OSGrid Director

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

> Actually, LESS will need some kind of avatar interop to be useful, so those
> two goals could be merged (or maybe first do C and then B).
>
> I absolutely agree! It's too bad that there are only two technology bases
> represented in the discussion in this group.
> With the weird relation that OpenSim is a separate code base, but one that
> was born as a reverse-engineering of the Second Life code base, and hence
> inherently mostly compatible.
>
> Sincerely,
>
> jw
>
>
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Dan Olivares <[email-masked]>
Date: Sun, 29 Mar 2009 00:22:20 -0400

I would suggest replacing 'code base', with 'client->server protocol'
since nobody looked at source.

I also note that OpenSimulator has a modular framework to which the
LLClient client plugin is just one of a few, but growing list of
compatible clients. :)

Sincerely

Dan

---

From: Barry Leiba <[email-masked]>
Date: Tue, 31 Mar 2009 22:00:46 -0400

> no single work, that can solve VW interop for all uses cases.

It may, indeed, be that there's plenty of work to go around, and the
it's ultimately the right thing to have multiple documents from each
of these areas coming out of the working group.  There are certainly
working groups with that sort of workload.

Those sorts of working groups didn't establish charters like that straight away.

The way to approach this, when you're coming into a community of
standards engineers who are less familiar with this stuff than you are
is to start by setting up a less ambitious chunk of work to get going
in a work environment you're not used to.  It makes both sides more
comfortable.

Carve out one or two areas to work on that most can agree with be (1)
useful and (2) feasible to finish in a relatively short time.  Set up
a charter that aims to work on those.  By the time that's close to
being done, you'll be used to the IETF and the IETF will be used to
you, and the group can be re-chartered (or parallel groups can be
formed) to crank on all the rest of this.

If you come to the IETF and say, "We have all this stuff we want to
do, and some people think some of it should be done, and others think
other of it should be done, and no one agrees on anything, but we want
to do it all!", it will give people the willies.  The IETF *does* have
work that can be described that way (mention NAT66 to a few people),
but it developed through community and familiarity.

Barry Leiba, MMOX BOF co-chair

---

From: Larry Masinter <[email-masked]>
Date: Tue, 31 Mar 2009 22:09:10 -0700

> A) authentication, teleport and switching region domains

This still looks ambitious

> B) remove simulation with server-server peering

This is interesting but requires some footwork to make sure
it can actually get deployed (assume you meant 'remote'
and not 'remove')

> C) avatar interop and import

This seems really hard, too, because of the different 
models.