Re: [mmox] Creating walled gardens considered harmful

Morgaine <morgaine.dinova@googlemail.com> Fri, 27 March 2009 21:02 UTC

Return-Path: <morgaine.dinova@googlemail.com>
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 9317B3A6A5A for <mmox@core3.amsl.com>; Fri, 27 Mar 2009 14:02:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.823
X-Spam-Level:
X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 BwV7Sx-IJdtU for <mmox@core3.amsl.com>; Fri, 27 Mar 2009 14:02:50 -0700 (PDT)
Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id E4E803A6A56 for <mmox@ietf.org>; Fri, 27 Mar 2009 14:02:49 -0700 (PDT)
Received: by ey-out-2122.google.com with SMTP id 4so276858eyf.31 for <mmox@ietf.org>; Fri, 27 Mar 2009 14:03:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=UT0OjgexsT81EjyJSB/el4cBm6+IrmPvjxO3a2lda5M=; b=K/FZNQH3M1JBtfDdEhkQFNxb/LyRd2nqG6aeXS/d8vU+vMJrE7xgqFeBLqKINXiNIC P8b9qUn19OUZOlDt3KY8avUavXx0HwhLA/Az4seAM7O09y8r46CSBlOiiFxSsC/Xs4DB 7fGCjSX2LFc3GoM2VJ/oGu/9qHBoZuVq1EZvo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kbsCW01fXxHHUzZW+6paR5Azjpy7+bc/hIJC5ZsLiYnqXPyzuD+zK7HkI0uERnYki6 ZRoRqIGigaYDLGc/bwJ6hEDGJii018/+SWhHyhHOcJg+qY6pE7o/RysIXSLizTDpzOWy 3bYzsTJ/6ew0i+WIZ8IgdjVDCJ6TSXnEl+wDI=
MIME-Version: 1.0
Received: by 10.210.115.17 with SMTP id n17mr1927614ebc.43.1238187823943; Fri, 27 Mar 2009 14:03:43 -0700 (PDT)
In-Reply-To: <E93EA1BB97D0984691DEC3DFEDBCCE4E07F32165@eusrcmw721.eamcs.ericsson.se>
References: <e0b04bba0903250007k6886383bja0a06884e8081ac7@mail.gmail.com> <49CA6728.4080607@gmail.com> <e0b04bba0903260638h3fc7d5ebpb918bfd529cd17fe@mail.gmail.com> <49CBC087.9070209@gmail.com> <e0b04bba0903262304k6c6cb307qc0ed4b2ae1c3dc60@mail.gmail.com> <49CD061D.30101@gmail.com> <E93EA1BB97D0984691DEC3DFEDBCCE4E07F32165@eusrcmw721.eamcs.ericsson.se>
Date: Fri, 27 Mar 2009 21:03:43 +0000
Message-ID: <e0b04bba0903271403j1c1f7bffm637fabbb977840c@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: James Kempf <james.kempf@ericsson.com>
Content-Type: multipart/alternative; boundary="0015174c40a46950c604662011df"
Cc: MMOX-IETF <mmox@ietf.org>, Jon Watte <jwatte@gmail.com>
Subject: Re: [mmox] Creating walled gardens considered harmful
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: Fri, 27 Mar 2009 21:02:52 -0000

That's a very well reasoned post, James.

What do other people think about this?

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

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

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

Morgaine.






On Fri, Mar 27, 2009 at 8:05 PM, James Kempf <james.kempf@ericsson.com>wrote:

