Re: [vwrap] The <embed> tag... is the group still interested in LLSD or DSD?

Joshua Bell <> Fri, 06 May 2011 16:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E150FE0726 for <>; Fri, 6 May 2011 09:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VBks7jB2E3Z3 for <>; Fri, 6 May 2011 09:19:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0EA7CE06D0 for <>; Fri, 6 May 2011 09:19:03 -0700 (PDT)
Received: by pwi5 with SMTP id 5so1952810pwi.31 for <>; Fri, 06 May 2011 09:19:03 -0700 (PDT)
Received: by with SMTP id p17mr1963933wfd.77.1304698743186; Fri, 06 May 2011 09:19:03 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 6 May 2011 09:18:43 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Joshua Bell <>
Date: Fri, 6 May 2011 09:18:43 -0700
Message-ID: <>
Content-Type: multipart/alternative; boundary=000e0cd212e820668304a29dd989
Subject: Re: [vwrap] The <embed> tag... is the group still interested in LLSD or DSD?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 May 2011 16:19:05 -0000

On Thu, May 5, 2011 at 11:46 PM, Vaughn Deluca <>wrote;wrote:

> What were the reasons to allow onl a single integer type? There must have
> been a good arguments for that?

IIRC, some of the languages we wished to support (Python comes to mind) did
not have support for integers larger than 32-bits. ECMAScript doesn't have
integer number types at all only IEEE 754 64-bit floats; if you constrain
the input and output to 32-bit integers it can represent those accurately,
but not 64-bit integers.

If you look at the history of LLSD, it started with 3 serialization formats
that explicitly specified the type of values - XML, binary, and "notation" -
a compact text serialization intermediate in size between binary and XML.
The IETF drafts dropped notation and added JSON. The JSON serialization was
"lossy" as LLSD describes types and values that don't exist in JSON
(Integer, Date, UUID, NaN, Infinity, etc). By design, though, the type
conversions described in the LLSD Draft accommodate e.g. by serializing a
Date as an ISO 8601 string, which when interpreted as a date by the receiver
results in the original Date by the string->date conversion rules. (I don't
know if we had resolved every issue with JSON serialization; certainly,
discussion about edge cases on this list never made it into a draft).

As far as adding new types: I believe there was the belief that this could
be accommodated by defining an "LLSD2" at some point in the future with a
distinct MIME type for serializations (e.g. application/llsd2+xml); unlike
the Web, content negotiation over HTTP was assumed to be functional within
VWRAP interoperation. Therefore, there was no push to ensure LLSD "v1" was
internally extensible or comprehensive for all imaginable scalar/structured

Anyway... if contributors have implementation of abstract data type systems
that share characteristics with LLSD and are thinking about adding
additional scalar/structured types, they should look at the issues with both
implementation languages and serialization formats.

-- Josh