Re: [mmox] taxonomy of topics

Christian Scholz <cs@comlounge.net> Tue, 24 February 2009 23:41 UTC

Return-Path: <cs@comlounge.net>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 039E43A6B19 for <mmox@core3.amsl.com>; Tue, 24 Feb 2009 15:41:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.355
X-Spam-Level:
X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTQPxtO2uLfh for <mmox@core3.amsl.com>; Tue, 24 Feb 2009 15:41:16 -0800 (PST)
Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 008593A6B1F for <mmox@ietf.org>; Tue, 24 Feb 2009 15:41:16 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 456E81CE0223; Wed, 25 Feb 2009 00:41:35 +0100 (CET)
Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2rphbbKb9+j; Wed, 25 Feb 2009 00:41:34 +0100 (CET)
Received: from [192.168.178.40] (pD9EBD593.dip.t-dialin.net [217.235.213.147]) by post.comlounge.net (Postfix) with ESMTP id 624BD1CE01A0; Wed, 25 Feb 2009 00:41:32 +0100 (CET)
Message-ID: <49A485AA.50502@comlounge.net>
Date: Wed, 25 Feb 2009 00:41:30 +0100
From: Christian Scholz <cs@comlounge.net>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: "Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com>
References: <05E4C6F6-14A9-42AF-9314-A51F8DF0A7C3@lindenlab.com>
In-Reply-To: <05E4C6F6-14A9-42AF-9314-A51F8DF0A7C3@lindenlab.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: mmox@ietf.org
Subject: Re: [mmox] taxonomy of topics
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Feb 2009 23:41:18 -0000

Hi!

Meadhbh Hamrick (Infinity) schrieb:

>     * why do we care about OLIVE, which is a proprietary protocol with a 
> single implementation?

Because we could maybe learn something from it. I want to know how OLIVE 
works, I want to know how Qwak works, how Croquet works and so on. I 
also want to know what their use cases are they are trying to solve and 
why the have choosen certain routes to go over others.

> so the questions i pose are...
>     * pursuit of which of these topics brings us to our goal of an 
> interoperable virtual worlds?

I think we should start with a collection of use cases, see where we can 
find common ground on these and then try to find which protocol or 
format is best suited for it. We have proposals on the table which we 
can discuss and weight the pro and cons of each. We also should IMHO 
wherever we can use existing protocols instead of inventing our own.

>     * what does it mean to be interoperable?

That's maybe an output from the use case discussion.

>     * must we have early agreement on all topics before we move forward 
> with any component?

Probably not on all topics but we should have a general agreement on a 
plan on how we move forward ;-)

> * OGP (Open Grid Protocol)
>     * should OGP be named something else?
>     * how do we do the event queue? (COMET? Bayeux? RHTTP? Long Poll?)
>     * where do we stuff permissions in this model?
>     * OGP/Teleport is not HyperGrid

I think that's too early to answer and I think OGP as it is now will not 
be adopted by most other VW vendors anyway. We need to first find the 
common ground on which we can interoperate and then we should choose the 
best format by evaluating existing standards and new proposals.
Then we can come up with a hopefully flexible enough solution which 
survives a bit.
I doubt that anybody will come away with some substantial engineering 
effort to make thinks work.

> * LLSD
>     * why is LLSD different from XDR? ASN.1? Google ProtocolBuffers?
>     * 128 bit integers? good enough?
>     * should LLSD be named something else?
>     * XML serialization
>         * maps are too much like apple plists in the XML serialization.

The same applies here and IMHO should be deferred until we know better 
what problem we have to solve.

> * MMOX Charter
>     * we should rename everything
>     * we should abandon interoperability in favor of general agreement 
> of model
> * IETF
> * Virtual Worlds in General

As said earlier, I would like to broaden certain areas up to also 
include the web (and talk to those people working on the web side of 
things on such stuff, e.g. OAuth people. You might even meet them at the 
meeting, but I am not sure how this is organized and if 
cross-pollination on IETF meetings is happening.

>     * Previously Established Protocols
>         * HLA, DIS, IEEE-1278 and related protocols
>         * OLIVE
>         * MXP?
>         * VRML
>     * Representation of virtual objects
>         * meshes vs. prims
>         * interaction models for virtual objects
>     * Intellectual Property Regimes for Virtual Worlds
>         * Creative Commons (awesome gateway to free culture or the 
> ultimate embodiment of evil in the noosphere?)
>         * DRM (the only way i'll trust you with my content or the 
> ultimate embodiment of evil in the noosphere?)
>     * permissions regime
>         * MPEG-21?
>         * must we mandate the SL-style c/m/t permission?

Again too early to say IMHO. The only thing which IMHO should be there 
is flexibility in that you may support various protocols to be future 
compatible but we limit the choice down now to a very small set of what 
MUST be implemented. Maybe it's even just one we define here but this 
could be replaced at some point (would be easy with a general means if 
service discovery as possible with e.g. XRD or POWDER).

-- Christian


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