> Hi Jon,
>
> I was at the BOF on Tues. You probably don't know me but I worked in
> IETF for around 10 years, recently I haven't been attending IETF but I'd
> like to offer my opinion on your email and the prospect of any work on a
> virtual worlds interoperability standard succeeding in IETF. I also have
> had some experience with virtual worlds, I did some work with Second
> Life shortly after the client went OpenSource, and I'm involved with a
> small group in Silicon Valley (FountainBlue) that is trying to organize
> events to foster networking among entrepenurs, investors, and
> technologists interested in virtual worlds.
>
> My opinion is that any such effort will take years, and it will by and
> large be out of date from a market standpoint by the time it is
> completed. In other words, by any reasonable definition of success, it
> will fail. Your email below is an initial indication of why.
>
> Basically your company (OLIVE?)and Second Life/OpenSIM are competitors.
> There are many others out there that compete with Second Life/OpenSIM.
> In situations like that, where there is one company or group of
> companies that want a standard and no basic agreement with other
> competitors for the need of interoperability to their business,
> standardization efforts in IETF invariably drag on, since the IETF rules
> that everybody gets their say allow competitors whose technology is not
> up for standardiztion to disrupt the proceedings. This is not a question
> of morality or anything, it is just good business sense, and everybody
> does it. Nobody wants a competitor's technology to get the "Good
> Housekeeping Seal of Approval" that a standard confers.
>
> An example of the exact opposite - where competitors have collaborated
> to achieve a successful standard - is MPLS, which was described last
> night at the technical plenary. But MPLS was addressing an industry that
> already had maybe 20 years of technical/business development, where the
> business roles of service providers, vendors, and customers were more
> clearly defined. Virtual worlds are considerably less mature (even given
> the abortive work in the early/mid 90's on dedicated VR systems). So the
> competitive posturing among VW companies is naturally more intense.
>
> My opinion on what you guys should do is the following:
>
> 1) The SL/OpenSIM/IBM people ought to go off and form an industry
> consortium and recruit some experienced protocol and distributed systems
> engineers to help them design OGP. IBM certainly has many such folks
> working for with experience in IETF, protocol engineering, and
> distributed systems design. Once they have their interoperability
> protocol done, they can publish it as an "informational RFC" if they
> want, this is something any individual or group can do and it does not
> constitute an "Internet Standard".
> 2) You and anyone else in the OLIVE(?) community should get together and
> work on the kind of interoperability protocol that addresses the system
> architecture and business ecosystem that you want to develop. You, too,
> can publish your work as an informational RFC.
> <This will allow both you and the SL/OpenSIM folks to focus on
> interesting technical issues and the particulars of your individual
> systems, rather than fighting each other on IETF mailing lists and
> generating carbon emissions flying to meetings that don't really decide
> anything>
> 3) By the time these parallel tracks are complete, it will be 3-5 years
> on (instead of 7-9, if that, which an IETF standardization effort would
> take) and the technology and business of virtual worlds will be much
> further along. At that time, there might be more clarity whether a
> commonality of business interests exists between multiple groups of
> virtual worlds which would allow them to supress their competitive
> postures and collaborate on a Internet-wide standard.
>
> Finally, putting on my volunteer hat, my feeling is that there are some
> serious, unresolved technical challenges involved in making VW a
> mass-market product. My feeling is that interoperability between VWs is
> only peripherally important. Having some kind of tacit agreement within
> the VW technical community about what those issues are, having academics
> working on research solutions, and having companies, too, implementing
> and deploying competing solutions which could prove themselves in the
> marketplace would be much more productive than fighting about an
> interoperability standard.
>
>                        jak
>
> PS: FountainBlue is sponsoring a virtual worlds event in Sept. at which
> companies can come and put up tables with information about what they
> are doing. If anyone is interested in participating, please send me
> email off-list.
>
>
>
> > -----Original Message-----
> > From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On
> > Behalf Of Jon Watte
> > Sent: Friday, March 27, 2009 10:00 AM
> > To: Morgaine
> > Cc: MMOX-IETF
> > Subject: Re: [mmox] Creating walled gardens considered harmful
> >
> > Morgaine wrote:
> > >
> > > While the original idea came from Linden Lab, that is no stumbling
> > > block:  every idea has to originate somewhere.  OGP has the great
> > > merit of being all-embracing as a concept, once you see
> > that certain
> > > ideas like /teleport/ and /client endpoint/ are actually much more
> > > flexible than they might at first appear.  /Client endpoints/ on an
> > > OLIVE server could "easily" allow Second Life clients to
> > interoperate
> > > with OLIVE clients.
> > >
> >
> > So, now for the less rosy situation:
> >
> > Even with the definition of the three services that you enumerated:
> >
> >    1. /Identity transfer is negotiated to provide continuity
> > of identity
> >       across the change of environment./
> >    2. /Presence transfer is negotiated to discontinue
> > presence in world
> >       A and commence presence in world B./
> >    3. /Asset transfer is negociated in the A->B direction to allow
> >       assets from world A to appear in world B, or to deny
> > the transfer
> >       where appropriate./
> >
> > There is no actual interoperability achieved if those are
> > standardized.
> > For a user of any other virtual world platform than
> > SecondLife/OpenSim,
> > these services would give them zero value. Thus, for virtual world
> > platforms other than SecondLife/OpenSim, there is close to zero
> > incentive to implement these services. And, because there is close to
> > zero incentive to implement these services, there is close to zero
> > incentive to participate in the standardization effort.
> >
> > I think that this is a problem. I'd like to understand how
> > others feel
> > about the same thing. I could see a number of different standpoints:
> >
> > 1. "It doesn't matter if some platforms won't participate in
> > this model;
> > we only care about the ones who do." (This leads to the
> > self-selecting
> > clique problem, which leads to isolated islands of separate
> > interoperability)
> > 2. "We need reasonably broad adoption for a standard to matter, so we
> > have to change the problem statement until there is value in the
> > standard for a reasonably broad set of platforms." (This leads to the
> > "re-define what we are doing" problem)
> > 3. "If we start here, then we can build on that in the future, until
> > such time as more platforms will get benefits from the
> > standard." (This
> > leads to the problem of building things intended to be used by others
> > without any input on what their constraints are)
> >
> > I currently am of opinion 2. I perceived the initial
> > standpoint by the
> > AWG contribution as 1. If you are of opinion 3, how are you
> > going to get
> > the requirements right?
> >
> > I think that it's important that everyone who will contribute to this
> > work actually clarifies what their assumptions are in this regard (as
> > well as the use case/requirements regard).
> >
> > Sincerely,
> >
> > jw
> >
> > _______________________________________________
> > mmox mailing list
> > mmox@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmox
> >
>