Re: [mmox] Another proposal for LLSD draft

Jon Watte <jwatte@gmail.com> Thu, 12 February 2009 19:39 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 6BA5928C157 for <mmox@core3.amsl.com>; Thu, 12 Feb 2009 11:39:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.711, 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 v+yvBqHMCpfu for <mmox@core3.amsl.com>; Thu, 12 Feb 2009 11:39:14 -0800 (PST)
Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 46CE73A6B94 for <mmox@ietf.org>; Thu, 12 Feb 2009 11:39:14 -0800 (PST)
Received: by yw-out-2324.google.com with SMTP id 5so1082224ywh.49 for <mmox@ietf.org>; Thu, 12 Feb 2009 11:39:19 -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:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=buQZIFNdZEW5nYA1r8nQq/lakZGaz0lhp22cHcGrHgc=; b=tgV8GvKKhJKOe1qmxUuvckZw8ijYgix7ScRdO2Kn0J7snVAe5SdPHeVpDIdAbiTPot Vv2Bz0qooY3sXtd3qctR8OhswyGJkh4ddP0Vymz50K/NYAAojMOY16U7/PWrRdVndxxs iV6INRjQdK0Nbd72hfKjQhpHT3tWX/OjOBNXM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=YCnV2F4Jn3x8qwciF9SHUx94+IpJoHje2uGmFDd05GFgeIwQfUsqzcoO62A6o5roOZ f1bqKK9BZUaRtTu/GMeFXGESqNQi+62Fq5WtXL5eTnsQ23myZhPJrOITKwqhwYKtGFh4 nmr0nGWJ/5oIy1+w20XG70cW2K2qMJaQymo8M=
Received: by 10.100.164.12 with SMTP id m12mr1535022ane.144.1234467558899; Thu, 12 Feb 2009 11:39:18 -0800 (PST)
Received: from ?192.168.168.106? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c28sm587565anc.25.2009.02.12.11.39.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 12 Feb 2009 11:39:17 -0800 (PST)
Message-ID: <49947AE3.9020504@gmail.com>
Date: Thu, 12 Feb 2009 11:39:15 -0800
From: Jon Watte <jwatte@gmail.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: mmox@ietf.org
References: <ebe4d1860902110250m597998aek3296da523f70892@mail.gmail.com> <49931BAA.10109@gmail.com> <e0b04bba0902112023r4380afc1o13f9deb719421214@mail.gmail.com>
In-Reply-To: <e0b04bba0902112023r4380afc1o13f9deb719421214@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [mmox] Another proposal for LLSD draft
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, 12 Feb 2009 19:39:15 -0000

Morgaine Dinova wrote:
> Unless the MMOX protocols are intended to carry EVERYTHING related to 
> VWs (and they well might, though I doubt it), we really need to 
> partition the universe of discourse into those things that we intend 
> to cover and those things that we don't.  A list of inclusions and 
> exclusions (if any) would be very useful to direct the discussion ahead.

I don't even yet understand what mode of interoperability you're 
tackling here. For example, there's the "universal client" ghost, which 
doesn't actually solve any real business problems. Then there's the 
"porting content" area, where we're seeing a lot of demand from 
customers. There's also "tieing servers together" which actually enables 
new and interesting, never-before-seen applications.

For an argument for why a "universal client" is a non-solution, see 
http://www.interopworld.com/node/31
For a description of what "tieing server together" might enable, see 
http://www.interopworld.com/node/22

So, before we start talking too much about specific details of 
serializing data, I think it would be great if we first figured out what 
kinds of new applications we're trying to enable through interoperability.

Sincerely,

jw