Re: [mmox] what does it mean to be interoperable?

Jon Watte <jwatte@gmail.com> Thu, 26 February 2009 23:20 UTC

Return-Path: <jwatte@gmail.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 E67FC3A6767 for <mmox@core3.amsl.com>; Thu, 26 Feb 2009 15:20:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.519
X-Spam-Level:
X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 TQkZ-NTnL3sU for <mmox@core3.amsl.com>; Thu, 26 Feb 2009 15:20:20 -0800 (PST)
Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id ABAD43A68F4 for <mmox@ietf.org>; Thu, 26 Feb 2009 15:20:20 -0800 (PST)
Received: by gxk22 with SMTP id 22so1905289gxk.13 for <mmox@ietf.org>; Thu, 26 Feb 2009 15:20:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=WR1JbT4/ApC6Y6iIi3k3T7aL+A60BZ292AS4hy0PIMc=; b=cvVM3YOouPG9+eelX9OFbmiEIGJF2SC6mWMaqAFLpl5lyyQcnLuY+ovjVlL8ILH7hn jTYbD9A/25lxp9/P13+ms8u2/ZXl9WF0DHG41qbO5X2ja3I2IroQ8R7cCUwP8iQAiDnk iuuE6mMkQL5LnEM0xdKXV0cspfCaXtG6zNP2k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=UCXQt8TEU78JA4KlDqroQv5YmwmQskzQJkxh9Z5Na7J9hSB865wGHEA+EI0UnqDBMP IE+oxMFttnOD37qsABNK7BpqQTOLKdXh2UCLw76r8wjUtPIgPvVsDD159x+91fz1ZgdA VQi+Bu3MfhsZygab2iiE8RqLyIJIKSXvmRAlQ=
Received: by 10.100.3.13 with SMTP id 13mr2131417anc.31.1235690442043; Thu, 26 Feb 2009 15:20:42 -0800 (PST)
Received: from ?192.168.168.114? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d21sm6005714and.26.2009.02.26.15.20.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 15:20:41 -0800 (PST)
Message-ID: <49A723C7.4030904@gmail.com>
Date: Thu, 26 Feb 2009 15:20:39 -0800
From: Jon Watte <jwatte@gmail.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: "Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com>
References: <228D0A40-F63F-4564-9200-0FF543902FD4@lindenlab.com> <e0b04bba0902261358s74e88140y12a411068be9e4ad@mail.gmail.com> <7D208FA9-3C91-422F-B24F-F1B0B85908B9@lindenlab.com>
In-Reply-To: <7D208FA9-3C91-422F-B24F-F1B0B85908B9@lindenlab.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: mmox@ietf.org
Subject: Re: [mmox] what does it mean to be interoperable?
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: Thu, 26 Feb 2009 23:20:22 -0000

Meadhbh Hamrick (Infinity) wrote:
> i don't know if linden could ever support an option-4, because of our 
> desire to have interoperability drive "user innovation." in other 
> words, we'll always be interested in a situation where developers 
> could extend the protocol to support value-added services. we're not 
> terribly frightened of option-5 because our view of the world has VW 
> operators deploying client software unique to their solution to handle 
> these value-added services.
>

I believe in that model (4), too. Now there are two things that I think 
are important:
1) An option-4 solution (there are protocols and formats that everyone 
recognizes), it's easy enough to add extensibility, on the level of 
"while we recognize the basic set, we can also recognize these 
additional things." In fact, not doing that would be almost criminally 
shortsighted.
2) An option-4 solution provides the model for interoperability, but for 
innovation or platform-specific features, you simply don't interoperate 
those bits. They are, after all, platform specific. For example, when 
interoperating, the network usage for an OLIVE client will go up, 
because the svelte network usage of OLIVE requires OLIVE-proprietary 
technology.

> in short, we expect OGP to never be a complete specification of a 
> virtual world protocol, but rather a protocol framework that together 
> with an interoperability profile sufficiently specifies client and 
> server behavior to achieve some measure of interoperability.

So, in effect, it will probably lead to the MOSS outcome, except for 
certain small cliques (There.com clusters talking to other There.com 
clusters; OpenSim talking to Second Life, Croquet talking to Qwaq, etc). 
That is not partucularly exciting to me, because I don't believe it will 
lead to the kinds of interoperability that our customers (and the world 
in general) deserves and demands.

I asked the question before, but didn't get an answer: What would you 
opinion be of doing the OGP/SL/OSim work in a forum like the AWG, and 
doing the option-4 work in the MMOX group? Would you lose anything if 
that's the approach?

Sincerely,

jw