[mmox] Industry involvement (was RE: Learning from the past; focusing on the future)

"Hurliman, John" <john.hurliman@intel.com> Mon, 23 February 2009 22:09 UTC

Return-Path: <john.hurliman@intel.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 4F4E53A6A76 for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 14:09:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.539
X-Spam-Level:
X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Ga--tCxvf1VG for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 14:09:24 -0800 (PST)
Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by core3.amsl.com (Postfix) with ESMTP id BD7A43A6A75 for <mmox@ietf.org>; Mon, 23 Feb 2009 14:09:21 -0800 (PST)
Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 23 Feb 2009 14:09:40 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.38,256,1233561600"; d="scan'208";a="113600364"
Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by azsmga001.ch.intel.com with ESMTP; 23 Feb 2009 14:09:40 -0800
Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx603.amr.corp.intel.com ([10.31.0.57]) with mapi; Mon, 23 Feb 2009 15:09:39 -0700
From: "Hurliman, John" <john.hurliman@intel.com>
To: "mmox@ietf.org" <mmox@ietf.org>
Date: Mon, 23 Feb 2009 15:09:34 -0700
Thread-Topic: Industry involvement (was RE: [mmox] Learning from the past; focusing on the future)
Thread-Index: AcmV++FCqr2SCKnDSNOd5vSpvKX5YAAADtbAAACWddA=
Message-ID: <62BFE5680C037E4DA0B0A08946C0933D502639B5@rrsmsx506.amr.corp.intel.com>
References: <FDF00DC7F277439581F4909E2C549AA6@KEVINPC> <49A2500F.3000104@gmail.com><e0b04bba0902230031s5065080j61058011201cd929@mail.gmail.com> <49A311BC.90405@gmail.com> <9A27EF31A4DF2C4C8BB45D661B13BA870535083A@MERCURY.forterrainc.com>
In-Reply-To: <9A27EF31A4DF2C4C8BB45D661B13BA870535083A@MERCURY.forterrainc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [mmox] Industry involvement (was RE: Learning from the past; focusing on the future)
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: Mon, 23 Feb 2009 22:09:25 -0000

I am representing Intel on this list and possibly at the BOF. My opinion is that there is a "wait and see" attitude across many industry and community partners, to see if a usable multi-platform spec is produced. As evidenced by the current discussion archives for MMOX, the amount of effort that it is taking to steer this in a vendor neutral direction is overwhelming. I had to rewrite the proposed charter just to keep the *definition of the group* from being written as a timeline to standardizing Linden Lab's protocol stack. The standardization of LLSD is embedded in the timeline, while myself and others have raised concerns about its utility in comparison to other competing IDLs.

While this discussion is going on, there is a risk of participation being perceived as consent. IBM's implementation of the first OGP teleport spec was added to the OpenSim codebase, and now OGP is touted as a joint effort between Linden Lab and the open source communities surrounding Second Life. I wrote an initial implementation of LLIDL, so I suppose under that definition LLSD/LLIDL is a joint effort between Intel and Linden Lab.

This could easily become a full time job for participants, and from what I can tell the only guaranteed output is that Linden Lab's LLSD/LLIDL/OGP technology will become standardized. Whether or not that stack is competitive with alternative proposals, or an alternative standard is proposed in parallel, is an open question. As Intel is not a virtual world vendor, and interested more in the wider technology landscape of virtual worlds it makes sense for me to be here. That doesn't apply to Qwaq, Multiverse, HiPiHi, ActiveWorlds, etc. who will lose nothing by ignoring the creation of a standard that doesn't provide any value to their platforms. Unless there is a clear return on the time investment it is unlikely that there will be broad industry participation.

John

