[mmox] what does it mean to be interoperable?

Meadhbh Hamrick (Infinity) <infinity@lindenlab.com> Thu, 26 February 2009 18:37 UTC

Return-Path: <infinity@lindenlab.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 2CC053A67D7 for <mmox@core3.amsl.com>; Thu, 26 Feb 2009 10:37:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.506
X-Spam-Level:
X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 fH2Z1tTprWa2 for <mmox@core3.amsl.com>; Thu, 26 Feb 2009 10:37:02 -0800 (PST)
Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 601423A67B0 for <mmox@ietf.org>; Thu, 26 Feb 2009 10:37:02 -0800 (PST)
Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id E96141414004 for <mmox@ietf.org>; Thu, 26 Feb 2009 10:37:23 -0800 (PST)
Message-Id: <228D0A40-F63F-4564-9200-0FF543902FD4@lindenlab.com>
From: Meadhbh Hamrick <infinity@lindenlab.com>
To: mmox@ietf.org
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Thu, 26 Feb 2009 10:37:23 -0800
X-Mailer: Apple Mail (2.930.3)
Subject: [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 18:37:03 -0000

so it seems clear we all have different ideas of what it means to be  
interoperable.

i thought i might try to define a couple of the definitions i think  
i've seen people use:

1. interoperability means all virtual worlds, wherever they are, may  
be accessed via a single unified client.

2. interoperability means all virtual worlds, wherever they are, use  
precisely the same protocol(s) and all virtual worlds represent data  
in formats understandable by all other virtual worlds, with a  
universal client.

3. interoperability means some virtual worlds may be accessed via a  
single unified client.

4. interoperability means some virtual worlds use precisely the same  
protocol(s) and all virtual worlds represent data in formats  
understandable by all other virtual worlds, without a universal client.

5. interoperability means some virtual worlds use some of the same  
protocols, without a universal client

6. interoperability means the "model" is the same, but with different  
protocols that may be bridged with protocol gateways.

it seems to me that many of us are using different descriptions for  
the word "interoperable" and it's causing mild discord and at least a  
couple instances of us talking past each other.

personally.. i'm kind of interested in option 5. it has the benefit of  
producing a protocol that is identifiable by routers, network  
management software, etc. it also provides a "slowly moving target"  
for open source developers (as opposed to the "fast moving target" of  
linden's existing protocol(s)). by making it public, VW operators can  
choose whether or not they wish to implement it. it also doesn't  
require VW operators to implement it (as if we could anyway) and it  
allows VW operators to avoid having to test interoperability with  
every other virtual world.

but it's not without drawbacks... this model can lead to a "MOSS-like"  
environment. (for those of you who don't remember MOSS or MIME  
Object(?) Security Services... it was a response to the drawbacks of  
PEM (privacy enhanced mail) which had a relative paucity of encryption  
options. but IMHO, MOSS introduced so many options that it was VERY  
easy for two implementations to adhere to the spec, but not actually  
be interoperable.)

so... i recommend that if we (as a group) wanted to pursue option-5..  
we also explicitly define what goes in an "interoperability profile."  
that way you could get the benefit of having a relatively stable  
protocol that could be targeted by open source developers which could  
be used by VW operators to help make client / server apps.

VW operators could publish their "interoperability profile" to tell  
people who wanted to build tools, extra services, or interoperable  
worlds what options would be available and how they would work.

-cheers
-m