[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