>-----Original Message-----
>From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of
>Robert Gehorsam
>Sent: Monday, February 23, 2009 1:30 PM
>To: Jon Watte; Morgaine
>Cc: Mystical Demina; mmox@ietf.org
>Subject: Re: [mmox] Learning from the past; focusing on the future
>
>I think part of the issue here with regard to the debate between broad
>and narrow interoperability is that, other than Jon representing
>Forterra's technical efforts, there are no other visibly participating
>technical representatives from any other virtual world technology
>providers or other relevant groups.  No one from Sun, Qwaq, Multiverse,
>HiPiHi, Activeworlds, any of the browser-based folks, Twinity, any of
>the game folks or kids worlds, Makena (the company that, contrary to
>some folks' assertions, is the company that makes and operates
>There.com), Proton Media, Icarus or its various partners, ECS, and so
>forth.   I've seen references to Qwaq but haven't seen Greg or anyone
>else from there participating here.   There are probably two dozen
>companies that would be reasonable candidates for this discussion, not
>to mention companies like Adobe, Google, Intel, Samsung, Sony and, yes,
>even Microsoft, all of which might arguably have some interesting
>contributions to make.
>
>It may be that this lack of broad participation is creating -- fairly or
>unfairly -- the sense that the conversation will naturally drift towards
>an SL-OS orientation -- despite what I see as the best intentions of
>many people here -- simply because, other than Forterra, no one else is
>stepping up to the plate.   I can tell you that *that* is not something
>that Forterra wants to see, because it's inherent in our view of the
>evolution of the internet that interoperability between diverse virtual
>worlds is essential for all to succeed.  So the imbalance in this
>ongoing discussion creates a false dynamic of conflict when none is
>intended.  Without broad input, how can we achieve broad
>interoperability?
>
>Is there any outreach going on to these various organizations, or is
>that somehow not part of the policy?  Not being really familiar with the
>workings of these sorts of technical groups, I just don't know.
>
>Robert
>
>-----Original Message-----
>From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of
>Jon Watte
>Sent: Monday, February 23, 2009 4:15 PM
>To: Morgaine
>Cc: Mystical Demina; mmox@ietf.org
>Subject: Re: [mmox] Learning from the past; focusing on the future
>
>Morgaine wrote:
>> I can't understand why you continue to raise the spectre that we're
>> here to rubberstamp SL standards.  We aren't.  I'm not aware of
>> anybody with that agenda.
>>
>
>Because there are several people on this list who say "OpenSim and
>Second Life are already trying to do client interoperability; I think we
>should run with it and not worry about something bigger."
>Similarly, I find that the current OGP proposal specifies some thing
>("Rezzing" of avatars) that are Second Life centric, while not
>specifying other things that would be necessary for an actually useful
>interoperable virtual world (like entity telemetry).
>
>Similarly, if OGP is specified as a mostly empty vessel that can contain
>arbitrary negotiated data, what would probably happen would be that
>OpenSim puts OpenSim data in that vessel, and IMVU puts IMVU data in
>that vessel, and both claim to support "OGP interoperability" but you
>can't do anything useful through that claim. I want to avoid that
>outcome.
>>
>> We are working in good faith towards your item 2), while noting that
>> item 2) means interop with "all" reasonable worlds, and that includes
>> Linden worlds.  It's not either/or, it's both.  Please grant us that,
>> so that we can actually make headway.
>>
>> /(Proviso: your item 2) says /*single ... simulation*/, which is
>> incorrect, as we have no remit to straightjacket diverse worlds into a
>
>> single simulation.)/
>
>What I mean by "single simulation" is what the user sees when connected
>to a specific, interoperating instance. I suppose the user could be
>connected to multiple of those, similar to opening multiple video
>streams in a media player, but then those generally have "nothing" to do
>with each other.
>
>
>Okay, so if most of us agree on 2), can we just say we have "rough
>consensus" on that, and politely reject any attempt to steer the work
>towards 1)?
>
>
>Sincerely,
>
>jw
>
>
>_______________________________________________
>mmox mailing list
>mmox@ietf.org
>https://www.ietf.org/mailman/listinfo/mmox
>_______________________________________________
>mmox mailing list
>mmox@ietf.org
>https://www.ietf.org/mailman/listinfo/mmox
>