[mmox] Formalizing my proposal
Catherine Pfeffer <cathypfeffer@gmail.com> Tue, 24 February 2009 19:04 UTC
Return-Path: <cathypfeffer@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 59A6D28C12F for <mmox@core3.amsl.com>; Tue, 24 Feb 2009 11:04:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 bvEX+GPlAFRL for <mmox@core3.amsl.com>; Tue, 24 Feb 2009 11:04:19 -0800 (PST)
Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id E6C2928C128 for <mmox@ietf.org>; Tue, 24 Feb 2009 11:04:18 -0800 (PST)
Received: by ey-out-2122.google.com with SMTP id 25so538040eya.31 for <mmox@ietf.org>; Tue, 24 Feb 2009 11:04:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=PkAjMkLNQiNZVn9Qkb2/cfmKiMjlXIGrMGX+RL49LSQ=; b=O+VpOFsrIh1tkJahfHgflP08QFLOaSIZagILrTE1HxWafJqhEBMHOIg0tx62oj+4a4 nrvve++Etr2i9hNfpo97VYemSa/vkus99NntF9S6zDRo08CvFts8jTle5F9bVFuoghIt bKXcmXMnUzp2VkOH6ksRpzuAIF1j8/X+0DGpg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=bD/+C0IbIDKGpmyU2vlzUr0nzTa6L9z8dBmIwifVoBaixh+2/Qew0ql0C3j7YVtRX/ hafYQAYYJBhfsXmRARRo0fKy0OquSu3Y2zybEmbdldUABpjCYF6K5vpfdoXV/Hc43fpB X428XwXTLaL84WVks4Q4X/5HWq7z9Qxj5jcbo=
MIME-Version: 1.0
Received: by 10.210.28.6 with SMTP id b6mr17340ebb.48.1235502277376; Tue, 24 Feb 2009 11:04:37 -0800 (PST)
Date: Tue, 24 Feb 2009 20:04:37 +0100
Message-ID: <ebe4d1860902241104k2761c55pd5b62358ce5c631c@mail.gmail.com>
From: Catherine Pfeffer <cathypfeffer@gmail.com>
To: mmox@ietf.org
Content-Type: multipart/alternative; boundary="0015174c1a685cb9fb0463aeca85"
Subject: [mmox] Formalizing my proposal
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: Tue, 24 Feb 2009 19:04:20 -0000
Infinity wrote: > 1. can you please submit your proposal? Sure. I'll submit a proposal that makes the XML serialization better, although it would assume: 1)- that LLSD is what we need for lower layer 2) that we would stick to three serializations for LLSD and not just one, leading to clumsy XML both points are still not certainties in my mind. But I'll send the formalized proposal as you asked it. > most of the XML LLSD is sent over HTTPS, > which might explain why you can't see it in wireshark Aaah, Ok, thanks for the tip! ;-) > 6. the reason we separate the serialization from the protocol > definition is we want to avoid having to add "binary serialization", > "json serialization" and "xml serialization" sections to each defined > protocol interaction. Yes, and that leads to a XML serialization that does not take all the advantage of what can be done in XML, and that takes a lot of bandwidth. Again, why would we need three serializations when one is just enough? Not saying that it's just 1/3rd of the implementation effort... > I think there's a history of people defining protocols > using relatively "high level" abstractions, then providing mechanistic > technique for generating the "octets over the wire." That's correct, it's nice to think in abstract terms, and then map the result to a given implementation. That does not mean you need three implementations... > 7. i really like the idea of using LLSD to represent meshes, link-sets > of prims, or even 2d SVG representations of avatars and objects. ... which means, in XML, that we could not re-use existing meshes or SVG XML dialects just by changing the namespace, but that we would have to "convert" everything to LLSD. While this would certainly work, it sounds to me like a lot of efforts, while simply mixing vw: and svg: namespaces in one single file could do the trick. Otherwise, you'd first have to define how SVG remaps to LLSD, then implement it. XML namespaces are precisely offering this ability to mix different type of data from different standards without ambiguity and without any need to remap one standard into the other. -- Cathy
- [mmox] Formalizing my proposal Catherine Pfeffer
- Re: [mmox] Formalizing my proposal Lisa Dusseault