From dzonatas@gmail.com Sun May 1 18:34:18 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED8EE0664 for ; Sun, 1 May 2011 18:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVnTjjvI4j9R for ; Sun, 1 May 2011 18:34:17 -0700 (PDT) Received: from mail-px0-f170.google.com (mail-px0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6C318E062A for ; Sun, 1 May 2011 18:34:17 -0700 (PDT) Received: by pxi19 with SMTP id 19so2244931pxi.15 for ; Sun, 01 May 2011 18:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=28V3y4JwC/h8Lcdf0RqRqUwYHK8uxUM9gqsfGaF3J4M=; b=XqSHuux2i99JIsC8xjbRL/WMgTvpw8QW56lGweBbPN8Si4AQEa9ksTWk8ht4vLfPHt fCN7QdwUSljvBKETCi/XK1xswfETDBbVZFZ9Wzvkgp+TWd29mvzyW5toSN/DARNi48yS IoWMWqhM4/rX7iQHc/g3Da8+XAzuAiS8l66d8= 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=CmIcc6NQTSGh6irCeZ0bXQ02I773HbhWIknoy2pgEz8eTMZ3gFkwjZGgZloOFxxepa q/Va3fr9ogutXbReOJtdOCfYK3kGHqsHnzARBR9vZ0qbkwVS84YeZsF+GBqiN/teSsfD lkzhipHlN04AewCtPr6XYVUwT4qIkK6bsHd3U= Received: by 10.68.40.134 with SMTP id x6mr7984016pbk.423.1304300056795; Sun, 01 May 2011 18:34:16 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id r7sm3476630pbo.52.2011.05.01.18.34.14 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 May 2011 18:34:15 -0700 (PDT) Message-ID: <4DBE09D2.4090007@gmail.com> Date: Sun, 01 May 2011 18:33:06 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org 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: Mon, 02 May 2011 01:34:18 -0000 In review of HTTPBIS (w/SPDY), TLS, and XMPP for forward-thinking cross-development with VWRAP, the one main concern I have with those and where I think VWRAP needs to focus is the language-agnostic approach in connections and transmissions. If we could move VWRAP more to the core and define default type system for basic data, then we can use the streams from the others to continue progress. The current complication to just add the others is how there is often allowances for JavaScript to control the connection or affect it in any way, which to me is similar to hardware-hacking (and easily breaks stream-ability, complicates batch queries, expects direct browser awareness, and more issues could be said we've known from real hardware-hacking). Those JavaScript allowances obviously have had the web-browser viewpoint paradigm in place, and VWRAP has had the virtual world paradigm. The problem with virtual world paradigm is that from one VW to another VW is like reinventing-the-Internet. I think VWRAP needs to refocus the "world" paradigm to useful patterns to virtualize and "wrap" these other IETF & RFC standards within XML. I don't mean redo every scheme, yet there are obvious patterns in the other WGs (& RFCs) that can use capabilities as deployed and present in VWRAP (yet to be fully outlined) rather than reinvent protocols. VWRAP can use the streams, presence, and TLS possibilities of the other WGs (& RFCs). As I have pointed out here: http://groups.google.com/group/spdy-dev/msg/2fe946257e157684 I continue to make the case/proposal for pivotal data. Imagine all queries being sent through a proxy (like with SPDY enabled) that then bundles (i.e. "wrap"s) up the data into a stream such as this basic flow: AVATAR:furryA GET ... PUT ... DELETE ... AVATAR:furryB POST ... ... If you think of the above flow as batched for the proxy to perform on the agent server, then the http queries could be used to manipulate inventory for furryA and furryB. The agent server could host WebSockets that viewers connect to such that would have those actions processed and then further bundled into the above for the region server to preform. Those http queries can actually be locally done on the region server, which then avoids transmission of the queries. The responses can be further bundled in return to the agent server. This basically projects the queries that would normally take place on the viewer sides into batches on the region. It only looks complicated until you consider the proxy does the http queries instead of the viewer or browser. Follow this pattern to "virtualize" monolithic browsers and viewers. We can design local proxy that acts as the (local) agent service for the viewer/browser. As IPv6 is fully in operation in June, we can use IPv4 clouds to be these proxies/agent-servers to the IPv6 world. The VWRAP enabled clouds adds purpose, not only to proxy, yet to stream, frame, and bundle queries between the IPv4 "region" and the IPv6 "region". Some already consider "the cloud" as the avatar/asset teleport device in regards to virtual worlds. Beside power consumption, one way I visualize these virtualization techniques is imagine your two robots/avatars on Mars and here on Earth you have a 3D surrounded room full of partitioned X-Windows and sound. There is a satellite as the proxy/agent-server. How can we use current protocols optimally to display here what is seen there? On top of that, add security for asset servers. Of note, the charter shows June 2011 for "Digital Assets". We could turn some of those HTTP requests, in the example above, directly into DAEs. When the proxy receives any DAE, the asset is stored into the cache. When the browser/viewer requests that asset item, the local cache already has the item and the browser/viewer possibly does not need to do further queries to the Internet. Essentially, detangled the web. On 04/30/2011 09:45 AM, Barry Leiba wrote: >> That said, we need to be leading this discussion on consensus that can >> be documented and posted. �And we need to focus on that and accomplish >> it soon, for a vague but near-term value of "soon". >> > We had a good bit of discussion in early April. Now that we're at the > end of April, and the discussions seem to have stopped for the last > couple of weeks, I'd like a progress report. Has there been any work > on coming to consensus on the direction the group wants to take? Any > progress on consensus for the contents of an intro/overview document? > > Barry, as chair > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Sun May 1 21:54:29 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD2EE0691 for ; Sun, 1 May 2011 21:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.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] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hYYecDBXF9X for ; Sun, 1 May 2011 21:54:28 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 645A6E062A for ; Sun, 1 May 2011 21:54:28 -0700 (PDT) Received: by qyk7 with SMTP id 7so2989979qyk.10 for ; Sun, 01 May 2011 21:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7Di38Q4lz0d1TEMXYvKAoBPwAcM0W16nEIghjeAwZjc=; b=YWuzK4aZeDBJI8OGnw838qwq/pWAlrM6XadALcdE84LmcpjEkhgQjxe6ALIaB+c081 nF9Bbe1qYtCpV2qEy1JA11Lf1b8NZH0EU4se90v7WEj0mcDO9HOWhjvkyrQPOmbcGyW4 MIHJoA4Ja2pElYY+lDM/IRq8tu2nyjfCfKDqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZzRw3axH+s4wahz1Gd1nmrr3BnKJMdNuuhycQcaJvmN2jz8NLh5R+JOwSfIgUkd6cF utyYcIC16c+5vv+fSb+xgrZhPfCu7uMusa1hFmBcwBMkDoD82iyMoAd7kcGy956UXXBh 3i8wPurii7H/MIPyAIKRqR9c++jEepO6PatSI= MIME-Version: 1.0 Received: by 10.229.102.85 with SMTP id f21mr5776764qco.25.1304312067620; Sun, 01 May 2011 21:54:27 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Sun, 1 May 2011 21:54:26 -0700 (PDT) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Mon, 2 May 2011 05:54:26 +0100 Message-ID: From: Morgaine To: Barry Leiba Content-Type: multipart/alternative; boundary=002354471a20777e5c04a243d11e Cc: vwrap@ietf.org Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org 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: Mon, 02 May 2011 04:54:29 -0000 --002354471a20777e5c04a243d11e Content-Type: text/plain; charset=ISO-8859-1 Barry, I took some time today to re-read every technical item posted here since your mail of March 23rd, and this is how I would summarize our recent burst of activity: - It seems that there is significant unhappiness about LLSD, for a range of reasons. Some are wondering why we are creating a new ADT rather than using an existing one like Protocol Buffers, while others are worried on a deeper level that LLSD is too rooted in SL legacy and gives us very little for the future. (I did not voice an opinion on that subject in this round, but I have in the past expressed worries about LLSD extensibility.) - All discussions now seem to be taking multiple worlds into account, which is a huge step forwards for interop and should serve us well for document writing, We are periodically giving assurance that "nobody is going to force you to interoperate", although that should really be obvious even to casual onlookers since denying interop is so easy. Additionally, it is our stated goal to support all deployment patterns, and the walled garden is one of those. - We have ascertained that we are not "writing docs just to write docs", but only docs that reflect consensus. Your description "tease consensus out of discussion and write it down" was very appealing. We are still at the teasing stage, but I do sense a convergence coming. - An attempt was made to gain a priori agreement to always accept superset requirements in VWRAP, or to put it another way, to adopt a group mantra of "design for tomorrow". I'm still not really sure whether it was the concept itself which attracted strong opposition (which I think would be most regrettable) or if the arguments were merely about choice of words. - Vaughn's wonderful protocol flow diagram kicked off an excellent discussion about protocol details. This was (remarkably) the first time we had ever discussed the asset access protocol over these 2-3 years of work, and it led us to examine two very important issues: (i) eliminating the burden of capabilities when there are no access restrictions on an asset, and (ii) separation of assets into metadata and content. This got us much closer to the real core of VWRAP than we have ever been, namely the asset services. - A previously unmentioned optional requirement appeared in the discussion: simulation consistency. Although optional, our protocol will need to allow it to be achieved (to the extent possible) when it is demanded by a region. Given all the above (and many other things discussed in passing), I am not at all unhappy with recent progress, and indeed it could be said that we achieved more for interop in 2 weeks than in the previous 2+ years. With regards to writing documents, we're still teasing out the technical details, but as we do this, our more general goals are starting to solidify as well, so I think that an Intro doc will come in due course. I do accept that this isn't happening very rapidly, but with so few bodies assisting in the analysis, it's hard to do better. Nevertheless, I think that we are achieving something useful. We may be even be close to condensing the recent discussions into a paragraph or two, because full solutions are not needed for an Intro. Morgaine. ========================= On Sat, Apr 30, 2011 at 5:45 PM, Barry Leiba wrote: > > That said, we need to be leading this discussion on consensus that can > > be documented and posted. And we need to focus on that and accomplish > > it soon, for a vague but near-term value of "soon". > > We had a good bit of discussion in early April. Now that we're at the > end of April, and the discussions seem to have stopped for the last > couple of weeks, I'd like a progress report. Has there been any work > on coming to consensus on the direction the group wants to take? Any > progress on consensus for the contents of an intro/overview document? > > Barry, as chair > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --002354471a20777e5c04a243d11e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Barry, I took some time today to re-read every technical item posted here s= ince your mail of March 23rd, and this is how I would summarize our recent = burst of activity:

  • It seems that there is significant unhapp= iness about LLSD, for a range of reasons.=A0 Some are wondering why we are = creating a new ADT rather than using an existing one like Protocol Buffers,= while others are worried on a deeper level that LLSD is too rooted in SL l= egacy and gives us very little for the future.=A0 (I did not voice an opini= on on that subject in this round, but I have in the past expressed worries = about LLSD extensibility.)
  • All discussions now seem to be taking multiple worlds into acc= ount, which is a huge step forwards for interop and should serve us well fo= r document writing,=A0 We are periodically giving assurance that "nobo= dy is going to force you to interoperate", although that should really= be obvious even to casual onlookers since denying interop is so easy.=A0 A= dditionally, it is our stated goal to support all deployment patterns, and = the walled garden is one of those.
  • We have ascertained that we are not "writing docs ju= st to write docs", but only docs that reflect consensus.=A0 Your descr= iption "tease consensus out of discussion and write it down" was = very appealing.=A0 We are still at the teasing stage, but I do sense a conv= ergence coming.
  • An attempt was made to gain a priori agreement to always accep= t superset requirements in VWRAP, or to put it another way, to adopt a grou= p mantra of "design for tomorrow".=A0 I'm still not really su= re whether it was the concept itself which attracted strong opposition (whi= ch I think would be most regrettable) or if the arguments were merely about= choice of words.
  • Vaughn's wonderful protocol flow diagram kicked off a= n excellent discussion about protocol details.=A0 This was (remarkably) the= first time we had ever discussed the asset access protocol over these 2-3 = years of work, and it led us to examine two very important issues: (i) elim= inating the burden of capabilities when there are no access restrictions on= an asset, and (ii) separation of assets into metadata and content.=A0 This= got us much closer to the real core of VWRAP than we have ever been, namel= y the asset services.
  • A previously unmentioned optional requirement appeared in the = discussion:=A0 simulation consistency.=A0 Although optional, our protocol w= ill need to allow it to be achieved (to the extent possible) when it is dem= anded by a region.

Given all the above (and many other things discussed in passing), = I am not at all unhappy with recent progress, and indeed it could be said t= hat we achieved more for interop in 2 weeks than in the previous 2+ years.= =A0 With regards to writing documents, we're still teasing out the tech= nical details, but as we do this, our more general goals are starting to so= lidify as well, so I think that an Intro doc will come in due course.

I do accept that this isn't happening very rapidly, but with so few= bodies assisting in the analysis, it's hard to do better.=A0 Neverthel= ess, I think that we are achieving something useful.

We may be even = be close to condensing the recent discussions into a paragraph or two, beca= use full solutions are not needed for an Intro.


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

O= n Sat, Apr 30, 2011 at 5:45 PM, Barry Leiba <barryleiba@computer.org> = wrote:
> That said, we need to be leading this discussion on consensus that ca= n
> be documented and posted. =A0And we need to focus on that and accompli= sh
> it soon, for a vague but near-term value of "soon".

We had a good bit of discussion in early April. =A0Now that we're= at the
end of April, and the discussions seem to have stopped for the last
couple of weeks, I'd like a progress report. =A0Has there been any work=
on coming to consensus on the direction the group wants to take? =A0Any
progress on consensus for the contents of an intro/overview document?

Barry, as chair
_________________________________________= ______
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--002354471a20777e5c04a243d11e-- From dzonatas@gmail.com Tue May 3 00:12:42 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB616E06DB for ; Tue, 3 May 2011 00:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rts+15-XBLkf for ; Tue, 3 May 2011 00:12:42 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0A49BE06D4 for ; Tue, 3 May 2011 00:12:42 -0700 (PDT) Received: by pzk5 with SMTP id 5so4200548pzk.31 for ; Tue, 03 May 2011 00:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=60KhxdZ7Msr9g04Epy/hg7NnAWkME4l8DHhS5xjMdqk=; b=TdrnUpU6hJxPiW0g6E4Z8WP960wuBuZZCZK2dFhzI9haK3l6VF5Mkz198lH2xUcyi+ faDZH6pHNPmDKGxG4FtXYgshye8wLQRy82xkvri9JPxL9xJou6RjKWXrr0Qg2uGD1n78 5pkGtRWzCAgfTraZ1cY6DOG3+PpwCWKrvFx8g= 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=ZLeNhnv5PmOH+U7/OlbSmyQJtIrfVgnyl1yxgv9v3EcnWRXU1fe+bOBmla1evNXQi8 APuPjUI8kbFoYShU/Ymn3LrO9KaBEz++f3kmN60cg9lgBh2IagGfkj7u/0LfxDcq+BQD yqiytmSlCDKZlYC+Yq4Uvlyn/jrliNysl4Ez4= Received: by 10.68.47.2 with SMTP id z2mr5014008pbm.327.1304406351730; Tue, 03 May 2011 00:05:51 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id d6sm4322657pbs.29.2011.05.03.00.05.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 May 2011 00:05:48 -0700 (PDT) Message-ID: <4DBFA909.3080009@gmail.com> Date: Tue, 03 May 2011 00:04:41 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org 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: Tue, 03 May 2011 07:12:42 -0000 To further zoom in past to now, I wonder if we should generally revisit & predict IPv4 *.net addresses have code-behind/IL that can be cached or shared as assets, so we can assume to sandbox *.net when in doubt. Assume IPv4 *.com addresses have code-behind/script secured on site or certified for transience. Assume IPv4 *.org addresses are web-fronts, proxies, gateways, and legacy. License issues 'can be resolved', diplomatically, by use of *.org as transition from *.edu "graduation" vitae. For virtualization, the significance here is XML element compression (with pattern kinetics and shared tokenization), which further means something to signal processors (or on the wire|stream|pipeline). Others may already have realized "what if there were already given common XML tokens for each TLD based on above" and even though the XML tag name is the same, the token value may differ for context (and precursorial types). If you follow, the differences in tokens values may act like pre-compressed interop states or less than volatile expect-states. Hmmm.... think I avoided terminology of quantum-jargon, dynamic compilers, and trinary arithmetics in the above. So I came up for a breath of air, and looked at http://test-ipv6.com/ ...then wondered about the viewer in a browser, or browser in a viewer, and reviewed the above ideology again (and fell-back to "frames" possibility and windows "surface" probability). On 04/30/2011 09:45 AM, Barry Leiba wrote: >> That said, we need to be leading this discussion on consensus that can >> be documented and posted. �And we need to focus on that and accomplish >> it soon, for a vague but near-term value of "soon". >> > We had a good bit of discussion in early April. Now that we're at the > end of April, and the discussions seem to have stopped for the last > couple of weeks, I'd like a progress report. Has there been any work > on coming to consensus on the direction the group wants to take? Any > progress on consensus for the contents of an intro/overview document? > > Barry, as chair > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Tue May 3 06:53:46 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3363E0694 for ; Tue, 3 May 2011 06:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0H6oCRENfe9 for ; Tue, 3 May 2011 06:53:46 -0700 (PDT) Received: from mail-px0-f170.google.com (mail-px0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4B9E081D for ; Tue, 3 May 2011 06:53:46 -0700 (PDT) Received: by pxi19 with SMTP id 19so155790pxi.15 for ; Tue, 03 May 2011 06:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5xdL/njgOTysO5jXJJj6Kb4AZ1IwRh+5sa+SXh65UME=; b=FuypqIszJl/8IOSts02Uut85wQD+hbczjKXLbI2HVWbofvintz/5PmJYFWazudbKmO G/Qt+NDDJzKZgk3Fw4f9t14g6dpW7h0Hr5FeVLwfrBVR90YT2EsaGosB3RQUgEUVHRPj TuD32OotG/ooSob67djPFswaBVYTGXWp1GcDM= 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=h+IO5w+5NXNvQaX2j4QYt9/OWDfMYdcVSNExMiM8KdRCnGNJvBVETH0ckwsU26QaLU V3QeFYUJaPwjaG0M9OIMOX0+1tg1nj0JjH2JKPhZWeEdfwR5UWjN33OeKixzqCKgkjJr lNbgNqh0fd7ogGWS15VritreEr736CSnk1tps= Received: by 10.68.64.193 with SMTP id q1mr4604258pbs.488.1304430825538; Tue, 03 May 2011 06:53:45 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id z7sm58069pbm.53.2011.05.03.06.53.43 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 May 2011 06:53:44 -0700 (PDT) Message-ID: <4DC008A5.3090002@gmail.com> Date: Tue, 03 May 2011 06:52:37 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: "vwrap@ietf.org" References: <4DBFA909.3080009@gmail.com> In-Reply-To: <4DBFA909.3080009@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org 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: Tue, 03 May 2011 13:53:46 -0000 Meant to add some purpose to that last message: how to see overall current trends without the envelope of proprietary or institutionalized mechanisms, and identify region-agent transistions in media. I did try to scrape people's simulated affinity of virtual worlds (if we re-charter); although, sim-usage is easier to explain and "play" with real-time concepts. My front-end workstation is already encapsulated in 3D with current protocols, and I can't grasp why continue to put another system for 3D "awesome" simulation within another 3D simulation within the 3D viewer within 2D browser in a 2D window in the 3D monitor on a 3D network (with various protocols on protocols) in the real 3D world. Thanks, I hope this is clearer. More later.... On 05/03/2011 12:04 AM, Dzonatas Sol wrote: > To further zoom in past to now, I wonder if we should generally > revisit & predict IPv4 *.net addresses have code-behind/IL that can be > cached or shared as assets, so we can assume to sandbox *.net when in > doubt. Assume IPv4 *.com addresses have code-behind/script secured on > site or certified for transience. Assume IPv4 *.org addresses are > web-fronts, proxies, gateways, and legacy. License issues 'can be > resolved', diplomatically, by use of *.org as transition from *.edu > "graduation" vitae. > > For virtualization, the significance here is XML element compression > (with pattern kinetics and shared tokenization), which further means > something to signal processors (or on the wire|stream|pipeline). > Others may already have realized "what if there were already given > common XML tokens for each TLD based on above" and even though the XML > tag name is the same, the token value may differ for context (and > precursorial types). If you follow, the differences in tokens values > may act like pre-compressed interop states or less than volatile > expect-states. > > Hmmm.... think I avoided terminology of quantum-jargon, dynamic > compilers, and trinary arithmetics in the above. > > So I came up for a breath of air, and looked at http://test-ipv6.com/ > > ...then wondered about the viewer in a browser, or browser in a > viewer, and reviewed the above ideology again (and fell-back to > "frames" possibility and windows "surface" probability). > > On 04/30/2011 09:45 AM, Barry Leiba wrote: >>> That said, we need to be leading this discussion on consensus that can >>> be documented and posted. �And we need to focus on that and accomplish >>> it soon, for a vague but near-term value of "soon". >> We had a good bit of discussion in early April. Now that we're at the >> end of April, and the discussions seem to have stopped for the last >> couple of weeks, I'd like a progress report. Has there been any work >> on coming to consensus on the direction the group wants to take? Any >> progress on consensus for the contents of an intro/overview document? >> >> Barry, as chair >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From ohmeadhbh@gmail.com Tue May 3 07:14:35 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54585E06B6 for ; Tue, 3 May 2011 07:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAGasvUiZwYt for ; Tue, 3 May 2011 07:14:33 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 45E1AE0684 for ; Tue, 3 May 2011 07:14:33 -0700 (PDT) Received: by wwa36 with SMTP id 36so89882wwa.13 for ; Tue, 03 May 2011 07:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=NbmbiSGoiLJjMuCeWeKoVxsoYcpM6WJe0pd0Ih4Azqo=; b=jjXK3RBDsULwilq/7+GBLsOmw8/91+hHKcJlBuFk6E6DHSKZtmP/BO8WZJfB7WYKiJ ysl+bROBiMElbEPw8+VPss4KWnX8W5sSa2OppkU5537RyWRJj+xKK2TPAA+HekTwHQgT 8ApUDNDQWaQVd4iF2qYh1IzByrWh0R1ouxCZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=Gjb9wP70CGihj0sg0qBopdfMgnXOJ/B215KUrtpsWCFRtMH5YlZ+cVPtkjc+uzGjkk LRxBRT0btd3sE1q6s09kEr9iOCxM+tBCeekEGJlgLjy0U7s152LjcuAWzM/lbipQ/LTl QMNV/6qfmL6UavWsPFwjK48TtxH3yWWZweGAY= Received: by 10.216.82.142 with SMTP id o14mr6909326wee.114.1304432071156; Tue, 03 May 2011 07:14:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.157.75 with HTTP; Tue, 3 May 2011 07:14:11 -0700 (PDT) In-Reply-To: <4DC008A5.3090002@gmail.com> References: <4DBFA909.3080009@gmail.com> <4DC008A5.3090002@gmail.com> From: Meadhbh Hamrick Date: Tue, 3 May 2011 07:14:11 -0700 Message-ID: To: Dzonatas Sol Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org 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: Tue, 03 May 2011 14:14:35 -0000 oh. the reason people layer protocols in general is so we can re-use the work done by others. like for instance, a lot of the old linden VWRAP / OGP stuff used REST semantics to access data. we could have written our own protocol on top of TCP, by why? HTTP had all the bits we needed. there were several very good implementations already out there, and firewalls will sometimes pass HTTP when they won't pass UDP or other TCP protocols. XMPP is also very interesting due to it's "event stream" semantics. my hope was to specify a high-level abstract data / interface description language (LLSD or DSD) and then produce "mappings" for concretizing abstract data definitions onto several real protocols (like HTTP, XMPP and RTP.) though i'm not sure if anyone here is even interested in that anymore. but the advantage of layering is you can create new services relatively easily. you just create the abstract description of the new service, and since you have rules for mapping the abstract service to a concrete protocol, you're more or less done. the alternative, embodied by the legacy linden UDP protocol (LLUP) was to shove a bunch of data into a packet and require the receiver to just know the structure and type details. this is not a way to produce resilient products. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Tue, May 3, 2011 at 6:52 AM, Dzonatas Sol wrote: > Meant to add some purpose to that last message: how to see overall curren= t > trends without the envelope of proprietary or institutionalized mechanism= s, > and identify region-agent transistions in media. > > I did try to scrape people's simulated affinity of virtual worlds (if we > re-charter); although, sim-usage is easier to explain and "play" with > real-time concepts. > > My front-end workstation is already encapsulated in 3D with current > protocols, and I can't grasp why continue to put another system for 3D > "awesome" simulation within another 3D simulation within the 3D viewer > within 2D browser in a 2D window in the 3D monitor on a 3D network (with > various protocols on protocols) in the real 3D world. > > Thanks, I hope this is clearer. =C2=A0More later.... > > On 05/03/2011 12:04 AM, Dzonatas Sol wrote: >> >> To further zoom in past to now, I wonder if we should generally revisit = & >> predict IPv4 *.net addresses have code-behind/IL that can be cached or >> shared as assets, so we can assume to sandbox *.net when in doubt. Assum= e >> IPv4 *.com addresses have code-behind/script secured on site or certifie= d >> for transience. Assume IPv4 *.org addresses are web-fronts, proxies, >> gateways, and legacy. License issues 'can be resolved', diplomatically, = by >> use of *.org as transition from *.edu "graduation" vitae. >> >> For virtualization, the significance here is XML element compression (wi= th >> pattern kinetics and shared tokenization), which further means something= to >> signal processors (or on the wire|stream|pipeline). Others may already h= ave >> realized "what if there were already given common XML tokens for each TL= D >> based on above" and even though the XML tag name is the same, the token >> value may differ for context (and precursorial types). If you follow, th= e >> differences in tokens values may act like pre-compressed interop states = or >> less than volatile expect-states. >> >> Hmmm.... =C2=A0think I avoided terminology of quantum-jargon, dynamic >> compilers, and trinary arithmetics in the above. >> >> So I came up for a breath of air, and looked at http://test-ipv6.com/ >> >> ...then wondered about the viewer in a browser, or browser in a viewer, >> and reviewed the above ideology again (and fell-back to "frames" possibi= lity >> and windows "surface" probability). >> >> On 04/30/2011 09:45 AM, Barry Leiba wrote: >>>> >>>> That said, we need to be leading this discussion on consensus that can >>>> be documented and posted. =EF=BF=BDAnd we need to focus on that and ac= complish >>>> it soon, for a vague but near-term value of "soon". >>> >>> We had a good bit of discussion in early April. =C2=A0Now that we're at= the >>> end of April, and the discussions seem to have stopped for the last >>> couple of weeks, I'd like a progress report. =C2=A0Has there been any w= ork >>> on coming to consensus on the direction the group wants to take? =C2=A0= Any >>> progress on consensus for the contents of an intro/overview document? >>> >>> Barry, as chair >>> _______________________________________________ >>> vwrap mailing list >>> vwrap@ietf.org >>> https://www.ietf.org/mailman/listinfo/vwrap >>> >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From ohmeadhbh@gmail.com Tue May 3 07:20:18 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A357EE06B6 for ; Tue, 3 May 2011 07:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYyPEq-Frzgl for ; Tue, 3 May 2011 07:20:16 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E254E0684 for ; Tue, 3 May 2011 07:20:16 -0700 (PDT) Received: by wyb29 with SMTP id 29so108584wyb.31 for ; Tue, 03 May 2011 07:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=F358dI6j7ewnF4TOiZ9MKIt1dbN5nGEwAQRix5poS5s=; b=fFb67BK2WFh6OtyKqVy4dtuL6rLA9OYzBUFovzqsBus9Vdr+xoYBUJxN5mBtbPAIss FJ4cGIT7hrKqjODaJfsCPdkZRlGTmgw+FykQQisxuayauRbzK5XWlQmKsS4Brt2OBgBV Z9gm/FLL6YCleIENIS5l72mZtIhL1CkR314eQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=ntDUO1lT592/KgN+DivBDgN8CLpcjgO+qnykkptcUPScyQuK50BBd5NujbiOzmd1se za1l/FyPz+Y1dkE2Qvq418BYzjgfCJHQ4XxsogtUAhQ3hzyRHGwV5eWXOzimDDEOGzmN cvIIxvCqph1bRzAoxR/Ss6VD+2E4jtQ9ZJnyY= Received: by 10.216.93.130 with SMTP id l2mr3665212wef.114.1304432415134; Tue, 03 May 2011 07:20:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.157.75 with HTTP; Tue, 3 May 2011 07:19:55 -0700 (PDT) From: Meadhbh Hamrick Date: Tue, 3 May 2011 07:19:55 -0700 Message-ID: To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [vwrap] is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Tue, 03 May 2011 14:20:18 -0000 is anyone in this group still interested in using LLSD (or it's successor, DSD)? if so, i'm going to publish the DSD draft here. if not, i'm going to wait for the group to say "we are in no way interested in LLSD or DSD" and then submit it as an individual submission to the RFC editor. it's been about three years, and i would really like to get an RFC published so i can take the X- off all my application/llsd family of mime types. so... may i see a show of hands... is anyone still planning on implementing a system with LLSD in this group? please just respond yes or no in reply to this thread. i'll start another thread for discussion. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com From ohmeadhbh@gmail.com Tue May 3 07:26:14 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC8FE06B6 for ; Tue, 3 May 2011 07:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5pPPA7Yn0Gb for ; Tue, 3 May 2011 07:26:13 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 89974E0684 for ; Tue, 3 May 2011 07:26:13 -0700 (PDT) Received: by wyb29 with SMTP id 29so113787wyb.31 for ; Tue, 03 May 2011 07:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=uyi7aL326PeFzLAO2+jejg4k6Znlmz3XAKjtFt4gJtI=; b=OWnyHRq2Dce4rGofEMs+T+Fcd3n0ieR2EbHUHAMDLUYnCL3ip4QcX7+i0xD5EPnQhu 6IY8C5+GRzbCVtuV2xRC45jm4haRxnERJf3gehoyWN4CDlf72KPzxUuXkBQCMLPAmisR OY5XhnAF2PA0ixh9C3p0iYSqJ1DLsRH9hp0Bw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=dfmR4JQwtzDlOe+heRsvrRS/tMZTB4qN8vc7r5d5VwyxC2W9ZyKjXNLGfDN1Y7MfPl NSprcjqRB6yFBBmiTdLkv9D+3H5N3dXCg+7zmD6cOZ6PCrP4QTL7stWERvoCR6ZxoIBr 5M+YW3AMpPl5YrYN6yXsUivyJIrpsHI9ugt+M= Received: by 10.216.82.142 with SMTP id o14mr6921143wee.114.1304432769111; Tue, 03 May 2011 07:26:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.157.75 with HTTP; Tue, 3 May 2011 07:25:49 -0700 (PDT) From: Meadhbh Hamrick Date: Tue, 3 May 2011 07:25:49 -0700 Message-ID: To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [vwrap] about abstract type systems... llsd and dsd X-BeenThere: vwrap@ietf.org 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: Tue, 03 May 2011 14:26:14 -0000 i think the most recent version of the LLSD draft can be found here: http://tools.ietf.org/id/draft-ietf-vwrap-type-system-00.txt i proposed a follow-on to LLSD (called DSD.) you can see an outline of it's features here: http://blog.meadhbh.org/2010/07/abstract-resource-definitions-vs-llidl.html but... if no-one in this group plans on using it, i would like to submit it as an individual submission to the RFC editor for the purpose of registering it's mime types. so... when you write your VWRAP implementation, are you going to use LLSD or DSD. why? why not? -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com From dzonatas@gmail.com Tue May 3 12:05:35 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B010E06B1 for ; Tue, 3 May 2011 12:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3KncHKj3e-7 for ; Tue, 3 May 2011 12:05:35 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 02F07E067F for ; Tue, 3 May 2011 12:05:34 -0700 (PDT) Received: by pzk5 with SMTP id 5so208094pzk.31 for ; Tue, 03 May 2011 12:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=MDGYoLL1AZmD5i/QkOGKpATaejTxv8mCNIJmkt1XwH8=; b=YfBKlFhAWyrmtzHbEbdkHUbqSM9N834D1fUA7Q8rOuRgVpHLkI2/033B42dkXckUw9 SVx9AOjZqYWJjwM+eSo3QH8y1yVKW2J3t8N5EZsD3JDsPTFEgQMxJE/GvLwxw5+XHoir GvTi0RrVfbCxLgXSAlRGrlnIE8F3NrgT3FsE0= 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=Xh2lXFEdsfRxCJYniXQkbxMMWcFlNeyGHPkeCOzQU8oKG406c6b+0hZleLxl2P6BgT LOSMoMPgPi7ldX3NfZwmjyjFX9WHScEb1dgiYWbs50xjoofoGh+EsKyBEjAXxaTRd0MP mIuS43FEwAkD+P0vdvK/GDmd9Bgh9vgH/Wr70= Received: by 10.68.47.5 with SMTP id z5mr232392pbm.450.1304449533340; Tue, 03 May 2011 12:05:33 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id r5sm202625pbe.101.2011.05.03.12.05.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 May 2011 12:05:32 -0700 (PDT) Message-ID: <4DC051BA.5020501@gmail.com> Date: Tue, 03 May 2011 12:04:26 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] about abstract type systems... llsd and dsd X-BeenThere: vwrap@ietf.org 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: Tue, 03 May 2011 19:05:35 -0000 On 05/03/2011 07:25 AM, Meadhbh Hamrick wrote: > so... when you write your VWRAP implementation, are you going to use > LLSD or DSD. why? why not? > Already implemented LLSD last year and deployed. Wrote Snowglobe.Scalar in C# that implents LLSD read/write from buffers/streams and native C# usage in familar format as used in the Snowglobe/Snowstorm C++ source. The source is in Icesphere. Also already started to move Icesphere and my contributions for Snowglobe/Snowstorm to github (where we can fork together). Others can find VWRAP, LLSD, and the HTTP server in Snowglobe/Snowstorm with what I started as combined queries (what SPDY doesn't do) between frames. I wrote my experience with pro/cons on this list that seemed unanswered. Have you looked at the LLIDL in my documentation and notice how the combined queries worked? Noticed your last message here: http://www.ietf.org/mail-archive/web/vwrap/current/msg00775.html Further straw-man without implementation, I can't give you any yes or no answer on that. There's no specific IETF rule, yet demonstrated flow seems what other WGs expect. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From ohmeadhbh@gmail.com Tue May 3 12:12:03 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285ACE06F9 for ; Tue, 3 May 2011 12:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXW8GnbEQci7 for ; Tue, 3 May 2011 12:12:02 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 18F2DE066E for ; Tue, 3 May 2011 12:12:01 -0700 (PDT) Received: by wwa36 with SMTP id 36so311708wwa.13 for ; Tue, 03 May 2011 12:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=csjE4ndQM6zFp8XtBamNeyW/3gKDKyD9suWqUcmSnQY=; b=D5scHdc7hqDwCV8WbdJzNsVU1taheDCb93A8EcMdjAjtkJwzIh10tE6n7nb4GEg7gn 77CupkxTkrPx5X3wYg0bGnYYdrMetw4GNp1wyuqZxylV3XVRG3eh/Cm99dr4SoLr3K5I 4+j8dzub8neGLrixfKGjfX7A6pOGW3UACzmo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=KdHdQ4/jty9iYQo42vg2dd7D1Ngz5btNL6R9eEATI3Ak3ffS9kI37d8fz8g+JUJdA9 Pjh/Rna2WYVX6VhfQCeiRTfHZYgqyt6r6Wv7KH/n49hBDBCCmXrXlE9tf32Vu/nK/Y82 TsXo9KSk/1qOa0NaXtaTMoKCj28q7RheNuLyw= Received: by 10.216.93.130 with SMTP id l2mr3951884wef.114.1304449921130; Tue, 03 May 2011 12:12:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.157.75 with HTTP; Tue, 3 May 2011 12:11:41 -0700 (PDT) In-Reply-To: <4DC051BA.5020501@gmail.com> References: <4DC051BA.5020501@gmail.com> From: Meadhbh Hamrick Date: Tue, 3 May 2011 12:11:41 -0700 Message-ID: To: Dzonatas Sol Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org Subject: Re: [vwrap] about abstract type systems... llsd and dsd X-BeenThere: vwrap@ietf.org 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: Tue, 03 May 2011 19:12:03 -0000 right. but that was before we decided as a group to rewrite the charter and intro doc. i guess my question to you would be, are you interested in keeping LLSD as part of VWRAP? -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Tue, May 3, 2011 at 12:04 PM, Dzonatas Sol wrote: > On 05/03/2011 07:25 AM, Meadhbh Hamrick wrote: >> >> so... when you write your VWRAP implementation, are you going to use >> LLSD or DSD. why? why not? >> > > Already implemented LLSD last year and deployed. Wrote Snowglobe.Scalar in > C# that implents LLSD read/write from buffers/streams and native C# usage in > familar format as used in the Snowglobe/Snowstorm C++ source. The source is > in Icesphere. Also already started to move Icesphere and my contributions > for Snowglobe/Snowstorm to github (where we can fork together). Others can > find VWRAP, LLSD, and the HTTP server in Snowglobe/Snowstorm with what I > started as combined queries (what SPDY doesn't do) between frames. > > I wrote my experience with pro/cons on this list that seemed unanswered. > Have you looked at the LLIDL in my documentation and notice how the combined > queries worked? > > Noticed your last message here: > http://www.ietf.org/mail-archive/web/vwrap/current/msg00775.html > > Further straw-man without implementation, I can't give you any yes or no > answer on that. There's no specific IETF rule, yet demonstrated flow seems > what other WGs expect. > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From ohmeadhbh@gmail.com Tue May 3 12:13:25 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1928DE0718 for ; Tue, 3 May 2011 12:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY63z4kK6B15 for ; Tue, 3 May 2011 12:13:24 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE9DE06C3 for ; Tue, 3 May 2011 12:13:24 -0700 (PDT) Received: by wwk4 with SMTP id 4so3612105wwk.1 for ; Tue, 03 May 2011 12:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9+GPbg2JjMzg+jGjaz5zBBb8+ECLdoeutfDPp/orF/c=; b=TLwXEW//S77vmNVh2CzLHUMREHLN44G2LIajaK9wg/JpZjipIz5BFh5B+jwBF4+qs1 Wmir8yzPzl8s8e+pztvpxiknAodImd71S6Kv1EJK8N4ObQMl0FhSOSNhIjjEGhEg71LB PBL7G35mhw/Q7L9hA+FGZVGSVa1mDHrHwOxHk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=pElMuolZDVA4mI2kitFeYmXm3jQqyzK2fVv22XV5lC5uhxcd9mGMXXw9rdkgU94FWS zJUoelOSHZJ3aSLZE/2rKESE/XldG9xyA/qy/v3wRBOUQ0HrcoVg+4WOZVQ8MMcoVHue QqOIH/gkeLR61hOrIXAnoogEdArOoI/tzzm4Y= Received: by 10.216.221.30 with SMTP id q30mr174673wep.84.1304450003070; Tue, 03 May 2011 12:13:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.157.75 with HTTP; Tue, 3 May 2011 12:13:03 -0700 (PDT) In-Reply-To: References: <4DC051BA.5020501@gmail.com> From: Meadhbh Hamrick Date: Tue, 3 May 2011 12:13:03 -0700 Message-ID: To: Dzonatas Sol Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org Subject: Re: [vwrap] about abstract type systems... llsd and dsd X-BeenThere: vwrap@ietf.org 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: Tue, 03 May 2011 19:13:25 -0000 and... is a DSD style syntax for resources and separation of concerns worth it to break compatibility with existing LLIDL implementations? -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Tue, May 3, 2011 at 12:11 PM, Meadhbh Hamrick wrote: > right. but that was before we decided as a group to rewrite the > charter and intro doc. > > i guess my question to you would be, are you interested in keeping > LLSD as part of VWRAP? > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Tue, May 3, 2011 at 12:04 PM, Dzonatas Sol wrote: >> On 05/03/2011 07:25 AM, Meadhbh Hamrick wrote: >>> >>> so... when you write your VWRAP implementation, are you going to use >>> LLSD or DSD. why? why not? >>> >> >> Already implemented LLSD last year and deployed. Wrote Snowglobe.Scalar in >> C# that implents LLSD read/write from buffers/streams and native C# usage in >> familar format as used in the Snowglobe/Snowstorm C++ source. The source is >> in Icesphere. Also already started to move Icesphere and my contributions >> for Snowglobe/Snowstorm to github (where we can fork together). Others can >> find VWRAP, LLSD, and the HTTP server in Snowglobe/Snowstorm with what I >> started as combined queries (what SPDY doesn't do) between frames. >> >> I wrote my experience with pro/cons on this list that seemed unanswered. >> Have you looked at the LLIDL in my documentation and notice how the combined >> queries worked? >> >> Noticed your last message here: >> http://www.ietf.org/mail-archive/web/vwrap/current/msg00775.html >> >> Further straw-man without implementation, I can't give you any yes or no >> answer on that. There's no specific IETF rule, yet demonstrated flow seems >> what other WGs expect. >> >> >> -- >> --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> > From dzonatas@gmail.com Tue May 3 12:40:26 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173DEE0744 for ; Tue, 3 May 2011 12:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VomEHBD8Mx2z for ; Tue, 3 May 2011 12:40:25 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC688E076D for ; Tue, 3 May 2011 12:40:24 -0700 (PDT) Received: by pzk5 with SMTP id 5so224148pzk.31 for ; Tue, 03 May 2011 12:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RHpUYpniWwBMVSCBI5sZ/s+iAHWiZXq3ZftQgMeMG9c=; b=PxAYTezF/TRby2cwfbK44IbkBvCF9i74YJPF3uqiwIvCm6lWbLmPrVVtL93PDMJwid zs6HCaUXEWaoRa2wc9ThVQLu3S25yLGixNiJ3etH2gXcJ0sXWNWaMv6xNAZdWHj4aq2G 6/lbc5K/LMvEoQJpBuFeV07eniDJh7irSZKSQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=olXxYJ5giEa9Sf9O2+5T3JHyIaXCNaj+YgElX38LL7RzRKJLudt3nUAI3zqxn0nfmp QVXsnG77PGmZe+BkByolU8DzBMnFobZhvzlS4Y51/hc01DftG2q58HgKlY19a4D7Jb5Z pOrQMQOdRYldXsaG5Gd46YyOcTV05FaznkklM= Received: by 10.68.9.196 with SMTP id c4mr286288pbb.461.1304451624442; Tue, 03 May 2011 12:40:24 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id z2sm222771pbp.48.2011.05.03.12.40.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 May 2011 12:40:21 -0700 (PDT) Message-ID: <4DC059E3.7050408@gmail.com> Date: Tue, 03 May 2011 12:39:15 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Meadhbh Hamrick References: <4DC051BA.5020501@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] about abstract type systems... llsd and dsd X-BeenThere: vwrap@ietf.org 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: Tue, 03 May 2011 19:40:26 -0000 With how I used LLIDL, yes. That's good enough for generic example of flow. I would further call that XML context with symbolic representation in content is highly abstract and atomical in the same instance. This has been demonstrated by dynamic compilers. Why avoid the obvious? On 05/03/2011 12:11 PM, Meadhbh Hamrick wrote: > right. but that was before we decided as a group to rewrite the > charter and intro doc. > > i guess my question to you would be, are you interested in keeping > LLSD as part of VWRAP? > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Tue, May 3, 2011 at 12:04 PM, Dzonatas Sol wrote: > >> On 05/03/2011 07:25 AM, Meadhbh Hamrick wrote: >> >>> so... when you write your VWRAP implementation, are you going to use >>> LLSD or DSD. why? why not? >>> >>> >> Already implemented LLSD last year and deployed. Wrote Snowglobe.Scalar in >> C# that implents LLSD read/write from buffers/streams and native C# usage in >> familar format as used in the Snowglobe/Snowstorm C++ source. The source is >> in Icesphere. Also already started to move Icesphere and my contributions >> for Snowglobe/Snowstorm to github (where we can fork together). Others can >> find VWRAP, LLSD, and the HTTP server in Snowglobe/Snowstorm with what I >> started as combined queries (what SPDY doesn't do) between frames. >> >> I wrote my experience with pro/cons on this list that seemed unanswered. >> Have you looked at the LLIDL in my documentation and notice how the combined >> queries worked? >> >> Noticed your last message here: >> http://www.ietf.org/mail-archive/web/vwrap/current/msg00775.html >> >> Further straw-man without implementation, I can't give you any yes or no >> answer on that. There's no specific IETF rule, yet demonstrated flow seems >> what other WGs expect. >> >> >> -- >> --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Wed May 4 05:25:00 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DFDE071A for ; Wed, 4 May 2011 05:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViOVjRw6Mnrj for ; Wed, 4 May 2011 05:25:00 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id C0242E0682 for ; Wed, 4 May 2011 05:24:59 -0700 (PDT) Received: by qwc23 with SMTP id 23so787437qwc.31 for ; Wed, 04 May 2011 05:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hrJUY5/5xDQxWFeZna3ep5aLUNneelm18ZeECeNoIRA=; b=PbexzN6cmIIHrLbvCH3NcGGwC6rFbzq0cL31EUUTvYvOi7nSjU9hDFuCjgkqJ63lRz JkzvkbUaDXrcCXcgAZIi7vWkHOLUDj3z/TGpfDsZfIaaq83FXZclHmU0xhl+1ni6HaWI hooHl7Vk2fqUTaTstE3/iJCVppetRz0HkFOdw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Jp7QKG0Qly8ajOiCcuhr8GH+7kKgAKNtTiCD0T7AqxbOmNylxqdtoR+deXaC4+mH0l OwYlg39ULrYKNWDyOJADr/6T54gDXCu0p9hSnpyqEzdO5GfbYh1qsdYvlc0nBmWVx9Jm PM8Q8RojN+yvJXvazHkZL6QpU2BtIr9rIpRQA= MIME-Version: 1.0 Received: by 10.229.44.141 with SMTP id a13mr704943qcf.101.1304511897395; Wed, 04 May 2011 05:24:57 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Wed, 4 May 2011 05:24:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 4 May 2011 13:24:57 +0100 Message-ID: From: Morgaine To: Meadhbh Hamrick Content-Type: multipart/alternative; boundary=001636831fa03fe34504a2725858 Cc: vwrap@ietf.org Subject: Re: [vwrap] is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Wed, 04 May 2011 12:25:01 -0000 --001636831fa03fe34504a2725858 Content-Type: text/plain; charset=ISO-8859-1 You're mixing up two very different questions, Meadhbh: the first is whether anyone is going to use DSD for something personally (in the way that they have already used LLSD in the past), and the second is whether VWRAP might adopt DSD for its type system. The answer to the first is clearly "*Yes*" because it's already been done with LLSD in an ad hoc fashion. However, it would be excellent if you were to publish a proper RFC on DSD, and even better if you could provide an actual library and bindings/API for it. None of the current implementations of LLSD went as far as creating separate and directly usable LLSD API projects maintained by their creators, as the libomv and C++ implementations are entangled within the very large codebases of their respective projects, and the other implementations are poor quality and not maintained. You could do much better than they did, and keep a discrete DSD library afloat and up to date. That would ensure its survival. The answer to the second question is equally clearly "*No*", because IETF working groups don't work through proposers' ultimatums. A few weeks ago there were significant questions raised here about whether LLSD/DSD is adequate for a standard that is intended *for the future* of VWs rather than for implementing today's SL and Opensim-based software, so it's clear that the issue hasn't been decided and requires more examination. Carlo put it (rather bluntly) here --- http://www.ietf.org/mail-archive/web/vwrap/current/msg00569.html . Without going into the politics of it, I want to see VWRAP have a properly extensible type system, and the current LLSD does not meet that requirement. Indeed, in the early days of our IETF effort, we spent months discussing the width of integers in LLSD because there was only *one width*allowed and it was *hardwired* in the spec. That's not an extensible approach to data types at all. We need to do a lot better in this area if we really mean "extensible" when we say "extensible". At present that ADT proposal is not extensible in any meaningful way. Morgaine. ==================== On Tue, May 3, 2011 at 3:19 PM, Meadhbh Hamrick wrote: > is anyone in this group still interested in using LLSD (or it's successor, > DSD)? > > if so, i'm going to publish the DSD draft here. if not, i'm going to > wait for the group to say "we are in no way interested in LLSD or DSD" > and then submit it as an individual submission to the RFC editor. it's > been about three years, and i would really like to get an RFC > published so i can take the X- off all my application/llsd family of > mime types. > > so... may i see a show of hands... is anyone still planning on > implementing a system with LLSD in this group? > > please just respond yes or no in reply to this thread. i'll start > another thread for discussion. > > -cheers > -meadhbh > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --001636831fa03fe34504a2725858 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You're mixing up two very different questions, Meadhbh:=A0 the first is= whether anyone is going to use DSD for something personally (in the way th= at they have already used LLSD in the past), and the second is whether VWRA= P might adopt DSD for its type system.

The answer to the first is clearly "Yes" because it= 9;s already been done with LLSD in an ad hoc fashion.=A0 However, it would = be excellent if you were to publish a proper RFC on DSD, and even better if= you could provide an actual library and bindings/API for it.=A0 None of th= e current implementations of LLSD went as far as creating separate and dire= ctly usable LLSD API projects maintained by their creators, as the libomv a= nd C++ implementations are entangled within the very large codebases of the= ir respective projects, and the other implementations are poor quality and = not maintained.=A0 You could do much better than they did, and keep a discr= ete DSD library afloat and up to date.=A0 That would ensure its survival.
The answer to the second question is equally clearly "No&qu= ot;, because IETF working groups don't work through proposers' ulti= matums.=A0 A few weeks ago there were significant questions raised here abo= ut whether LLSD/DSD is adequate for a standard that is intended for the = future of VWs rather than for implementing today's SL and Opensim-b= ased software, so it's clear that the issue hasn't been decided and= requires more examination.

Carlo put it (rather bluntly) here --- http://www.ietf.org/mail-archi= ve/web/vwrap/current/msg00569.html .=A0 Without going into the politics= of it, I want to see VWRAP have a properly extensible type system, and the= current LLSD does not meet that requirement.=A0 Indeed, in the early days = of our IETF effort, we spent months discussing the width of integers in LLS= D because there was only one width allowed and it was hardwired in the spec.=A0 That's not an extensible approach to data types at a= ll.

We need to do a lot better in this area if we really mean "extensi= ble" when we say "extensible".=A0 At present that ADT propos= al is not extensible in any meaningful way.


Morgaine.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Tue, May 3, 2011 at 3:19 PM, Meadhbh Hamrick <ohmeadhbh@gmail.c= om> wrote:
is anyone in this group still interested in using LLSD (or it's success= or, DSD)?

if so, i'm going to publish the DSD draft here. if not, i'm going t= o
wait for the group to say "we are in no way interested in LLSD or DSD&= quot;
and then submit it as an individual submission to the RFC editor. it's<= br> been about three years, and i would really like to get an RFC
published so i can take the X- off all my application/llsd family of
mime types.

so... may i see a show of hands... is anyone still planning on
implementing a system with LLSD in this group?

please just respond yes or no in reply to this thread. i'll start
another thread for discussion.

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadh= bh.org/ * OhMeadhbh@gmail.com
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--001636831fa03fe34504a2725858-- From dzonatas@gmail.com Wed May 4 06:31:52 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60693E0791 for ; Wed, 4 May 2011 06:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.182 X-Spam-Level: X-Spam-Status: No, score=-4.182 tagged_above=-999 required=5 tests=[AWL=-0.583, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAMtoiH2akoy for ; Wed, 4 May 2011 06:31:51 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B35EE0790 for ; Wed, 4 May 2011 06:31:51 -0700 (PDT) Received: by pvh1 with SMTP id 1so644142pvh.31 for ; Wed, 04 May 2011 06:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TFAPrzLnlEBoVFj2LBJmfSz4NX/pBlgCFiuGmghkMqg=; b=jhC3hk6QFFbFIyzG3VeAsxDkj1474uLzA3n0RcHZf08myQQp4cXKvG9Q5NpF+8ioYc y7oTPmkY53YP9nRbYtt9f0ITBHMFxM6LADSPSbds/jBN609MqkL2JB4Rg/9fY/4qk+a+ Y87JwlwpAjqVIM3/la59MmABCM2v/1yWkNEGg= 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=cLUV6I9L8mfU+C2CPuKyJJfRMOvtnMIFHEp95+JaY87R1oqLmRU5yb71b5zmiGKp7m Crvb7UdV+pxK4giioNxFSRdATUFAr0DSe30Vrfb60ZdWIjFXq4VH/E8kSRiiOllnQcKe fW3IGfXC2XS18QmUCXUyIKKIoPIAZL6fH1yTo= Received: by 10.68.39.102 with SMTP id o6mr1508950pbk.120.1304515910237; Wed, 04 May 2011 06:31:50 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id 8sm742486pbw.23.2011.05.04.06.31.48 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2011 06:31:49 -0700 (PDT) Message-ID: <4DC15504.3090503@gmail.com> Date: Wed, 04 May 2011 06:30:44 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [vwrap] is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Wed, 04 May 2011 13:31:52 -0000 I considered LLSD format not just for legacy reasons, yet LL obviously used it because it is easier to document. It can be improved, yes, so I don't see the argument about it's extensibility of any merit. If the data can be traslated to XML, then we know we can further translate into other types or formats that work better. Usually that 'better' is something considered 'obvious' with RFCs, and that's where we 'obviously' don't have to update the RFC. There is enough reason to update the RFC for combined queries (and further denote such in LLIDL for pivotal data), yet seems like people have gone other routes, like SPDY, to accomplish the same basis in connection pipelines. I think the IDL needs to be in as format that others WGs besides VWRAP can use, and to denote the pivotal data only focuses more on the region-agent transistions. Realize that we are not all on the same scale as we work this, which is normal. I don't see why to update the RFC if it doesn't at least address that. Otherwise, I'm not against either LLSD or DSD. I do prefer the symbolic assembly equivalent before the plain english equivalent The symbolic equivalent tends to avoid use of reserved words in LLIDL. I think the extensibility of LLSD is moot given the XML translation is given. Anybody can further extend the XML data. For example, here is JSONx: https://datatracker.ietf.org/doc/draft-rsalz-jsonx . So, from XML to XML of those documents two are now trivial WIP. On 05/04/2011 05:24 AM, Morgaine wrote: > You're mixing up two very different questions, Meadhbh:� the first is > whether anyone is going to use DSD for something personally (in the > way that they have already used LLSD in the past), and the second is > whether VWRAP might adopt DSD for its type system. > > The answer to the first is clearly "*Yes*" because it's already been > done with LLSD in an ad hoc fashion.� However, it would be excellent > if you were to publish a proper RFC on DSD, and even better if you > could provide an actual library and bindings/API for it.� None of the > current implementations of LLSD went as far as creating separate and > directly usable LLSD API projects maintained by their creators, as the > libomv and C++ implementations are entangled within the very large > codebases of their respective projects, and the other implementations > are poor quality and not maintained.� You could do much better than > they did, and keep a discrete DSD library afloat and up to date.� That > would ensure its survival. > > The answer to the second question is equally clearly "*No*", because > IETF working groups don't work through proposers' ultimatums.� A few > weeks ago there were significant questions raised here about whether > LLSD/DSD is adequate for a standard that is intended /for the future/ > of VWs rather than for implementing today's SL and Opensim-based > software, so it's clear that the issue hasn't been decided and > requires more examination. > > Carlo put it (rather bluntly) here --- > http://www.ietf.org/mail-archive/web/vwrap/current/msg00569.html .� > Without going into the politics of it, I want to see VWRAP have a > properly extensible type system, and the current LLSD does not meet > that requirement.� Indeed, in the early days of our IETF effort, we > spent months discussing the width of integers in LLSD because there > was only *one width* allowed and it was *hardwired* in the spec.� > That's not an extensible approach to data types at all. > > We need to do a lot better in this area if we really mean "extensible" > when we say "extensible".� At present that ADT proposal is not > extensible in any meaningful way. > > > Morgaine. > > > > ==================== > > On Tue, May 3, 2011 at 3:19 PM, Meadhbh Hamrick > wrote: > > is anyone in this group still interested in using LLSD (or it's > successor, DSD)? > > if so, i'm going to publish the DSD draft here. if not, i'm going to > wait for the group to say "we are in no way interested in LLSD or DSD" > and then submit it as an individual submission to the RFC editor. it's > been about three years, and i would really like to get an RFC > published so i can take the X- off all my application/llsd family of > mime types. > > so... may i see a show of hands... is anyone still planning on > implementing a system with LLSD in this group? > > please just respond yes or no in reply to this thread. i'll start > another thread for discussion. > > -cheers > -meadhbh > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Wed May 4 07:02:36 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2B7E0719 for ; Wed, 4 May 2011 07:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8obGQeAc8sw for ; Wed, 4 May 2011 07:02:35 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 18B21E06A4 for ; Wed, 4 May 2011 07:02:34 -0700 (PDT) Received: by qyk29 with SMTP id 29so2730495qyk.10 for ; Wed, 04 May 2011 07:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jZ3HBAUC8CtNa063eweKM/aClAofo2OBgIqRD/21U8Q=; b=LIr3CTq7IChdtamvSqx9EaCfg3nag3Z1HpAC9zLhxH0P8uoqIV4cSaDonToPNWOJ/Y 18UOAAr+9ETtnrPrEea+E0c9wYvYk8gQbbIlrezvbmE36ju/PRpkBbO54CzzSccl0Zq0 t9FZJNBmtl9+trQtoMouYNoj1vjYIlXSGQpjs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rQ4fQPzmuQjDbd0ooG8OoGJY6RwO6HuPI5qlZZR19OinbhMPXNb2GsC904pJZvbwei 2fwIKAonJRUWLyA8clHJREsQop+vwIfgTCgS1FYWJOfPNzsNX+mZag5OtWZCkcyCeg/Y B2ognY6ZpcKv7nok4QmnZgyiv5KgHu26XETHE= MIME-Version: 1.0 Received: by 10.229.119.134 with SMTP id z6mr829214qcq.63.1304517754352; Wed, 04 May 2011 07:02:34 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Wed, 4 May 2011 07:02:34 -0700 (PDT) In-Reply-To: <4DC15504.3090503@gmail.com> References: <4DC15504.3090503@gmail.com> Date: Wed, 4 May 2011 15:02:34 +0100 Message-ID: From: Morgaine To: Dzonatas Sol Content-Type: multipart/alternative; boundary=000e0cd5c94e59f36304a273b5e1 Cc: vwrap@ietf.org Subject: Re: [vwrap] is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Wed, 04 May 2011 14:02:36 -0000 --000e0cd5c94e59f36304a273b5e1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Extensibility through XML is not extensibility of the types of the underlying ADT. The types of the ADT are expressed through 3 canonical serializations. Those serializations merely reflect the types defined by the underlying ADT= , and the XML serialization alone cannot extend the underlying ADT without breaking the mapping of the ADT to the other serializations. It's the type system itself that has to be extensible before you can validl= y use extended types in one of its serializations. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Wed, May 4, 2011 at 2:30 PM, Dzonatas Sol wrote: > I considered LLSD format not just for legacy reasons, yet LL obviously us= ed > it because it is easier to document. It can be improved, yes, so I don't = see > the argument about it's extensibility of any merit. If the data can be > traslated to XML, then we know we can further translate into other types = or > formats that work better. Usually that 'better' is something considered > 'obvious' with RFCs, and that's where we 'obviously' don't have to update > the RFC. > > There is enough reason to update the RFC for combined queries (and furthe= r > denote such in LLIDL for pivotal data), yet seems like people have gone > other routes, like SPDY, to accomplish the same basis in connection > pipelines. I think the IDL needs to be in as format that others WGs besid= es > VWRAP can use, and to denote the pivotal data only focuses more on the > region-agent transistions. Realize that we are not all on the same scale = as > we work this, which is normal. > > I don't see why to update the RFC if it doesn't at least address that. > Otherwise, I'm not against either LLSD or DSD. I do prefer the symbolic > assembly equivalent before the plain english equivalent The symbolic > equivalent tends to avoid use of reserved words in LLIDL. > > I think the extensibility of LLSD is moot given the XML translation is > given. Anybody can further extend the XML data. For example, here is JSON= x: > https://datatracker.ietf.org/doc/draft-rsalz-jsonx . So, from XML to XML > of those documents two are now trivial WIP. > > > On 05/04/2011 05:24 AM, Morgaine wrote: > >> You're mixing up two very different questions, Meadhbh:=EF=BF=BD the fir= st is >> whether anyone is going to use DSD for something personally (in the way = that >> they have already used LLSD in the past), and the second is whether VWRA= P >> might adopt DSD for its type system. >> >> The answer to the first is clearly "*Yes*" because it's already been don= e >> with LLSD in an ad hoc fashion.=EF=BF=BD However, it would be excellent = if you were >> to publish a proper RFC on DSD, and even better if you could provide an >> actual library and bindings/API for it.=EF=BF=BD None of the current imp= lementations >> of LLSD went as far as creating separate and directly usable LLSD API >> projects maintained by their creators, as the libomv and C++ implementat= ions >> are entangled within the very large codebases of their respective projec= ts, >> and the other implementations are poor quality and not maintained.=EF=BF= =BD You >> could do much better than they did, and keep a discrete DSD library aflo= at >> and up to date.=EF=BF=BD That would ensure its survival. >> >> The answer to the second question is equally clearly "*No*", because IET= F >> working groups don't work through proposers' ultimatums.=EF=BF=BD A few = weeks ago >> there were significant questions raised here about whether LLSD/DSD is >> adequate for a standard that is intended /for the future/ of VWs rather = than >> for implementing today's SL and Opensim-based software, so it's clear th= at >> the issue hasn't been decided and requires more examination. >> >> Carlo put it (rather bluntly) here --- >> http://www.ietf.org/mail-archive/web/vwrap/current/msg00569.html .=EF=BF= =BD >> Without going into the politics of it, I want to see VWRAP have a proper= ly >> extensible type system, and the current LLSD does not meet that >> requirement.=EF=BF=BD Indeed, in the early days of our IETF effort, we s= pent months >> discussing the width of integers in LLSD because there was only *one wid= th* >> allowed and it was *hardwired* in the spec.=EF=BF=BD That's not an exten= sible >> approach to data types at all. >> >> We need to do a lot better in this area if we really mean "extensible" >> when we say "extensible".=EF=BF=BD At present that ADT proposal is not e= xtensible in >> any meaningful way. >> >> >> Morgaine. >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> On Tue, May 3, 2011 at 3:19 PM, Meadhbh Hamrick > ohmeadhbh@gmail.com>> wrote: >> >> is anyone in this group still interested in using LLSD (or it's >> successor, DSD)? >> >> if so, i'm going to publish the DSD draft here. if not, i'm going to >> wait for the group to say "we are in no way interested in LLSD or DSD= " >> and then submit it as an individual submission to the RFC editor. it'= s >> been about three years, and i would really like to get an RFC >> published so i can take the X- off all my application/llsd family of >> mime types. >> >> so... may i see a show of hands... is anyone still planning on >> implementing a system with LLSD in this group? >> >> please just respond yes or no in reply to this thread. i'll start >> another thread for discussion. >> >> -cheers >> -meadhbh >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --000e0cd5c94e59f36304a273b5e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Extensibility through XML is not extensibility of the types of the underlyi= ng ADT.

The types of the ADT are expressed through 3 canonical seria= lizations.=C2=A0 Those serializations merely reflect the types defined by t= he underlying ADT, and the XML serialization alone cannot extend the underl= ying ADT without breaking the mapping of the ADT to the other serialization= s.

It's the type system itself that has to be extensible before you ca= n validly use extended types in one of its serializations.


Morga= ine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

On Wed, May 4, 2011 at 2:30 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
=
I considered LLSD format not just for legacy reasons, yet LL obviously used= it because it is easier to document. It can be improved, yes, so I don'= ;t see the argument about it's extensibility of any merit. If the data = can be traslated to XML, then we know we can further translate into other t= ypes or formats that work better. Usually that 'better' is somethin= g considered 'obvious' with RFCs, and that's where we 'obvi= ously' don't have to update the RFC.

There is enough reason to update the RFC for combined queries (and further = denote such in LLIDL for pivotal data), yet seems like people have gone oth= er routes, like SPDY, to accomplish the same basis in connection pipelines.= I think the IDL needs to be in as format that others WGs besides VWRAP can= use, and to denote the pivotal data only focuses more on the region-agent = transistions. Realize that we are not all on the same scale as we work this= , which is normal.

I don't see why to update the RFC if it doesn't at least address th= at. Otherwise, I'm not against either LLSD or DSD. I do prefer the symb= olic assembly equivalent before the plain english equivalent The symbolic e= quivalent tends to avoid use of reserved words in LLIDL.

I think the extensibility of LLSD is moot given the XML translation is give= n. Anybody can further extend the XML data. For example, here is JSONx: https://datatracker.ietf.org/doc/draft-rsalz-jsonx . So, from XML to= XML of those documents two are now trivial WIP.


On 05/04/2011 05:24 AM, Morgaine wrote:
You're mixing up two very different questions, Meadhbh:=EF=BF=BD the fi= rst is whether anyone is going to use DSD for something personally (in the = way that they have already used LLSD in the past), and the second is whethe= r VWRAP might adopt DSD for its type system.

The answer to the first is clearly "*Yes*" because it's alrea= dy been done with LLSD in an ad hoc fashion.=EF=BF=BD However, it would be = excellent if you were to publish a proper RFC on DSD, and even better if yo= u could provide an actual library and bindings/API for it.=EF=BF=BD None of= the current implementations of LLSD went as far as creating separate and d= irectly usable LLSD API projects maintained by their creators, as the libom= v and C++ implementations are entangled within the very large codebases of = their respective projects, and the other implementations are poor quality a= nd not maintained.=EF=BF=BD You could do much better than they did, and kee= p a discrete DSD library afloat and up to date.=EF=BF=BD That would ensure = its survival.

The answer to the second question is equally clearly "*No*", beca= use IETF working groups don't work through proposers' ultimatums.= =EF=BF=BD A few weeks ago there were significant questions raised here abou= t whether LLSD/DSD is adequate for a standard that is intended /for the fut= ure/ of VWs rather than for implementing today's SL and Opensim-based s= oftware, so it's clear that the issue hasn't been decided and requi= res more examination.

Carlo put it (rather bluntly) here --- http://www.ietf.= org/mail-archive/web/vwrap/current/msg00569.html .=EF=BF=BD Without goi= ng into the politics of it, I want to see VWRAP have a properly extensible = type system, and the current LLSD does not meet that requirement.=EF=BF=BD = Indeed, in the early days of our IETF effort, we spent months discussing th= e width of integers in LLSD because there was only *one width* allowed and = it was *hardwired* in the spec.=EF=BF=BD That's not an extensible appro= ach to data types at all.

We need to do a lot better in this area if we really mean "extensible&= quot; when we say "extensible".=EF=BF=BD At present that ADT prop= osal is not extensible in any meaningful way.


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Tue, May 3, 2011 at 3:19 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com <mailto:ohmeadhbh@gmail.com&= gt;> wrote:

=C2=A0 =C2=A0is anyone in this group still interested in using LLSD (or it= 's
=C2=A0 =C2=A0successor, DSD)?

=C2=A0 =C2=A0if so, i'm going to publish the DSD draft here. if not, i= 'm going to
=C2=A0 =C2=A0wait for the group to say "we are in no way interested i= n LLSD or DSD"
=C2=A0 =C2=A0and then submit it as an individual submission to the RFC edi= tor. it's
=C2=A0 =C2=A0been about three years, and i would really like to get an RFC=
=C2=A0 =C2=A0published so i can take the X- off all my application/llsd fa= mily of
=C2=A0 =C2=A0mime types.

=C2=A0 =C2=A0so... may i see a show of hands... is anyone still planning o= n
=C2=A0 =C2=A0implementing a system with LLSD in this group?

=C2=A0 =C2=A0please just respond yes or no in reply to this thread. i'= ll start
=C2=A0 =C2=A0another thread for discussion.

=C2=A0 =C2=A0-cheers
=C2=A0 =C2=A0-meadhbh
=C2=A0 =C2=A0--
=C2=A0 =C2=A0meadhbh hamrick * it's pronounced "maeve"
=C2=A0 =C2=A0@OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com
=C2=A0 =C2=A0<mailto:OhMeadhbh@gmail.com>
=C2=A0 =C2=A0_______________________________________________
=C2=A0 =C2=A0vwrap mailing list
=C2=A0 =C2=A0vwrap@iet= f.org <mailto:vw= rap@ietf.org>

=C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/vwrap



_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap
=C2=A0


--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant


_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--000e0cd5c94e59f36304a273b5e1-- From dzonatas@gmail.com Wed May 4 07:22:43 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1646FE0719 for ; Wed, 4 May 2011 07:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhGL1g+RD4eG for ; Wed, 4 May 2011 07:22:42 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD10E06A4 for ; Wed, 4 May 2011 07:22:42 -0700 (PDT) Received: by pvh1 with SMTP id 1so670180pvh.31 for ; Wed, 04 May 2011 07:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Zzs+7JizwGPULlXzQ7UCCh+j0vyUel/d3xwPnxxenKs=; b=xC6LMtfi09dxmg1CRS5xYA+9eJRy0A1/mfF8GTMbYMe8xwl6KW/JaH+AE5QHNewauo +LtYsXfGM/FzSgoUVTSLaG832tKbyxSZ7lKA7HKA6NjyTtaf0w9vU9x0i8b/PfBnUKh1 i3O/m/0mGTzDiZgeIWNkGKWfbmyvwNAQvWz1g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=khv6m0Tlad4ydO2iC1bg98QbGUdQF3TmSa8lkNCkTel1CaVp0cbj8S+iL1ZivrxSrO bz4ehkEdFEGJ5h1YzBBD5vuLa2xKFqAPCkY5ZeKqs4WgNEokz2Mek3EwMbioyBFh0kcK Cc3bHDyJmcgzeQidMUfnmxGxv2o1rEr87BEIE= Received: by 10.68.16.100 with SMTP id f4mr1661224pbd.57.1304518961970; Wed, 04 May 2011 07:22:41 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id q10sm765907pbk.39.2011.05.04.07.22.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2011 07:22:40 -0700 (PDT) Message-ID: <4DC160F0.1030201@gmail.com> Date: Wed, 04 May 2011 07:21:36 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Morgaine References: <4DC15504.3090503@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Wed, 04 May 2011 14:22:43 -0000 We already know highly abstract data types that have all kinds of extensibility, so there is no need to reinvent that much. We just need "best fit" for the documentation and basic usage of resources as capabilities with LLIDL. Any further extensibility is specific to implementation, and that specific implementation should be expected (as common mode with RFCs). What matters is, can we use these data types to convey the concept? Yes, we have demonstrated we can. Again, I worry less about that and more about the combine queries, which would let you extend in many other ways besides mere serialization, especially when pivotal data is known. Your argument only justifies further reason for me to move and update SNOW-375 ( http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375 ) to the IETF wiki, especially if we expect STLP, which I rather forward-think about, instead of private unencrypted URIs. On 05/04/2011 07:02 AM, Morgaine wrote: > Extensibility through XML is not extensibility of the types of the > underlying ADT. > > The types of the ADT are expressed through 3 canonical > serializations. Those serializations merely reflect the types defined > by the underlying ADT, and the XML serialization alone cannot extend > the underlying ADT without breaking the mapping of the ADT to the > other serializations. > > It's the type system itself that has to be extensible before you can > validly use extended types in one of its serializations. > > > Morgaine. > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From ohmeadhbh@gmail.com Wed May 4 07:33:00 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17592E078A for ; Wed, 4 May 2011 07:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9wM6dKDU1VL for ; Wed, 4 May 2011 07:32:55 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 32A2CE0790 for ; Wed, 4 May 2011 07:32:53 -0700 (PDT) Received: by wwa36 with SMTP id 36so886210wwa.13 for ; Wed, 04 May 2011 07:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=ILHrcl0INajqBTS01ZU9zkpQ5vcqLVazb1ZZRXbZbSM=; b=B4RHu6anU46BqYFHzQ1JhlRZVgeo7QXdTJZ6zpmvkaXJ6dY8zJIkwWZXYiyuM5SCQt +omyOFf06cLUJWmfXciuC3hXa1ThB8HBylLvhP0A/x51BZW8T7C9lxuN70ncQSyWVbqe dJGeFM6LC0QtCtmATGTT3uDKDcjMjb/co7R+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=gRVOGI7+PubHgZrtUcmbFXgKXiRo/ENCOXG4maJDEfs96eXdxfJ3+vLalREzqFg42Y RRyY3QV94eRr1rxnRa8AsqV65Ze5uD5lOZPhYNhScniw2B1Hw1vAzsYKesiZx8D8/OC+ l7EN958GplXw51dDroiY0Ah8amJk9HNittw88= Received: by 10.216.82.142 with SMTP id o14mr1145498wee.114.1304519572116; Wed, 04 May 2011 07:32:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.157.75 with HTTP; Wed, 4 May 2011 07:32:32 -0700 (PDT) In-Reply-To: <4DC160F0.1030201@gmail.com> References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> From: Meadhbh Hamrick Date: Wed, 4 May 2011 07:32:32 -0700 Message-ID: To: Dzonatas Sol Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Wed, 04 May 2011 14:33:00 -0000 but the question was... yes or no... do we want LLSD or DSD (it's successor) to be part of VWRAP moving forward? -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Wed, May 4, 2011 at 7:21 AM, Dzonatas Sol wrote: > We already know highly abstract data types that have all kinds of > extensibility, so there is no need to reinvent that much. > > We just need "best fit" for the documentation and basic usage of resource= s > as capabilities with LLIDL. > > Any further extensibility is specific to implementation, and that specifi= c > implementation should be expected (as common mode with RFCs). What matter= s > is, can we use these data types to convey the concept? Yes, we have > demonstrated we can. > > Again, I worry less about that and more about the combine queries, which > would let you extend in many other ways besides mere serialization, > especially when pivotal data is known. > > Your argument only justifies further reason for me to move and update > SNOW-375 ( http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375 ) t= o > the IETF wiki, especially if we expect STLP, which I rather forward-think > about, instead of private unencrypted URIs. > > > On 05/04/2011 07:02 AM, Morgaine wrote: >> >> Extensibility through XML is not extensibility of the types of the >> underlying ADT. >> >> The types of the ADT are expressed through 3 canonical serializations. >> =A0Those serializations merely reflect the types defined by the underlyi= ng >> ADT, and the XML serialization alone cannot extend the underlying ADT >> without breaking the mapping of the ADT to the other serializations. >> >> It's the type system itself that has to be extensible before you can >> validly use extended types in one of its serializations. >> >> >> Morgaine. >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From dzonatas@gmail.com Wed May 4 08:10:03 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED546E0684 for ; Wed, 4 May 2011 08:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.037 X-Spam-Level: X-Spam-Status: No, score=-4.037 tagged_above=-999 required=5 tests=[AWL=-0.438, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EqneMe7AuII for ; Wed, 4 May 2011 08:10:01 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 26F18E0792 for ; Wed, 4 May 2011 08:10:01 -0700 (PDT) Received: by pzk5 with SMTP id 5so696708pzk.31 for ; Wed, 04 May 2011 08:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HW221hBL1+GtIGnTpJDoTNzJc4ZYhL9kIh6qDLXwMkU=; b=CBYBPr2oytGvRQj4KU0IeYSzY37S/1Mpaahn2N8bBcWdYOLBX+mwYzf5pm2UOjrf5P qV3ixCDbm6bNJuOQfefGwbqp00z979A57Iv5fMaIS9KZzHoC1PjGb0QCWaTV2vcHQ9CF JxQ2rHkA6EWUFdJmhlle1/DYoX5+z9aFAg6gU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Xwg2+g9cL0ULDAlUFBfkROOCjX4HgR13M0PkVvWMvj5CoF82GZLPHmqDoVHK8p9vrv PzN0RutAaaJbGho6o0dzkEkB3Gy/pVYGYD+OfUvf6synO0jUZEnLSwKDbc8IHrz9pWDv uPRXvczaNB7GzBS2d5eLKvAi168qyOGJnyEU8= Received: by 10.68.65.36 with SMTP id u4mr1736890pbs.156.1304521800642; Wed, 04 May 2011 08:10:00 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id i7sm790915pbs.19.2011.05.04.08.09.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2011 08:09:59 -0700 (PDT) Message-ID: <4DC16C07.8020502@gmail.com> Date: Wed, 04 May 2011 08:08:55 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Meadhbh Hamrick References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Wed, 04 May 2011 15:10:04 -0000 Don't worry, I (we) "get it". In attempts (to implement and) go forward with both LLSD and DSD, I already answered that question. I await your further effort to the effort I did to review your previous posts about DSD. http://www.ietf.org/mail-archive/web/vwrap/current/msg00833.html http://www.ietf.org/mail-archive/web/vwrap/current/msg00830.html If you expect yours to remain "out of scope" to this WG, then lets continue to go forward with LLSD as-is. Why use such straw-man to avoid the obvious concern of private unencrypted URIs, which breaks this WG if we continue to avoid this big elephant in the room. With the LLIDL additions I made for combined queries, this at least helps "secure" that insecurity with being able pipeline requests over pivotal data. Obviously, any demand to use only plain old HTTP leads right back to the elephant. RFCs shouldn't be used to make people look stupid by default expected implementation. I hope no one here is trying to do this, yet the avoidance of this issue make this much questionable. There is an obvious level of concern about privacy and copybots. This elephant is a show-stopper unless you got lawyers already to help protect "the game". http://en.wikipedia.org/wiki/The_Game_%28mind_game%29 We're being more serious about simulation and region-agent transistion then just games (and its loops) that has been repeated for the last few years. The game needs to stop we are trying to address the issue. Do recognize TLS/STLP as viable or do you continue to recommend to only send either LLSD or DSD over simple HTTP? On 05/04/2011 07:32 AM, Meadhbh Hamrick wrote: > but the question was... yes or no... do we want LLSD or DSD (it's > successor) to be part of VWRAP moving forward? > > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Wed, May 4, 2011 at 7:21 AM, Dzonatas Sol wrote: > >> We already know highly abstract data types that have all kinds of >> extensibility, so there is no need to reinvent that much. >> >> We just need "best fit" for the documentation and basic usage of resources >> as capabilities with LLIDL. >> >> Any further extensibility is specific to implementation, and that specific >> implementation should be expected (as common mode with RFCs). What matters >> is, can we use these data types to convey the concept? Yes, we have >> demonstrated we can. >> >> Again, I worry less about that and more about the combine queries, which >> would let you extend in many other ways besides mere serialization, >> especially when pivotal data is known. >> >> Your argument only justifies further reason for me to move and update >> SNOW-375 ( http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375 ) to >> the IETF wiki, especially if we expect STLP, which I rather forward-think >> about, instead of private unencrypted URIs. >> >> >> On 05/04/2011 07:02 AM, Morgaine wrote: >> >>> Extensibility through XML is not extensibility of the types of the >>> underlying ADT. >>> >>> The types of the ADT are expressed through 3 canonical serializations. >>> �Those serializations merely reflect the types defined by the underlying >>> ADT, and the XML serialization alone cannot extend the underlying ADT >>> without breaking the mapping of the ADT to the other serializations. >>> >>> It's the type system itself that has to be extensible before you can >>> validly use extended types in one of its serializations. >>> >>> >>> Morgaine. >>> >>> >> >> -- >> --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Wed May 4 08:49:44 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D01E0740 for ; Wed, 4 May 2011 08:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.876 X-Spam-Level: X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8hcX+7iRQu6 for ; Wed, 4 May 2011 08:49:43 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 609DBE078F for ; Wed, 4 May 2011 08:49:43 -0700 (PDT) Received: by qyk29 with SMTP id 29so2833756qyk.10 for ; Wed, 04 May 2011 08:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dgoGBtDMdinfKqR73i3ZLTbTc+EfiSQMG0DJYH9UJPg=; b=EfPU0vvLp7tz7Nig1ODsS8CgmhBqm29OVBo9XU6H8d3sVJVFUuaif64F6XCN4GwZSY PoMIGOrL18GSfeysw1gAbcFgzWERefP8KjEOf1pVBlKPhHqP91BRsZwtUYWKsDccwZx1 XTAtfz+qDkm9TpO1qqr+JgWxSHN2MVWN3YENk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vzErOHv8PkNx4CZcEtwppDbYC4/d/NUYgMRJZpU1qDrNcHeahikyQgO3xpTtulnidm Jl6LB13U8aV3TCBFQiFNG2Nc2wEOfuxn20oK7gCz+OWLIcF1EE/6XrtQWMQ096hrj0MA rmrXAyJcuT8JjE4RzQueLUrQCu6LccUgy8liE= MIME-Version: 1.0 Received: by 10.224.198.8 with SMTP id em8mr1200790qab.305.1304524182636; Wed, 04 May 2011 08:49:42 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Wed, 4 May 2011 08:49:42 -0700 (PDT) In-Reply-To: References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> Date: Wed, 4 May 2011 16:49:42 +0100 Message-ID: From: Morgaine To: Meadhbh Hamrick Content-Type: multipart/alternative; boundary=20cf300fb16d81c6e204a275344a Cc: vwrap@ietf.org Subject: Re: [vwrap] is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Wed, 04 May 2011 15:49:44 -0000 --20cf300fb16d81c6e204a275344a Content-Type: text/plain; charset=ISO-8859-1 That's a far clearer question than you asked initially, and so its easier to give a specific answer. (Indeed, I already did before, in the second part of my response.) While I don't know exactly what DSD is (an RFC would be excellent!), if it's just LLSD with another name then the type system of its underlying ADT is not extensible, and therefore it won't support new types going forward into the future. From my perspective, a non-extensible type system is *not sufficient* for VWRAP because it blocks the evolution of transported elementary types. And LLSD is actually worse than merely non-extensible, because it isn't flexible either, especially in providing just a single integer type. That's not enough. We need to design for tomorrow, not just for today. Morgaine. ================= On Wed, May 4, 2011 at 3:32 PM, Meadhbh Hamrick wrote: > but the question was... yes or no... do we want LLSD or DSD (it's > successor) to be part of VWRAP moving forward? > > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Wed, May 4, 2011 at 7:21 AM, Dzonatas Sol wrote: > > We already know highly abstract data types that have all kinds of > > extensibility, so there is no need to reinvent that much. > > > > We just need "best fit" for the documentation and basic usage of > resources > > as capabilities with LLIDL. > > > > Any further extensibility is specific to implementation, and that > specific > > implementation should be expected (as common mode with RFCs). What > matters > > is, can we use these data types to convey the concept? Yes, we have > > demonstrated we can. > > > > Again, I worry less about that and more about the combine queries, which > > would let you extend in many other ways besides mere serialization, > > especially when pivotal data is known. > > > > Your argument only justifies further reason for me to move and update > > SNOW-375 ( http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375 ) > to > > the IETF wiki, especially if we expect STLP, which I rather forward-think > > about, instead of private unencrypted URIs. > > > > > > On 05/04/2011 07:02 AM, Morgaine wrote: > >> > >> Extensibility through XML is not extensibility of the types of the > >> underlying ADT. > >> > >> The types of the ADT are expressed through 3 canonical serializations. > >> Those serializations merely reflect the types defined by the underlying > >> ADT, and the XML serialization alone cannot extend the underlying ADT > >> without breaking the mapping of the ADT to the other serializations. > >> > >> It's the type system itself that has to be extensible before you can > >> validly use extended types in one of its serializations. > >> > >> > >> Morgaine. > >> > > > > > > -- > > --- https://twitter.com/Dzonatas_Sol --- > > Web Development, Software Engineering, Virtual Reality, Consultant > > > > _______________________________________________ > > vwrap mailing list > > vwrap@ietf.org > > https://www.ietf.org/mailman/listinfo/vwrap > > > --20cf300fb16d81c6e204a275344a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's a far clearer question than you asked initially, and so its easi= er to give a specific answer.=A0 (Indeed, I already did before, in the seco= nd part of my response.)

While I don't know exactly what DSD is = (an RFC would be excellent!), if it's just LLSD with another name then = the type system of its underlying ADT is not extensible, and therefore it w= on't support new types going forward into the future.=A0 From my perspe= ctive, a non-extensible type system is not sufficient for VWRAP beca= use it blocks the evolution of transported elementary types.

And LLSD is actually worse than merely non-extensible, because it isn&#= 39;t flexible either, especially in providing just a single integer type.= =A0 That's not enough.

We need to design for tomorrow, not just = for today.


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

On Wed, May 4, 2011 at 3:32 PM,= Meadhbh Hamrick <ohmeadhbh@gmail.com> wrote:
but the question = was... yes or no... do we want LLSD or DSD (it's
successor) to be part of VWRAP moving forward?

--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadh= bh.org/ * OhMeadhbh@gmail.com



On Wed, May 4, 2011 at 7:21 AM, Dzo= natas Sol <dzonatas@gmail.com&= gt; wrote:
> We already know highly abstract data types that have all kinds of
> extensibility, so there is no need to reinvent that much.
>
> We just need "best fit" for the documentation and basic usag= e of resources
> as capabilities with LLIDL.
>
> Any further extensibility is specific to implementation, and that spec= ific
> implementation should be expected (as common mode with RFCs). What mat= ters
> is, can we use these data types to convey the concept? Yes, we have > demonstrated we can.
>
> Again, I worry less about that and more about the combine queries, whi= ch
> would let you extend in many other ways besides mere serialization, > especially when pivotal data is known.
>
> Your argument only justifies further reason for me to move and update<= br> > SNOW-375 ( http://wiki.secondlife.com/wiki/User:Dzonatas= _Sol/SNOW-375 ) to
> the IETF wiki, especially if we expect STLP, which I rather forward-th= ink
> about, instead of private unencrypted URIs.
>
>
> On 05/04/2011 07:02 AM, Morgaine wrote:
>>
>> Extensibility through XML is not extensibility of the types of the=
>> underlying ADT.
>>
>> The types of the ADT are expressed through 3 canonical serializati= ons.
>> =A0Those serializations merely reflect the types defined by the un= derlying
>> ADT, and the XML serialization alone cannot extend the underlying = ADT
>> without breaking the mapping of the ADT to the other serialization= s.
>>
>> It's the type system itself that has to be extensible before y= ou can
>> validly use extended types in one of its serializations.
>>
>>
>> Morgaine.
>>
>
>
> --
> --- htt= ps://twitter.com/Dzonatas_Sol ---
> Web Development, Software Engineering, Virtual Reality, Consultant
>
> ________________________= _______________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>

--20cf300fb16d81c6e204a275344a-- From dzonatas@gmail.com Wed May 4 08:56:55 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAB4E0750 for ; Wed, 4 May 2011 08:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXCHVtx-qp-b for ; Wed, 4 May 2011 08:56:54 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA62BE0786 for ; Wed, 4 May 2011 08:56:54 -0700 (PDT) Received: by pvh1 with SMTP id 1so720697pvh.31 for ; Wed, 04 May 2011 08:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EHMJrSprbbHb3WYu9RA598PSMFOdmSf6IMKG3fyKqDA=; b=KbVUkuWLjUiq/f3RoDUSWY4gPWnbBx2QF8U+VfZ1N8enSZnggmaz+eme+hZErOviuG tCBmldt03kanXfhcdC+5+du8KPb6tSqGYlMaHYLqV6+5phvLEeH1TsX4iWztSdRb+/su iJA/4bChl8TVs2iLjvHRerpoiKFX98XO86/8o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=w2VW+WRb8E+0fB2ZLK5ewUZI1Ah90J8YgGF/TlWKsmcr+wdjrlJQAQ5He913e+nX+Q rR4APigmzspt/avrBADuxL2LQNQhaUnwaPYxKNmnSI+ICDXShsbEJ6ZvxpC6ut1p6BuJ rxFZ7MFijWUaRIpvYtUhoglpCLC8mPqJns77A= Received: by 10.68.49.136 with SMTP id u8mr1671047pbn.170.1304524614363; Wed, 04 May 2011 08:56:54 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id l3sm808732pbq.75.2011.05.04.08.56.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2011 08:56:53 -0700 (PDT) Message-ID: <4DC17704.3020201@gmail.com> Date: Wed, 04 May 2011 08:55:48 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Morgaine References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org, Meadhbh Hamrick Subject: Re: [vwrap] is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Wed, 04 May 2011 15:56:55 -0000 It doesn't block "evolution of transported elementary types", as the transport layer is underneath the application layer. As demonstrated (and proven) with flow in XML, we can easily keep the high-level types in the higher layer. LLSD is merely the high-level types, not overall primitives. On 05/04/2011 08:49 AM, Morgaine wrote: > That's a far clearer question than you asked initially, and so its > easier to give a specific answer.� (Indeed, I already did before, in > the second part of my response.) > > While I don't know exactly what DSD is (an RFC would be excellent!), > if it's just LLSD with another name then the type system of its > underlying ADT is not extensible, and therefore it won't support new > types going forward into the future.� From my perspective, a > non-extensible type system is *not sufficient* for VWRAP because it > blocks the evolution of transported elementary types. > > And LLSD is actually worse than merely non-extensible, because it > isn't flexible either, especially in providing just a single integer > type.� That's not enough. > > We need to design for tomorrow, not just for today. > > > Morgaine. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Wed May 4 09:06:38 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4359E0686 for ; Wed, 4 May 2011 09:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RO8rZA+sZom3 for ; Wed, 4 May 2011 09:06:38 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id BAF41E0684 for ; Wed, 4 May 2011 09:06:37 -0700 (PDT) Received: by qwc23 with SMTP id 23so1007749qwc.31 for ; Wed, 04 May 2011 09:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zZCi//pH0utsdHbsU5qqjzeTWZh56UiNPZh9A4Fv8Qs=; b=awoc0JNAp2sVgaFsQqbJcTNs9RntcCQ5josZKu5KLXZNq1/3fCuRc2ovSBS97uDyga lYZiwhrotZccyDRJ3zJ8vQmEns6mQQePjwKxvQk/kYCB15mQJLNaP/dk+2xQyJPYIpO3 h5oRSIbE44akwjhrCNtRiHOGMUppTs1VVvOfU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DhRZCZH30rB46aa3eEsxuQFTrw9FQO5mWSFWZNsNo545JKwASkDrAiZmnnhBUz7yOo KE1zXDZWY6uvIwyDVqblT6QsfaenwoKOQW/gh9OmCqMk3qMBMitLrvpm9YpI4VJUEWzo aRJYcUcFMBri3FX2PkK++Nq7KkjOJpml6Y+cY= MIME-Version: 1.0 Received: by 10.229.44.141 with SMTP id a13mr928883qcf.101.1304525196666; Wed, 04 May 2011 09:06:36 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Wed, 4 May 2011 09:06:36 -0700 (PDT) In-Reply-To: <4DC17704.3020201@gmail.com> References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> Date: Wed, 4 May 2011 17:06:36 +0100 Message-ID: From: Morgaine To: Dzonatas Sol Content-Type: multipart/alternative; boundary=001636831fa0f2b0f104a27570f7 Cc: vwrap@ietf.org, Meadhbh Hamrick Subject: Re: [vwrap] is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Wed, 04 May 2011 16:06:38 -0000 --001636831fa0f2b0f104a27570f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I gather that you don't understand the type model of LLSD + serializations then. The ADT defines the elementary data types and composite resource types. Th= e serializations then implement both of these for transport on-the-wire. There is nothing that one specific serialization like XML can do to to extend the elementary data types provided by the ADT. Your answers simply don't address the non-extensibility and non-flexibility of elementary types. The XML tail cannot wag the ADT dog. The relationshi= p is the other way around, it's the ADT that defines the elementary types, which are transported in all serializations. You keep referring to the flexibility of XML, but that is irrelevant to the ADT. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Wed, May 4, 2011 at 4:55 PM, Dzonatas Sol wrote: > It doesn't block "evolution of transported elementary types", as the > transport layer is underneath the application layer. As demonstrated (and > proven) with flow in XML, we can easily keep the high-level types in the > higher layer. LLSD is merely the high-level types, not overall primitives= . > > > On 05/04/2011 08:49 AM, Morgaine wrote: > >> That's a far clearer question than you asked initially, and so its easie= r >> to give a specific answer.=EF=BF=BD (Indeed, I already did before, in th= e second >> part of my response.) >> >> While I don't know exactly what DSD is (an RFC would be excellent!), if >> it's just LLSD with another name then the type system of its underlying = ADT >> is not extensible, and therefore it won't support new types going forwar= d >> into the future.=EF=BF=BD From my perspective, a non-extensible type sys= tem is *not >> sufficient* for VWRAP because it blocks the evolution of transported >> elementary types. >> >> And LLSD is actually worse than merely non-extensible, because it isn't >> flexible either, especially in providing just a single integer type.=EF= =BF=BD That's >> not enough. >> >> We need to design for tomorrow, not just for today. >> >> >> Morgaine. >> > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > --001636831fa0f2b0f104a27570f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I gather that you don't understand the type model of LLSD + serializati= ons then.

The ADT defines the elementary data types and composite re= source types.=C2=A0 The serializations then implement both of these for tra= nsport on-the-wire.=C2=A0 There is nothing that one specific serialization = like XML can do to to extend the elementary data types provided by the ADT.=

Your answers simply don't address the non-extensibility and non-fle= xibility of elementary types.=C2=A0 The XML tail cannot wag the ADT dog.=C2= =A0 The relationship is the other way around, it's the ADT that defines= the elementary types, which are transported in all serializations.

You keep referring to the flexibility of XML, but that is irrelevant to= the ADT.


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Wed, Ma= y 4, 2011 at 4:55 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
It doesn't bl= ock "evolution of transported elementary types", as the transport= layer is underneath the application layer. As demonstrated (and proven) wi= th flow in XML, we can easily keep the high-level types in the higher layer= . LLSD is merely the high-level types, not overall primitives.


On 05/04/2011 08:49 AM, Morgaine wrote:
That's a far clearer question than you asked initially, and so its easi= er to give a specific answer.=EF=BF=BD (Indeed, I already did before, in th= e second part of my response.)

While I don't know exactly what DSD is (an RFC would be excellent!), if= it's just LLSD with another name then the type system of its underlyin= g ADT is not extensible, and therefore it won't support new types going= forward into the future.=EF=BF=BD From my perspective, a non-extensible ty= pe system is *not sufficient* for VWRAP because it blocks the evolution of = transported elementary types.

And LLSD is actually worse than merely non-extensible, because it isn't= flexible either, especially in providing just a single integer type.=EF=BF= =BD That's not enough.

We need to design for tomorrow, not just for today.


Morgaine.

--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant


--001636831fa0f2b0f104a27570f7-- From dzonatas@gmail.com Wed May 4 09:45:02 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5169DE0684 for ; Wed, 4 May 2011 09:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZyC9ycqjpMk for ; Wed, 4 May 2011 09:45:01 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6542AE0794 for ; Wed, 4 May 2011 09:45:01 -0700 (PDT) Received: by pvh1 with SMTP id 1so745931pvh.31 for ; Wed, 04 May 2011 09:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uoDVbTAJsSR3PLhTFpWTjwEzoYu8CO0G4jl9W8uzIpM=; b=E/dyEOyKRr5PwmEI20dPdQB2igXKwdNcVD3ccBc2F7cTC2/x6cPc6DR5mSeGKS6XK7 rVVLWTZ/xrzdJo5vk2Gk5xXDY8aT8JfKCDhRcXr5s9hp88sKLXvl/g/ygiiB6ANuAkaA oq3LKpTG/7jO38Hhd9cIbWKRPHMkBRNVxh4vc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=DG710N8iwMQMqbQwB4dS/nKAEWd0AVWobdGnZuIHVR/MZkMibYsiWQq+w8x/vMwUbe d9bV3fHR27xmke052Rv4Uzjl9i84HPJwmwdmx1LxH40XmZV2NMcFHImW/u5GbGp9DWS4 HIw6d71GfXd1pRssuTIqiH6dFh1lSOzzvRN0I= Received: by 10.68.50.138 with SMTP id c10mr1694655pbo.448.1304527501139; Wed, 04 May 2011 09:45:01 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id 5sm835288pbn.25.2011.05.04.09.44.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2011 09:45:00 -0700 (PDT) Message-ID: <4DC1824B.6040609@gmail.com> Date: Wed, 04 May 2011 09:43:55 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Morgaine References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org, Meadhbh Hamrick Subject: Re: [vwrap] is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Wed, 04 May 2011 16:45:02 -0000 On 05/04/2011 09:06 AM, Morgaine wrote: > I gather that you don't understand the type model of LLSD + > serializations then. That is rude for you to assume that, and also consider that I have an active implementation. Please, be more serious. I know you have realized this much as you tried to promote Icesphere in the past, yet your political stance changes too often. Such talk doesn't belong on this list, you could have simply e-mail off list and asked what you don't understand about what I know. (was that you that sent me private email? nope, doesn't have "Morgaine" on the sender) On that note: I don't appreciate how you and others have treated me as the escapegoat! What do you expect? To send the inventor of XYZ language to school to certify that he knows XYZ language? > > The ADT defines the elementary data types and composite resource > types. The serializations then implement both of these for transport > on-the-wire. There is nothing that one specific serialization like > XML can do to to extend the elementary data types provided by the ADT. LLSD was specifically stated in source as the high-level like data types useful at low-level languages: low-level scalar data. Go ahead and assume LLSD means... you know... what the "reverse engineers" called it. Now that Mono has LLVM, and Attachment laid of Mono-employees, we can only assume they didn't want to look at the source of the LL version. Maybe its better hands now, and less need to re-standardize and re-implement the CIL libraries that Microsoft already distributes. It's helpful to read the source, yet due to much anxiety-induced fears of that alone your argument is endless and redundant to reinvent generics when that is already done. > > Your answers simply don't address the non-extensibility and > non-flexibility of elementary types. The XML tail cannot wag the ADT > dog. The relationship is the other way around, it's the ADT that > defines the elementary types, which are transported in all serializations. I have, you just avoid the demonstrated flow and source for some reason. ADTs still have to stream in ordinary ways to flow. > > You keep referring to the flexibility of XML, but that is irrelevant > to the ADT. You obviously want to avoid XML, despite the very implementation is based on plain text headers and XML data. I'm not even gonna ask why you avoid this over and over. Can you answer the question about region-agent transistion and if SLTP is viable, or do you want to continue to send any abstract data over clear text? -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Wed May 4 10:22:55 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAFBE07D3 for ; Wed, 4 May 2011 10:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTlKwIB01XaJ for ; Wed, 4 May 2011 10:22:54 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B12BE07D9 for ; Wed, 4 May 2011 10:22:51 -0700 (PDT) Received: by qwc23 with SMTP id 23so1081025qwc.31 for ; Wed, 04 May 2011 10:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=J1X2EOJ3hQoVeaUq2F0Pv004HwKjsdbvoUZ5PdBqkMU=; b=TOqKeZyz+kRg4TB2kyA7WOjrZYU1QQ0051B/IWEl7GaWmD7C6inhwzUSSAMuAw9+Lr Rl9nEmGCWiW3sQN6vLbauQh5kVmUmHF/siwtt34m/G4OgIEz1M9WSyxpvi2/JniTQ1cR NtnMu9egWA630wa1gRO1TxX3cE3LtqfXYFgZ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=aIdHskWSPw0yI+swyLrGbYW0CygJ6K5ONL2zSr4LU3Dvo5jdR7mtbe41pM+1KOvzKS 4GkHS6yJs2gn5UbqZ7KqP8q+g3P04pJdMnO3se6f+bmgCWUIYea+9e40L1lSmgcscYDB 0ds5Qrd3O3jYTKqbYPaxh0cxcpxr5tfapV3GQ= MIME-Version: 1.0 Received: by 10.229.127.96 with SMTP id f32mr1030215qcs.139.1304529770395; Wed, 04 May 2011 10:22:50 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Wed, 4 May 2011 10:22:50 -0700 (PDT) In-Reply-To: <4DC1824B.6040609@gmail.com> References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> Date: Wed, 4 May 2011 18:22:50 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cdf65f29036c004a2768115 Subject: Re: [vwrap] is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Wed, 04 May 2011 17:22:55 -0000 --000e0cdf65f29036c004a2768115 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 4, 2011 at 5:43 PM, Dzonatas Sol wrote: > On 05/04/2011 09:06 AM, Morgaine wrote: > >> I gather that you don't understand the type model of LLSD + serializations >> then. >> > > That is rude for you to assume that, and also consider that I have an > active implementation. Please, be more serious. > I apologize, I should not have implied that you lack understanding, my bad! Let me rephrase it more precisely. Your responses do not *demonstrate*understanding of the type model of LLSD + serializations. You persist in suggesting that the extensibility of XML can extend the elementary types of LLSD, when it absolutely cannot do that. I am confident that you do understand this, but it hasn't come across yet. I recommend leaving XML out of the discussion, because it's just one out of 3 primary serializations. Leaving it out (for now) will help highlight the non-extensibility of the LLSD elementary data types. > > I know you have realized this much as you tried to promote Icesphere in the > past, yet your political stance changes too often. Such talk doesn't belong > on this list, you could have simply e-mail off list and asked what you don't > understand about what I know. (was that you that sent me private email? > nope, doesn't have "Morgaine" on the sender) On that note: I don't > appreciate how you and others have treated me as the escapegoat! What do you > expect? To send the inventor of XYZ language to school to certify that he > knows XYZ language? > > > I supported Icesphere and SNOW-375 because XML-based REST was useful in LL-derived viewers, today. VWRAP is a very different use case. We need to design VWRAP for the future, not merely to work with the current-day SL and current-day Opensim. > LLSD was specifically stated in source as the high-level like data types > useful at low-level languages: low-level scalar data. Go ahead and assume > LLSD means... you know... what the "reverse engineers" called it. Now that > Mono has LLVM, and Attachment laid of Mono-employees, we can only assume > they didn't want to look at the source of the LL version. Maybe its better > hands now, and less need to re-standardize and re-implement the CIL > libraries that Microsoft already distributes. > > It's helpful to read the source, yet due to much anxiety-induced fears of > that alone your argument is endless and redundant to reinvent generics when > that is already done. > > > I have no idea what any of that means. > > >> Your answers simply don't address the non-extensibility and >> non-flexibility of elementary types. The XML tail cannot wag the ADT dog. >> The relationship is the other way around, it's the ADT that defines the >> elementary types, which are transported in all serializations. >> > > I have, you just avoid the demonstrated flow and source for some reason. > ADTs still have to stream in ordinary ways to flow. > > > I don't know what you mean here. It doesn't seem related to ADT types. > >> You keep referring to the flexibility of XML, but that is irrelevant to >> the ADT. >> > > > You obviously want to avoid XML, despite the very implementation is based > on plain text headers and XML data. I'm not even gonna ask why you avoid > this over and over. Can you answer the question about region-agent > transistion and if SLTP is viable, or do you want to continue to send any > abstract data over clear text? > > > No I do not want to avoid XML, quite the opposite. XML is one of the 3 initial serializations of LLSD and it's perfectly fine for that, and I expect XML to be used a lot over HTTP transport. But you cannot extend the elementary types of the ADT by extending your XML. That's the "XML tail wagging the ADT dog" to which I referred --- it doesn't work that way. If you want extensible and/or flexible elementary types, the ADT has to be defined to allow them, because those get serialized in all 3 (or more) serializations, not just in XML. It's a really fundamental aspect of the ADT that it defines our types independent of its serializations. It's a useful concept, but the problem with this particular one -- LLSD (DSD?) -- is that the elementary types are neither flexible nor extensible. Morgaine. --000e0cdf65f29036c004a2768115 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, May 4, 2011 at 5:43 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
=
On 05/04/2011 09:06 AM, Morgaine wrote:
I gather that you don't understand the type model of LLSD + serializati= ons then.

That is rude for you to assume that, and also consider that I have an activ= e implementation. Please, be more serious.


I a= pologize, I should not have implied that you lack understanding, my bad!
Let me rephrase it more precisely.=A0 Your responses do not demonstr= ate understanding of the type model of LLSD + serializations.=A0 You pe= rsist in suggesting that the extensibility of XML can extend the elementary= types of LLSD, when it absolutely cannot do that.=A0 I am confident that y= ou do understand this, but it hasn't come across yet.

I recommend leaving XML out of the discussion, because it's just on= e out of 3 primary serializations.=A0 Leaving it out (for now) will help hi= ghlight the non-extensibility of the LLSD elementary data types.

=A0=

I know you have realized this much as you tried to promote Icesphere in the= past, yet your political stance changes too often. Such talk doesn't b= elong on this list, you could have simply e-mail off list and asked what yo= u don't understand about what I know. (was that you that sent me privat= e email? nope, doesn't have "Morgaine" on the sender) On that= note: I don't appreciate how you and others have treated me as the esc= apegoat! What do you expect? To send the inventor of XYZ language to school= to certify that he knows XYZ language?


I supported Icesphere and SNOW-375 because XML-= based REST was useful in LL-derived viewers, today.=A0 VWRAP is a very diff= erent use case.=A0 We need to design VWRAP for the future, not merely to wo= rk with the current-day SL and current-day Opensim.


=A0
LLSD was specifically stated in source as the high-level like data types us= eful at low-level languages: low-level scalar data. Go ahead and assume LLS= D means... you know... what the "reverse engineers" called it. No= w that Mono has LLVM, and Attachment laid of Mono-employees, we can only as= sume they didn't want to look at the source of the LL version. Maybe it= s better hands now, and less need to re-standardize and re-implement the CI= L libraries that Microsoft already distributes.

It's helpful to read the source, yet due to much anxiety-induced fears = of that alone your argument is endless and redundant to reinvent generics w= hen that is already done.


=A0
I have no idea what any of that m= eans.
<= div class=3D"im">

Your answers simply don't address the non-extensibility and non-flexibi= lity of elementary types. =A0The XML tail cannot wag the ADT dog. =A0The re= lationship is the other way around, it's the ADT that defines the eleme= ntary types, which are transported in all serializations.

I have, you just avoid the demonstrated flow and source for some reason. AD= Ts still have to stream in ordinary ways to flow.


=A0
I don't know what you mean here. =A0It doesn't seem related to ADT = types.
=A0

You keep referring to the flexibility of XML, but that is irrelevant to the= ADT.


You obviously want to avoid XML, despite the very implementation is based o= n plain text headers and XML data. I'm not even gonna ask why you avoid= this over and over. Can you answer the question about region-agent transis= tion and if SLTP is viable, or do you want to continue to send any abstract= data over clear text?


No I do not want to avoid XML, quite the = opposite.

XML is one of the 3 initial serializations of LLSD and it&= #39;s perfectly fine for that, and I expect XML to be used a lot over HTTP = transport. =A0But you cannot extend the elementary types of the ADT by exte= nding your XML. =A0That's the "XML tail wagging the ADT dog" = to which I referred --- it doesn't work that way. =A0If you want extens= ible and/or flexible elementary types, the ADT has to be defined to allow t= hem, because those get serialized in all 3 (or more) serializations, not ju= st in XML.

It's a really fundamental aspect of the ADT that it defines our typ= es independent of its serializations. =A0It's a useful concept, but the= problem with this particular one -- LLSD (DSD?) -- is that the elementary = types are neither flexible nor extensible.


Morgaine.



--000e0cdf65f29036c004a2768115-- From dzonatas@gmail.com Wed May 4 11:06:37 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBF4E07C5 for ; Wed, 4 May 2011 11:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.917 X-Spam-Level: X-Spam-Status: No, score=-3.917 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyvTZ9TG6cxP for ; Wed, 4 May 2011 11:06:36 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 30C75E07C9 for ; Wed, 4 May 2011 11:06:36 -0700 (PDT) Received: by pvh1 with SMTP id 1so785871pvh.31 for ; Wed, 04 May 2011 11:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UwJbekgTuxEusl2/9rs3Ucb5M8NzYhr3mOFMM1dpum4=; b=RiWTkPyDHw++B/VQaF0jJIZta+giPaW6LoHXn3Oecr2ACSoTPmDMSOjvzjqWUGBc3g UODx+YHQGEZR+OYvxUBvvPEb/GFoTuAgSJ5vbZp1cb7ipiRqbPFOXbKXe0RvzVUJBfyX aLGXVZStmgxApbKESrlOkQx1O7YwLe9Rynxnw= 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=CdamkHYC9FqSjKdvjjgD0BLXl3Qr9Be3zflafZP/CB23jW1IDwJIwUWk8PMDGA/rnX 2cxEw3EjOi+F3WR8SSc2u19XV5sdc+iklFqM9ZBxAVqmX0ikZAXqrxEfEoStv+66XwUT IMZ+G8dXSxBquvjA8Frhh4ktY3pj8FrX3tz1c= Received: by 10.68.36.232 with SMTP id t8mr1922254pbj.82.1304532395936; Wed, 04 May 2011 11:06:35 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id e4sm875571pbj.4.2011.05.04.11.06.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2011 11:06:35 -0700 (PDT) Message-ID: <4DC1956A.5020204@gmail.com> Date: Wed, 04 May 2011 11:05:30 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [vwrap] is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Wed, 04 May 2011 18:06:37 -0000 On 05/04/2011 10:22 AM, Morgaine wrote: > Let me rephrase it more precisely.� Your responses do not > *demonstrate* understanding of the type model of LLSD + > serializations.� You persist in suggesting that the extensibility of > XML can extend the elementary types of LLSD, when it absolutely cannot > do that.� I am confident that you do understand this, but it hasn't > come across yet. > > I recommend leaving XML out of the discussion, because it's just one > out of 3 primary serializations.� Leaving it out (for now) will help > highlight the non-extensibility of the LLSD elementary data types. XML is only a more graphic form than ASCII and extended with common multi-byte format useful to detect network order. Because it is human-readable, many miss *that* obvious critical fact. If you send XML data, we don't have to worry about the network order for whatever abstract data types you make up. XML is more than just serialization and mark-up language, yet this how people *start* with such concepts. It remains very useful for more advanced flows with absolute simplicity to the core to parse, and continues to be ridiculously easy to optimize, tokenize, and compress (with static dictionaries). Note that with static dictionaries, concerns like power consumption are already thought about because to even get that analytic computation done for each and every message only consumes more power. You're telling us you want to leave that already well-thought-critical details out of the discussion when it is already standardized and already just easily said as "XML"? We realize that some implementers made LLSD mean "Linden Lab Serialized Data", and they wanted JSON instead because it *was* easily to eval() to parse. (Except now JSON has to avoid injections just like SQL & perl/php, etc, ...). I'm pretty sure the real problem has been DEMONSTRATED with the implementation(s), especially where you further demonstrated that you want to leave out any mention of the extensibility features in order to show the problem with non-extensibility. That sounds familiar. > It's a really fundamental aspect of the ADT that it defines our types > independent of its serializations. �It's a useful concept, but the > problem with this particular one -- LLSD (DSD?) -- is that the > elementary types are neither flexible nor extensible. > Let the VMs define further ADTs. We only need a few standard data types. This WG should only be concerned with being able to document (and clarify) the flow, especially the region-agent transistions. If the flow uses standard LLSD data types to define some complex abstract data type, perfect enough. I wouldn't be surprised if we add one more LLSD data type for DAEs, as that may be the perfect place for it. Then you can go and add any relevant extension you want to the DAE, even more abstract data types within the DAE, and further you don't even have to worry about it all being in RFC format. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Wed May 4 11:26:32 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA6EE07CD for ; Wed, 4 May 2011 11:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xs8TFO3XLDZ7 for ; Wed, 4 May 2011 11:26:31 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 93FBAE0700 for ; Wed, 4 May 2011 11:26:31 -0700 (PDT) Received: by qwc23 with SMTP id 23so1135915qwc.31 for ; Wed, 04 May 2011 11:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=rkMV4GI6MtpIbBBdL+cNk4hU2OS/9lz3TN85zGyWHfs=; b=xc+eGJzUjemQ5yMJ2qm/EVsC1DMkhR7I2jZN4mJBkqIHRcl4W6uFE9/DuWgxX6N/QY igjZV+lpgicZC2jdyeDDk9f251mHPGAxukcc/j0q3L667g2S3uH7Gy8EIxRmJ54I/foW FuijwO2tVuQgTolshoOy2gW8lVVMCwXaWF/zo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=uvgXauIceCeJNYePB2pWhu71KsAaYCBGPz4LRrLqYlCUF+slmsvvwJF9FDKt4UPFtJ wgjL/VHd3LJbnJFHEGNWWpfBV6BhO5cDnL9vMTlpo1dBEq54OonJJ1pCAx9CRS6DSAnE mIdScijvwUJjaEmP+DvRK3hrcM/o6KmR1RZWY= MIME-Version: 1.0 Received: by 10.229.119.134 with SMTP id z6mr1113876qcq.63.1304533590962; Wed, 04 May 2011 11:26:30 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Wed, 4 May 2011 11:26:30 -0700 (PDT) In-Reply-To: <4DC1956A.5020204@gmail.com> References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> Date: Wed, 4 May 2011 19:26:30 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd5c94e49766904a27765c2 Subject: Re: [vwrap] is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Wed, 04 May 2011 18:26:33 -0000 --000e0cd5c94e49766904a27765c2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 4, 2011 at 7:05 PM, Dzonatas Sol wrote: > > XML is more than just serialization and mark-up language, yet this how > people *start* with such concepts. It remains very useful for more advanc= ed > flows with absolute simplicity to the core to parse, and continues to be > ridiculously easy to optimize, tokenize, and compress (with static > dictionaries). Note that with static dictionaries, concerns like power > consumption are already thought about because to even get that analytic > computation done for each and every message only consumes more power. > > This is what I can't seem to get across to you. All those wonderful features of XML are *IRRELEVANT* to the extensibility of the ADT's primitiv= e types, because the ADT defines its very limited set of abstract types itself, directly. The only thing that the ADT's serializations can do is express those predefined ADT types on the wire. You can't extend the primitive types in a serialization of the ADT. If you were arguing that our ADT's primary type definitions should be in XM= L then you would have quite a good point, because then the types would be bot= h flexible and extensible. But that's not what we're discussing here. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D On Wed, May 4, 2011 at 7:05 PM, Dzonatas Sol wrote: > On 05/04/2011 10:22 AM, Morgaine wrote: > >> Let me rephrase it more precisely.=EF=BF=BD Your responses do not *demon= strate* >> understanding of the type model of LLSD + serializations.=EF=BF=BD You p= ersist in >> suggesting that the extensibility of XML can extend the elementary types= of >> LLSD, when it absolutely cannot do that.=EF=BF=BD I am confident that yo= u do >> understand this, but it hasn't come across yet. >> >> I recommend leaving XML out of the discussion, because it's just one out >> of 3 primary serializations.=EF=BF=BD Leaving it out (for now) will help= highlight >> the non-extensibility of the LLSD elementary data types. >> > > XML is only a more graphic form than ASCII and extended with common > multi-byte format useful to detect network order. Because it is > human-readable, many miss *that* obvious critical fact. If you send XML > data, we don't have to worry about the network order for whatever abstrac= t > data types you make up. > > XML is more than just serialization and mark-up language, yet this how > people *start* with such concepts. It remains very useful for more advanc= ed > flows with absolute simplicity to the core to parse, and continues to be > ridiculously easy to optimize, tokenize, and compress (with static > dictionaries). Note that with static dictionaries, concerns like power > consumption are already thought about because to even get that analytic > computation done for each and every message only consumes more power. > > You're telling us you want to leave that already well-thought-critical > details out of the discussion when it is already standardized and already > just easily said as "XML"? > > We realize that some implementers made LLSD mean "Linden Lab Serialized > Data", and they wanted JSON instead because it *was* easily to eval() to > parse. (Except now JSON has to avoid injections just like SQL & perl/php, > etc, ...). > > I'm pretty sure the real problem has been DEMONSTRATED with the > implementation(s), especially where you further demonstrated that you wan= t > to leave out any mention of the extensibility features in order to show t= he > problem with non-extensibility. That sounds familiar. > > > > It's a really fundamental aspect of the ADT that it defines our types >> independent of its serializations. =EF=BF=BDIt's a useful concept, but t= he problem >> with this particular one -- LLSD (DSD?) -- is that the elementary types = are >> neither flexible nor extensible. >> >> > Let the VMs define further ADTs. We only need a few standard data types. > This WG should only be concerned with being able to document (and clarify= ) > the flow, especially the region-agent transistions. If the flow uses > standard LLSD data types to define some complex abstract data type, perfe= ct > enough. I wouldn't be surprised if we add one more LLSD data type for DAE= s, > as that may be the perfect place for it. Then you can go and add any > relevant extension you want to the DAE, even more abstract data types wit= hin > the DAE, and further you don't even have to worry about it all being in R= FC > format. > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --000e0cd5c94e49766904a27765c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, May 4, 2011 at 7:05 PM, Dzonatas Sol <dzonatas@gmail.com><= /span> wrote:

XML is more than just serialization and mark-up language, yet this how=20 people *start* with such concepts. It remains very useful for more=20 advanced flows with absolute simplicity to the core to parse, and=20 continues to be ridiculously easy to optimize, tokenize, and compress=20 (with static dictionaries). Note that with static dictionaries, concerns like power consumption are already thought about because to even get=20 that analytic computation done for each and every message only consumes=20 more power.


This is what I can't seem to get across to = you.=C2=A0 All those wonderful features of XML are IRRELEVANT to the= extensibility of the ADT's primitive types, because the ADT defines it= s very limited set of abstract types itself, directly.=C2=A0 The only thing= that the ADT's serializations can do is express those predefined ADT t= ypes on the wire.=C2=A0 You can't extend the primitive types in a seria= lization of the ADT.

If you were arguing that our ADT's primary type definitions should = be in XML then you would have quite a good point, because then the types wo= uld be both flexible and extensible.=C2=A0 But that's not what we'r= e discussing here.


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Wed, May 4, 2011 at 7:05 PM, Dzonatas Sol <= dzonatas@gmail.com> wro= te:
On 05/04/2011 10:22 AM, Morgaine wrote:
Let me rephrase it more precisely.=EF=BF=BD Your responses do not *demonstr= ate* understanding of the type model of LLSD + serializations.=EF=BF=BD You= persist in suggesting that the extensibility of XML can extend the element= ary types of LLSD, when it absolutely cannot do that.=EF=BF=BD I am confide= nt that you do understand this, but it hasn't come across yet.

I recommend leaving XML out of the discussion, because it's just one ou= t of 3 primary serializations.=EF=BF=BD Leaving it out (for now) will help = highlight the non-extensibility of the LLSD elementary data types.

XML is only a more graphic form than ASCII and extended with common multi-b= yte format useful to detect network order. Because it is human-readable, ma= ny miss *that* obvious critical fact. If you send XML data, we don't ha= ve to worry about the network order for whatever abstract data types you ma= ke up.

XML is more than just serialization and mark-up language, yet this how peop= le *start* with such concepts. It remains very useful for more advanced flo= ws with absolute simplicity to the core to parse, and continues to be ridic= ulously easy to optimize, tokenize, and compress (with static dictionaries)= . Note that with static dictionaries, concerns like power consumption are a= lready thought about because to even get that analytic computation done for= each and every message only consumes more power.

You're telling us you want to leave that already well-thought-critical = details out of the discussion when it is already standardized and already j= ust easily said as "XML"?

We realize that some implementers made LLSD mean "Linden Lab Serialize= d Data", and they wanted JSON instead because it *was* easily to eval(= ) to parse. (Except now JSON has to avoid injections just like SQL & pe= rl/php, etc, ...).

I'm pretty sure the real problem has been DEMONSTRATED with the impleme= ntation(s), especially where you further demonstrated that you want to leav= e out any mention of the extensibility features in order to show the proble= m with non-extensibility. That sounds familiar.



It's a really fundamental aspect of the ADT that it defines our types i= ndependent of its serializations. =EF=BF=BDIt's a useful concept, but t= he problem with this particular one -- LLSD (DSD?) -- is that the elementar= y types are neither flexible nor extensible.


Let the VMs define further ADTs. We only need a few standard data types. Th= is WG should only be concerned with being able to document (and clarify) th= e flow, especially the region-agent transistions. If the flow uses standard= LLSD data types to define some complex abstract data type, perfect enough.= I wouldn't be surprised if we add one more LLSD data type for DAEs, as= that may be the perfect place for it. Then you can go and add any relevant= extension you want to the DAE, even more abstract data types within the DA= E, and further you don't even have to worry about it all being in RFC f= ormat.



--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--000e0cd5c94e49766904a27765c2-- From dzonatas@gmail.com Wed May 4 12:36:07 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C77E074D for ; Wed, 4 May 2011 12:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.891 X-Spam-Level: X-Spam-Status: No, score=-3.891 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJAfWPbUvUSd for ; Wed, 4 May 2011 12:36:06 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E7F44E06B1 for ; Wed, 4 May 2011 12:36:05 -0700 (PDT) Received: by pwi5 with SMTP id 5so854187pwi.31 for ; Wed, 04 May 2011 12:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pAM+5hywcQWs/Ej1c4TbGL5syawUgn369MmrZZns9hQ=; b=jasB52s0WIkyUETQt+YKgCV+T7EUlubKjicycBaTkP89TSPETInwuIwT4d1dinrD8W u80MK32+EnVC9ZH8RS1f72bNm1EWgxXjJVyVL3IKYgP0mYq/rbNTPmpAXqPstO3nzo7H uHDuMnpjCvYPEIBVpL3rrhAnE+yRxqhJgpRKA= 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=O5YL+i0B6x3xvs4xEnPp2W69+I5+hNgyfPhKEm84Usz9LwORkIhQ8BG5ys9H14MJwu f8vZ9mMj5yJk/wcuVzXmCRI24O/uXA8aT7iWcRNaWKRmv1O5WhvaZhJC0Iujj2ls0Nl/ zC/kDPG5mT6iZofKDdxzKpAaFUozMsdYgYGzw= Received: by 10.68.14.37 with SMTP id m5mr1893524pbc.474.1304537354810; Wed, 04 May 2011 12:29:14 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id d3sm910057pbh.73.2011.05.04.12.29.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2011 12:29:14 -0700 (PDT) Message-ID: <4DC1A8C9.9090406@gmail.com> Date: Wed, 04 May 2011 12:28:09 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [vwrap] ADT? is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Wed, 04 May 2011 19:36:07 -0000 I would like to add the "stream buffer" data type, with optional metadata to normalize access to higher-levels, and with intent of content extraction/replacement by element tag (like XPath). This would make it so much easier to implement asset servers and agent services. (Yet, I rather have more implementation first than simple Schroedinger's cat idealogy to base RFC submission). Do you want to update the text below to add your "ADT" to the already implemented type system? In WIP: http://tools.ietf.org/html/draft-ietf-vwrap-type-system-00 Section 2: The LLSD abstract type system describes the semantics of data passed between two network hosts. These types characterize the data when serialized for transport, when stored in memory, and when accessed by applications. The types are designed to be common enough that native types in existing serializations and programming languages will be usable directly. It is anticipated that LLSD data may be serialized in systems with fewer types or stored in native programming language structures with less precise types, and still interoperate in a predictable, reliable manner. To support this, conversions are defined to govern how data received or stored as one type may be read as another. For example, if an application expects to read an LLSD value as an Integer, but the serialization used to transport the value only supported Reals, then a conversion governs how the application will see the transported value. Another case would be where an application wants to read an LLSD value as a URL, but the programing language only supports String as a data type. Again, there is a defined conversion for this case. The intention is that applications will interact with LLSD data via interfaces in terms of these types, even if the underlying language or transports do not directly support them, while retaining as much direct compatibility with those native types as possible. An LLSD value is either a simple datum or a composite structure. A simple data value can have one of nine simple types: Undefined, Boolean, Integer, Real, String, UUID, Date, URI or Binary. Composite structures can be either of the types Array or Map. On 05/04/2011 11:26 AM, Morgaine wrote: > On Wed, May 4, 2011 at 7:05 PM, Dzonatas Sol > wrote: > > > XML is more than just serialization and mark-up language, yet this > how people *start* with such concepts. It remains very useful for > more advanced flows with absolute simplicity to the core to parse, > and continues to be ridiculously easy to optimize, tokenize, and > compress (with static dictionaries). Note that with static > dictionaries, concerns like power consumption are already thought > about because to even get that analytic computation done for each > and every message only consumes more power. > > > This is what I can't seem to get across to you. All those wonderful > features of XML are *IRRELEVANT* to the extensibility of the ADT's > primitive types, because the ADT defines its very limited set of > abstract types itself, directly. The only thing that the ADT's > serializations can do is express those predefined ADT types on the > wire. You can't extend the primitive types in a serialization of the ADT. > > If you were arguing that our ADT's primary type definitions should be > in XML then you would have quite a good point, because then the types > would be both flexible and extensible. But that's not what we're > discussing here. > > > Morgaine. > > > > > ========================== > > On Wed, May 4, 2011 at 7:05 PM, Dzonatas Sol > wrote: > > On 05/04/2011 10:22 AM, Morgaine wrote: > > Let me rephrase it more precisely.� Your responses do not > *demonstrate* understanding of the type model of LLSD + > serializations.� You persist in suggesting that the > extensibility of XML can extend the elementary types of LLSD, > when it absolutely cannot do that.� I am confident that you do > understand this, but it hasn't come across yet. > > I recommend leaving XML out of the discussion, because it's > just one out of 3 primary serializations.� Leaving it out (for > now) will help highlight the non-extensibility of the LLSD > elementary data types. > > > XML is only a more graphic form than ASCII and extended with > common multi-byte format useful to detect network order. Because > it is human-readable, many miss *that* obvious critical fact. If > you send XML data, we don't have to worry about the network order > for whatever abstract data types you make up. > > XML is more than just serialization and mark-up language, yet this > how people *start* with such concepts. It remains very useful for > more advanced flows with absolute simplicity to the core to parse, > and continues to be ridiculously easy to optimize, tokenize, and > compress (with static dictionaries). Note that with static > dictionaries, concerns like power consumption are already thought > about because to even get that analytic computation done for each > and every message only consumes more power. > > You're telling us you want to leave that already > well-thought-critical details out of the discussion when it is > already standardized and already just easily said as "XML"? > > We realize that some implementers made LLSD mean "Linden Lab > Serialized Data", and they wanted JSON instead because it *was* > easily to eval() to parse. (Except now JSON has to avoid > injections just like SQL & perl/php, etc, ...). > > I'm pretty sure the real problem has been DEMONSTRATED with the > implementation(s), especially where you further demonstrated that > you want to leave out any mention of the extensibility features in > order to show the problem with non-extensibility. That sounds > familiar. > > > > It's a really fundamental aspect of the ADT that it defines > our types independent of its serializations. �It's a useful > concept, but the problem with this particular one -- LLSD > (DSD?) -- is that the elementary types are neither flexible > nor extensible. > > > Let the VMs define further ADTs. We only need a few standard data > types. This WG should only be concerned with being able to > document (and clarify) the flow, especially the region-agent > transistions. If the flow uses standard LLSD data types to define > some complex abstract data type, perfect enough. I wouldn't be > surprised if we add one more LLSD data type for DAEs, as that may > be the perfect place for it. Then you can go and add any relevant > extension you want to the DAE, even more abstract data types > within the DAE, and further you don't even have to worry about it > all being in RFC format. > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Wed May 4 14:02:30 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C918DE06B7 for ; Wed, 4 May 2011 14:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.933 X-Spam-Level: X-Spam-Status: No, score=-2.933 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6FjrhxhBlH4 for ; Wed, 4 May 2011 14:02:29 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D5669E06A3 for ; Wed, 4 May 2011 14:02:28 -0700 (PDT) Received: by qwc23 with SMTP id 23so1268388qwc.31 for ; Wed, 04 May 2011 14:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=+WmqugJHnZXcJMYKTGg0fD+eztTLooqRJ4/lPw0OOMI=; b=U2aIy09az61leyVYmAfqg99Qv6Uxw22Qk/xXolTOr8G0hm4pTIiAgRhrT3B/8fQ9At bxHCseiZwnc/EqP4Xt+iP2cxYOOWLBQO52jfslkuR2XIk6fzXHRcAzmfFIy+XPWREry6 ZKP7eFtuRWJd8ayEqgiUAg9IRo0+M3WpP3lAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=p5+HQOsCSX3IBuGwk8a/E8wKbenXMCVmc3BXU95bk4prlIi81ieGaTAWhUghsc0GG6 HoIqOnHgRLvv2Rk8ataBJ2A5t98dFqdZmlLJG/e9llQ/xFOW/UiZ3pgXq4o3X47sTz+y NPn15tKUtkYAWjLLr43d2mUbUGje6rp5ZfK8o= MIME-Version: 1.0 Received: by 10.229.68.203 with SMTP id w11mr1241773qci.291.1304542948096; Wed, 04 May 2011 14:02:28 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Wed, 4 May 2011 14:02:27 -0700 (PDT) In-Reply-To: <4DC1A8C9.9090406@gmail.com> References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> Date: Wed, 4 May 2011 22:02:27 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016e6513a1c03f99604a2799381 Subject: Re: [vwrap] ADT? is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Wed, 04 May 2011 21:02:30 -0000 --0016e6513a1c03f99604a2799381 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 4, 2011 at 8:28 PM, Dzonatas Sol wrote: > I would like to add the "stream buffer" data type, with optional metadata > to normalize access to higher-levels, and with intent of content > extraction/replacement by element tag (like XPath). This would make it so > much easier to implement asset servers and agent services. (Yet, I rather > have more implementation first than simple Schroedinger's cat idealogy to > base RFC submission). > > Do you want to update the text below to add your "ADT" to the already > implemented type system? ??? Although I don't actually understand what you've written above, or why, I'm going to try to help by taking a wild guess at what you might have meant. It's possible that you believe that I have some concrete types in mind that I want to add to LLSD's predefined set of primitive types, and that you are inviting me to add them. Is that the right interpretation? Assuming that this is so, please note that whatever types I may have in mind, adding them to the predefined set of LLSD will not make that set of types extensible. All it will achieve is to make LLSD more flexible *for m= e *, by adding types that I happen to want. Adding more predefined primitive types does add flexibility, but flexibility and extensibility are two different things. Type extensibility is obviously far more powerful than having a wide range of predefined types, because it would allow you to extend the set of primitive types in the ADT however you wish, so the future is open-ended. Despite that, it is quite common to aim for a flexible set of primitive types instead of an extensible one. We could aim for a more flexible set o= f primitive types for VWRAP, or we could aim for an extensible set, or a bit of both. But to provide neither is a very poor choice, and would not be "designing for the future". If we were to choose flexibility instead of extensibility for our ADT system, I would certainly recommend very strongly that all the usual intege= r types be predefined, because they are used extremely widely, and provide fo= r very efficient binary serializations. That would be a good start! Before we continue this line of discussion further though, perhaps you'd better confirm that this is the topic that you had in mind above, because your mention of "stream buffer data type with optional metadata" makes me think that there is a strong chance that you're referring to something completely different. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Wed, May 4, 2011 at 8:28 PM, Dzonatas Sol wrote: > I would like to add the "stream buffer" data type, with optional metadata > to normalize access to higher-levels, and with intent of content > extraction/replacement by element tag (like XPath). This would make it so > much easier to implement asset servers and agent services. (Yet, I rather > have more implementation first than simple Schroedinger's cat idealogy to > base RFC submission). > > Do you want to update the text below to add your "ADT" to the already > implemented type system? > > In WIP: http://tools.ietf.org/html/draft-ietf-vwrap-type-system-00 > Section 2: > > The LLSD abstract type system describes the semantics of data passed > between two network hosts. These types characterize the data when > serialized for transport, when stored in memory, and when accessed by > applications. > > The types are designed to be common enough that native types in > existing serializations and programming languages will be usable > directly. It is anticipated that LLSD data may be serialized in > systems with fewer types or stored in native programming language > structures with less precise types, and still interoperate in a > predictable, reliable manner. To support this, conversions are > defined to govern how data received or stored as one type may be read > as another. > > For example, if an application expects to read an LLSD value as an > Integer, but the serialization used to transport the value only > supported Reals, then a conversion governs how the application will > see the transported value. Another case would be where an > application wants to read an LLSD value as a URL, but the programing > language only supports String as a data type. Again, there is a > defined conversion for this case. > > The intention is that applications will interact with LLSD data via > interfaces in terms of these types, even if the underlying language > or transports do not directly support them, while retaining as much > direct compatibility with those native types as possible. > > An LLSD value is either a simple datum or a composite structure. A > simple data value can have one of nine simple types: Undefined, > Boolean, Integer, Real, String, UUID, Date, URI or Binary. Composite > structures can be either of the types Array or Map. > > > > On 05/04/2011 11:26 AM, Morgaine wrote: > >> On Wed, May 4, 2011 at 7:05 PM, Dzonatas Sol > dzonatas@gmail.com>> wrote: >> >> >> XML is more than just serialization and mark-up language, yet this >> how people *start* with such concepts. It remains very useful for >> more advanced flows with absolute simplicity to the core to parse, >> and continues to be ridiculously easy to optimize, tokenize, and >> compress (with static dictionaries). Note that with static >> dictionaries, concerns like power consumption are already thought >> about because to even get that analytic computation done for each >> and every message only consumes more power. >> >> >> This is what I can't seem to get across to you. All those wonderful >> features of XML are *IRRELEVANT* to the extensibility of the ADT's primi= tive >> types, because the ADT defines its very limited set of abstract types >> itself, directly. The only thing that the ADT's serializations can do i= s >> express those predefined ADT types on the wire. You can't extend the >> primitive types in a serialization of the ADT. >> >> If you were arguing that our ADT's primary type definitions should be in >> XML then you would have quite a good point, because then the types would= be >> both flexible and extensible. But that's not what we're discussing here= . >> >> >> Morgaine. >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >> >> On Wed, May 4, 2011 at 7:05 PM, Dzonatas Sol > dzonatas@gmail.com>> wrote: >> >> On 05/04/2011 10:22 AM, Morgaine wrote: >> >> Let me rephrase it more precisely.=EF=BF=BD Your responses do not >> *demonstrate* understanding of the type model of LLSD + >> serializations.=EF=BF=BD You persist in suggesting that the >> extensibility of XML can extend the elementary types of LLSD, >> when it absolutely cannot do that.=EF=BF=BD I am confident that y= ou do >> understand this, but it hasn't come across yet. >> >> I recommend leaving XML out of the discussion, because it's >> just one out of 3 primary serializations.=EF=BF=BD Leaving it out= (for >> now) will help highlight the non-extensibility of the LLSD >> elementary data types. >> >> >> XML is only a more graphic form than ASCII and extended with >> common multi-byte format useful to detect network order. Because >> it is human-readable, many miss *that* obvious critical fact. If >> you send XML data, we don't have to worry about the network order >> for whatever abstract data types you make up. >> >> XML is more than just serialization and mark-up language, yet this >> how people *start* with such concepts. It remains very useful for >> more advanced flows with absolute simplicity to the core to parse, >> and continues to be ridiculously easy to optimize, tokenize, and >> compress (with static dictionaries). Note that with static >> dictionaries, concerns like power consumption are already thought >> about because to even get that analytic computation done for each >> and every message only consumes more power. >> >> You're telling us you want to leave that already >> well-thought-critical details out of the discussion when it is >> already standardized and already just easily said as "XML"? >> >> We realize that some implementers made LLSD mean "Linden Lab >> Serialized Data", and they wanted JSON instead because it *was* >> easily to eval() to parse. (Except now JSON has to avoid >> injections just like SQL & perl/php, etc, ...). >> >> I'm pretty sure the real problem has been DEMONSTRATED with the >> implementation(s), especially where you further demonstrated that >> you want to leave out any mention of the extensibility features in >> order to show the problem with non-extensibility. That sounds >> familiar. >> >> >> >> It's a really fundamental aspect of the ADT that it defines >> our types independent of its serializations. =EF=BF=BDIt's a usef= ul >> concept, but the problem with this particular one -- LLSD >> (DSD?) -- is that the elementary types are neither flexible >> nor extensible. >> >> >> Let the VMs define further ADTs. We only need a few standard data >> types. This WG should only be concerned with being able to >> document (and clarify) the flow, especially the region-agent >> transistions. If the flow uses standard LLSD data types to define >> some complex abstract data type, perfect enough. I wouldn't be >> surprised if we add one more LLSD data type for DAEs, as that may >> be the perfect place for it. Then you can go and add any relevant >> extension you want to the DAE, even more abstract data types >> within the DAE, and further you don't even have to worry about it >> all being in RFC format. >> >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --0016e6513a1c03f99604a2799381 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 4, 2011 at 8:28 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
=
I would like to add the "stream buffer" data type, with optional m= etadata to normalize access to higher-levels, and with intent of content=20 extraction/replacement by element tag (like XPath). This would make it=20 so much easier to implement asset servers and agent services. (Yet, I=20 rather have more implementation first than simple Schroedinger's cat=20 idealogy to base RFC submission).

Do you want to update the text below to add your "ADT" to the alr= eady implemented type system?


???

Although = I don't actually understand what you've written above, or why, I= 9;m going to try to help by taking a wild guess at what you might have mean= t.=C2=A0 It's possible that you believe that I have some concrete types= in mind that I want to add to LLSD's predefined set of primitive types= , and that you are inviting me to add them.=C2=A0 Is that the right interpr= etation?

Assuming that this is so, please note that whatever types I may have in= mind, adding them to the predefined set of LLSD will not make that set of = types extensible.=C2=A0 All it will achieve is to make LLSD more flexible <= b>for me, by adding types that I happen to want.=C2=A0 Adding more pred= efined primitive types does add flexibility, but flexibility and extensibil= ity are two different things.

Type extensibility is obviously far more powerful than having a wide ra= nge of predefined types, because it would allow you to extend the set of pr= imitive types in the ADT however you wish, so the future is open-ended.=C2= =A0 Despite that, it is quite common to aim for a flexible set of primitive= types instead of an extensible one.=C2=A0 We could aim for a more flexible= set of primitive types for VWRAP, or we could aim for an extensible set, o= r a bit of both.=C2=A0 But to provide neither is a very poor choice, and wo= uld not be "designing for the future".

If we were to choose flexibility instead of extensibility for our ADT s= ystem, I would certainly recommend very strongly that all the usual integer= types be predefined, because they are used extremely widely, and provide f= or very efficient binary serializations. =C2=A0That would be a good start!<= br>
Before we continue this line of discussion further though, perhaps you&= #39;d better confirm that this is the topic that you had in mind above, bec= ause your mention of "stream buffer data type with optional metadata&q= uot; makes me think that there is a strong chance that you're referring= to something completely different.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

O= n Wed, May 4, 2011 at 8:28 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
I would like to a= dd the "stream buffer" data type, with optional metadata to norma= lize access to higher-levels, and with intent of content extraction/replace= ment by element tag (like XPath). This would make it so much easier to impl= ement asset servers and agent services. (Yet, I rather have more implementa= tion first than simple Schroedinger's cat idealogy to base RFC submissi= on).

Do you want to update the text below to add your "ADT" to the alr= eady implemented type system?

In WIP: http://tools.ietf.org/html/draft-ietf-vwrap-type-syst= em-00
Section 2:

=C2=A0 The LLSD abstract type system describes the semantics of data passe= d
=C2=A0 between two network hosts. =C2=A0These types characterize the data = when
=C2=A0 serialized for transport, when stored in memory, and when accessed = by
=C2=A0 applications.

=C2=A0 The types are designed to be common enough that native types in
=C2=A0 existing serializations and programming languages will be usable =C2=A0 directly. =C2=A0It is anticipated that LLSD data may be serialized = in
=C2=A0 systems with fewer types or stored in native programming language =C2=A0 structures with less precise types, and still interoperate in a
=C2=A0 predictable, reliable manner. =C2=A0To support this, conversions ar= e
=C2=A0 defined to govern how data received or stored as one type may be re= ad
=C2=A0 as another.

=C2=A0 For example, if an application expects to read an LLSD value as an<= br> =C2=A0 Integer, but the serialization used to transport the value only
=C2=A0 supported Reals, then a conversion governs how the application will=
=C2=A0 see the transported value. =C2=A0Another case would be where an
=C2=A0 application wants to read an LLSD value as a URL, but the programin= g
=C2=A0 language only supports String as a data type. =C2=A0Again, there is= a
=C2=A0 defined conversion for this case.

=C2=A0 The intention is that applications will interact with LLSD data via=
=C2=A0 interfaces in terms of these types, even if the underlying language=
=C2=A0 or transports do not directly support them, while retaining as much=
=C2=A0 direct compatibility with those native types as possible.

=C2=A0 An LLSD value is either a simple datum or a composite structure. = =C2=A0A
=C2=A0 simple data value can have one of nine simple types: Undefined,
=C2=A0 Boolean, Integer, Real, String, UUID, Date, URI or Binary. =C2=A0Co= mposite
=C2=A0 structures can be either of the types Array or Map.



On 05/04/2011 11:26 AM, Morgaine wrote:
On Wed, May 4, 2011 at 7:05 PM, Dzonatas Sol <dzonatas@gmail.com <mailto:dzonatas@gmail.com>>= wrote:


=C2=A0 =C2=A0XML is more than just serialization and mark-up language, yet= this
=C2=A0 =C2=A0how people *start* with such concepts. It remains very useful= for
=C2=A0 =C2=A0more advanced flows with absolute simplicity to the core to p= arse,
=C2=A0 =C2=A0and continues to be ridiculously easy to optimize, tokenize, = and
=C2=A0 =C2=A0compress (with static dictionaries). Note that with static =C2=A0 =C2=A0dictionaries, concerns like power consumption are already tho= ught
=C2=A0 =C2=A0about because to even get that analytic computation done for = each
=C2=A0 =C2=A0and every message only consumes more power.


This is what I can't seem to get across to you. =C2=A0All those wonderf= ul features of XML are *IRRELEVANT* to the extensibility of the ADT's p= rimitive types, because the ADT defines its very limited set of abstract ty= pes itself, directly. =C2=A0The only thing that the ADT's serialization= s can do is express those predefined ADT types on the wire. =C2=A0You can&#= 39;t extend the primitive types in a serialization of the ADT.

If you were arguing that our ADT's primary type definitions should be i= n XML then you would have quite a good point, because then the types would = be both flexible and extensible. =C2=A0But that's not what we're di= scussing here.


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

On Wed, May 4, 2011 at 7:05 PM, Dzonatas Sol <dzonatas@gmail.com <mailto:dzonatas@gmail.com>>= wrote:

=C2=A0 =C2=A0On 05/04/2011 10:22 AM, Morgaine wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0Let me rephrase it more precisely.=EF=BF=BD You= r responses do not
=C2=A0 =C2=A0 =C2=A0 =C2=A0*demonstrate* understanding of the type model o= f LLSD +
=C2=A0 =C2=A0 =C2=A0 =C2=A0serializations.=EF=BF=BD You persist in suggest= ing that the
=C2=A0 =C2=A0 =C2=A0 =C2=A0extensibility of XML can extend the elementary = types of LLSD,
=C2=A0 =C2=A0 =C2=A0 =C2=A0when it absolutely cannot do that.=EF=BF=BD I a= m confident that you do
=C2=A0 =C2=A0 =C2=A0 =C2=A0understand this, but it hasn't come across = yet.

=C2=A0 =C2=A0 =C2=A0 =C2=A0I recommend leaving XML out of the discussion, = because it's
=C2=A0 =C2=A0 =C2=A0 =C2=A0just one out of 3 primary serializations.=EF=BF= =BD Leaving it out (for
=C2=A0 =C2=A0 =C2=A0 =C2=A0now) will help highlight the non-extensibility = of the LLSD
=C2=A0 =C2=A0 =C2=A0 =C2=A0elementary data types.


=C2=A0 =C2=A0XML is only a more graphic form than ASCII and extended with<= br> =C2=A0 =C2=A0common multi-byte format useful to detect network order. Beca= use
=C2=A0 =C2=A0it is human-readable, many miss *that* obvious critical fact.= If
=C2=A0 =C2=A0you send XML data, we don't have to worry about the netwo= rk order
=C2=A0 =C2=A0for whatever abstract data types you make up.

=C2=A0 =C2=A0XML is more than just serialization and mark-up language, yet= this
=C2=A0 =C2=A0how people *start* with such concepts. It remains very useful= for
=C2=A0 =C2=A0more advanced flows with absolute simplicity to the core to p= arse,
=C2=A0 =C2=A0and continues to be ridiculously easy to optimize, tokenize, = and
=C2=A0 =C2=A0compress (with static dictionaries). Note that with static =C2=A0 =C2=A0dictionaries, concerns like power consumption are already tho= ught
=C2=A0 =C2=A0about because to even get that analytic computation done for = each
=C2=A0 =C2=A0and every message only consumes more power.

=C2=A0 =C2=A0You're telling us you want to leave that already
=C2=A0 =C2=A0well-thought-critical details out of the discussion when it i= s
=C2=A0 =C2=A0already standardized and already just easily said as "XM= L"?

=C2=A0 =C2=A0We realize that some implementers made LLSD mean "Linden= Lab
=C2=A0 =C2=A0Serialized Data", and they wanted JSON instead because i= t *was*
=C2=A0 =C2=A0easily to eval() to parse. (Except now JSON has to avoid
=C2=A0 =C2=A0injections just like SQL & perl/php, etc, ...).

=C2=A0 =C2=A0I'm pretty sure the real problem has been DEMONSTRATED wi= th the
=C2=A0 =C2=A0implementation(s), especially where you further demonstrated = that
=C2=A0 =C2=A0you want to leave out any mention of the extensibility featur= es in
=C2=A0 =C2=A0order to show the problem with non-extensibility. That sounds=
=C2=A0 =C2=A0familiar.



=C2=A0 =C2=A0 =C2=A0 =C2=A0It's a really fundamental aspect of the ADT= that it defines
=C2=A0 =C2=A0 =C2=A0 =C2=A0our types independent of its serializations. = =EF=BF=BDIt's a useful
=C2=A0 =C2=A0 =C2=A0 =C2=A0concept, but the problem with this particular o= ne -- LLSD
=C2=A0 =C2=A0 =C2=A0 =C2=A0(DSD?) -- is that the elementary types are neit= her flexible
=C2=A0 =C2=A0 =C2=A0 =C2=A0nor extensible.


=C2=A0 =C2=A0Let the VMs define further ADTs. We only need a few standard = data
=C2=A0 =C2=A0types. This WG should only be concerned with being able to =C2=A0 =C2=A0document (and clarify) the flow, especially the region-agent<= br> =C2=A0 =C2=A0transistions. If the flow uses standard LLSD data types to de= fine
=C2=A0 =C2=A0some complex abstract data type, perfect enough. I wouldn'= ;t be
=C2=A0 =C2=A0surprised if we add one more LLSD data type for DAEs, as that= may
=C2=A0 =C2=A0be the perfect place for it. Then you can go and add any rele= vant
=C2=A0 =C2=A0extension you want to the DAE, even more abstract data types<= br> =C2=A0 =C2=A0within the DAE, and further you don't even have to worry = about it
=C2=A0 =C2=A0all being in RFC format.



=C2=A0 =C2=A0-- =C2=A0 =C2=A0 --- https://twitter.com/Dzonatas_Sol ---
=C2=A0 =C2=A0Web Development, Software Engineering, Virtual Reality, Consu= ltant

=C2=A0 =C2=A0_______________________________________________
=C2=A0 =C2=A0vwrap mailing list
=C2=A0 =C2=A0vwrap@iet= f.org <mailto:vw= rap@ietf.org>
=C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/vwrap



_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap
=C2=A0


--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--0016e6513a1c03f99604a2799381-- From dzonatas@gmail.com Wed May 4 15:22:35 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D9CE06F0 for ; Wed, 4 May 2011 15:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrSiGlq3byZt for ; Wed, 4 May 2011 15:22:31 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C3E62E0663 for ; Wed, 4 May 2011 15:22:31 -0700 (PDT) Received: by pzk5 with SMTP id 5so901472pzk.31 for ; Wed, 04 May 2011 15:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Vv+bx2yW1ACteLXhoivTnrGUIrd5r0BJaA5hGPDDLhM=; b=ZBFwyFIMSqaiBg0QEVWzhIpu4N52qaRzC1gna0+1t7tYAEZZ11QmXoHOgkR7HuUIMV Sr8hXCTSMQLz0E9KuPDIwQF9KG7ziz2Nn59wNVcY4XuTLULjetersHvWoWR9N7fx4/5k ewN9mEB87PL/JHhvV8/z9ceFnhIm019BjC/A4= 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=GjxljE0A5NgMkwbF9csGAF79BYyLNvPPZQ8pz5m7emoZhtqkiShU75uv8DDsPapJKf 9AieDxv0Pjov7Dc1xfKwRad8yG/cj589M9bXzILjEC96QCFvo4FKx+ETnctwSay/NKmm J+x8DjY8nFR1ojHDYlRlu31yIoleUApRrfCC4= Received: by 10.68.55.166 with SMTP id t6mr2222656pbp.223.1304547751497; Wed, 04 May 2011 15:22:31 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id d9sm995283pba.16.2011.05.04.15.22.29 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2011 15:22:30 -0700 (PDT) Message-ID: <4DC1D165.7010705@gmail.com> Date: Wed, 04 May 2011 15:21:25 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Wed, 04 May 2011 22:22:36 -0000 I've already confirmed the addition of the "stream buffer" data type idea and know the boundaries well enough that such mechanism incorporates the solution for several discussion that have occurred here and elsewhere. That's where you would want to add your "ADT". The *the flow* needs to remain consistent, as much as possible, and continue to work in future design with other possible metadata. The draft WIP explained LLSD clearly enough that to totally redefine that LLSD for absolute extensibility is only *against* the flow of *support* for anything like pre-defined types; further, to continue to break such WIP only causes re-implementation, re-negotiation, and re-standardization of already definitive work. Is your goal to break that work flow and cause people to rewrite protocol drivers based, constantly, on every extensive "designing for the future" data type? I call your motion careless "loop". Even C/C++ programmers know the avoid the pointer that points to itself. Abstract type system does not mean the data has to be absolutely extensive every possible moment. Maybe that is somewhat possible if you expect hardware to automatically transform metallic physicals based on every machine language instruction that needs to be extensive. We do look at this at every scale besides your "game loop". I like quantum-jargon because that avoids such ludicrous ever-every-sense. We are not dumb despite what people think about our druggie lingo and organic morphisms, as this shows you've gone down deep with scalability. What your after has already been invented as the "dynamic compiler" simply in those words, not ADT. Note: we already did work on dynamic compilers decades ago. Don't tell me I don't know the power of these, "type extensibility is obviously far more powerful than having a wide range of predefined types". I've already posted related work on these lists, maybe you didn't recognize the simplicity. Morgaine, you're out of scope. After you get someone to implement your blessed extensive abstract type system, then I bet you'll want something even more raw then that. We been there and like to inspire. Please, stay positive. Do you object to the addition of one more predefined data types, like the "stream buffer"? There already is something like http://www.w3schools.com/schema/ . The element is already in use. We already have tags for the deep down scalable raw structures. Actually, I invented one tag called that does all the above already, so how about the predefined embed'ed data type instead of endless extensibility? It works in notecards already to inventory: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Asset#notecard On 05/04/2011 02:02 PM, Morgaine wrote: > On Wed, May 4, 2011 at 8:28 PM, Dzonatas Sol > wrote: > > I would like to add the "stream buffer" data type, with optional > metadata to normalize access to higher-levels, and with intent of > content extraction/replacement by element tag (like XPath). This > would make it so much easier to implement asset servers and agent > services. (Yet, I rather have more implementation first than > simple Schroedinger's cat idealogy to base RFC submission). > > Do you want to update the text below to add your "ADT" to the > already implemented type system? > > > > ??? > > Although I don't actually understand what you've written above, or > why, I'm going to try to help by taking a wild guess at what you might > have meant. It's possible that you believe that I have some concrete > types in mind that I want to add to LLSD's predefined set of primitive > types, and that you are inviting me to add them. Is that the right > interpretation? > > Assuming that this is so, please note that whatever types I may have > in mind, adding them to the predefined set of LLSD will not make that > set of types extensible. All it will achieve is to make LLSD more > flexible *for me*, by adding types that I happen to want. Adding more > predefined primitive types does add flexibility, but flexibility and > extensibility are two different things. > > Type extensibility is obviously far more powerful than having a wide > range of predefined types, because it would allow you to extend the > set of primitive types in the ADT however you wish, so the future is > open-ended. Despite that, it is quite common to aim for a flexible > set of primitive types instead of an extensible one. We could aim for > a more flexible set of primitive types for VWRAP, or we could aim for > an extensible set, or a bit of both. But to provide neither is a very > poor choice, and would not be "designing for the future". > > If we were to choose flexibility instead of extensibility for our ADT > system, I would certainly recommend very strongly that all the usual > integer types be predefined, because they are used extremely widely, > and provide for very efficient binary serializations. That would be a > good start! > > Before we continue this line of discussion further though, perhaps > you'd better confirm that this is the topic that you had in mind > above, because your mention of "stream buffer data type with optional > metadata" makes me think that there is a strong chance that you're > referring to something completely different. > > > Morgaine. > > > > > > ====================== > > On Wed, May 4, 2011 at 8:28 PM, Dzonatas Sol > wrote: > > I would like to add the "stream buffer" data type, with optional > metadata to normalize access to higher-levels, and with intent of > content extraction/replacement by element tag (like XPath). This > would make it so much easier to implement asset servers and agent > services. (Yet, I rather have more implementation first than > simple Schroedinger's cat idealogy to base RFC submission). > > Do you want to update the text below to add your "ADT" to the > already implemented type system? > > In WIP: http://tools.ietf.org/html/draft-ietf-vwrap-type-system-00 > Section 2: > > The LLSD abstract type system describes the semantics of data passed > between two network hosts. These types characterize the data when > serialized for transport, when stored in memory, and when > accessed by > applications. > > The types are designed to be common enough that native types in > existing serializations and programming languages will be usable > directly. It is anticipated that LLSD data may be serialized in > systems with fewer types or stored in native programming language > structures with less precise types, and still interoperate in a > predictable, reliable manner. To support this, conversions are > defined to govern how data received or stored as one type may be > read > as another. > > For example, if an application expects to read an LLSD value as an > Integer, but the serialization used to transport the value only > supported Reals, then a conversion governs how the application will > see the transported value. Another case would be where an > application wants to read an LLSD value as a URL, but the programing > language only supports String as a data type. Again, there is a > defined conversion for this case. > > The intention is that applications will interact with LLSD data via > interfaces in terms of these types, even if the underlying language > or transports do not directly support them, while retaining as much > direct compatibility with those native types as possible. > > An LLSD value is either a simple datum or a composite structure. A > simple data value can have one of nine simple types: Undefined, > Boolean, Integer, Real, String, UUID, Date, URI or Binary. > Composite > structures can be either of the types Array or Map. > > > > On 05/04/2011 11:26 AM, Morgaine wrote: > > On Wed, May 4, 2011 at 7:05 PM, Dzonatas Sol > > >> wrote: > > > XML is more than just serialization and mark-up language, > yet this > how people *start* with such concepts. It remains very > useful for > more advanced flows with absolute simplicity to the core to > parse, > and continues to be ridiculously easy to optimize, > tokenize, and > compress (with static dictionaries). Note that with static > dictionaries, concerns like power consumption are already > thought > about because to even get that analytic computation done > for each > and every message only consumes more power. > > > This is what I can't seem to get across to you. All those > wonderful features of XML are *IRRELEVANT* to the > extensibility of the ADT's primitive types, because the ADT > defines its very limited set of abstract types itself, > directly. The only thing that the ADT's serializations can do > is express those predefined ADT types on the wire. You can't > extend the primitive types in a serialization of the ADT. > > If you were arguing that our ADT's primary type definitions > should be in XML then you would have quite a good point, > because then the types would be both flexible and extensible. > But that's not what we're discussing here. > > > Morgaine. > > > > > ========================== > > On Wed, May 4, 2011 at 7:05 PM, Dzonatas Sol > > >> wrote: > > On 05/04/2011 10:22 AM, Morgaine wrote: > > Let me rephrase it more precisely.� Your responses do not > *demonstrate* understanding of the type model of LLSD + > serializations.� You persist in suggesting that the > extensibility of XML can extend the elementary types of > LLSD, > when it absolutely cannot do that.� I am confident that > you do > understand this, but it hasn't come across yet. > > I recommend leaving XML out of the discussion, because it's > just one out of 3 primary serializations.� Leaving it > out (for > now) will help highlight the non-extensibility of the LLSD > elementary data types. > > > XML is only a more graphic form than ASCII and extended with > common multi-byte format useful to detect network order. > Because > it is human-readable, many miss *that* obvious critical > fact. If > you send XML data, we don't have to worry about the network > order > for whatever abstract data types you make up. > > XML is more than just serialization and mark-up language, > yet this > how people *start* with such concepts. It remains very > useful for > more advanced flows with absolute simplicity to the core to > parse, > and continues to be ridiculously easy to optimize, > tokenize, and > compress (with static dictionaries). Note that with static > dictionaries, concerns like power consumption are already > thought > about because to even get that analytic computation done > for each > and every message only consumes more power. > > You're telling us you want to leave that already > well-thought-critical details out of the discussion when it is > already standardized and already just easily said as "XML"? > > We realize that some implementers made LLSD mean "Linden Lab > Serialized Data", and they wanted JSON instead because it *was* > easily to eval() to parse. (Except now JSON has to avoid > injections just like SQL & perl/php, etc, ...). > > I'm pretty sure the real problem has been DEMONSTRATED with the > implementation(s), especially where you further > demonstrated that > you want to leave out any mention of the extensibility > features in > order to show the problem with non-extensibility. That sounds > familiar. > > > > It's a really fundamental aspect of the ADT that it defines > our types independent of its serializations. �It's a useful > concept, but the problem with this particular one -- LLSD > (DSD?) -- is that the elementary types are neither flexible > nor extensible. > > > Let the VMs define further ADTs. We only need a few > standard data > types. This WG should only be concerned with being able to > document (and clarify) the flow, especially the region-agent > transistions. If the flow uses standard LLSD data types to > define > some complex abstract data type, perfect enough. I wouldn't be > surprised if we add one more LLSD data type for DAEs, as > that may > be the perfect place for it. Then you can go and add any > relevant > extension you want to the DAE, even more abstract data types > within the DAE, and further you don't even have to worry > about it > all being in RFC format. > > > > -- --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, > Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > https://www.ietf.org/mailman/listinfo/vwrap > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Wed May 4 15:42:06 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C0FE06DF for ; Wed, 4 May 2011 15:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.512 X-Spam-Level: X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iev0OFJIhbMZ for ; Wed, 4 May 2011 15:42:05 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id B8C02E06CB for ; Wed, 4 May 2011 15:42:05 -0700 (PDT) Received: by pxi2 with SMTP id 2so1010038pxi.38 for ; Wed, 04 May 2011 15:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gK/yLjRuPmJVVUcWV8/ZSee4gejC4cMLHTYXssDRtGc=; b=XHRWLVFBa8ckVfevh39tCaYTkMhn0oqiUP+TrKhs4TPMfz+xpSKfKLX265QITq1H1T 4TT1mjUyNZGX9EhOTfOWExYgU9LaPfidWvklkX4VrPTynah+kNbZXU+faF8WMPhA9QXY dj/blYHv6JG0/4Ofzf1NkJ1FPE2+z3j9nA9m8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=MKdJh/zQQPtiQ/G+ATMp5lTMr18GOjGVSOLXWn6cNpjXrdur5gy6aVtCABxlekz98d X9/h9YzDlt0QrG2Mt+hXbKXfMVbo5cd+lzt7RPk4JNiMa2cW6Lp4GdBnixf/iQNpj/NT 4nTmXXEK2fW/YMdeVDXGQVHb0yT9YNlAL+7WU= Received: by 10.68.57.209 with SMTP id k17mr2174413pbq.280.1304548925434; Wed, 04 May 2011 15:42:05 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id k7sm1003928pbe.32.2011.05.04.15.42.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2011 15:42:04 -0700 (PDT) Message-ID: <4DC1D5FC.6040608@gmail.com> Date: Wed, 04 May 2011 15:41:00 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Dzonatas Sol References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> In-Reply-To: <4DC1D165.7010705@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Wed, 04 May 2011 22:42:06 -0000 On 05/04/2011 03:21 PM, Dzonatas Sol wrote: > Actually, I invented one tag called that does all the above > already, so how about the predefined embed'ed data type instead of > endless extensibility? > On that NOTE: any more needed extensibility is transistioned into capabilities. Whereas, capabilities means more resources (as dynamic extensions grow); therefore, this requires minimization of number of connections instead of one connection per resource. Thus, that proportion leads into the reason for combined/bundled queries that I have already mentioned and implemented, as maximum # of connections are too easily reached without such mechanism. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Wed May 4 15:59:12 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CBAE0717 for ; Wed, 4 May 2011 15:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPm27q9IbgJa for ; Wed, 4 May 2011 15:59:11 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82CD8E06C7 for ; Wed, 4 May 2011 15:59:11 -0700 (PDT) Received: by qwc23 with SMTP id 23so1345407qwc.31 for ; Wed, 04 May 2011 15:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=aHCpt01UFLRwIHr4BDtlqdcYp4kQusOYvKJMiFvbq0k=; b=sK5ICUTrRJorUtk8KdptKm/wdVGcfdIYFhxuNdPP0STHx9yoVKsRoy97lJlPCqLCLa nwTlpBCVmTzi5xEGWPlq+oOQwjWsZG5sAAPN3zyMGyURzRKOAIAfGMjfbXLvFHveUmZH U5YJPOcdwatUPENV0LA8gBWA9mA9MSoI5qvfk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=GniPJzhcnCdunwVWvnykE/ffRbGlfCbTlJvn9OYqL9bS3yUDC6iRksRHoDCxfw0fOP BKj/U1NIRmYZahnHthW+FvqxpLr3Kq1n82/KDABlyuTqp0/uYFc2JOOW5AenRmRxXHCy cN84jvfqwchF6zJfAcH0LJaaOKyXc8cIvqCSw= MIME-Version: 1.0 Received: by 10.229.119.134 with SMTP id z6mr1335529qcq.63.1304549950597; Wed, 04 May 2011 15:59:10 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Wed, 4 May 2011 15:59:10 -0700 (PDT) In-Reply-To: <4DC1D5FC.6040608@gmail.com> References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> Date: Wed, 4 May 2011 23:59:10 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd5c94e65afdd04a27b3448 Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Wed, 04 May 2011 22:59:12 -0000 --000e0cd5c94e65afdd04a27b3448 Content-Type: text/plain; charset=ISO-8859-1 I have no idea what either of the last list two posts meant. I tried to interpret the preceding post as best I could and to find room for technical discussion, but clearly the attempt has failed. I'll leave it at that. Morgaine. =========================== On Wed, May 4, 2011 at 11:41 PM, Dzonatas Sol wrote: > On 05/04/2011 03:21 PM, Dzonatas Sol wrote: > >> Actually, I invented one tag called that does all the above >> already, so how about the predefined embed'ed data type instead of endless >> extensibility? >> >> > On that NOTE: any more needed extensibility is transistioned into > capabilities. > > Whereas, capabilities means more resources (as dynamic extensions grow); > therefore, this requires minimization of number of connections instead of > one connection per resource. Thus, that proportion leads into the reason for > combined/bundled queries that I have already mentioned and implemented, as > maximum # of connections are too easily reached without such mechanism. > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --000e0cd5c94e65afdd04a27b3448 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have no idea what either of the last list two posts meant.

I tried= to interpret the preceding post as best I could and to find room for techn= ical discussion, but clearly the attempt has failed.

I'll leave = it at that.


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


On Wed, May 4, 2011 at 11:41 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:<= br>
On 05/04/2011 03:21 PM, Dzonatas Sol wrote:
Actually, I invented one tag called <embed> that does all the above a= lready, so how about the predefined embed'ed data type instead of endle= ss extensibility?


On that NOTE: any more needed extensibility is transistioned into capabilit= ies.

Whereas, capabilities means more resources (as dynamic extensions grow); th= erefore, this requires minimization of number of connections instead of one= connection per resource. Thus, that proportion leads into the reason for c= ombined/bundled queries that I have already mentioned and implemented, as m= aximum # of connections are too easily reached without such mechanism.


--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--000e0cd5c94e65afdd04a27b3448-- From vaughn.deluca@gmail.com Wed May 4 23:32:09 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A92E06DD for ; Wed, 4 May 2011 23:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id natzFgMiR+ot for ; Wed, 4 May 2011 23:32:08 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC02E06C0 for ; Wed, 4 May 2011 23:32:08 -0700 (PDT) Received: by eye13 with SMTP id 13so652382eye.31 for ; Wed, 04 May 2011 23:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gAf8n4fl8tPrN/WOKQhNHHppPR37pO//vJ0OqYCKwxI=; b=ixRvi7L07/zoKZA5KopeClDyFhqdi7FmAPsphl3DJR6e/lySCfPwt9iBauF+cqpb2z mdIRCeWUOW4q/jcWgzmlcMYkO93zofekC0UGlOziGbNme9OBtRMDzvhqjW4Fl0qWC9Fq T/XSYo5rxT73/IH0ip2BUKsSH6NfyTN2uj3KY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mHNTNvgWi+Y/P2f7Mwz1SOznq+bqQC3QRt/2TV/4tz2bYKSxcawmI3D4L+k2fqcsXr bQ10a9+fBW/eVgygRYn4KFhiuH/NOzlKCGdjrP6gWlK8Ji2V2qd31VTQwCeOsuAZ2ybr wHzE7BabMqSnZiA6oQgqN+9wMJC7AVSsEaXdU= MIME-Version: 1.0 Received: by 10.213.26.155 with SMTP id e27mr50549ebc.136.1304577127195; Wed, 04 May 2011 23:32:07 -0700 (PDT) Received: by 10.213.30.6 with HTTP; Wed, 4 May 2011 23:32:07 -0700 (PDT) In-Reply-To: References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> Date: Thu, 5 May 2011 08:32:07 +0200 Message-ID: From: Vaughn Deluca To: Morgaine Content-Type: multipart/alternative; boundary=0015174c138e3fa3f804a2818818 Cc: vwrap@ietf.org Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Thu, 05 May 2011 06:32:09 -0000 --0015174c138e3fa3f804a2818818 Content-Type: text/plain; charset=ISO-8859-1 Morgaine, You observe LLSD is not extendable. Dzonatas argues that the this can be solved at a higher level using XML. You object that this entangles the serialisation with basic ADT So what do you suggest is the way forward? - Can LLSD itself be made extensible? -if not, do we have enough commitment in the group to start from scratch? -if not, do the benefits of an absolutely clean engineering solution outweighs the costs of disrupting the already slow progress here? We reach for the sky, but run the risk of over extending our current capabilities. I am all for rigorous design, but i think i prefer actual implementation of an imperfect system over sitting and waiting for an ultimate dream. If we don't get demonstrated commitment for specifying (and implementing!) an alternative, my vote go's to sticking with LLSD, if only to show conclusively were it falls short of our needs. -- Vaughn On Thu, May 5, 2011 at 12:59 AM, Morgaine wrote: > I have no idea what either of the last list two posts meant. > > I tried to interpret the preceding post as best I could and to find room > for technical discussion, but clearly the attempt has failed. > > I'll leave it at that. > > > Morgaine. > > > > =========================== > > > > On Wed, May 4, 2011 at 11:41 PM, Dzonatas Sol wrote: > >> On 05/04/2011 03:21 PM, Dzonatas Sol wrote: >> >>> Actually, I invented one tag called that does all the above >>> already, so how about the predefined embed'ed data type instead of endless >>> extensibility? >>> >>> >> On that NOTE: any more needed extensibility is transistioned into >> capabilities. >> >> Whereas, capabilities means more resources (as dynamic extensions grow); >> therefore, this requires minimization of number of connections instead of >> one connection per resource. Thus, that proportion leads into the reason for >> combined/bundled queries that I have already mentioned and implemented, as >> maximum # of connections are too easily reached without such mechanism. >> >> >> -- >> --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > --0015174c138e3fa3f804a2818818 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Morgaine,

You observe LLSD is not extendable.= Dzonatas argues that the this can be solved at a higher level using XML. = =A0You object that this =A0entangles the serialisation with basic ADT
=

So what do you suggest is the way forward?
- Can L= LSD itself be made extensible?
-if not, do we have enough commitm= ent in the group to start from scratch?
-if not, do the benefits = of an absolutely clean engineering solution outweighs the costs of disrupti= ng the already slow progress here? We reach for the sky, but run the risk o= f over extending our current capabilities.

I am all for rigorous design, but i think i prefer actu= al implementation of an imperfect system over sitting and waiting for an ul= timate dream.
If we don't get demonstrated commitment for spe= cifying (and implementing!) an alternative, my vote go's to sticking wi= th LLSD, if only to show conclusively were it falls short of our needs.

-- Vaughn


On Thu, May 5, 2011 at 12:59 AM, Morgaine <morgaine.dinova@googlemail.com= > wrote:
I have no idea what either of the last list= two posts meant.

I tried to interpret the preceding post as best I = could and to find room for technical discussion, but clearly the attempt ha= s failed.

I'll leave it at that.


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



On Wed, May 4, 2011 at 11:41 PM= , Dzonatas Sol <dzonatas@gmail.com> wrote:
On 05/04/2011 03:2= 1 PM, Dzonatas Sol wrote:
Actually, I invented one tag called <embed> that does all the above a= lready, so how about the predefined embed'ed data type instead of endle= ss extensibility?


On that NOTE: any more needed extensibility is transistioned into capabilit= ies.

Whereas, capabilities means more resources (as dynamic extensions grow); th= erefore, this requires minimization of number of connections instead of one= connection per resource. Thus, that proportion leads into the reason for c= ombined/bundled queries that I have already mentioned and implemented, as m= aximum # of connections are too easily reached without such mechanism.


--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


--0015174c138e3fa3f804a2818818-- From morgaine.dinova@googlemail.com Thu May 5 07:33:24 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A97E067C for ; Thu, 5 May 2011 07:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b01tFmCihUA1 for ; Thu, 5 May 2011 07:33:23 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9B6AE0593 for ; Thu, 5 May 2011 07:33:22 -0700 (PDT) Received: by qwc23 with SMTP id 23so1809333qwc.31 for ; Thu, 05 May 2011 07:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oUlif5ZXI9sFZWUGmceI6AP8aQPe/6iyer0RiYBIyls=; b=heSOGxPeVby1cbVywqnShEXUHAvcrbX9BkIIXb2DHIEUhgbkOoOpkOEmLunk1cULV9 sG5dnOoxLT2Q05CtLrSSglyGBdZp9CSKBRX0zFHedyrUfn0U/hispwSaon2S2oeYLE9J A++51YYLvDpZ/zeXh0atbUFbVtxgt4BYWFnls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Vcy+TxZ2qynAA1sbZqy9G+wrRQE4PrCpD2MDSf2GrpLv9+vwb6cZM4M8hCd1aVX1Pw o9Nsc1sIRLOUzQKxSg2MVaBNi4b+LYhtmlYBCfh2CtNqMOBgUP4Ex6HPzQucJ5QJCtLA pwzcCK1W97wl7augnOU5BIJA6PN2IqFvyvSzU= MIME-Version: 1.0 Received: by 10.224.74.76 with SMTP id t12mr2383929qaj.355.1304606001776; Thu, 05 May 2011 07:33:21 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Thu, 5 May 2011 07:33:21 -0700 (PDT) In-Reply-To: References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> Date: Thu, 5 May 2011 15:33:21 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0015175d015e4ec75104a28841b2 Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Thu, 05 May 2011 14:33:24 -0000 --0015175d015e4ec75104a28841b2 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 5, 2011 at 7:32 AM, Vaughn Deluca wrote: > > So what do you suggest is the way forward? > I suggest the following as a way forward with very little pain or delay: - As other serialization systems have done, add those predefined types that we can easily foresee will be very beneficial to VW applications. That certainly includes all the usual integer types, maybe others. We could agree on a useful set of them today, it's not hard. It wouldn't be perfect, but it would be "our best shot" at supporting what the immediate future requires. It would give our types system added *flexibility*, and its extra *efficiency* would improve the performance of our binary serializations. - As Carlo has suggested in the past, add a version negotiation system so that when VW projects find our 2011 set of base types inadequate, they can evolve the types system and negotiate use of a newer one dynamically at protocol initiation time, without needing to come back to the IETF. This would give us a measure of *extensibility* without needing to make our initial elementary types extensible. - Can LLSD itself be made extensible? > > It can be made extensible, yes, but with this group's track record of continually saying "No" even to simple technical advances, I would not want to be an advocate for more complex extensible base types. Instead, I'll make do with Carlo's approach, ie. extensibility through negotiating alternative versions. > > I am all for rigorous design, but i think i prefer actual implementation of > an imperfect system over sitting and waiting for an ultimate dream. > If we don't get demonstrated commitment for specifying (and implementing!) > an alternative, my vote go's to sticking with LLSD, if only to show > conclusively were it falls short of our needs. > > Which is why I suggest that we do no more than add those types that we can envisage being needed in designs *today*, without speculating about tomorrow. Such flexibility is the least we can do while pretending to be "designing for the future". If we go forward with a design that *WE KNOW FULL WELL* is inflexible and inefficient through providing only a single integer type, then we cannot pretend to be designing for the future at all, it's designing for a specific application today. > > I am all for rigorous design, but i think i prefer actual implementation of > an imperfect system over sitting and waiting for an ultimate dream. > If we don't get demonstrated commitment for specifying (and implementing!) > an alternative, my vote go's to sticking with LLSD, if only to show > conclusively were it falls short of our needs. > There is no point going through all this IETF effort just to produce a protocol that we know is designed for today, without even a nod for the future. It will be obsolete before it's released. If we did so in ignorance, fine, we would deserve to be ignored by future VW designers who will find our design skills so lacking in future vision. But we would not be doing so in ignorance. Others in this group have commented on the lack of future proofing in LLSD too, not just myself. We would be rolling out a poor types system with our eyes wide open, despite being made aware of its lack of flexibility and extensibility. Future VW designers won't have any sympathy at all, we will be laughed at and condemned as knowingly regressive. And they would be right. I do not believe that this group is so technically incompetent that we can't produce a types system with a measure of flexibility and extensibility (through negotiation at least). What we do clearly suffer from is extreme inertia and resistance from some participants with a regressive outlook on protocol design, so much so that you're suggesting that we move forward with a known inflexible system just because of our people problems here. Well I can't help that. I've been doing my bit for pulling the cart into the future, despite intense opposition. That's how engineering advances are made, by always designing for tomorrow. I wish a few more people here would help with that. Morgaine. ======================== On Thu, May 5, 2011 at 7:32 AM, Vaughn Deluca wrote: > Morgaine, > > You observe LLSD is not extendable. Dzonatas argues that the this can be > solved at a higher level using XML. You object that this entangles the > serialisation with basic ADT > > So what do you suggest is the way forward? > - Can LLSD itself be made extensible? > -if not, do we have enough commitment in the group to start from scratch? > -if not, do the benefits of an absolutely clean engineering solution > outweighs the costs of disrupting the already slow progress here? We reach > for the sky, but run the risk of over extending our current capabilities. > > I am all for rigorous design, but i think i prefer actual implementation of > an imperfect system over sitting and waiting for an ultimate dream. > If we don't get demonstrated commitment for specifying (and implementing!) > an alternative, my vote go's to sticking with LLSD, if only to show > conclusively were it falls short of our needs. > > -- Vaughn > > > On Thu, May 5, 2011 at 12:59 AM, Morgaine wrote: > >> I have no idea what either of the last list two posts meant. >> >> I tried to interpret the preceding post as best I could and to find room >> for technical discussion, but clearly the attempt has failed. >> >> I'll leave it at that. >> >> >> Morgaine. >> >> >> >> =========================== >> >> >> >> On Wed, May 4, 2011 at 11:41 PM, Dzonatas Sol wrote: >> >>> On 05/04/2011 03:21 PM, Dzonatas Sol wrote: >>> >>>> Actually, I invented one tag called that does all the above >>>> already, so how about the predefined embed'ed data type instead of endless >>>> extensibility? >>>> >>>> >>> On that NOTE: any more needed extensibility is transistioned into >>> capabilities. >>> >>> Whereas, capabilities means more resources (as dynamic extensions grow); >>> therefore, this requires minimization of number of connections instead of >>> one connection per resource. Thus, that proportion leads into the reason for >>> combined/bundled queries that I have already mentioned and implemented, as >>> maximum # of connections are too easily reached without such mechanism. >>> >>> >>> -- >>> --- https://twitter.com/Dzonatas_Sol --- >>> Web Development, Software Engineering, Virtual Reality, Consultant >>> >>> _______________________________________________ >>> vwrap mailing list >>> vwrap@ietf.org >>> https://www.ietf.org/mailman/listinfo/vwrap >>> >> >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > --0015175d015e4ec75104a28841b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, May 5, 2011 at 7:32 AM, Vaughn Deluca <vaughn.deluca@gmail.com> = wrote:

So what do you suggest is the way forward?


I suggest the following as a way forward with very little pai= n or delay:

  • As other serialization systems have done, add th= ose predefined types that we can easily foresee will be very beneficial to = VW applications.=A0 That certainly includes all the usual integer types, ma= ybe others.=A0 We could agree on a useful set of them today, it's not h= ard.=A0 It wouldn't be perfect, but it would be "our best shot&quo= t; at supporting what the immediate future requires.=A0 It would give our t= ypes system added flexibility, and its extra efficiency would= improve the performance of our binary serializations.
  • As Carlo has suggested in the past, add a version negotia= tion system so that when VW projects find our 2011 set of base types inadeq= uate, they can evolve the types system and negotiate use of a newer one dyn= amically at protocol initiation time, without needing to come back to the I= ETF.=A0 This would give us a measure of extensibility without needin= g to make our initial elementary types extensible.

- Can LLSD itself be made extensible?

It can be made extensible, yes, but with this group's track re= cord of continually saying "No" even to simple technical advances= , I would not want to be an advocate for more complex extensible base types= .=A0 Instead, I'll make do with Carlo's approach, ie. extensibility= through negotiating alternative versions.
=A0
I am all for rigorous design, but i think i prefer=20 actual implementation of an imperfect system over sitting and waiting=20 for an ultimate dream.
If we don't get demonstrated commitmen= t for specifying (and implementing!) an alternative, my vote go's to=20 sticking with LLSD, if only to show conclusively were it falls short of=20 our needs.


Which is why I suggest that we do no = more than add those types that we can envisage being needed in designs t= oday, without speculating about tomorrow.=A0 Such flexibility is the le= ast we can do while pretending to be "designing for the future".= =A0 If we go forward with a design that WE KNOW FULL WELL is inflexi= ble and inefficient through providing only a single integer type, then we c= annot pretend to be designing for the future at all, it's designing for= a specific application today.
=A0

I am all for rigorous design, but i think i prefer=20 actual implementation of an imperfect system over sitting and waiting=20 for an ultimate dream.
If we don't get demonstrated commitmen= t for specifying (and implementing!) an alternative, my vote go's to=20 sticking with LLSD, if only to show conclusively were it falls short of=20 our needs.


There is no point going through all th= is IETF effort just to produce a protocol that we know is designed for toda= y, without even a nod for the future.=A0 It will be obsolete before it'= s released.

If we did so in ignorance, fine, we would deserve to be ignored by futu= re VW designers who will find our design skills so lacking in future vision= .=A0 But we would not be doing so in ignorance.=A0 Others in this group hav= e commented on the lack of future proofing in LLSD too, not just myself.=A0= We would be rolling out a poor types system with our eyes wide open, despi= te being made aware of its lack of flexibility and extensibility.=A0 Future= VW designers won't have any sympathy at all, we will be laughed at and= condemned as knowingly regressive.=A0 And they would be right.

I do not believe that this group is so technically incompetent that we = can't produce a types system with a measure of flexibility and extensib= ility (through negotiation at least).=A0 What we do clearly suffer from is = extreme inertia and resistance from some participants with a regressive out= look on protocol design, so much so that you're suggesting that we move= forward with a known inflexible system just because of our people problems= here.

Well I can't help that.=A0 I've been doing my bit for pulling t= he cart into the future, despite intense opposition.=A0 That's how engi= neering advances are made, by always designing for tomorrow.=A0 I wish a fe= w more people here would help with that.


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Thu, Ma= y 5, 2011 at 7:32 AM, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
Morgaine,

You observe LLSD is not extendable. Dzonatas argues = that the this can be solved at a higher level using XML. =A0You object that= this =A0entangles the serialisation with basic ADT

So what do you suggest is the way forward?
- Can L= LSD itself be made extensible?
-if not, do we have enough commitm= ent in the group to start from scratch?
-if not, do the benefits = of an absolutely clean engineering solution outweighs the costs of disrupti= ng the already slow progress here? We reach for the sky, but run the risk o= f over extending our current capabilities.

I am all for rigorous design, but i think i prefer actu= al implementation of an imperfect system over sitting and waiting for an ul= timate dream.
If we don't get demonstrated commitment for spe= cifying (and implementing!) an alternative, my vote go's to sticking wi= th LLSD, if only to show conclusively were it falls short of our needs.

-- Vaughn


On T= hu, May 5, 2011 at 12:59 AM, Morgaine <morgaine.dinova@google= mail.com> wrote:
I have no idea wh= at either of the last list two posts meant.

I tried to interpret the= preceding post as best I could and to find room for technical discussion, = but clearly the attempt has failed.

I'll leave it at that.


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


=
On Wed, May 4, 2011 at 11:41 PM, Dzonatas So= l <dzonatas@gmail.com> wrote:
On 05/04/201= 1 03:21 PM, Dzonatas Sol wrote:
Actually, I invented one tag called <embed> that does all the above a= lready, so how about the predefined embed'ed data type instead of endle= ss extensibility?


On that NOTE: any more needed extensibility is transistioned into capabilit= ies.

Whereas, capabilities means more resources (as dynamic extensions grow); th= erefore, this requires minimization of number of connections instead of one= connection per resource. Thus, that proportion leads into the reason for c= ombined/bundled queries that I have already mentioned and implemented, as m= aximum # of connections are too easily reached without such mechanism.


--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap



--0015175d015e4ec75104a28841b2-- From dzonatas@gmail.com Thu May 5 08:00:41 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688FEE0689 for ; Thu, 5 May 2011 08:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=-1.549, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666, SARE_LWFORWARD=1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGl-t10SDSpN for ; Thu, 5 May 2011 08:00:40 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C87DFE0593 for ; Thu, 5 May 2011 08:00:40 -0700 (PDT) Received: by pzk5 with SMTP id 5so1306808pzk.31 for ; Thu, 05 May 2011 08:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=PM8B2dT8hkdt4WL2qGXm+88Uu+nb16TVUlbiN7xGwS0=; b=bPnqtsovNZijoExrsr8x53ytZptWP8fUgW9t81Lza8ie4cwvoAagUHz5ECqdxm7B9f XB4DMxrHJ9/hHFNWKRrpZixhtpFG7m2jBdm9UgXZ0urxsTWtE3todjHvkdcrq1+BjAdD +tOv+6Lqhw3ec078atc9poQv2RSLwQ5cdzM1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=T26XsBpt8x/JtqUDM/i3ZtUTPGb/5Dyipqoanzqw0VYjD7D8LlcIGc/oc2T4XIF392 g7ZnW1TF5FF3tSY93lqRzLnudatnK7dPqZ1VK9nBOCojotBDLfDGzwv8T0yJwFD0UxxG xOIDiqcDYIJ9DcS4nA/jAkSPrwGvzY1ucuE7o= Received: by 10.142.165.14 with SMTP id n14mr1272896wfe.109.1304607640285; Thu, 05 May 2011 08:00:40 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id w14sm2889329wfh.20.2011.05.05.08.00.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 May 2011 08:00:39 -0700 (PDT) Message-ID: <4DC2BB58.4080005@gmail.com> Date: Thu, 05 May 2011 07:59:36 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: "vwrap@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [vwrap] note well: forward-looking statements X-BeenThere: vwrap@ietf.org 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: Thu, 05 May 2011 15:00:41 -0000 I have neither intended to kill VWRAP nor wash my hand clean of such work in progress. Let me make sure others are aware before they make choices about their assets. This next summarized statement helps interested corporations in their independent action. > Certain statements [in writ] that are not historical facts are "forward-looking statements" > within the meaning of the Private Securities Litigation Reform Act of 1995. Such > statements may be identified by the use of words such as "anticipate, "believe," "expect," > "future," "may," "will," "would," "should," "plan," "projected," "potential," "intend," and > similar expressions." IETF doesn't appear to ignore that even if the world-wide community does not follow U.S. S.E.C. The scale of polymerization may be unfamiliar to all members. Taint ideology is still useful to convey proven concepts, and so is the work in progress. I appreciate the effort and tools provided by the IETF... thank you! -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From vaughn.deluca@gmail.com Thu May 5 23:52:19 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A81CE069C for ; Thu, 5 May 2011 23:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOkSn9Ic8sK7 for ; Thu, 5 May 2011 23:52:18 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2BEE0663 for ; Thu, 5 May 2011 23:52:16 -0700 (PDT) Received: by ewy19 with SMTP id 19so1028759ewy.31 for ; Thu, 05 May 2011 23:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+rHsezkRxb7uPq406b8nAnH9as0R/zC16XrZgchznak=; b=xWQ99FMRN5mlm122QcPsT4PQ0gzJhe/FLdixb+5dJKdp5qHCEgbEe2xT5xCgZiUcC/ UxvFC0Or5VjIenEXyBFpbeeLwSzE1HTW1q/X4VZhxF7XLfuEavejvMDwwpU5JiLAu/q8 qyFV59unAe3gGHGmy9niZ3wzmMTgiSFWwXYZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TVrO/+jGCg7eF5n9qc64e13nyRvt7pnIRgWcfd0145ZlXbIVkOnfPY9Tc6IRS9VpGR Or+i/wYOZ2WZf+IuuD1IqZJ0Oamn7Bt9U+AXUUWje4zXT6m12sSts9d6bK4pY/nLKhAP Esof4A3yPvWArYjPALwcczP5nEhAV1xQJIau4= MIME-Version: 1.0 Received: by 10.213.23.7 with SMTP id p7mr657180ebb.60.1304664410663; Thu, 05 May 2011 23:46:50 -0700 (PDT) Received: by 10.213.30.6 with HTTP; Thu, 5 May 2011 23:46:50 -0700 (PDT) In-Reply-To: References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> Date: Fri, 6 May 2011 08:46:50 +0200 Message-ID: From: Vaughn Deluca To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0015174c3f6ebfaa4304a295da4c Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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 06:52:19 -0000 --0015174c3f6ebfaa4304a295da4c Content-Type: text/plain; charset=ISO-8859-1 Morgaine, vwrap, Your proposal sounds good, and a lot more workable than starting from scratch. However you wrote earlier: > Indeed, in the early days of our IETF effort, we spent months discussing the > width of integers in LLSD because there was only one width allowed and it was > hardwired in the spec. What were the reasons to allow onl a single integer type? There must have been a good arguments for that? Up til now i saw suggestions for adding more integer types and for adding a stream buffer type. I think we should aim for keeping the set of additions as small as possible. You suggest to add "all the usual integer types and maybe others", what would those other types be? Are you thinking of Dzonatas' his stream buffer type, or something else? The version negotiation system seems to be orthogonal to adding extra types to LLSD, i think we should try and reach consensus on the data types first. It indeed looks like this can be done with very little pain or delay. -- Vaughn On Thu, May 5, 2011 at 4:33 PM, Morgaine wrote: > On Thu, May 5, 2011 at 7:32 AM, Vaughn Deluca wrote: > >> >> So what do you suggest is the way forward? >> > > > I suggest the following as a way forward with very little pain or delay: > > > - As other serialization systems have done, add those predefined types > that we can easily foresee will be very beneficial to VW applications. That > certainly includes all the usual integer types, maybe others. We could > agree on a useful set of them today, it's not hard. It wouldn't be perfect, > but it would be "our best shot" at supporting what the immediate future > requires. It would give our types system added *flexibility*, and its > extra *efficiency* would improve the performance of our binary > serializations. > > > - As Carlo has suggested in the past, add a version negotiation system > so that when VW projects find our 2011 set of base types inadequate, they > can evolve the types system and negotiate use of a newer one dynamically at > protocol initiation time, without needing to come back to the IETF. This > would give us a measure of *extensibility* without needing to make our > initial elementary types extensible. > > > - Can LLSD itself be made extensible? >> >> > It can be made extensible, yes, but with this group's track record of > continually saying "No" even to simple technical advances, I would not want > to be an advocate for more complex extensible base types. Instead, I'll > make do with Carlo's approach, ie. extensibility through negotiating > alternative versions. > > >> >> I am all for rigorous design, but i think i prefer actual implementation >> of an imperfect system over sitting and waiting for an ultimate dream. >> If we don't get demonstrated commitment for specifying (and implementing!) >> an alternative, my vote go's to sticking with LLSD, if only to show >> conclusively were it falls short of our needs. >> >> > Which is why I suggest that we do no more than add those types that we can > envisage being needed in designs *today*, without speculating about > tomorrow. Such flexibility is the least we can do while pretending to be > "designing for the future". If we go forward with a design that *WE KNOW > FULL WELL* is inflexible and inefficient through providing only a single > integer type, then we cannot pretend to be designing for the future at all, > it's designing for a specific application today. > > >> >> I am all for rigorous design, but i think i prefer actual implementation >> of an imperfect system over sitting and waiting for an ultimate dream. >> If we don't get demonstrated commitment for specifying (and implementing!) >> an alternative, my vote go's to sticking with LLSD, if only to show >> conclusively were it falls short of our needs. >> > > > There is no point going through all this IETF effort just to produce a > protocol that we know is designed for today, without even a nod for the > future. It will be obsolete before it's released. > > If we did so in ignorance, fine, we would deserve to be ignored by future > VW designers who will find our design skills so lacking in future vision. > But we would not be doing so in ignorance. Others in this group have > commented on the lack of future proofing in LLSD too, not just myself. We > would be rolling out a poor types system with our eyes wide open, despite > being made aware of its lack of flexibility and extensibility. Future VW > designers won't have any sympathy at all, we will be laughed at and > condemned as knowingly regressive. And they would be right. > > I do not believe that this group is so technically incompetent that we > can't produce a types system with a measure of flexibility and extensibility > (through negotiation at least). What we do clearly suffer from is extreme > inertia and resistance from some participants with a regressive outlook on > protocol design, so much so that you're suggesting that we move forward with > a known inflexible system just because of our people problems here. > > Well I can't help that. I've been doing my bit for pulling the cart into > the future, despite intense opposition. That's how engineering advances are > made, by always designing for tomorrow. I wish a few more people here would > help with that. > > > Morgaine. > > > > ======================== > > > On Thu, May 5, 2011 at 7:32 AM, Vaughn Deluca wrote: > >> Morgaine, >> >> You observe LLSD is not extendable. Dzonatas argues that the this can be >> solved at a higher level using XML. You object that this entangles the >> serialisation with basic ADT >> >> So what do you suggest is the way forward? >> - Can LLSD itself be made extensible? >> -if not, do we have enough commitment in the group to start from scratch? >> -if not, do the benefits of an absolutely clean engineering solution >> outweighs the costs of disrupting the already slow progress here? We reach >> for the sky, but run the risk of over extending our current capabilities. >> >> I am all for rigorous design, but i think i prefer actual implementation >> of an imperfect system over sitting and waiting for an ultimate dream. >> If we don't get demonstrated commitment for specifying (and implementing!) >> an alternative, my vote go's to sticking with LLSD, if only to show >> conclusively were it falls short of our needs. >> >> -- Vaughn >> >> >> On Thu, May 5, 2011 at 12:59 AM, Morgaine > > wrote: >> >>> I have no idea what either of the last list two posts meant. >>> >>> I tried to interpret the preceding post as best I could and to find room >>> for technical discussion, but clearly the attempt has failed. >>> >>> I'll leave it at that. >>> >>> >>> Morgaine. >>> >>> >>> >>> =========================== >>> >>> >>> >>> On Wed, May 4, 2011 at 11:41 PM, Dzonatas Sol wrote: >>> >>>> On 05/04/2011 03:21 PM, Dzonatas Sol wrote: >>>> >>>>> Actually, I invented one tag called that does all the above >>>>> already, so how about the predefined embed'ed data type instead of endless >>>>> extensibility? >>>>> >>>>> >>>> On that NOTE: any more needed extensibility is transistioned into >>>> capabilities. >>>> >>>> Whereas, capabilities means more resources (as dynamic extensions grow); >>>> therefore, this requires minimization of number of connections instead of >>>> one connection per resource. Thus, that proportion leads into the reason for >>>> combined/bundled queries that I have already mentioned and implemented, as >>>> maximum # of connections are too easily reached without such mechanism. >>>> >>>> >>>> -- >>>> --- https://twitter.com/Dzonatas_Sol --- >>>> Web Development, Software Engineering, Virtual Reality, Consultant >>>> >>>> _______________________________________________ >>>> vwrap mailing list >>>> vwrap@ietf.org >>>> https://www.ietf.org/mailman/listinfo/vwrap >>>> >>> >>> >>> _______________________________________________ >>> vwrap mailing list >>> vwrap@ietf.org >>> https://www.ietf.org/mailman/listinfo/vwrap >>> >>> >> > --0015174c3f6ebfaa4304a295da4c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Morgaine, vwrap,

=A0Your proposal sounds good= , and =A0a lot more workable than starting from scratch. =A0However you wro= te earlier:
=A0
> Indeed, in the early days of o= ur IETF effort, we spent months discussing the=A0
> width of integers in LLSD because there was only one width allowe= d and it was=A0
> hardwired in the spec.

<= div>What were the reasons to allow onl a single integer type? There must ha= ve been a good arguments for that?=A0

Up til now i saw suggestions for adding more integer ty= pes and for adding a stream buffer type.=A0
I think we should aim= for keeping the set of additions as small as possible.
You sugge= st to add "all the=A0usual integer types and maybe others", what woul= d those other types be?
Are you thinking of Dzonatas' his stream buffer type, or somethi= ng else?

The=A0version negotiation system seems to be orthogonal to adding = extra types to LLSD, i think we should =A0try and reach consensus on the da= ta types first.=A0It indeed looks like this can be done=A0with very little = pain or delay.

-- Vaughn


On Thu, May 5, 2011 at 4:33 PM, Morgaine <morgaine.dinova@googlemail.co= m> wrote:
On Thu, May 5, 2011 at 7:= 32 AM, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:<= br>

So what do you suggest is the way forward?


I suggest the following as a way forward with very litt= le pain or delay:

  • As other serialization systems have done, = add those predefined types that we can easily foresee will be very benefici= al to VW applications.=A0 That certainly includes all the usual integer typ= es, maybe others.=A0 We could agree on a useful set of them today, it's= not hard.=A0 It wouldn't be perfect, but it would be "our best sh= ot" at supporting what the immediate future requires.=A0 It would give= our types system added flexibility, and its extra efficiency= would improve the performance of our binary serializations.
  • As Carlo has suggested in the past, add a version negotia= tion system so that when VW projects find our 2011 set of base types inadeq= uate, they can evolve the types system and negotiate use of a newer one dyn= amically at protocol initiation time, without needing to come back to the I= ETF.=A0 This would give us a measure of extensibility without needin= g to make our initial elementary types extensible.

- Can LLSD itself be made extensib= le?


It can be made extensible, yes, but with this group's tr= ack record of continually saying "No" even to simple technical ad= vances, I would not want to be an advocate for more complex extensible base= types.=A0 Instead, I'll make do with Carlo's approach, ie. extensi= bility through negotiating alternative versions.
=A0

I am all for rigorous design, but i think i prefer= =20 actual implementation of an imperfect system over sitting and waiting=20 for an ultimate dream.
If we don't get demonstrated commitmen= t for specifying (and implementing!) an alternative, my vote go's to=20 sticking with LLSD, if only to show conclusively were it falls short of=20 our needs.


Which is why I suggest that we = do no more than add those types that we can envisage being needed in design= s today, without speculating about tomorrow.=A0 Such flexibility is = the least we can do while pretending to be "designing for the future&q= uot;.=A0 If we go forward with a design that WE KNOW FULL WELL is in= flexible and inefficient through providing only a single integer type, then= we cannot pretend to be designing for the future at all, it's designin= g for a specific application today.
=A0

I am all for rigorous design, but i think i pre= fer=20 actual implementation of an imperfect system over sitting and waiting=20 for an ultimate dream.
If we don't get demonstrated commitmen= t for specifying (and implementing!) an alternative, my vote go's to=20 sticking with LLSD, if only to show conclusively were it falls short of=20 our needs.


There is no point going through = all this IETF effort just to produce a protocol that we know is designed fo= r today, without even a nod for the future.=A0 It will be obsolete before i= t's released.

If we did so in ignorance, fine, we would deserve to be ignored by futu= re VW designers who will find our design skills so lacking in future vision= .=A0 But we would not be doing so in ignorance.=A0 Others in this group hav= e commented on the lack of future proofing in LLSD too, not just myself.=A0= We would be rolling out a poor types system with our eyes wide open, despi= te being made aware of its lack of flexibility and extensibility.=A0 Future= VW designers won't have any sympathy at all, we will be laughed at and= condemned as knowingly regressive.=A0 And they would be right.

I do not believe that this group is so technically incompetent that we = can't produce a types system with a measure of flexibility and extensib= ility (through negotiation at least).=A0 What we do clearly suffer from is = extreme inertia and resistance from some participants with a regressive out= look on protocol design, so much so that you're suggesting that we move= forward with a known inflexible system just because of our people problems= here.

Well I can't help that.=A0 I've been doing my bit for pulling t= he cart into the future, despite intense opposition.=A0 That's how engi= neering advances are made, by always designing for tomorrow.=A0 I wish a fe= w more people here would help with that.


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=
On Thu, May 5, 2011 at 7:32 AM, Vaughn Deluc= a <vaughn.deluca@gmail.com> wrote:
Morgaine,

You observe LLSD is not extendable. Dzonatas argues that t= he this can be solved at a higher level using XML. =A0You object that this = =A0entangles the serialisation with basic ADT

So what do you suggest is the way forward?
- Can L= LSD itself be made extensible?
-if not, do we have enough commitm= ent in the group to start from scratch?
-if not, do the benefits = of an absolutely clean engineering solution outweighs the costs of disrupti= ng the already slow progress here? We reach for the sky, but run the risk o= f over extending our current capabilities.

I am all for rigorous design, but i think i prefer actu= al implementation of an imperfect system over sitting and waiting for an ul= timate dream.
If we don't get demonstrated commitment for spe= cifying (and implementing!) an alternative, my vote go's to sticking wi= th LLSD, if only to show conclusively were it falls short of our needs.

-- Vaughn


On Thu, May 5, 20= 11 at 12:59 AM, Morgaine <morgaine.dinova@googlemail.com&= gt; wrote:
I have no idea what eit= her of the last list two posts meant.

I tried to interpret the prece= ding post as best I could and to find room for technical discussion, but cl= early the attempt has failed.

I'll leave it at that.


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


=
On Wed, May 4, 2011 at 11:41 PM, Dzonatas So= l <dzonatas@gmail.com> wrote:
On 05/04/2011 03:2= 1 PM, Dzonatas Sol wrote:
Actually, I invented one tag called <embed> that does all the above a= lready, so how about the predefined embed'ed data type instead of endle= ss extensibility?


On that NOTE: any more needed extensibility is transistioned into capabilit= ies.

Whereas, capabilities means more resources (as dynamic extensions grow); th= erefore, this requires minimization of number of connections instead of one= connection per resource. Thus, that proportion leads into the reason for c= ombined/bundled queries that I have already mentioned and implemented, as m= aximum # of connections are too easily reached without such mechanism.


--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap




--0015174c3f6ebfaa4304a295da4c-- From josh@lindenlab.com Fri May 6 09:19:04 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E150FE0726 for ; Fri, 6 May 2011 09:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: 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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBks7jB2E3Z3 for ; Fri, 6 May 2011 09:19:04 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (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 10.142.142.17 with SMTP id p17mr1963933wfd.77.1304698743186; Fri, 06 May 2011 09:19:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.165.9 with HTTP; Fri, 6 May 2011 09:18:43 -0700 (PDT) In-Reply-To: References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> From: Joshua Bell Date: Fri, 6 May 2011 09:18:43 -0700 Message-ID: To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd212e820668304a29dd989 Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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 --000e0cd212e820668304a29dd989 Content-Type: text/plain; charset=UTF-8 On Thu, May 5, 2011 at 11:46 PM, Vaughn Deluca 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 types. 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 --000e0cd212e820668304a29dd989 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, May 5, 2011 at 11:46 PM, Vaughn Deluca <vaughn.deluca@gmail.com>= wrote:

What were the reasons to allow onl a single integer typ= e? There must have been a good arguments for that?=C2=A0
=

IIRC, some of the languages we wished to support (Pytho= n comes to mind) did not have support for integers larger than 32-bits. ECM= AScript doesn't have integer number types at all only IEEE 754 64-bit f= loats; if you constrain the input and output to 32-bit integers it can repr= esent those accurately, but not 64-bit integers.

If you look at the history of LLSD, it started with 3 s= erialization formats that explicitly specified the type of values - XML, bi= nary, 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 i= nterpreted as a date by the receiver results in the original Date by the st= ring->date conversion rules. (I don't know if we had resolved every = issue with JSON serialization; certainly, discussion about edge cases on th= is list never made it into a draft).

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

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

-- Josh

--000e0cd212e820668304a29dd989-- From dzonatas@gmail.com Fri May 6 13:35:35 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73758E07DA for ; Fri, 6 May 2011 13:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.657 X-Spam-Level: X-Spam-Status: No, score=-3.657 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCxya0rnv1-m for ; Fri, 6 May 2011 13:35:34 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C2F79E07D1 for ; Fri, 6 May 2011 13:35:34 -0700 (PDT) Received: by pzk5 with SMTP id 5so2058729pzk.31 for ; Fri, 06 May 2011 13:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=86xvQrYR7puqak+3NGUWmfr0GiMC0FHtjN2KKaaKnUU=; b=Ncb7aWUtkU2zYn2xQSEnAUSR7npzN5DeOaoaMaWrWiJr1yu7inF0k/QXb9kGJw2rVb QExdMIgM3P+D5unjemwC7ACYULsq6W2ZP6i5j4Ozi3tYpa9AjNWK18wadOsAnOijM59q F93vVCkMQuJWw7uny8uOW/f4RbrfJwEFoBTsI= 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=bs1CZugkXvwY++q8WDQVbp3KC/C5lHAy95/HL6xgrZ8TBHlWeBqsyLBoS2jdQwyWvr CvawZR0EeG9Gl+ymHfZ+7JxDBkKq2YUSHH6ECpcSf0hbA8NjXaGbEdy8k7IlYUyOiUry k6OtsiueJBrfB4j1XqDodkTj0zn1tKpXRwVt8= Received: by 10.68.59.73 with SMTP id x9mr5160990pbq.452.1304714134466; Fri, 06 May 2011 13:35:34 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id g5sm2347118pbj.62.2011.05.06.13.35.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 May 2011 13:35:33 -0700 (PDT) Message-ID: <4DC45B56.1020604@gmail.com> Date: Fri, 06 May 2011 13:34:30 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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 20:35:35 -0000 On 05/06/2011 09:18 AM, Joshua Bell wrote: > > 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. +1 Or, Content-Type: application/llsd+1+xml Or, Content-Type: application/llsd++xml Or, Content-Type: xml-ietf-vwrap/llsd+adt+extra ...etc, would work yet I believe - and + still are transient denotations for with or without DTD, so... Content-Type: xml-ietf-vwrap/urn:[bank]:llsd.proxy.net:map,abstract,... Yes, LLSD as-is continues to work even without excessive headers. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Fri May 6 21:37:40 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE07E0736 for ; Fri, 6 May 2011 21:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mgEiFZ556YA for ; Fri, 6 May 2011 21:37:37 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3BBE072D for ; Fri, 6 May 2011 21:37:36 -0700 (PDT) Received: by qwc23 with SMTP id 23so2844705qwc.31 for ; Fri, 06 May 2011 21:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ihtxx+ngd92iwEl/hOUP8E33k+rMgneeuknoBb3gIxM=; b=Br179tRK5T2wsCsgqhp2Mv0XakSY9NsTUglIY/ctw6AHGNkg4wKrd54qTDAYcUN7NC ivBPbHMms9lacmxoiRQDbW2CIjz4E7OBPuT2EF4PwyuUqMIx4dMeJX+xzypmpns2LLUi KTgqKJvb5jLiXoRABRNRJzPGatLYswRtO+oVY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=em24KRCUtLTVcB+gGnxAAen92gk7D/2rSupsMgJTPXIAxO4Z4TmgV72Hn6aZiWWU2Z Kb4A+6NXXZ07IVpP+kPte51+q6JMNlwEuK3C/PrNt+c/LpehmCMekZcc/bRVGJR6t8pV qlsjZvLw3Qy4KvSxV8P58wZg02+fDUw5QwSJA= MIME-Version: 1.0 Received: by 10.229.119.134 with SMTP id z6mr1448233qcq.63.1304743055086; Fri, 06 May 2011 21:37:35 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Fri, 6 May 2011 21:37:34 -0700 (PDT) In-Reply-To: References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> Date: Sat, 7 May 2011 05:37:34 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd5c94e525e4d04a2a82ae4 Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sat, 07 May 2011 04:37:40 -0000 --000e0cd5c94e525e4d04a2a82ae4 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 6, 2011 at 7:46 AM, Vaughn Deluca wrote: > Morgaine, > > Your proposal sounds good, and a lot more workable than starting from > scratch. However you wrote earlier: > > > Indeed, in the early days of our IETF effort, we spent months discussing > the > > width of integers in LLSD because there was only one width allowed and it > was > > hardwired in the spec. > > What were the reasons to allow onl a single integer type? There must have > been a good arguments for that? > > Joshua has replied about the history of it, but I'd like to reply about its future. When you create an ADT system and expect it to have multiple language bindings, then you should not base your ADT's set of primitive types on your initial choice of languages, because that introduces several very poor consequences: - It reduces your set of primitive types to the lowest common denominator of types directly supported by your initial set of languages, and hence makes your ADT system a very narrow one, the opposite of "flexible type system". - It makes those initial language bindings "special" because they have been given special consideration, whereas further language bindings won't enjoy similar support as design targets. That's not designing for the future. - It makes application developers repeatedly pay the penalty for not having specific types directly suited to their application, a continuing cost. - It places the burden of type poverty on all language bindings instead of only on the language that is type-inadequate. Better languages have to suffer the penalty of an inferior one in their midst. - The lack of the shortest integer types impacts on binary serializations especially severely. While all serializations are rendered less efficient when they are forced to use a single generic integer type, it is the binary serialization that is impacted most. This is both unhelpful and ironic, since it is the binary serialization that is chosen when you want the most efficiency. It is the worst possible outcome that the binary serialization is affected worst. - By requiring your most efficient language bindings (C/C++) to use fixed length integers instead of those that they employ internally, it reduces their efficiency disproportionately every time they cross the binding boundary. Less efficient languages won't notice any slowdown because the loss of binding efficiency is masked by their overheads, whereas C/C++ have virtually no overheads and so are impacted most. This is the wrong way around, namely designing to benefit the least efficient use case. So given quite a number of negative consequences, what's the actual benefit of taking the design approach described by Joshua? Well allegedly it's so that the initial set of languages can all represent the primitive data types of the ADT directly, but I dispute that that goal has any merit in practice. First of all, tying your design to the type and representational poverty of Python and ECMAScript misses the point that your most efficient scalable server systems are not likely to be written in them. Clients may be written in less efficient languages, but inefficiencies in clients don't impact on system scalability because all those inefficiencies occur in parallel. It's the efficiency of server side that matters far more when designing efficient scalable systems, so server side requirements should be considered first. (Then bandwidth requirements next, and client requirements last.) Secondly, it makes no sense to limit the primitive types transported by a protocol to those which slow languages like Python and ECMAScript can represent, because the overheads inherent in those languages vastly outweigh any impact from protocol-language mismatch. What's more, those languages are not prevented from using their internal representations just because a protocol provides shorter integers for efficiency, so it is not a valid argument that supporting Python and ECMAScript precludes using shorter types in the protocol. That's just incorrect. And thirdly, having to use a single size of integer for all purposes introduces semantic problems which we alluded to quite recently when discussing Service Level Semantic Interoperability -- http://www.ietf.org/mail-archive/web/vwrap/current/msg00657.html . It's a very bad approach at the best of times, in effect a loss of type information for everything that is integral but is not 32 bits in length. It results in additional value bounds checking in the application to eliminate inappropriate values arriving within the single-length protocol field, since the protocol provides no direct support for any integer semantic other than signed 32-bit. This is bad. I really can't see any valid reason why a protocol's primitive types would be chosen on the basis that's been described. It's just not a good engineering basis. > Up til now i saw suggestions for adding more integer types and for adding a > stream buffer type. > I think we should aim for keeping the set of additions as small as possible. > You suggest to add "all the usual integer types and maybe others", what > would those other types be? > Mostly just all the integer types, because they are the key to efficiency on the wire and in language bindings, and they also improve the semantic clarity. There is only one other type missing that results in significant and common inefficiencies, and that is bit arrays. They are used not only for actual bit-oriented bulk data but more frequently for carrying packed boolean fields, like say "Restricted" and other metadata bits that we discussed recently, and many other uses. We're very likely to see multiple booleans transmitted in messages, so lack of bit packing would be unfortunate for the efficiency of our boolean serializations. However ... It's so hard to get any change at all agreed here that I'll waive on the bit arrays or bit packing and just try to push the full range of integer fields. > Are you thinking of Dzonatas' his stream buffer type, or something else? > "Stream buffer type" made no sense to me if its name accurately described what it did. All protocol values are immutable by definition, and hence a field in a protocol message cannot be a buffer for anything at all. Maybe something else was intended, but it was never described to us so I can't comment on it further. > The version negotiation system seems to be orthogonal to adding extra > types to LLSD, i think we should try and reach consensus on the data types > first. It indeed looks like this can be done with very little pain or delay. > Yes, it's nicely orthogonal, as long as we number our protocol as VWRAP-1 or something like that. And yes, it could be done with very little pain or delay .... but it won't be. Just watch. :DDDDDDDDDDDDD Morgaine. ======================== On Fri, May 6, 2011 at 7:46 AM, Vaughn Deluca wrote: > Morgaine, vwrap, > > Your proposal sounds good, and a lot more workable than starting from > scratch. However you wrote earlier: > > > Indeed, in the early days of our IETF effort, we spent months discussing > the > > width of integers in LLSD because there was only one width allowed and it > was > > hardwired in the spec. > > What were the reasons to allow onl a single integer type? There must have > been a good arguments for that? > > Up til now i saw suggestions for adding more integer types and for adding a > stream buffer type. > I think we should aim for keeping the set of additions as small as > possible. > You suggest to add "all the usual integer types and maybe others", what > would those other types be? > Are you thinking of Dzonatas' his stream buffer type, or something else? > > The version negotiation system seems to be orthogonal to adding extra > types to LLSD, i think we should try and reach consensus on the data types > first. It indeed looks like this can be done with very little pain or delay. > > -- Vaughn > > > On Thu, May 5, 2011 at 4:33 PM, Morgaine wrote: > >> On Thu, May 5, 2011 at 7:32 AM, Vaughn Deluca wrote: >> >>> >>> So what do you suggest is the way forward? >>> >> >> >> I suggest the following as a way forward with very little pain or delay: >> >> >> - As other serialization systems have done, add those predefined types >> that we can easily foresee will be very beneficial to VW applications. That >> certainly includes all the usual integer types, maybe others. We could >> agree on a useful set of them today, it's not hard. It wouldn't be perfect, >> but it would be "our best shot" at supporting what the immediate future >> requires. It would give our types system added *flexibility*, and its >> extra *efficiency* would improve the performance of our binary >> serializations. >> >> >> - As Carlo has suggested in the past, add a version negotiation system >> so that when VW projects find our 2011 set of base types inadequate, they >> can evolve the types system and negotiate use of a newer one dynamically at >> protocol initiation time, without needing to come back to the IETF. This >> would give us a measure of *extensibility* without needing to make our >> initial elementary types extensible. >> >> >> - Can LLSD itself be made extensible? >>> >>> >> It can be made extensible, yes, but with this group's track record of >> continually saying "No" even to simple technical advances, I would not want >> to be an advocate for more complex extensible base types. Instead, I'll >> make do with Carlo's approach, ie. extensibility through negotiating >> alternative versions. >> >> >>> >>> I am all for rigorous design, but i think i prefer actual implementation >>> of an imperfect system over sitting and waiting for an ultimate dream. >>> If we don't get demonstrated commitment for specifying (and >>> implementing!) an alternative, my vote go's to sticking with LLSD, if only >>> to show conclusively were it falls short of our needs. >>> >>> >> Which is why I suggest that we do no more than add those types that we can >> envisage being needed in designs *today*, without speculating about >> tomorrow. Such flexibility is the least we can do while pretending to be >> "designing for the future". If we go forward with a design that *WE KNOW >> FULL WELL* is inflexible and inefficient through providing only a single >> integer type, then we cannot pretend to be designing for the future at all, >> it's designing for a specific application today. >> >> >>> >>> I am all for rigorous design, but i think i prefer actual implementation >>> of an imperfect system over sitting and waiting for an ultimate dream. >>> If we don't get demonstrated commitment for specifying (and >>> implementing!) an alternative, my vote go's to sticking with LLSD, if only >>> to show conclusively were it falls short of our needs. >>> >> >> >> There is no point going through all this IETF effort just to produce a >> protocol that we know is designed for today, without even a nod for the >> future. It will be obsolete before it's released. >> >> If we did so in ignorance, fine, we would deserve to be ignored by future >> VW designers who will find our design skills so lacking in future vision. >> But we would not be doing so in ignorance. Others in this group have >> commented on the lack of future proofing in LLSD too, not just myself. We >> would be rolling out a poor types system with our eyes wide open, despite >> being made aware of its lack of flexibility and extensibility. Future VW >> designers won't have any sympathy at all, we will be laughed at and >> condemned as knowingly regressive. And they would be right. >> >> I do not believe that this group is so technically incompetent that we >> can't produce a types system with a measure of flexibility and extensibility >> (through negotiation at least). What we do clearly suffer from is extreme >> inertia and resistance from some participants with a regressive outlook on >> protocol design, so much so that you're suggesting that we move forward with >> a known inflexible system just because of our people problems here. >> >> Well I can't help that. I've been doing my bit for pulling the cart into >> the future, despite intense opposition. That's how engineering advances are >> made, by always designing for tomorrow. I wish a few more people here would >> help with that. >> >> >> Morgaine. >> >> >> >> ======================== >> >> >> On Thu, May 5, 2011 at 7:32 AM, Vaughn Deluca wrote: >> >>> Morgaine, >>> >>> You observe LLSD is not extendable. Dzonatas argues that the this can be >>> solved at a higher level using XML. You object that this entangles the >>> serialisation with basic ADT >>> >>> So what do you suggest is the way forward? >>> - Can LLSD itself be made extensible? >>> -if not, do we have enough commitment in the group to start from scratch? >>> -if not, do the benefits of an absolutely clean engineering solution >>> outweighs the costs of disrupting the already slow progress here? We reach >>> for the sky, but run the risk of over extending our current capabilities. >>> >>> I am all for rigorous design, but i think i prefer actual implementation >>> of an imperfect system over sitting and waiting for an ultimate dream. >>> If we don't get demonstrated commitment for specifying (and >>> implementing!) an alternative, my vote go's to sticking with LLSD, if only >>> to show conclusively were it falls short of our needs. >>> >>> -- Vaughn >>> >>> >>> On Thu, May 5, 2011 at 12:59 AM, Morgaine < >>> morgaine.dinova@googlemail.com> wrote: >>> >>>> I have no idea what either of the last list two posts meant. >>>> >>>> I tried to interpret the preceding post as best I could and to find room >>>> for technical discussion, but clearly the attempt has failed. >>>> >>>> I'll leave it at that. >>>> >>>> >>>> Morgaine. >>>> >>>> >>>> >>>> =========================== >>>> >>>> >>>> >>>> On Wed, May 4, 2011 at 11:41 PM, Dzonatas Sol wrote: >>>> >>>>> On 05/04/2011 03:21 PM, Dzonatas Sol wrote: >>>>> >>>>>> Actually, I invented one tag called that does all the above >>>>>> already, so how about the predefined embed'ed data type instead of endless >>>>>> extensibility? >>>>>> >>>>>> >>>>> On that NOTE: any more needed extensibility is transistioned into >>>>> capabilities. >>>>> >>>>> Whereas, capabilities means more resources (as dynamic extensions >>>>> grow); therefore, this requires minimization of number of connections >>>>> instead of one connection per resource. Thus, that proportion leads into the >>>>> reason for combined/bundled queries that I have already mentioned and >>>>> implemented, as maximum # of connections are too easily reached without such >>>>> mechanism. >>>>> >>>>> >>>>> -- >>>>> --- https://twitter.com/Dzonatas_Sol --- >>>>> Web Development, Software Engineering, Virtual Reality, Consultant >>>>> >>>>> _______________________________________________ >>>>> vwrap mailing list >>>>> vwrap@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/vwrap >>>>> >>>> >>>> >>>> _______________________________________________ >>>> vwrap mailing list >>>> vwrap@ietf.org >>>> https://www.ietf.org/mailman/listinfo/vwrap >>>> >>>> >>> >> > --000e0cd5c94e525e4d04a2a82ae4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, May 6, 2011 at 7:46 AM, Vaughn Deluca <vaughn.deluca@gmail.com> = wrote:
Morgaine,

=A0Your proposal sounds good, and = =A0a lot more workable than starting from scratch. =A0However you wrote ear= lier:
=A0
> Indeed, in the early days of our IET= F effort, we spent months discussing the=A0
> width of integers in LLSD because there was only one width allowe= d and it was=A0
> hardwired in the spec.

<= div>What were the reasons to allow onl a single integer type? There must ha= ve been a good arguments for that?=A0


Joshua has replied about the history o= f it, but I'd like to reply about its future.

When you create an= ADT system and expect it to have multiple language bindings, then you shou= ld not base your ADT's set of primitive types on your initial choice of= languages, because that introduces several very poor consequences:

  • It reduces your set of primitive types to the lowest common den= ominator of types directly supported by your initial set of languages, and = hence makes your ADT system a very narrow one, the opposite of "flexib= le type system".
  • It makes those initial language bindings "special" b= ecause they have been given special consideration, whereas further language= bindings won't enjoy similar support as design targets.=A0 That's = not designing for the future.
  • It makes application developers repeatedly pay the penalty for= not having specific types directly suited to their application, a continui= ng cost.
  • It places the burden of type poverty on all langu= age bindings instead of only on the language that is type-inadequate.=A0 Be= tter languages have to suffer the penalty of an inferior one in their midst= .
  • The lack of the shortest integer types impacts on binary seria= lizations especially severely.=A0 While all serializations are rendered les= s efficient when they are forced to use a single generic integer type, it i= s the binary serialization that is impacted most.=A0 This is both unhelpful= and ironic, since it is the binary serialization that is chosen when you w= ant the most efficiency.=A0 It is the worst possible outcome that the binar= y serialization is affected worst.
  • By requiring your most efficient language bindings (C/C++) to = use fixed length integers instead of those that they employ internally, it = reduces their efficiency disproportionately every time they cross the bindi= ng boundary.=A0 Less efficient languages won't notice any slowdown beca= use the loss of binding efficiency is masked by their overheads, whereas C/= C++ have virtually no overheads and so are impacted most.=A0 This is the wr= ong way around, namely designing to benefit the least efficient use case.


So given quite a number of negative consequences, what= 9;s the actual benefit of taking the design approach described by Joshua?= =A0 Well allegedly it's so that the initial set of languages can all re= present the primitive data types of the ADT directly, but I dispute that th= at goal has any merit in practice.

First of all, tying your design to the type and representational povert= y of Python and ECMAScript misses the point that your most efficient scalab= le server systems are not likely to be written in them.=A0 Clients may be w= ritten in less efficient languages, but inefficiencies in clients don't= impact on system scalability because all those inefficiencies occur in par= allel.=A0 It's the efficiency of server side that matters far more when= designing efficient scalable systems, so server side requirements should b= e considered first.=A0 (Then bandwidth requirements next, and client requir= ements last.)

Secondly, it makes no sense to limit the primitive types transported by= a protocol to those which slow languages like Python and ECMAScript can re= present, because the overheads inherent in those languages vastly outweigh = any impact from protocol-language mismatch.=A0 What's more, those langu= ages are not prevented from using their internal representations just becau= se a protocol provides shorter integers for efficiency, so it is not a vali= d argument that supporting Python and ECMAScript precludes using shorter ty= pes in the protocol.=A0 That's just incorrect.

And thirdly, having to use a single size of integer for all purposes in= troduces semantic problems which we alluded to quite recently when discussi= ng Service Level Semantic Interoperability -- http://www.ietf.org/mail-ar= chive/web/vwrap/current/msg00657.html .=A0 It's a very bad approach= at the best of times, in effect a loss of type information for everything = that is integral but is not 32 bits in length.=A0 It results in additional = value bounds checking in the application to eliminate inappropriate values = arriving within the single-length protocol field, since the protocol provid= es no direct support for any integer semantic other than signed 32-bit.=A0 = This is bad.

I really can't see any valid reason why a protocol's primitive = types would be chosen on the basis that's been described.=A0 It's j= ust not a good engineering basis.


=A0
Up til now i saw suggestions for adding more integer types = and for adding a stream buffer type.
I think we should aim for keeping the set of additions as small as pos= sible.
You suggest to add "all the=A0usual integer types and maybe others", what would those other = types be?


Mostly just all the int= eger types, because they are the key to efficiency on the wire and in langu= age bindings, and they also improve the semantic clarity.

There is only one other type missing that results in significant and co= mmon inefficiencies, and that is bit arrays.=A0 They are used not only for = actual bit-oriented bulk data but more frequently for carrying packed boole= an fields, like say "Restricted" and other metadata bits that we = discussed recently, and many other uses.=A0 We're very likely to see mu= ltiple booleans transmitted in messages, so lack of bit packing would be un= fortunate for the efficiency of our boolean serializations.=A0 However ...<= br>
It's so hard to get any change at all agreed here that I'll wai= ve on the bit arrays or bit packing and just try to push the full range of = integer fields.


=A0
Are you thinking of D= zonatas' his stream buffer type, or something else?


"Stream buffer type" made no sense to me if its name accurately= =20 described what it did.=A0 All protocol values are immutable by definition,= =20 and hence a field in a protocol message cannot be a buffer for anything=20 at all.=A0 Maybe something else was intended, but it was never described=20 to us so I can't comment on it further.



The=A0version negotiation system seems to be orthogonal to adding extra types to=20 LLSD, i think we should =A0try and reach consensus on the data types=20 first.=A0It indeed looks like this can be done=A0with very little pain or= =20 delay.


Yes, it's nicely orthogo= nal, as long as we number our protocol as VWRAP-1 or something like that.= =A0 And yes, it could be done with very little pain or delay .... but it wo= n't be.=A0 Just watch. :DDDDDDDDDDDDD


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On F= ri, May 6, 2011 at 7:46 AM, Vaughn Deluca <vaughn.deluca@gmail.com> wrot= e:
Morgaine, vw= rap,

=A0Your proposal sounds good, and =A0a lot mo= re workable than starting from scratch. =A0However you wrote earlier:
=A0
> Indeed, in the early days of our IETF effort,= we spent months discussing the=A0
> width of integers in LLSD because there was only one width allowe= d and it was=A0
> hardwired in the spec.

<= div>What were the reasons to allow onl a single integer type? There must ha= ve been a good arguments for that?=A0

Up til now i saw suggestions for adding more integer ty= pes and for adding a stream buffer type.=A0
I think we should aim= for keeping the set of additions as small as possible.
You sugge= st to add "all the=A0usual = integer types and maybe others", what would those other types be?
Are you thinking of D= zonatas' his stream buffer type, or something else?

The=A0version negotiation system seems to be o= rthogonal to adding extra types to LLSD, i think we should =A0try and reach= consensus on the data types first.=A0It indeed looks like this can be done= =A0with very little pain or delay.

-- Vaughn

On Thu, May 5, 2011 at 4:33 P= M, Morgaine <morgaine.dinova@googlemail.com> wr= ote:
On Thu, May = 5, 2011 at 7:32 AM, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:

So what do you suggest is the way forward?


I suggest the following as a way forward with very litt= le pain or delay:

  • As other serialization systems have done, = add those predefined types that we can easily foresee will be very benefici= al to VW applications.=A0 That certainly includes all the usual integer typ= es, maybe others.=A0 We could agree on a useful set of them today, it's= not hard.=A0 It wouldn't be perfect, but it would be "our best sh= ot" at supporting what the immediate future requires.=A0 It would give= our types system added flexibility, and its extra efficiency= would improve the performance of our binary serializations.
  • As Carlo has suggested in the past, add a version negotia= tion system so that when VW projects find our 2011 set of base types inadeq= uate, they can evolve the types system and negotiate use of a newer one dyn= amically at protocol initiation time, without needing to come back to the I= ETF.=A0 This would give us a measure of extensibility without needin= g to make our initial elementary types extensible.

- Can LLSD itself be made extensible?

It can be made extensible, yes, but with this group's tr= ack record of continually saying "No" even to simple technical ad= vances, I would not want to be an advocate for more complex extensible base= types.=A0 Instead, I'll make do with Carlo's approach, ie. extensi= bility through negotiating alternative versions.
=A0

I am all for rigorous design, but i think i prefer=20 actual implementation of an imperfect system over sitting and waiting=20 for an ultimate dream.
If we don't get demonstrated commitmen= t for specifying (and implementing!) an alternative, my vote go's to=20 sticking with LLSD, if only to show conclusively were it falls short of=20 our needs.


Which is why I suggest that we = do no more than add those types that we can envisage being needed in design= s today, without speculating about tomorrow.=A0 Such flexibility is = the least we can do while pretending to be "designing for the future&q= uot;.=A0 If we go forward with a design that WE KNOW FULL WELL is in= flexible and inefficient through providing only a single integer type, then= we cannot pretend to be designing for the future at all, it's designin= g for a specific application today.
=A0

I am all for rigorous design, but i think i prefer=20 actual implementation of an imperfect system over sitting and waiting=20 for an ultimate dream.
If we don't get demonstrated commitmen= t for specifying (and implementing!) an alternative, my vote go's to=20 sticking with LLSD, if only to show conclusively were it falls short of=20 our needs.


There is no point going through = all this IETF effort just to produce a protocol that we know is designed fo= r today, without even a nod for the future.=A0 It will be obsolete before i= t's released.

If we did so in ignorance, fine, we would deserve to be ignored by futu= re VW designers who will find our design skills so lacking in future vision= .=A0 But we would not be doing so in ignorance.=A0 Others in this group hav= e commented on the lack of future proofing in LLSD too, not just myself.=A0= We would be rolling out a poor types system with our eyes wide open, despi= te being made aware of its lack of flexibility and extensibility.=A0 Future= VW designers won't have any sympathy at all, we will be laughed at and= condemned as knowingly regressive.=A0 And they would be right.

I do not believe that this group is so technically incompetent that we = can't produce a types system with a measure of flexibility and extensib= ility (through negotiation at least).=A0 What we do clearly suffer from is = extreme inertia and resistance from some participants with a regressive out= look on protocol design, so much so that you're suggesting that we move= forward with a known inflexible system just because of our people problems= here.

Well I can't help that.=A0 I've been doing my bit for pulling t= he cart into the future, despite intense opposition.=A0 That's how engi= neering advances are made, by always designing for tomorrow.=A0 I wish a fe= w more people here would help with that.


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


On Thu, May 5, 2011 at 7:32 AM, Vaughn Deluca <v= aughn.deluca@gmail.com> wrote:
Morgaine,

You observe LLSD is not extendable. Dzonatas argues = that the this can be solved at a higher level using XML. =A0You object that= this =A0entangles the serialisation with basic ADT

So what do you suggest is the way forward?
- Can L= LSD itself be made extensible?
-if not, do we have enough commitm= ent in the group to start from scratch?
-if not, do the benefits = of an absolutely clean engineering solution outweighs the costs of disrupti= ng the already slow progress here? We reach for the sky, but run the risk o= f over extending our current capabilities.

I am all for rigorous design, but i think i prefer actu= al implementation of an imperfect system over sitting and waiting for an ul= timate dream.
If we don't get demonstrated commitment for spe= cifying (and implementing!) an alternative, my vote go's to sticking wi= th LLSD, if only to show conclusively were it falls short of our needs.

-- Vaughn


On Thu, May 5, 20= 11 at 12:59 AM, Morgaine <morgaine.dinova@googlemail.com&= gt; wrote:
I have no idea wh= at either of the last list two posts meant.

I tried to interpret the= preceding post as best I could and to find room for technical discussion, = but clearly the attempt has failed.

I'll leave it at that.


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


=
On Wed, May 4, 2011 at 11:41 PM, Dzonatas So= l <dzonatas@gmail.com> wrote:
On 05/04/201= 1 03:21 PM, Dzonatas Sol wrote:
Actually, I invented one tag called <embed> that does all the above a= lready, so how about the predefined embed'ed data type instead of endle= ss extensibility?


On that NOTE: any more needed extensibility is transistioned into capabilit= ies.

Whereas, capabilities means more resources (as dynamic extensions grow); th= erefore, this requires minimization of number of connections instead of one= connection per resource. Thus, that proportion leads into the reason for c= ombined/bundled queries that I have already mentioned and implemented, as m= aximum # of connections are too easily reached without such mechanism.


--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap





--000e0cd5c94e525e4d04a2a82ae4-- From dahliatrimble@gmail.com Sat May 7 00:50:43 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF21E0681 for ; Sat, 7 May 2011 00:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSvmMEF9XRuR for ; Sat, 7 May 2011 00:50:41 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 41BD6E06F1 for ; Sat, 7 May 2011 00:50:40 -0700 (PDT) Received: by bwz13 with SMTP id 13so3492212bwz.31 for ; Sat, 07 May 2011 00:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=e40wsZSI2j5VB05PvPLtE368AzAXRKabp2FdNwlmwiU=; b=Kfi/Ltk9F5kTiEnmtWsWnX/5nny68Fr4BLEjqQEMVZjQiyoBlGdosbiVHZmd/VEGSX rZXU7vk43QLrphZ/IUTT09hw8uQcm+uliUbb25npwBaTMNpFl9eEwUKFZ+hmRk9ZOBnF VLD/s9XQGjeAShkTWnbTcrsAdm7jXzbI63NhY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=S72fTTb18MsAi6VRvEDxLtz6WcNUc8J2QehlBDUPfspQlp8Mb6Q1Li6A8ji1okVB0h U5C+ZGpcjh44Fm32cCxPj5141ybRMubxCP64LaRGIPJpNOvxRfxajgEfndlVyi2lGMtK 1OcNVW0P4E2d5Cd71mQBSz0xfw4E47QVRHrsM= MIME-Version: 1.0 Received: by 10.204.41.206 with SMTP id p14mr2542821bke.53.1304754317625; Sat, 07 May 2011 00:45:17 -0700 (PDT) Received: by 10.204.79.66 with HTTP; Sat, 7 May 2011 00:45:17 -0700 (PDT) In-Reply-To: References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> Date: Sat, 7 May 2011 00:45:17 -0700 Message-ID: From: Dahlia Trimble To: Joshua Bell Content-Type: multipart/alternative; boundary=bcaec555517a9f090304a2aac9a8 Cc: vwrap@ietf.org Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sat, 07 May 2011 07:50:43 -0000 --bcaec555517a9f090304a2aac9a8 Content-Type: text/plain; charset=ISO-8859-1 I believe python supports very large integers. Try this in your python interpreter: >>> bigint = 2**(2**16) >>> print bigint I first became aware of missing integer types in LLSD when I was coding the event queue messages to support group chat in OpenSimulator. It seems that "region handles" are 64 bit integers in the LL protocols but are encoded as a base64 encoded binary blob in LLSD as LLSD has no support for integers larger than 32 bits. I suspect that changing LLSD to have larger integer types might create some compatibility issues with existing implementations that expect to use the binary blob. On Fri, May 6, 2011 at 9:18 AM, Joshua Bell wrote: > On Thu, May 5, 2011 at 11:46 PM, Vaughn Deluca 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 > types. > > 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 > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > --bcaec555517a9f090304a2aac9a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I believe python supports very large integers. Try this in your python inte= rpreter:

>>> bigint =3D 2**(2**16)
>>> print bi= gint

I first became aware of missing integer types in LLSD when I wa= s coding the event queue messages to support group chat in OpenSimulator. I= t seems that "region handles" are 64 bit integers in the LL proto= cols but are encoded as a base64 encoded binary blob in LLSD as LLSD has no= support for integers larger than 32 bits. I suspect that changing LLSD to = have larger integer types might create some compatibility issues with exist= ing implementations that expect to use the binary blob.


On Fri, May 6, 2011 at 9:18 AM, Joshua B= ell <josh@linden= lab.com> wrote:
On Thu, May 5, 2011 at 11:46 PM, Vaughn Deluca <v= aughn.deluca@gmail.com> wrote:

What were the reasons to allow onl a single integer typ= e? There must have been a good arguments for that?=A0

IIRC, some of the languages we wished to support (Py= thon 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-bi= t floats; if you constrain the input and output to 32-bit integers it can r= epresent those accurately, but not 64-bit integers.

If you look at the history of LLSD, it started with 3 s= erialization formats that explicitly specified the type of values - XML, bi= nary, 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 i= nterpreted as a date by the receiver results in the original Date by the st= ring->date conversion rules. (I don't know if we had resolved every = issue with JSON serialization; certainly, discussion about edge cases on th= is list never made it into a draft).

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

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

-- Josh


_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


--bcaec555517a9f090304a2aac9a8-- From morgaine.dinova@googlemail.com Sat May 7 07:32:08 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE91E06C5 for ; Sat, 7 May 2011 07:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.867 X-Spam-Level: X-Spam-Status: No, score=-2.867 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rayntz81r9ct for ; Sat, 7 May 2011 07:32:07 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05ECEE068B for ; Sat, 7 May 2011 07:32:06 -0700 (PDT) Received: by qwc23 with SMTP id 23so3004066qwc.31 for ; Sat, 07 May 2011 07:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=2OSGiR9Ihi3s+Fu+Ceu460LrxQYbnvopownqRLy18m8=; b=mEFjq043k9MLxUMjxgC0vqKj9iE3pdTVjQgWx6HnVQSMf4j2p2UcQcSzCHumFK3CeX cO6PZ5bDmkQy4CdLTiHEg6F08qSs0wpG+orhK2KR5xUaCXzLJ8aiN6cWsY/JAqgAPk6V HUT/PHLQOSLaW3r5hBa8h2NbjlLkxebJx7iF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=isNfmzBbVGNAosAi0tfIIoMMayPTZ7u66K2BRhH7WjExanAt+IzzchOp+N/94de3G+ UhuiNlZosK/TvKbYgw2TvnYv4ls1ZZRr944EK2SB8Tn/pTEeXOWMhE6e4cfbfOGbKrXT Sn9HimKdPHxkfQ3JRLOc/2FR4zWV7eqI0kKqk= MIME-Version: 1.0 Received: by 10.229.119.134 with SMTP id z6mr1782374qcq.63.1304778725784; Sat, 07 May 2011 07:32:05 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Sat, 7 May 2011 07:32:05 -0700 (PDT) In-Reply-To: References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> Date: Sat, 7 May 2011 15:32:05 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd5c94e75ffe004a2b078fc Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sat, 07 May 2011 14:32:08 -0000 --000e0cd5c94e75ffe004a2b078fc Content-Type: text/plain; charset=ISO-8859-1 Oh dear, that's sad to hear, Dahlia. So not only was the original premise of Python not having longer integers wrong (although the addition of bigints may have been recent), but the missing types in LLSD even forced SL designers to use base64 blobs in their absence. That strongly highlights the mistake that was made in the early ADT. Even worse, that design decision then went on to compromise Opensim's implementation by forcing it to employ base64 blobs to be compatible with SL viewers, since Opensim has no independent viewer of its own . Such mistakes often propagate to other parties through no fault of theirs, just because the original design decision was not a good one. *Well now is the time for change! * The IETF's Mission Statement places upon us a duty to work for the benefit of all Internet users, so let's not perpetuate the old mistake and spread the harm to future virtual worlds. We have the technical competency to do better than was done in the past. Morgaine. ========================= On Sat, May 7, 2011 at 8:45 AM, Dahlia Trimble wrote: > I believe python supports very large integers. Try this in your python > interpreter: > > >>> bigint = 2**(2**16) > >>> print bigint > > I first became aware of missing integer types in LLSD when I was coding the > event queue messages to support group chat in OpenSimulator. It seems that > "region handles" are 64 bit integers in the LL protocols but are encoded as > a base64 encoded binary blob in LLSD as LLSD has no support for integers > larger than 32 bits. I suspect that changing LLSD to have larger integer > types might create some compatibility issues with existing implementations > that expect to use the binary blob. > > > On Fri, May 6, 2011 at 9:18 AM, Joshua Bell wrote: > >> On Thu, May 5, 2011 at 11:46 PM, Vaughn Deluca 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 >> types. >> >> 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 >> >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > --000e0cd5c94e75ffe004a2b078fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Oh dear, that's sad to hear, Dahlia.

So not only was the origina= l premise of Python not having longer integers wrong (although the addition= of bigints may have been recent), but the missing types in LLSD even force= d SL designers to use base64 blobs in their absence.=A0 That strongly highl= ights the mistake that was made in the early ADT.

Even worse, that design decision then went on to compromise Opensim'= ;s implementation by forcing it to employ base64 blobs to be compatible wit= h SL viewers, since Opensim has no independent viewer of its own .=A0 Such = mistakes often propagate to other parties through no fault of theirs, just = because the original design decision was not a good one.

Well now is the time for change!

The IETF's Mission S= tatement places upon us a duty to work for the benefit of all Internet user= s, so let's not perpetuate the old mistake and spread the harm to futur= e virtual worlds.=A0 We have the technical competency to do better than was= done in the past.


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

O= n Sat, May 7, 2011 at 8:45 AM, Dahlia Trimble <dahliatrimble@gmail.com> = wrote:
I believe python = supports very large integers. Try this in your python interpreter:

&= gt;>> bigint =3D 2**(2**16)
>>> print bigint

I first became aware of missing integer ty= pes in LLSD when I was coding the event queue messages to support group cha= t in OpenSimulator. It seems that "region handles" are 64 bit int= egers in the LL protocols but are encoded as a base64 encoded binary blob i= n LLSD as LLSD has no support for integers larger than 32 bits. I suspect t= hat changing LLSD to have larger integer types might create some compatibil= ity issues with existing implementations that expect to use the binary blob= .


On Fri= , May 6, 2011 at 9:18 AM, Joshua Bell <josh@lindenlab.com> = wrote:
=
On Thu, May 5, 2011 at 11:46 PM, Vaughn Deluca <<= a href=3D"mailto:vaughn.deluca@gmail.com" target=3D"_blank">vaughn.deluca@g= mail.com> wrote:

What were the reasons to allow onl a single integer typ= e? There must have been a good arguments for that?=A0

IIRC, some of the languages we wished to support (Py= thon 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-bi= t floats; if you constrain the input and output to 32-bit integers it can r= epresent those accurately, but not 64-bit integers.

If you look at the history of LLSD, it started with 3 s= erialization formats that explicitly specified the type of values - XML, bi= nary, 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 i= nterpreted as a date by the receiver results in the original Date by the st= ring->date conversion rules. (I don't know if we had resolved every = issue with JSON serialization; certainly, discussion about edge cases on th= is list never made it into a draft).

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

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

-- Josh


_________________________________________= ______
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap



_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


--000e0cd5c94e75ffe004a2b078fc-- From ohmeadhbh@gmail.com Sat May 7 08:02:52 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE184E0724 for ; Sat, 7 May 2011 08:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN2q1r4KyjjL for ; Sat, 7 May 2011 08:02:51 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 69C17E06C5 for ; Sat, 7 May 2011 08:02:51 -0700 (PDT) Received: by wyb29 with SMTP id 29so3482931wyb.31 for ; Sat, 07 May 2011 08:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=m8v5/hWpD1mcd91PdehtIFCLUXEmj4U9V9upZNnCdEA=; b=eZMt8axHSpeBKXjODuy3f30K6LOj5eYgqcEJZ/Koa24SE2VVrgMbRBrcjocUgAGO8x S6Yla0iKQevB++uV4k1pcOC1YU9+C7mRrbeE9ErR1H8ypyDuSsl+2xI550ejSqltHAtG 3B1Q5O9pSboPGeE2ADxqgFjm0B9SzPnMpihS8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=a4hP5T5Z/Oq5N8QGSbJ6Qifb9GV4719DZwpOEkBS1cFUFhhI/MPkkWO4gpdbkeluQo OItqyxo8+yQ/hDeO5jb8RTN+NJwhIZGLhTcnJWmO28HajRK8FTH+saZ0i2RlnNIrQ3MH y0a6Q7auN57YrXK/vxqtaTvCHMJwku+iQHRV0= Received: by 10.216.79.5 with SMTP id h5mr4844289wee.110.1304780569115; Sat, 07 May 2011 08:02:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.154.1 with HTTP; Sat, 7 May 2011 08:02:29 -0700 (PDT) In-Reply-To: <4DC45B56.1020604@gmail.com> References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> <4DC45B56.1020604@gmail.com> From: Meadhbh Hamrick Date: Sat, 7 May 2011 08:02:29 -0700 Message-ID: To: Dzonatas Sol Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sat, 07 May 2011 15:02:52 -0000 or... you could simply add a version tag to the contents of the LLSD. so, an XML LLSD blob might look like: 2 ... and a json blob might look like { version: 2, ... } (though this example would require us to make the version element in a map verboten.) -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Fri, May 6, 2011 at 1:34 PM, Dzonatas Sol wrote: > On 05/06/2011 09:18 AM, Joshua Bell wrote: >> >> 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. > > +1 > > Or, Content-Type: application/llsd+1+xml > Or, Content-Type: application/llsd++xml > Or, Content-Type: xml-ietf-vwrap/llsd+adt+extra > > ...etc, would work yet I believe - and + still are transient denotations for > with or without DTD, so... > > Content-Type: xml-ietf-vwrap/urn:[bank]:llsd.proxy.net:map,abstract,... > > Yes, LLSD as-is continues to work even without excessive headers. > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From sllists@boroon.dasgupta.ch Sat May 7 08:14:11 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E26E072E for ; Sat, 7 May 2011 08:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.387 X-Spam-Level: X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id is18ITlKhn8J for ; Sat, 7 May 2011 08:14:09 -0700 (PDT) Received: from datendelphin.net (india288.server4you.de [85.25.150.202]) by ietfa.amsl.com (Postfix) with ESMTP id E2479E06C5 for ; Sat, 7 May 2011 08:14:08 -0700 (PDT) Received: from [192.168.1.107] (adsl-89-217-134-70.adslplus.ch [89.217.134.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by datendelphin.net (Postfix) with ESMTPSA id 793FB2E045 for ; Sat, 7 May 2011 17:17:35 +0200 (CEST) Message-ID: <4DC561BC.3040309@boroon.dasgupta.ch> Date: Sat, 07 May 2011 17:14:04 +0200 From: Boroondas Gupte User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040106040909010605070807" Subject: [vwrap] Python integer types (was: The tag... is the group still interested in LLSD or DSD?) X-BeenThere: vwrap@ietf.org 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: Sat, 07 May 2011 15:14:11 -0000 This is a multi-part message in MIME format. --------------040106040909010605070807 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 05/07/2011 09:45 AM, Dahlia Trimble wrote: > I believe python supports very large integers. Try this in your python > interpreter: > > >>> bigint = 2**(2**16) > >>> print bigint In fact, python features two built-in integer types: * plain integers (int) * long integers (long) According to the python documentation on built-in numeric types , python's int is implemented using long in C. This means it has at least 32 bits, but can be larger on certain systems. E.g. on a 64bit Linux, it'll be 64 bits long, as I've just verified myself: >>> import sys >>> 2 ** 63 - 1 == sys.maxint True Python's long is unlimited in size (at the cost of performance). Conveniently, python converts from int to long as needed, even if no longs are amongst the operands: >>> sys.maxint 9223372036854775807 >>> sys.maxint + 1 9223372036854775808L (The L postfix indicates a long literal.) Conversion from long to int doesn't happen implicitly, but can be done explicitly if wanted. Cheers, Boroondas --------------040106040909010605070807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 05/07/2011 09:45 AM, Dahlia Trimble wrote:
I believe python supports very large integers. Try this in your python interpreter:

>>> bigint = 2**(2**16)
>>> print bigint
In fact, python features two built-in integer types:
  • plain integers (int)
  • long integers (long)
According to the python documentation on built-in numeric types, python's int is implemented using long in C. This means it has at least 32 bits, but can be larger on certain systems. E.g. on a 64bit Linux, it'll be 64 bits long, as I've just verified myself:
>>> import sys
>>> 2 ** 63 - 1 == sys.maxint
True
Python's long is unlimited in size (at the cost of performance). Conveniently, python converts from int to long as needed, even if no longs are amongst the operands:
>>> sys.maxint
9223372036854775807
>>> sys.maxint + 1
9223372036854775808L
(The L postfix indicates a long literal.) Conversion from long to int doesn't happen implicitly, but can be done explicitly if wanted.

Cheers,
Boroondas
--------------040106040909010605070807-- From ohmeadhbh@gmail.com Sat May 7 08:19:46 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562EBE06C5 for ; Sat, 7 May 2011 08:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QM+DhcZpejwE for ; Sat, 7 May 2011 08:19:45 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 66277E06BA for ; Sat, 7 May 2011 08:19:44 -0700 (PDT) Received: by wwa36 with SMTP id 36so3042002wwa.13 for ; Sat, 07 May 2011 08:19:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lcz+vOcBeiBqIS1EFjG+OX27NbYSgBfMkQeNeYwfsYo=; b=JLRkex/4Xdyw7pMbQl5rN2M1TpsFlwGq534Nr9FSjzX1yUwYPjm4o0Gro9Gqope6dr 0TpE7eV668YMIDLlxcIk6psi4vXmcaYHh0Opck2S7ZctOW6c4zEj4crNIIfX4HuycC99 gzEUhK2ZeRH6iH/MLozUIirNoeCe3fZZdWpr0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=hm1aEsduR6P6/9R7LkF4wpU8h/RQd5B11ZH1wxif5JQ47+eqNEM0+KYPHUi7Xv2bab FNVwyDcfkIXuvUVKAyAstViSmljyD2jLFTrfCo7Qq+jHgO5P2MpjZosbe5kgW5+WIayP aE2OzVwMsc4ltI5+7L6LiPWDH3HqwsK9ESWXQ= Received: by 10.216.143.7 with SMTP id k7mr4818996wej.95.1304781583083; Sat, 07 May 2011 08:19:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.154.1 with HTTP; Sat, 7 May 2011 08:19:23 -0700 (PDT) In-Reply-To: References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> From: Meadhbh Hamrick Date: Sat, 7 May 2011 08:19:23 -0700 Message-ID: To: Joshua Bell Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sat, 07 May 2011 15:19:46 -0000 Josh, it's even worse than that. Python inherits the integer size from the compiler that generated it. So, if you compile python on a system with a 16 bit int (which used to be pretty common in some embedded systems) you get a version of python that uses 16 bit ints. I think you touched on an important aspect though... JSON is meant to be a transfer syntax and is not supposed to make assumptions about the sizes of types on the sending and receiving system. LLSD is more than a transfer syntax, it's an abstract type system that DOES impose limitations on sizes for types. Sometimes it's easy to confuse the type system with the transfer syntax. &c &c m -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Fri, May 6, 2011 at 9:18 AM, Joshua Bell wrote: > On Thu, May 5, 2011 at 11:46 PM, Vaughn Deluca > 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 > types. > 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 > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > From ohmeadhbh@gmail.com Sat May 7 08:20:03 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA380E06DA for ; Sat, 7 May 2011 08:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEGzu7d4LNgx for ; Sat, 7 May 2011 08:20:01 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 23BE5E06BA for ; Sat, 7 May 2011 08:20:00 -0700 (PDT) Received: by wyb29 with SMTP id 29so3489876wyb.31 for ; Sat, 07 May 2011 08:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cvIo/rqjDX+ApTmLGUMi36XdMvxQD46VMwU2in05Ta8=; b=FkHYbIzZ5chbynacFmtpPTo9HfMWgoygZkmC0LPultUxFkPZrbgmPMEJy5Z2ZUpUYa KM8tuyoIO/TN+wu2AKcruT/lzsZddAMSxrGckZc57UR7ip19tAdFbr2LLmwtR8VQ8Up4 Ruf/fTocoj7p75lvG9Yhk1RFwSUwWY952mTnE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=u8l3lcS/uaCEhHIhmSf8n8j9JRGKw+o3jT+SbzjHwNUXEOt1qsn7mz1CFrQgmvQ8la Ln1knVJsNrbhjuiLN7ei3CosEjh2qxsPszzdFrEChgGmKdA9hYmns+eB2ctN/oi5Q4Bi Rz/KcQux2Zk3ie6PTqbsLBHXywxr3YyfXfNHM= Received: by 10.216.14.199 with SMTP id d49mr4841509wed.65.1304781599128; Sat, 07 May 2011 08:19:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.154.1 with HTTP; Sat, 7 May 2011 08:19:39 -0700 (PDT) In-Reply-To: References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> From: Meadhbh Hamrick Date: Sat, 7 May 2011 08:19:39 -0700 Message-ID: To: Dahlia Trimble Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sat, 07 May 2011 15:20:04 -0000 Hey Dahlia, Yes, the way the legacy protocol handles region handles is a hack (at best.) My suggestion has always been to, since we're creating a new protocol, use something other than a 64 bit integer for a region handle. IIRC, we were planning on revamping this bit of the protocol to use a URL as a region handle to avoid the problem of requiring a global region handle to host registry. But that's kind of off-topic, assuming the topic is bigints in LLSD. One of the reasons I'm not especially happy with LLSD is that it does not distinguish between the abstract type system and the transfer syntax. Changing the existing LLSD to support big integers would require a modification to the binary serialization. The JSON and XML serializations are fine, they don't add size restrictions to integer fields at the transfer syntax level. So you would likely have to add a new tag to the binary serialization for "multi precision integer" which was simply a string of 32 bit ints in network order. Or you would have to change the semantics of the existing integer encoding to support multi precision ints. Either way you have to change the existing LLSD binary serialization. As a historical note, there was a bit of debate on this topic inside the lab. One side wanted Radix 10 Floats and MP Ints and the other side suggesting that once you opened the doors to expansion, there was no telling where you would stop and pointing out that you can do MP Ints as long as you bury them in binary strings. Ultimately, those of us who supported Radix 10 floats and MP Ints were laid off before them what supported a minimal set of types. &c &c m -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Sat, May 7, 2011 at 12:45 AM, Dahlia Trimble wrote: > I believe python supports very large integers. Try this in your python > interpreter: > >>>> bigint = 2**(2**16) >>>> print bigint > > I first became aware of missing integer types in LLSD when I was coding the > event queue messages to support group chat in OpenSimulator. It seems that > "region handles" are 64 bit integers in the LL protocols but are encoded as > a base64 encoded binary blob in LLSD as LLSD has no support for integers > larger than 32 bits. I suspect that changing LLSD to have larger integer > types might create some compatibility issues with existing implementations > that expect to use the binary blob. > > > On Fri, May 6, 2011 at 9:18 AM, Joshua Bell wrote: >> >> On Thu, May 5, 2011 at 11:46 PM, Vaughn Deluca >> 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 >> types. >> 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 >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > From morgaine.dinova@googlemail.com Sat May 7 08:25:44 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B09DE06E6 for ; Sat, 7 May 2011 08:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.876 X-Spam-Level: X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmCInCWE1PL9 for ; Sat, 7 May 2011 08:25:43 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D0689E06BA for ; Sat, 7 May 2011 08:25:42 -0700 (PDT) Received: by qwc23 with SMTP id 23so3020605qwc.31 for ; Sat, 07 May 2011 08:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=2A36RDdtp5ClkFRNhXBcCDSzgBkf+QPqAR8B8dFm+LQ=; b=ms7RmGciJh5Hct4SqbbYPiwkKGSen7So45Y1G/2JAmS/xUNdASVMpCWCRd3F2bkEYJ dVkVrFfdXq4z5XX8dXeHVdU7nMWqeDfaXvSrQToyOQfuF9ZAwKPMBegDg6pQ8l71ifyW E/OXqki+G6Vdfdn1wiZIR3Jbnku5XHpEXDyBM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=UpYOBxBXGBMMpfvn4D1pwskLqLf5RyBj9aCVEcICQ9TVJV5l0sxkzgS5cG0B8m8hvN 1T3Ma6kzfLXwTl3jhrCH/uN1wU5YmyBidLHUU0CPIpXOMWtiRYQs+QDp1woc0K1v1Hg0 uGhfveHPZuFCVqvvzjUmUvGOqVmhxalk7ZINY= MIME-Version: 1.0 Received: by 10.229.102.85 with SMTP id f21mr3559568qco.25.1304781939182; Sat, 07 May 2011 08:25:39 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Sat, 7 May 2011 08:25:39 -0700 (PDT) In-Reply-To: References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> <4DC45B56.1020604@gmail.com> Date: Sat, 7 May 2011 16:25:39 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=002354471a20fe8ba004a2b137b1 Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sat, 07 May 2011 15:25:44 -0000 --002354471a20fe8ba004a2b137b1 Content-Type: text/plain; charset=ISO-8859-1 We will certainly need to have a protocol negotiation handshake if we have any pretentions of being "extensible", and this negotiation phase needs to be present in all serializations, including binary ones. Carlo's advice about this is good. Version 1.0 for VWRAP needs to be as good as we can make it though, not the current LLSD spec which is clearly very limited. Knowingly keeping it inferior and immediately creating problems for everybody is a very poor way to proceed. I recommend that if you want LLSD/DSD unchanged from its current spec then you should publish it as an RFC, and avoid all these discussions. Here in VWRAP we have a far more onerous duty, which is to publish a *good* types spec. Morgaine. ==================== On Sat, May 7, 2011 at 4:02 PM, Meadhbh Hamrick wrote: > or... you could simply add a version tag to the contents of the LLSD. > so, an XML LLSD blob might look like: > > > > 2 > ... > > > and a json blob might look like > { > version: 2, > ... > } > > (though this example would require us to make the version element in a > map verboten.) > > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Fri, May 6, 2011 at 1:34 PM, Dzonatas Sol wrote: > > On 05/06/2011 09:18 AM, Joshua Bell wrote: > >> > >> 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. > > > > +1 > > > > Or, Content-Type: application/llsd+1+xml > > Or, Content-Type: application/llsd++xml > > Or, Content-Type: xml-ietf-vwrap/llsd+adt+extra > > > > ...etc, would work yet I believe - and + still are transient denotations > for > > with or without DTD, so... > > > > Content-Type: xml-ietf-vwrap/urn:[bank]:llsd.proxy.net:map,abstract,... > > > > Yes, LLSD as-is continues to work even without excessive headers. > > > > > > -- > > --- https://twitter.com/Dzonatas_Sol --- > > Web Development, Software Engineering, Virtual Reality, Consultant > > > > _______________________________________________ > > vwrap mailing list > > vwrap@ietf.org > > https://www.ietf.org/mailman/listinfo/vwrap > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --002354471a20fe8ba004a2b137b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We will certainly need to have a protocol negotiation handshake if we have = any pretentions of being "extensible", and this negotiation phase= needs to be present in all serializations, including binary ones.=A0 Carlo= 's advice about this is good.

Version 1.0 for VWRAP needs to be as good as we can make it though, not= the current LLSD spec which is clearly very limited.=A0 Knowingly keeping = it inferior and immediately creating problems for everybody is a very poor = way to proceed.

I recommend that if you want LLSD/DSD unchanged from its current spec t= hen you should publish it as an RFC, and avoid all these discussions.=A0 He= re in VWRAP we have a far more onerous duty, which is to publish a good<= /i> types spec.


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

On Sat, May 7, 2= 011 at 4:02 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com> wrote:
or... you could s= imply add a version tag to the contents of the LLSD.
so, an XML LLSD blob might look like:

<?xml version=3D"1.0"?>
<llsd>
=A0<version>2</version>
=A0...
</llsd>

and a json blob might look like
{
=A0version: 2,
=A0...
}

(though this example would require us to make the version element in a
map verboten.)

--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadh= bh.org/ * OhMeadhbh@gmail.com



On Fri, May 6, 2011 at 1:34 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
> On 05/06/2011 09:18 AM, Joshua Bell wrote:
>>
>> As far as adding new types: I believe there was the belief that th= is 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 functiona= l within
>> VWRAP interoperation.
>
> +1
>
> Or, Content-Type: application/llsd+1+xml
> Or, Content-Type: application/llsd++xml
> Or, Content-Type: xml-ietf-vwrap/llsd+adt+extra
>
> ...etc, would work yet I believe - and + still are transient denotatio= ns for
> with or without DTD, so...
>
> Content-Type: xml-ietf-vwrap/urn:[bank]:llsd.proxy.net:map,abstract,..= .
>
> Yes, LLSD as-is continues to work even without excessive headers.
>
>
> --
> --- htt= ps://twitter.com/Dzonatas_Sol ---
> Web Development, Software Engineering, Virtual Reality, Consultant
>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--002354471a20fe8ba004a2b137b1-- From ohmeadhbh@gmail.com Sat May 7 08:29:33 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3C6E06E6 for ; Sat, 7 May 2011 08:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxvrFXr3+qsc for ; Sat, 7 May 2011 08:29:31 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CEB90E06BA for ; Sat, 7 May 2011 08:29:30 -0700 (PDT) Received: by wyb29 with SMTP id 29so3493447wyb.31 for ; Sat, 07 May 2011 08:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=G5wEbPfogrk3NerA8Zbw6XgHV80i+/YAV2qXd1MU9jw=; b=e3fLZ2ep9/S4Xct29Bv9df4htcVlpRPtKhmrm0ortVHow+YxBTsA9ImalvKfhBso9C oh5Nb17JO+WU4PLpATG/bCAy3E+STVTUG9hSroYzLf9OU1FWScstcEIUslOVqQLj3agA sdK82DVgq7FOj/r1qNDwC7Z81gJ1ZHf4yDW/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Bqhkd/thSEP2NdkO7rRm8SY4KVdQwfWJwqtLjj304UntJ4J95VYdBq9Fdo1y3Mwm4s tUSiLlBts5oZ3PqcLs0sZb8rnwf6J2+a11yJJOH9lMW3qR+2Y4XAK90roSqjhCdcv2nI A5JKNXHFYhAaesVCxiW9Q4kmPyuUA58f/Ovr0= Received: by 10.216.79.5 with SMTP id h5mr4841689wee.110.1304780389075; Sat, 07 May 2011 07:59:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.154.1 with HTTP; Sat, 7 May 2011 07:59:29 -0700 (PDT) In-Reply-To: References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> From: Meadhbh Hamrick Date: Sat, 7 May 2011 07:59:29 -0700 Message-ID: To: Dahlia Trimble Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sat, 07 May 2011 15:29:33 -0000 Hey Dahlia, Yes, the way the legacy protocol handles region handles is a hack (at best.) My suggestion has always been to, since we're creating a new protocol, use something other than a 64 bit integer for a region handle. IIRC, we were planning on revamping this bit of the protocol to use a URL as a region handle to avoid the problem of requiring a global region handle to host registry. But that's kind of off-topic, assuming the topic is bigints in LLSD. One of the reasons I'm not especially happy with LLSD is that it does not distinguish between the abstract type system and the transfer syntax. Changing the existing LLSD to support big integers would require a modification to the binary serialization. The JSON and XML serializations are fine, they don't add size restrictions to integer fields at the transfer syntax level. So you would likely have to add a new tag to the binary serialization for "multi precision integer" which was simply a string of 32 bit ints in network order. Or you would have to change the semantics of the existing integer encoding to support multi precision ints. Either way you have to change the existing LLSD binary serialization. As a historical note, there was a bit of debate on this topic inside the lab. One side wanted Radix 10 Floats and MP Ints and the other side suggesting that once you opened the doors to expansion, there was no telling where you would stop and pointing out that you can do MP Ints as long as you bury them in binary strings. Ultimately, those of us who supported Radix 10 floats and MP Ints were laid off before them what supported a minimal set of types. -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Sat, May 7, 2011 at 12:45 AM, Dahlia Trimble wrote: > I believe python supports very large integers. Try this in your python > interpreter: > >>>> bigint = 2**(2**16) >>>> print bigint > > I first became aware of missing integer types in LLSD when I was coding the > event queue messages to support group chat in OpenSimulator. It seems that > "region handles" are 64 bit integers in the LL protocols but are encoded as > a base64 encoded binary blob in LLSD as LLSD has no support for integers > larger than 32 bits. I suspect that changing LLSD to have larger integer > types might create some compatibility issues with existing implementations > that expect to use the binary blob. > > > On Fri, May 6, 2011 at 9:18 AM, Joshua Bell wrote: >> >> On Thu, May 5, 2011 at 11:46 PM, Vaughn Deluca >> 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 >> types. >> 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 >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > From sllists@boroon.dasgupta.ch Sat May 7 08:49:17 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC57FE06BB for ; Sat, 7 May 2011 08:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zx0qeQHnxg9o for ; Sat, 7 May 2011 08:49:17 -0700 (PDT) Received: from datendelphin.net (india288.server4you.de [85.25.150.202]) by ietfa.amsl.com (Postfix) with ESMTP id E8370E0682 for ; Sat, 7 May 2011 08:49:16 -0700 (PDT) Received: from [192.168.1.107] (adsl-89-217-134-70.adslplus.ch [89.217.134.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by datendelphin.net (Postfix) with ESMTPSA id B0F622E045 for ; Sat, 7 May 2011 17:52:44 +0200 (CEST) Message-ID: <4DC569FB.90608@boroon.dasgupta.ch> Date: Sat, 07 May 2011 17:49:15 +0200 From: Boroondas Gupte User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020903010305000909000401" Subject: [vwrap] Python integer types, again (was: The tag... is the group still interested in LLSD or DSD?) X-BeenThere: vwrap@ietf.org 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: Sat, 07 May 2011 15:49:18 -0000 This is a multi-part message in MIME format. --------------020903010305000909000401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 05/07/2011 05:19 PM, Meadhbh Hamrick wrote: > Josh, it's even worse than that. > > Python inherits the integer size from the compiler that generated it. > So, if you compile python on a system with a 16 bit int (which used to > be pretty common in some embedded systems) you get a version of python > that uses 16 bit ints. Fortunately, it's not as bad as /that/. While it's true that python inherits the integer size from the compiler, it doesn't use C's int to implements python ints, but C's long and thus can guarantee a precision of at least 32 bits. Also, due to seamless conversion (see my other post ) to python's (unlimited precision) long, the actual size of python's int (or the implementation dependence of that size) can probably be ignored most of the time, except maybe for performance considerations. Cheers, Boroondas --------------020903010305000909000401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 05/07/2011 05:19 PM, Meadhbh Hamrick wrote: 
Josh, it's even worse than that.

Python inherits the integer size from the compiler that generated it.
So, if you compile python on a system with a 16 bit int (which used to
be pretty common in some embedded systems) you get a version of python
that uses 16 bit ints.
Fortunately, it's not as bad as that. While it's true that python inherits the integer size from the compiler, it doesn't use C's int to implements python ints, but C's long and thus can guarantee a precision of at least 32 bits. Also, due to seamless conversion (see my other post) to python's (unlimited precision) long, the actual size of python's int (or the implementation dependence of that size) can probably be ignored most of the time, except maybe for performance considerations.

Cheers,
Boroondas
--------------020903010305000909000401-- From ohmeadhbh@gmail.com Sat May 7 08:56:07 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89741E06DD for ; Sat, 7 May 2011 08:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+kNwJibhbWJ for ; Sat, 7 May 2011 08:56:06 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 72C77E0682 for ; Sat, 7 May 2011 08:56:06 -0700 (PDT) Received: by wyb29 with SMTP id 29so3503564wyb.31 for ; Sat, 07 May 2011 08:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rLxl912q8rXWxcGcxz/z3ajkNhHAPR7HltAZ4NFC9Hc=; b=TrBNSynKGONHWD3vUQZWNFe2yn21sqNMXrmGA1p3sBml1xIwDCixmLgc68d0cIsSoG XVp4U0WsqI9uTrkJe4qyquzuG+1yo1Zb6O2+7VyGdKzhAEqZD3y5pf/zcxYY78Io7gBc NbdlIv4hezhigY4lS0QmI/nNYAP+Tu5d3AeFQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=mL5ZQSBddksp2bZAJPen2V2Jz2TVaC+8W6tFGK8RLlg0Mj+L2DSi+mHqC8ML8thG+3 55gGO+RpKeNmbOQSX0ERQawhmX57HJMANnFMRnRrbrPWHMIJn9rQ2fPUHa4klqbhtxw8 f16KLb1aWYHl7dddP27O8uHP5MMvot+gKuLmY= Received: by 10.216.145.206 with SMTP id p56mr780895wej.80.1304783269093; Sat, 07 May 2011 08:47:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.154.1 with HTTP; Sat, 7 May 2011 08:47:29 -0700 (PDT) In-Reply-To: <4DC561BC.3040309@boroon.dasgupta.ch> References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> <4DC561BC.3040309@boroon.dasgupta.ch> From: Meadhbh Hamrick Date: Sat, 7 May 2011 08:47:29 -0700 Message-ID: To: Boroondas Gupte Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org Subject: Re: [vwrap] Python integer types (was: The tag... is the group still interested in LLSD or DSD?) X-BeenThere: vwrap@ietf.org 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: Sat, 07 May 2011 15:56:07 -0000 blarg. you're right. looks like python moved from using c int's for python ints to using c longs back in 2.2. -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Sat, May 7, 2011 at 8:14 AM, Boroondas Gupte wrote: > On 05/07/2011 09:45 AM, Dahlia Trimble wrote: > > I believe python supports very large integers. Try this in your python > interpreter: > >>>> bigint = 2**(2**16) >>>> print bigint > > In fact, python features two built-in integer types: > > plain integers (int) > long integers (long) > > According to the python documentation on built-in numeric types, python's > int is implemented using long in C. This means it has at least 32 bits, but > can be larger on certain systems. E.g. on a 64bit Linux, it'll be 64 bits > long, as I've just verified myself: > >>>> import sys >>>> 2 ** 63 - 1 == sys.maxint > True > > Python's long is unlimited in size (at the cost of performance). > Conveniently, python converts from int to long as needed, even if no longs > are amongst the operands: > >>>> sys.maxint > 9223372036854775807 >>>> sys.maxint + 1 > 9223372036854775808L > > (The L postfix indicates a long literal.) Conversion from long to int > doesn't happen implicitly, but can be done explicitly if wanted. > > Cheers, > Boroondas > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > From ohmeadhbh@gmail.com Sat May 7 10:02:47 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806F8E06C0 for ; Sat, 7 May 2011 10:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYa1gWE9thPc for ; Sat, 7 May 2011 10:02:46 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC19E0691 for ; Sat, 7 May 2011 10:02:45 -0700 (PDT) Received: by wyb29 with SMTP id 29so3528469wyb.31 for ; Sat, 07 May 2011 10:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WkMyB+SP+JY/hJ/eOb3sdYLtgnJksdepnOQYV/YwJPA=; b=JasZ0ddncmOJL5OtdeTFFTQ2TSYVTuzYIaBaaf/VFw2PeW/TJusnPuagVA+wK+amaR eADV2q/a5Pw+zeG+XLuPxvxNgac70JZLO/9iJe9jDrSjuMzJ3Yu1Yl5Kq2gcPAaLtKEq MlEBHRiKxgfuk2zmh3FEq5itg5htRL8yNne3g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=r7s6GhtxCK7WWvJA+5OpqsdIcMO7jWEaTeqpfwV8pL1zqnkand1OfZXWrGcsFU1+AE LfzlbUbAcLXeJw+5Y7/zj7o5vWv+IzxXnDz0LGx6OAeSFmo8k/6f1lyYNRUBCCdk/ZCe HtkLXoAPgux7spL0ipubVjYL8CHGuYSyybfjk= Received: by 10.216.79.5 with SMTP id h5mr4932555wee.110.1304787442076; Sat, 07 May 2011 09:57:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.154.1 with HTTP; Sat, 7 May 2011 09:57:02 -0700 (PDT) In-Reply-To: <4DC569FB.90608@boroon.dasgupta.ch> References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> <4DC569FB.90608@boroon.dasgupta.ch> From: Meadhbh Hamrick Date: Sat, 7 May 2011 09:57:02 -0700 Message-ID: To: Boroondas Gupte Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org Subject: Re: [vwrap] Python integer types, again (was: The tag... is the group still interested in LLSD or DSD?) X-BeenThere: vwrap@ietf.org 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: Sat, 07 May 2011 17:02:47 -0000 well. yes. for modern python versions. i think 2.2 was the first version to use longs instead of ints. -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Sat, May 7, 2011 at 8:49 AM, Boroondas Gupte wrote: > On 05/07/2011 05:19 PM, Meadhbh Hamrick wrote: > > Josh, it's even worse than that. > > Python inherits the integer size from the compiler that generated it. > So, if you compile python on a system with a 16 bit int (which used to > be pretty common in some embedded systems) you get a version of python > that uses 16 bit ints. > > Fortunately, it's not as bad as that. While it's true that python inherits > the integer size from the compiler, it doesn't use C's int to implements > python ints, but C's long and thus can guarantee a precision of at least 32 > bits. Also, due to seamless conversion (see my other post) to python's > (unlimited precision) long, the actual size of python's int (or the > implementation dependence of that size) can probably be ignored most of the > time, except maybe for performance considerations. > > Cheers, > Boroondas > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > From dzonatas@gmail.com Sat May 7 10:23:08 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A50AE06C0 for ; Sat, 7 May 2011 10:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AW9-EJ9effbS for ; Sat, 7 May 2011 10:23:07 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF90E0691 for ; Sat, 7 May 2011 10:23:07 -0700 (PDT) Received: by pwi5 with SMTP id 5so2434270pwi.31 for ; Sat, 07 May 2011 10:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oCKjT7IhLE9QEEMJDT7YOJiw9oCBgTfhXdXB/BDwDvg=; b=Rp7OJl850mM5W4gkgJuOnb48NX/aPzYNk857GMk8mhRugCcx+HoI8eoA4dwPClEUh8 PDWVBC9VSURI0DDuZGmsEYeinQq97mXHSkJZDd4c98UUDuINxPHzafFbMxE+wdSXRBfL FIEKw27s9HcMfXMuyH/WUEorCtEp8Oy6HQt6c= 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=mCXVYLEb4vIe65u9O1pK3dJL2jYwBoo1LSxdLCT7pf51zlVY7J5hWU5yEPsW5u28Xb b9yckd3BFir6Org++DTmz9VVvgAOkcyd/hnx1ClDydRfzoLDXJcYhJ83SvwE/Cwo0jPL zkpEteDrikveI99yTb+CRGp7VawQdWSiM9OIQ= Received: by 10.142.143.15 with SMTP id q15mr2570296wfd.60.1304788986594; Sat, 07 May 2011 10:23:06 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id f4sm2930901pbs.36.2011.05.07.10.23.05 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 May 2011 10:23:05 -0700 (PDT) Message-ID: <4DC57FBD.6010103@gmail.com> Date: Sat, 07 May 2011 10:22:05 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sat, 07 May 2011 17:23:08 -0000 That is why there are differences in transmit type and expect type. That is not obvious unless without source code. Self-documents that transistion possibility. On 05/07/2011 12:45 AM, Dahlia Trimble wrote: > I believe python supports very large integers. Try this in your python > interpreter: > > >>> bigint = 2**(2**16) > >>> print bigint > > I first became aware of missing integer types in LLSD when I was > coding the event queue messages to support group chat in > OpenSimulator. It seems that "region handles" are 64 bit integers in > the LL protocols but are encoded as a base64 encoded binary blob in > LLSD as LLSD has no support for integers larger than 32 bits. I > suspect that changing LLSD to have larger integer types might create > some compatibility issues with existing implementations that expect to > use the binary blob. > > > On Fri, May 6, 2011 at 9:18 AM, Joshua Bell > wrote: > > On Thu, May 5, 2011 at 11:46 PM, Vaughn Deluca > > 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 > types. > > 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 > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Sat May 7 11:06:15 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1AAE0707 for ; Sat, 7 May 2011 11:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJEDV5X6-UPO for ; Sat, 7 May 2011 11:06:14 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id D6CDAE071F for ; Sat, 7 May 2011 11:06:14 -0700 (PDT) Received: by pxi2 with SMTP id 2so2535465pxi.38 for ; Sat, 07 May 2011 11:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lOJKohLD9sh9cCfKaHVWD0UwkYjBX167BxHNOw9gieM=; b=JDRBfPjHnlxVKmpWtS0mwonYO9UktKtDwH+7giBOQq3h3b4psgZAIaSQxdsdHVUvc0 mNULfC5J3eTjP3yOWQ8+ZiChE8yc+D8wcgb9zVEernzgEEuEIb3lebk4FLBJAW73gEVS qgqE+BSitUFKucqfuSwDRbGBT9wgbO7jaq55k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=R89PJR5GTKaWYTaYpu32drCU/xo5+X4q7rlR0xLIJPiNzTBWfxb3L8nqVH9yH9gOfS PpCpQgEW0jPL834zq8LY5MQ5UJfH/VMlCgLeKaxklfC34yo8S+ebrPRaR/eKdbx7qk8B uJDuiCWPtfA2YAISbMuWMjnwFnSu3BKuySJBs= Received: by 10.68.47.2 with SMTP id z2mr1591309pbm.327.1304791574307; Sat, 07 May 2011 11:06:14 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id l3sm2946442pbq.75.2011.05.07.11.06.12 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 May 2011 11:06:13 -0700 (PDT) Message-ID: <4DC589D9.3070705@gmail.com> Date: Sat, 07 May 2011 11:05:13 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Dzonatas Sol References: <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> <4DC57FBD.6010103@gmail.com> In-Reply-To: <4DC57FBD.6010103@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sat, 07 May 2011 18:06:15 -0000 To answer the outstanding question, 6 million lines of code and each of them were documented in comments. I simply said to the outsourcer there is the problem and figure every comment costs $1. How much is it to hire somebody to update one line of code plus one comment? I didn't get the job, yet the the outsourcer did! Amicable. On 05/07/2011 10:22 AM, Dzonatas Sol wrote: > That is why there are differences in transmit type and expect type. > That is not obvious unless without source code. Self-documents that > transistion possibility. > > > On 05/07/2011 12:45 AM, Dahlia Trimble wrote: >> I believe python supports very large integers. Try this in your >> python interpreter: >> >> >>> bigint = 2**(2**16) >> >>> print bigint >> >> I first became aware of missing integer types in LLSD when I was >> coding the event queue messages to support group chat in >> OpenSimulator. It seems that "region handles" are 64 bit integers in >> the LL protocols but are encoded as a base64 encoded binary blob in >> LLSD as LLSD has no support for integers larger than 32 bits. I >> suspect that changing LLSD to have larger integer types might create >> some compatibility issues with existing implementations that expect >> to use the binary blob. >> >> >> On Fri, May 6, 2011 at 9:18 AM, Joshua Bell > > wrote: >> >> On Thu, May 5, 2011 at 11:46 PM, Vaughn Deluca >> > 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 >> types. >> >> 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 >> >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From sllists@boroon.dasgupta.ch Sat May 7 13:29:36 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C50E06F6 for ; Sat, 7 May 2011 13:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nb4oj4giBKlf for ; Sat, 7 May 2011 13:29:34 -0700 (PDT) Received: from datendelphin.net (india288.server4you.de [85.25.150.202]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBE1E06F3 for ; Sat, 7 May 2011 13:29:33 -0700 (PDT) Received: from [192.168.1.107] (adsl-89-217-134-70.adslplus.ch [89.217.134.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by datendelphin.net (Postfix) with ESMTPSA id 859622E045 for ; Sat, 7 May 2011 22:33:01 +0200 (CEST) Message-ID: <4DC5ABAB.5040306@boroon.dasgupta.ch> Date: Sat, 07 May 2011 22:29:31 +0200 From: Boroondas Gupte User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [vwrap] What does "ADT" mean? X-BeenThere: vwrap@ietf.org 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: Sat, 07 May 2011 20:29:36 -0000 Sorry to come up here with a 'language' issue, but this has confused me a bit. (Maybe because I'm not a native speaker of English.) The abbreviation "ADT" has been used on this list a lot recently. (I think mainly by Morgaine.) To me, it seems like in most of the uses here on the list, it has to have the meaning "abstract type system" to make any sense. Though, the only related expansion of the abbreviation I can find is "abstract data type", which isn't a synonym of "abstract type system", as far as I can tell. (If I've understood correctly, an abstract type system is composed from abstract data types and conversion rules between them.) If the use of "ADT" to mean "abstract type system" was just a mistake that got carried on for a short time, I suggest to cease using it in that meaning to avoid confusion and use the abbreviation only when you actually mean "abstract data type". Either write out "abstract type system" fully when you intend that meaning, or use a different abbreviation - maybe "ATS" or "ADTS" (for "abstract data type system"). Cheers, Boroondas From dzonatas@gmail.com Sat May 7 14:48:03 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E89DE06BA for ; Sat, 7 May 2011 14:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.974 X-Spam-Level: X-Spam-Status: No, score=-3.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdiBRVw8mrjS for ; Sat, 7 May 2011 14:48:02 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 15E92E067A for ; Sat, 7 May 2011 14:48:01 -0700 (PDT) Received: by pzk5 with SMTP id 5so2500731pzk.31 for ; Sat, 07 May 2011 14:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3w/B0AyNx8Mz2b8SIkSUi6LvmhmQGD1KHQioeIKvQkw=; b=LdWRSV5THtC8QwvuqqpL67iFN85Zk/tfoYKDqCtlJjilwghHh4W3NV3YsY5e4XhSNk KaXBifExEb3YlnaW/zBHzb5/jNVZrc680/wbpvgeDghRmaNikfe2bqjjWaOFMRzSXVG/ UMEYbt+sW1DCUt3cB9clrIPj/hpIn6S7USm14= 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=OOJMU2t8d3v/Fu5i4d0RVyrec6dNW6uguKYD+CrxSBZHPSDQR5hwFcxhoGxq6rM5KW kdoK5PGWile21j1AL8RW4cfwsnNylBiKPDs1Xr4R/8U+K1iLE40EaM3iaJhbx/yI2sHT T+TII62CU5JC4yaaqO8v20o5VZaryVBOX3qYs= Received: by 10.68.25.102 with SMTP id b6mr7423236pbg.14.1304804881479; Sat, 07 May 2011 14:48:01 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id c6sm129006pbu.35.2011.05.07.14.48.00 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 May 2011 14:48:00 -0700 (PDT) Message-ID: <4DC5BDD5.7080103@gmail.com> Date: Sat, 07 May 2011 14:47:01 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC5ABAB.5040306@boroon.dasgupta.ch> In-Reply-To: <4DC5ABAB.5040306@boroon.dasgupta.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] What does "ADT" mean? X-BeenThere: vwrap@ietf.org 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: Sat, 07 May 2011 21:48:03 -0000 +1 On 05/07/2011 01:29 PM, Boroondas Gupte wrote: > Sorry to come up here with a 'language' issue, but this has confused me > a bit. (Maybe because I'm not a native speaker of English.) > > The abbreviation "ADT" has been used on this list a lot recently. (I > think mainly by Morgaine.) To me, it seems like in most of the uses here > on the list, it has to have the meaning "abstract type system" to make > any sense. Though, the only related expansion of the abbreviation I can > find is "abstract data type", which isn't a synonym of "abstract type > system", as far as I can tell. (If I've understood correctly, an > abstract type system is composed from abstract data types and conversion > rules between them.) > > If the use of "ADT" to mean "abstract type system" was just a mistake > that got carried on for a short time, I suggest to cease using it in > that meaning to avoid confusion and use the abbreviation only when you > actually mean "abstract data type". Either write out "abstract type > system" fully when you intend that meaning, or use a different > abbreviation - maybe "ATS" or "ADTS" (for "abstract data type system"). > > Cheers, > Boroondas > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Sat May 7 18:47:35 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B8BE0680 for ; Sat, 7 May 2011 18:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tV3DZK+4P0e7 for ; Sat, 7 May 2011 18:47:34 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 64899E0678 for ; Sat, 7 May 2011 18:47:34 -0700 (PDT) Received: by qwc23 with SMTP id 23so3173332qwc.31 for ; Sat, 07 May 2011 18:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=xtMecgqChtPxtlngThKPVbLNcv8RwIjvaicBR1ZR3KQ=; b=FMgR0jprzNjJVQB6BYgVJn34nclNHBdQqwGdq90ZJi+HYgbCFFfpKDjOKO/kA3Agko +QZIY2LLrVZsutucMf+D6O2STrRgmqKWLxm05gw6pjd2xS9zcCBbcVKbILPYlLMQI1VJ Vqp3galju6YuSfyU7QyOe8ZRr4W6uausfiskM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=sbyj+FCg5ZPzj2RL3CIi8srzLIas7wxTGa5zfTLWd4AppipjGG/HogVycXJjtjRQ+I cLGuzxlvzoAmXEDGv6RS+w3edEI1eGxKgMNlUKUUpU20bGUMZrSPJ+9+f6f9P+qwEnzX tyGzH1nJncMOA9i8wltu5GqWLDct2/GSsoTh0= MIME-Version: 1.0 Received: by 10.229.127.96 with SMTP id f32mr3826857qcs.139.1304819251508; Sat, 07 May 2011 18:47:31 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Sat, 7 May 2011 18:47:31 -0700 (PDT) In-Reply-To: <4DC5BDD5.7080103@gmail.com> References: <4DC5ABAB.5040306@boroon.dasgupta.ch> <4DC5BDD5.7080103@gmail.com> Date: Sun, 8 May 2011 02:47:31 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cdf65f2fb74f004a2b9e7bb Subject: Re: [vwrap] What does "ADT" mean? X-BeenThere: vwrap@ietf.org 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: Sun, 08 May 2011 01:47:35 -0000 --000e0cdf65f2fb74f004a2b9e7bb Content-Type: text/plain; charset=ISO-8859-1 ADT means Abstract Data Type. A system of abstract data types (such as LLSD) has no accepted name or abbreviation, but commonly one says "ADT system", or where context allows an unambiguous interpretation, simply "ADT". No mystery there, it has been so for decades of common usage in Computing. :-) Morgaine. ======================= On Sat, May 7, 2011 at 10:47 PM, Dzonatas Sol wrote: > +1 > > > On 05/07/2011 01:29 PM, Boroondas Gupte wrote: > >> Sorry to come up here with a 'language' issue, but this has confused me >> a bit. (Maybe because I'm not a native speaker of English.) >> >> The abbreviation "ADT" has been used on this list a lot recently. (I >> think mainly by Morgaine.) To me, it seems like in most of the uses here >> on the list, it has to have the meaning "abstract type system" to make >> any sense. Though, the only related expansion of the abbreviation I can >> find is "abstract data type", which isn't a synonym of "abstract type >> system", as far as I can tell. (If I've understood correctly, an >> abstract type system is composed from abstract data types and conversion >> rules between them.) >> >> If the use of "ADT" to mean "abstract type system" was just a mistake >> that got carried on for a short time, I suggest to cease using it in >> that meaning to avoid confusion and use the abbreviation only when you >> actually mean "abstract data type". Either write out "abstract type >> system" fully when you intend that meaning, or use a different >> abbreviation - maybe "ATS" or "ADTS" (for "abstract data type system"). >> >> Cheers, >> Boroondas >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --000e0cdf65f2fb74f004a2b9e7bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ADT means Abstract Data Type.

A system of abstract data types (such = as LLSD) has no accepted name or abbreviation, but commonly one says "= ADT system", or where context allows an unambiguous interpretation, si= mply "ADT".

No mystery there, it has been so for decades of common usage in Computi= ng. :-)


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

O= n Sat, May 7, 2011 at 10:47 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
+1


On 05/07/2011 01:29 PM, Boroondas Gupte wrote:
Sorry to come up here with a 'language' issue, but this has confuse= d me
a bit. (Maybe because I'm not a native speaker of English.)

The abbreviation "ADT" has been used on this list a lot recently.= (I
think mainly by Morgaine.) To me, it seems like in most of the uses here on the list, it has to have the meaning "abstract type system" to= make
any sense. Though, the only related expansion of the abbreviation I can
find is "abstract data type", which isn't a synonym of "= abstract type
system", as far as I can tell. (If I've understood correctly, an abstract type system is composed from abstract data types and conversion rules between them.)

If the use of "ADT" to mean "abstract type system" was = just a mistake
that got carried on for a short time, I suggest to cease using it in
that meaning to avoid confusion and use the abbreviation only when you
actually mean "abstract data type". Either write out "abstra= ct type
system" fully when you intend that meaning, or use a different
abbreviation - maybe "ATS" or "ADTS" (for "abstrac= t data type system").

Cheers,
Boroondas
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

=A0


--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant


_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--000e0cdf65f2fb74f004a2b9e7bb-- From morgaine.dinova@googlemail.com Sat May 7 19:22:35 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9E9E0680 for ; Sat, 7 May 2011 19:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.89 X-Spam-Level: X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyW4hfHKrv5F for ; Sat, 7 May 2011 19:22:33 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 44D7FE064B for ; Sat, 7 May 2011 19:22:33 -0700 (PDT) Received: by qwc23 with SMTP id 23so3180230qwc.31 for ; Sat, 07 May 2011 19:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Vmnb6JFn2/DXrbI8KS024jH1632E7pJnn4ZqZbh8d00=; b=uOd81+atBPxPylc8lHR9FhZcd7SCHEEcc/dDaKYfFLRGK/hlbeJ6W+wHlP0r0cab9N kTNJyoicI/V+D/HHshOSi4yONGzChS9PSC7wTUqF/hpZIu9CFhJUh9MU9KQ4kOjYPvc+ KM5+ew44qqIPCpnyBfKISnhaViiKFxfz+rIWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=KwR6KdMxMNYYzvoYFTC10/EadkyhJduODEYT8lhIGcxjOdXUB86F/AEJzZIP9s/f/R RZ4I9q0mEdqHoOvPlVhGGbLv5b5jVkdiVPAVQoHwt95jVPWPeRJl1VOfWzLHWi6vv3/+ zqFad5GCHf5xmoLMvZmL3+IZ6GK5UgyM2Ju+c= MIME-Version: 1.0 Received: by 10.229.44.141 with SMTP id a13mr3758891qcf.101.1304821352480; Sat, 07 May 2011 19:22:32 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Sat, 7 May 2011 19:22:32 -0700 (PDT) In-Reply-To: References: <4DC15504.3090503@gmail.com> <4DC160F0.1030201@gmail.com> <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> Date: Sun, 8 May 2011 03:22:32 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=001636831fa035bfbf04a2ba6541 Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sun, 08 May 2011 02:22:35 -0000 --001636831fa035bfbf04a2ba6541 Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 7, 2011 at 4:19 PM, Meadhbh Hamrick wrote: > > One of the reasons I'm not especially happy with LLSD is that it does > not distinguish between the abstract type system and the transfer > syntax. I agree 100%. If one has the worthy goal of defining a semantically complete ADT system, then the last thing one should do is to couple it to specific serializations, and even less to specific language bindings. That was a total mistake in LLSD in practical terms. If you want to make a types system efficiently implementable, then stick to the requirements of hardware architectures which evolve slowly over decades, like x86. Languages evolve to much shorter timescales, and a good ADT system should be usable with whatever language comes along. Furthermore, efficient serializations and languages are devised all the time because efficiency is a much-sought engineering goal. Unless you provide your ADT system with all the normal primitive types for the common hardware architectures, you are inherently discriminating against the most efficient serializations and languages, LLSD is guilty of this, which is what I'm trying to correct for VWRAP. It's not hard to achieve, but it needs the will for progress. Morgaine. ================ On Sat, May 7, 2011 at 4:19 PM, Meadhbh Hamrick wrote: > Hey Dahlia, > > Yes, the way the legacy protocol handles region handles is a hack (at > best.) My suggestion has always been to, since we're creating a new > protocol, use something other than a 64 bit integer for a region > handle. IIRC, we were planning on revamping this bit of the protocol > to use a URL as a region handle to avoid the problem of requiring a > global region handle to host registry. > > But that's kind of off-topic, assuming the topic is bigints in LLSD. > > One of the reasons I'm not especially happy with LLSD is that it does > not distinguish between the abstract type system and the transfer > syntax. Changing the existing LLSD to support big integers would > require a modification to the binary serialization. The JSON and XML > serializations are fine, they don't add size restrictions to integer > fields at the transfer syntax level. > > So you would likely have to add a new tag to the binary serialization > for "multi precision integer" which was simply a string of 32 bit ints > in network order. Or you would have to change the semantics of the > existing integer encoding to support multi precision ints. Either way > you have to change the existing LLSD binary serialization. > > As a historical note, there was a bit of debate on this topic inside > the lab. One side wanted Radix 10 Floats and MP Ints and the other > side suggesting that once you opened the doors to expansion, there was > no telling where you would stop and pointing out that you can do MP > Ints as long as you bury them in binary strings. Ultimately, those of > us who supported Radix 10 floats and MP Ints were laid off before them > what supported a minimal set of types. > > &c &c > m > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Sat, May 7, 2011 at 12:45 AM, Dahlia Trimble > wrote: > > I believe python supports very large integers. Try this in your python > > interpreter: > > > >>>> bigint = 2**(2**16) > >>>> print bigint > > > > I first became aware of missing integer types in LLSD when I was coding > the > > event queue messages to support group chat in OpenSimulator. It seems > that > > "region handles" are 64 bit integers in the LL protocols but are encoded > as > > a base64 encoded binary blob in LLSD as LLSD has no support for integers > > larger than 32 bits. I suspect that changing LLSD to have larger integer > > types might create some compatibility issues with existing > implementations > > that expect to use the binary blob. > > > > > > On Fri, May 6, 2011 at 9:18 AM, Joshua Bell wrote: > >> > >> On Thu, May 5, 2011 at 11:46 PM, Vaughn Deluca > > >> 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 > >> types. > >> 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 > >> > >> _______________________________________________ > >> vwrap mailing list > >> vwrap@ietf.org > >> https://www.ietf.org/mailman/listinfo/vwrap > >> > > > > > > _______________________________________________ > > vwrap mailing list > > vwrap@ietf.org > > https://www.ietf.org/mailman/listinfo/vwrap > > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --001636831fa035bfbf04a2ba6541 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, May 7, 2011 at 4:19 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com= > wrote:

One of the reasons I'm not especially happy with LLSD is that it does not distinguish between the abstract type system and the transfer
syntax.


I agree 100%.=A0 If one has the worthy goa= l of defining a semantically complete ADT system, then the last thing one s= hould do is to couple it to specific serializations, and even less to speci= fic language bindings.=A0 That was a total mistake in LLSD in practical ter= ms.

If you want to make a types system efficiently implementable, then stic= k to the requirements of hardware architectures which evolve slowly over de= cades, like x86.=A0 Languages evolve to much shorter timescales, and a good= ADT system should be usable with whatever language comes along.

Furthermore, efficient serializations and languages are devised all the= time because efficiency is a much-sought engineering goal.=A0 Unless you p= rovide your ADT system with all the normal primitive types for the common h= ardware architectures, you are inherently discriminating against the most e= fficient serializations and languages,

LLSD is guilty of this, which is what I'm trying to correct for VWR= AP.=A0 It's not hard to achieve, but it needs the will for progress.

Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

On Sat, May 7, 2011 at 4:19 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com= > wrote:
Hey Dahlia,

Yes, the way the legacy protocol handles region handles is a hack (at
best.) My suggestion has always been to, since we're creating a new
protocol, use something other than a 64 bit integer for a region
handle. IIRC, we were planning on revamping this bit of the protocol
to use a URL as a region handle to avoid the problem of requiring a
global region handle to host registry.

But that's kind of off-topic, assuming the topic is bigints in LLSD.
One of the reasons I'm not especially happy with LLSD is that it does not distinguish between the abstract type system and the transfer
syntax. Changing the existing LLSD to support big integers would
require a modification to the binary serialization. The JSON and XML
serializations are fine, they don't add size restrictions to integer fields at the transfer syntax level.

So you would likely have to add a new tag to the binary serialization
for "multi precision integer" which was simply a string of 32 bit= ints
in network order. Or you would have to change the semantics of the
existing integer encoding to support multi precision ints. Either way
you have to change the existing LLSD binary serialization.

As a historical note, there was a bit of debate on this topic inside
the lab. One side wanted Radix 10 Floats and MP Ints and the other
side suggesting that once you opened the doors to expansion, there was
no telling where you would stop and pointing out that you can do MP
Ints as long as you bury them in binary strings. Ultimately, those of
us who supported Radix 10 floats and MP Ints were laid off before them
what supported a minimal set of types.

&c &c
m
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadh= bh.org/ * OhMe= adhbh@gmail.com



On Sat, May 7, 2011 at 12:45 AM, Dahlia Trimble = <dahliatrim= ble@gmail.com> wrote:
> I believe python supports very large integers. Try this in your python=
> interpreter:
>
>>>> bigint =3D 2**(2**16)
>>>> print bigint
>
> I first became aware of missing integer types in LLSD when I was codin= g the
> event queue messages to support group chat in OpenSimulator. It seems = that
> "region handles" are 64 bit integers in the LL protocols but= are encoded as
> a base64 encoded binary blob in LLSD as LLSD has no support for intege= rs
> larger than 32 bits. I suspect that changing LLSD to have larger integ= er
> types might create some compatibility issues with existing implementat= ions
> that expect to use the binary blob.
>
>
> On Fri, May 6, 2011 at 9:18 AM, Joshua Bell <josh@lindenlab.com> wrote:
>>
>> On Thu, May 5, 2011 at 11:46 PM, Vaughn Deluca <vaughn.deluca@gmail.com&g= t;
>> wrote:
>>>
>>> What were the reasons to allow onl a single integer type? Ther= e 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 y= ou
>> 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 serializatio= n
>> formats that explicitly specified the type of values - XML, binary= , and
>> "notation" - a compact text serialization intermediate i= n size between
>> binary and XML. The IETF drafts dropped notation and added JSON. T= he JSON
>> serialization was "lossy" as LLSD describes types and va= lues 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 a= s a date
>> by the receiver results in the original Date by the string->dat= e 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 th= is 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 functiona= l within
>> VWRAP interoperation. Therefore, there was no push to ensure LLSD = "v1" was
>> internally extensible or comprehensive for all imaginable scalar/s= tructured
>> types.
>> Anyway... if contributors have implementation of abstract data typ= e
>> systems that share characteristics with LLSD and are thinking abou= t adding
>> additional scalar/structured types, they should look at the issues= with both
>> implementation languages and serialization formats.
>> -- Josh
>>
>> _______________________________________________
>> vwrap mailing list
>> vwrap@ietf.org=
>> https://www.ietf.org/mailman/listinfo/vwrap
>>
>
>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org=
> https://www.ietf.org/mailman/listinfo/vwrap
>
>
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--001636831fa035bfbf04a2ba6541-- From dzonatas@gmail.com Sat May 7 19:56:13 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4D1E0680 for ; Sat, 7 May 2011 19:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.963 X-Spam-Level: X-Spam-Status: No, score=-3.963 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbM2I4jJcgE1 for ; Sat, 7 May 2011 19:56:13 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 021B7E0674 for ; Sat, 7 May 2011 19:56:12 -0700 (PDT) Received: by pxi2 with SMTP id 2so2643788pxi.38 for ; Sat, 07 May 2011 19:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ACEagqBg3rAnIcq2L+RrzW2NxhTwXx6X8loobE/zdB4=; b=O4O+g6VXfwJVlAC/xyMlhzr9rY0ZZTu6PGCFPHGyjEX3+PGF5+a5QefumxEtBGlQgM Lt2w+M/rh2AfmJ24HmBRrrwsfzfH8Odk4U8uNVEMIlqZ1icCcIap9aB6t0Wje8u87f5x oxn8qUGR+aKWwsIh6TN92u4CFlBw4rSO+nGaw= 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=gMZLlNi25MOirmI2sgcSCiA36rCyZZLQ1OBHYzRrvBB86RptiNn4CDrN30L0EWsde7 zgvWeHIEcz9i/IgrEMnU9s24UFOE+n6rkXicD3ex+lvFXKw5GKOQr9LkT8bAiL3hjP1M EUWrKj4yl4vB15ld4BTfk2yadE4tF0CPSggB4= Received: by 10.68.15.101 with SMTP id w5mr7303556pbc.134.1304823372496; Sat, 07 May 2011 19:56:12 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id o4sm3173623pbl.98.2011.05.07.19.56.11 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 May 2011 19:56:11 -0700 (PDT) Message-ID: <4DC60610.3040606@gmail.com> Date: Sat, 07 May 2011 19:55:12 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sun, 08 May 2011 02:56:13 -0000 I vote nay on Morgain's attempt at "social engineering" LLSD code any further, especially in the eyes and ears of IETF's Trust, replacement of LLSD with "ADT" and such semantics is out of scope. Let's continue our mutations (IL) and evolve! Morgaine, you seem to have an invested interest in specific hardware. We need simple, language agnostic (VM) approaches, not language specific approaches. Please keep this simple to additional types or clarification. DSP does not always means dynamic signal processor. On 05/07/2011 07:22 PM, Morgaine wrote: > Furthermore, efficient serializations and languages are devised all > the time because efficiency is a much-sought engineering goal.� Unless > you provide your ADT system with all the normal primitive types for > the common hardware architectures, you are inherently discriminating > against the most efficient serializations and languages, > > LLSD is guilty of this, which is what I'm trying to correct for > VWRAP.� It's not hard to achieve, but it needs the will for progress. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Sat May 7 20:45:40 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F706E0669 for ; Sat, 7 May 2011 20:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAqQrd21Kqty for ; Sat, 7 May 2011 20:45:39 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE85E064B for ; Sat, 7 May 2011 20:45:38 -0700 (PDT) Received: by qyk29 with SMTP id 29so393802qyk.10 for ; Sat, 07 May 2011 20:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ozo0rGZ/TP9Oe6gP2M3QorERuHxVEy73ndmba9dZUBc=; b=ZAgG/JUgzfOfHQ5MZEL7YnBAVWtFbqIBeCnaGrwMD91BtdCRAOWAjoas/kxq98rlMp llViMDGz12RrMHbN+Ir/JYDGEzSmAqLlgVNVAjiSG90G8ubQ3fnqKUEVwTP1QfkG89DV nqm75y+F0Qy8rW4A9xT5VSFhawcxlx03YWhLA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=riThnx2K68lsA81agfFIAbrmjcrSenHtOYJc1RN2A/c8SpqSr85oqc1/fbGyn99/2m EJDMQ8fmazFDMYc/LXnh3XxJZeEauF0a8Y1+wkLEUD/+hDSNZJTxQDuKtatboVka35OF yoAZ9Lil6N36EO03itcU56wgqDC+IqhDrzL6s= MIME-Version: 1.0 Received: by 10.229.44.141 with SMTP id a13mr3797778qcf.101.1304826338134; Sat, 07 May 2011 20:45:38 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Sat, 7 May 2011 20:45:37 -0700 (PDT) In-Reply-To: <4DC60610.3040606@gmail.com> References: <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> <4DC60610.3040606@gmail.com> Date: Sun, 8 May 2011 04:45:37 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=001636831fa060cbf804a2bb8e14 Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sun, 08 May 2011 03:45:40 -0000 --001636831fa060cbf804a2bb8e14 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, May 8, 2011 at 3:55 AM, Dzonatas Sol wrote: > We need simple, language agnostic (VM) approaches, not language specific > approaches. It appears that you haven't understood what I've written. I'm arguing * against* the language-specificity upon which LLSD was designed, and broadening its primitive data types so that all languages are supported well, including the most efficient ones. Apparently you agree with me, according to your last statement. The current LLSD was designed on the basis that its primitive data types were supported directly by type empoverished languages like Python and ECMAscript, as Joshua explained to us. That language-specific approach is extremely poor, and results in inefficient serializations and inefficient bindings to the most efficient languages. That needs to be corrected so that future virtual worlds don't suffer from the poor design approach used previously. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D On Sun, May 8, 2011 at 3:55 AM, Dzonatas Sol wrote: > I vote nay on Morgain's attempt at "social engineering" LLSD code any > further, especially in the eyes and ears of IETF's Trust, replacement of > LLSD with "ADT" and such semantics is out of scope. Let's continue our > mutations (IL) and evolve! > > Morgaine, you seem to have an invested interest in specific hardware. We > need simple, language agnostic (VM) approaches, not language specific > approaches. Please keep this simple to additional types or clarification. > DSP does not always means dynamic signal processor. > > > On 05/07/2011 07:22 PM, Morgaine wrote: > >> Furthermore, efficient serializations and languages are devised all the >> time because efficiency is a much-sought engineering goal.=EF=BF=BD Unle= ss you >> provide your ADT system with all the normal primitive types for the comm= on >> hardware architectures, you are inherently discriminating against the mo= st >> efficient serializations and languages, >> >> LLSD is guilty of this, which is what I'm trying to correct for VWRAP.= =EF=BF=BD >> It's not hard to achieve, but it needs the will for progress. >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --001636831fa060cbf804a2bb8e14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, May 8, 2011 at 3:55 AM, Dzonatas Sol <dzonatas@gmail.com> wrote:
=
We need simple, language agnostic (VM) approaches, not language specific=20 approaches.


It appears that you haven't unders= tood what I've written.=C2=A0 I'm arguing against the langua= ge-specificity upon which LLSD was designed, and broadening its primitive d= ata types so that all languages are supported well, including the most effi= cient ones.

Apparently you agree with me, according to your last statement.

= The current LLSD was designed on the basis that its primitive data types we= re supported directly by type empoverished languages like Python and ECMAsc= ript, as Joshua explained to us.=C2=A0 That language-specific approach is e= xtremely poor, and results in inefficient serializations and inefficient bi= ndings to the most efficient languages.

That needs to be corrected so that future virtual worlds don't suff= er from the poor design approach used previously.


Morgaine.
<= br>


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

On Sun, May 8, 2011 at 3:55 AM, Dzonatas Sol <dzonatas@gmail.com> wrote:
=
I vote nay on Morgain's attempt at "social engineering" LLSD = code any further, especially in the eyes and ears of IETF's Trust, repl= acement of LLSD with "ADT" and such semantics is out of scope. Le= t's continue our mutations (IL) and evolve!

Morgaine, you seem to have an invested interest in specific hardware. We ne= ed simple, language agnostic (VM) approaches, not language specific approac= hes. Please keep this simple to additional types or clarification. DSP does= not always means dynamic signal processor.


On 05/07/2011 07:22 PM, Morgaine wrote:
Furthermore, efficient serializations and languages are devised all the tim= e because efficiency is a much-sought engineering goal.=EF=BF=BD Unless you= provide your ADT system with all the normal primitive types for the common= hardware architectures, you are inherently discriminating against the most= efficient serializations and languages,

LLSD is guilty of this, which is what I'm trying to correct for VWRAP.= =EF=BF=BD It's not hard to achieve, but it needs the will for progress.=


--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

_______________________________________________

--001636831fa060cbf804a2bb8e14-- From dzonatas@gmail.com Sat May 7 21:39:24 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFDEE069D for ; Sat, 7 May 2011 21:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upu0EqAZpnwM for ; Sat, 7 May 2011 21:39:22 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEE8E067F for ; Sat, 7 May 2011 21:39:21 -0700 (PDT) Received: by pxi2 with SMTP id 2so2663557pxi.38 for ; Sat, 07 May 2011 21:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nYp3ZBcMwMuiTZyMWMz1qo/ePUPeyoMVGknGagpLMlQ=; b=QdJ24LzyLULRCfRAOpTIiLcPNRg1WEbKfOcvE9zLCOiUNawRUoNZ5ghACWypXGGrvP Ca1xjNrmnxdbjUjVvnHxzw79ha0J+M0qlDmrn6I9E30lyOaB2bgGcrb37/CtDHeA5sUN 4WRAJAVDavH69GHv68DHjlOjli6ror7Sp06Lo= 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=HgKeOumS1aJa07PEXDxM/Yl+oThFwaVKYSRWJ1KIzgvuTMonq07Bn4T/ob6LLUjGcb v1AyRlrYYlnuCMAFqoaT4UqTsa0++oWaFZoJMoX838zJ3nWRR8hB4UYoGA/CFJi6LyTK 6Judq2PIsmV+89527IXg//H5ZY0/DU+S4zxTQ= Received: by 10.68.50.161 with SMTP id d1mr7664102pbo.439.1304829560759; Sat, 07 May 2011 21:39:20 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id d9sm3224322pbs.10.2011.05.07.21.39.19 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 May 2011 21:39:19 -0700 (PDT) Message-ID: <4DC61E3C.5080307@gmail.com> Date: Sat, 07 May 2011 21:38:20 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> <4DC60610.3040606@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sun, 08 May 2011 04:39:24 -0000 On 05/07/2011 08:45 PM, Morgaine wrote: > It appears that you haven't understood what I've written. Somehow that creation attempt of yours is some magical license to endlessly straw man without identification. I think the good book exists about that already. Don't even start me on how your "social engineering" proposal could affect the colleges and treatment of children or child labor within your walled garden utopia of future virtual worlds. Even you say "that is not how it works" yet you want to change the past... the real past? Let me guess... *whoosh* ...like none of that ever happened or came close. I wonder if U.C. Berkeley Law studies France's law code on microeconomics, and if IETF might fork such license representation... for... homework as assets. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Sat May 7 21:57:41 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E22FE06D5 for ; Sat, 7 May 2011 21:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-212zP8VWJY for ; Sat, 7 May 2011 21:57:35 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id A5B47E0656 for ; Sat, 7 May 2011 21:57:35 -0700 (PDT) Received: by qyk7 with SMTP id 7so3375462qyk.10 for ; Sat, 07 May 2011 21:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=nkhzJGgvzmyp4QxuR/u1ccLC8l8DKIZGhtNDeVF42MU=; b=mSrzPCK4RuTPEBsAOjvPUF/+MFcAuvlSSFKvLZb/z6o6YT8amlo1S6t+gcZz4lFP1O OAZ50OaMWKVX2xOIXleutgUhykZXMWbF53orPnNQ10tuzI4m8gNG5AHnpqe4gcIMsKIr clokeSSoWb1vFbIEXIrXuTWnL5KTzv3pwn5Fs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=VvwKUgKwcdHd3zWVkid5Vh1SQZNrKLettXClD5LALKGrALRJeOzUDyG/mASK1MdUs/ hs5ECy2zuVQjt/ug18xVvQzK48kcUt/j18gmZR8YGVoHZCQlP6kkiGwhdIzIEPe9mASq Vl2JaJ+eGyV21u/dl01PlCEa69s4Yrkhk0t6w= MIME-Version: 1.0 Received: by 10.229.119.134 with SMTP id z6mr2230230qcq.63.1304830654794; Sat, 07 May 2011 21:57:34 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Sat, 7 May 2011 21:57:34 -0700 (PDT) In-Reply-To: <4DC61E3C.5080307@gmail.com> References: <4DC17704.3020201@gmail.com> <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> <4DC60610.3040606@gmail.com> <4DC61E3C.5080307@gmail.com> Date: Sun, 8 May 2011 05:57:34 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd5c94eabcdeb04a2bc8f8a Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sun, 08 May 2011 04:57:41 -0000 --000e0cd5c94eabcdeb04a2bc8f8a Content-Type: text/plain; charset=ISO-8859-1 I have no idea what you're talking about Dzon, but it's a rant and not technical. We're meant to be discussing a technical topic here. On the technical topic of LLSD design, earlier you wrote "*We need simple, language agnostic (VM) approaches, not language specific approaches*", which is exactly the position that I've been maintaining throughout all of this. I'm glad to hear that you agree. Joshua confirmed the language-specific design origins of LLSD for us, so there is no doubting that. It has led even Linden Lab into problems like having to represent handles as a base64 blob through lack of longer integer types than 32 bit. It was a poor design decision even for its originators. VWs further down the road will need a more flexible ADT system to express their needs and to allow more efficient serializations and language bindings to be created. That's why I'm trying to lose the language specificity of LLSD's past and give us more flexible data types to support efficient serialization and fast languages. Morgaine. ======================== On Sun, May 8, 2011 at 5:38 AM, Dzonatas Sol wrote: > On 05/07/2011 08:45 PM, Morgaine wrote: > >> It appears that you haven't understood what I've written. >> > > Somehow that creation attempt of yours is some magical license to endlessly > straw man without identification. I think the good book exists about that > already. > > Don't even start me on how your "social engineering" proposal could affect > the colleges and treatment of children or child labor within your walled > garden utopia of future virtual worlds. Even you say "that is not how it > works" yet you want to change the past... the real past? Let me guess... > *whoosh* ...like none of that ever happened or came close. > > I wonder if U.C. Berkeley Law studies France's law code on microeconomics, > and if IETF might fork such license representation... for... homework as > assets. > > > > -- > > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --000e0cd5c94eabcdeb04a2bc8f8a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have no idea what you're talking about Dzon, but it's a rant and = not technical.=A0 We're meant to be discussing a technical topic here.<= br>
On the technical topic of LLSD design, earlier you wrote "We need simple, language agnostic (VM) approaches, not language specific=20 approaches", which is exactly the position that I've been main= taining throughout all of this.=A0 I'm glad to hear that you agree.
=
Joshua confirmed the language-specific design origins of LLSD for us, s= o there is no doubting that.=A0 It has led even Linden Lab into problems li= ke having to represent handles as a base64 blob through lack of longer inte= ger types than 32 bit.=A0 It was a poor design decision even for its origin= ators.

VWs further down the road will need a more flexible ADT system to expre= ss their needs and to allow more efficient serializations and language bind= ings to be created.=A0 That's why I'm trying to lose the language s= pecificity of LLSD's past and give us more flexible data types to suppo= rt efficient serialization and fast languages.


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Sun, Ma= y 8, 2011 at 5:38 AM, Dzonatas Sol <dzonatas@gmail.com> wrote:
On 05/07/2011 08:45 PM, Morgaine wrote:
It appears that you haven't understood what I've written.

Somehow that creation attempt of yours is some magical license to endlessly= straw man without identification. I think the good book exists about that = already.

Don't even start me on how your "social engineering" proposal= could affect the colleges and treatment of children or child labor within = your walled garden utopia of future virtual worlds. Even you say "that= is not how it works" yet you want to change the past... the real past= ? Let me guess... =A0 *whoosh* ...like none of that ever happened or came c= lose.

I wonder if U.C. Berkeley Law studies France's law code on microeconomi= cs, and if IETF might fork such license representation... for... =A0homewor= k as assets.



--

--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--000e0cd5c94eabcdeb04a2bc8f8a-- From dzonatas@gmail.com Sun May 8 04:53:44 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FA6E067C for ; Sun, 8 May 2011 04:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.942 X-Spam-Level: X-Spam-Status: No, score=-3.942 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFAuaJW2I+rM for ; Sun, 8 May 2011 04:53:43 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id AFC6CE065A for ; Sun, 8 May 2011 04:53:43 -0700 (PDT) Received: by pvh1 with SMTP id 1so2694920pvh.31 for ; Sun, 08 May 2011 04:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7r5QxcgGNu+Nza13Tz+Rj0N6od15btRFc2m74/DywJg=; b=dKfrsM0DmLQCL5I7HA1My3t0qAav4xMCYgu3ELrE3VH5K5kyJXhsCw9hSYSjnWJjAL lnxfQdFoCyIhNFGTh5HS1nqPHkFRmIMzy3buSUHeadObv0HumgY1y361Gv9r7dA2X/EH M9wDyvAHgTYwwpeNBBohb8FlElJi8BtAfbB3I= 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=tYLdmFQa0sovyCcQxSOWMejxx3WleySwHYo7iy0RsC3svnuUBKo8pX5GgdmHOBTvhk +WKq4Iqvps/teuF3z9+t8nXQZ1Pr0t93j7ZeQiAp/10Skd7vVkOs6IKgiGC4M/SUdBhF 2DuAr3/3gRF7FxMXTRNVn1+Ev4Te4Khivn4k8= Received: by 10.68.50.72 with SMTP id a8mr8124543pbo.364.1304855623096; Sun, 08 May 2011 04:53:43 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id r2sm3407708pbp.99.2011.05.08.04.53.41 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 04:53:41 -0700 (PDT) Message-ID: <4DC6840B.9050203@gmail.com> Date: Sun, 08 May 2011 04:52:43 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> <4DC60610.3040606@gmail.com> <4DC61E3C.5080307@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sun, 08 May 2011 11:53:44 -0000 Morgaine, please provide exact text here in the list of what you want updated. There are already enough motion to keep scalar data as scalar. If that alone is too hard to comprehend, then your "designing for the future" ignores complete backward compatibility and the many implementations that already exist. My last post is only on topic of the IETF interest even if merely stated in the obvious truths, just not in words you could twist so easily. We only need simple agreement/disagreements, not staged assignments. Because of that alone, I can't take you seriously on any scale, even when the scope is pushed completely to the limits. Please, just provide your draft-adt-00... so we can focus on consensus and scale. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Sun May 8 05:38:16 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CBDE074F for ; Sun, 8 May 2011 05:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.905 X-Spam-Level: X-Spam-Status: No, score=-2.905 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsEb4y6kSH6i for ; Sun, 8 May 2011 05:38:14 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id C9140E0747 for ; Sun, 8 May 2011 05:38:13 -0700 (PDT) Received: by qyk7 with SMTP id 7so3463525qyk.10 for ; Sun, 08 May 2011 05:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=2W7D5ZDmnexWzy9t0Fh3TFBIY80cTTmk8wlbzo/TpWM=; b=lOROnsTPcN5rvotupUVBl9qTSS7nBpgFMOQIDM/vtJQhLtl+4AUWGQualqNdtFnR/I /Hjr68q+5lWl3oiFkuqFPSsp0RBoVndvmsNe6kcjjRyj/ciMRCxNeYfWICYQ/Vo0IvjL M01vT96CIIH6sxRL/tXddoKePlNwmDxEMUWAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=hSIeX9LCCgYSu+rND7QpiyWiJ9FqUM0+StNiZaFfXydXN98z9/PUNODibRGAR4Q6NA BlBh6iV4kNYtu7Lc0kLcyh/dwCJy9Z/r8dA72xWT09vU7gu+TQfBrhb8tYpf9ZTztD/0 lstD6Ap1Dh0f5iOJfb7tx2hited/NO/o0DlRI= MIME-Version: 1.0 Received: by 10.229.50.193 with SMTP id a1mr4128865qcg.177.1304858292595; Sun, 08 May 2011 05:38:12 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Sun, 8 May 2011 05:38:12 -0700 (PDT) In-Reply-To: <4DC6840B.9050203@gmail.com> References: <4DC1824B.6040609@gmail.com> <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> <4DC60610.3040606@gmail.com> <4DC61E3C.5080307@gmail.com> <4DC6840B.9050203@gmail.com> Date: Sun, 8 May 2011 13:38:12 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00163646cede032ff404a2c2ff21 Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sun, 08 May 2011 12:38:16 -0000 --00163646cede032ff404a2c2ff21 Content-Type: text/plain; charset=ISO-8859-1 On Sun, May 8, 2011 at 12:52 PM, Dzonatas Sol wrote: > Morgaine, please provide exact text here in the list of what you want > updated. That's what we're working on right now. I don't have exact text, we're working out the details first on the list, and once we have those worked out, and we see a consensus forming, then we can start writing an updated document ready for the next draft. > There are already enough motion to keep scalar data as scalar. > I don't know what that means. > > If that alone is too hard to comprehend, then your "designing for the > future" ignores complete backward compatibility and the many implementations > that already exist. We are not designing for backwards compatibility, and there are no implementations of any VWRAP protocol yet, not even of VWRAP's ADT system which is currently still being defined. You're confusing two different "LLSD". The LLSD that is in current use in Second Life and in OpenSimulator is not the ADT system that we are creating for VWRAP --- there is just a coincidence of names currently, because Linden's LLSD was used as the starting point for our work. That name needs to change to avoid the confusion that you've just demonstrated. Meadhbh has renamed her ADT system to "DSD", but if her system is not amenable to change for the purposes of VWRAP then we can't use that name either. Nothing that we do here is going to affect the LLSD that is employed by Linden Lab, and Opensim will almost certainly continue to use that same LLSD for compatibility with SL. We don't have the power to alter their LLSD, even if we wanted to (which we don't). This has been explained here many times already. The above probably highlights the urgency with which we need to adopt a different name for VWRAP's ADT system. > My last post is only on topic of the IETF interest even if merely stated in > the obvious truths, just not in words you could twist so easily. > I don't know what that means. > We only need simple agreement/disagreements, not staged assignments. > Because of that alone, I can't take you seriously on any scale, even when > the scope is pushed completely to the limits. > > I don't know what that means. > Please, just provide your draft-adt-00... so we can focus on consensus and > scale. > > I don't know what you mean by "scale" here. Regarding the draft, we're still working out what the next draft of our ADT system should contain. Your help would be appreciated, but if you aren't interested in improving the ADT system for VWRAP then at least please don't block us from working on it. Morgaine. ======================== On Sun, May 8, 2011 at 12:52 PM, Dzonatas Sol wrote: > Morgaine, please provide exact text here in the list of what you want > updated. There are already enough motion to keep scalar data as scalar. > > If that alone is too hard to comprehend, then your "designing for the > future" ignores complete backward compatibility and the many implementations > that already exist. My last post is only on topic of the IETF interest even > if merely stated in the obvious truths, just not in words you could twist so > easily. > > We only need simple agreement/disagreements, not staged assignments. > Because of that alone, I can't take you seriously on any scale, even when > the scope is pushed completely to the limits. > > Please, just provide your draft-adt-00... so we can focus on consensus and > scale. > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --00163646cede032ff404a2c2ff21 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, May 8, 2011 at 12:52 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
=
Morgaine, please provide exact text here in the list of what you want updated.=20


That's what we're working on right now.= =A0 I don't have exact text, we're working out the details first on= the list, and once we have those worked out, and we see a consensus formin= g, then we can start writing an updated document ready for the next draft.<= br>
=A0
Ther= e are already enough motion to keep scalar data as scalar.
=


I don't know what that means.
=A0

If that alone is too hard to comprehend, then your "designing for the= =20 future" ignores complete backward compatibility and the many=20 implementations that already exist.


We are not des= igning for backwards compatibility, and there are no implementations of any= VWRAP protocol yet, not even of VWRAP's ADT system which is currently = still being defined.=A0 You're confusing two different "LLSD"= .

The LLSD that is in current use in Second Life and in OpenSimulator is = not the ADT system that we are creating for VWRAP --- there is just a coinc= idence of names currently, because Linden's LLSD was used as the starti= ng point for our work.=A0 That name needs to change to avoid the confusion = that you've just demonstrated.=A0 Meadhbh has renamed her ADT system to= "DSD", but if her system is not amenable to change for the purpo= ses of VWRAP then we can't use that name either.

Nothing that we do here is going to affect the LLSD that is employed by= Linden Lab, and Opensim will almost certainly continue to use that same LL= SD for compatibility with SL.=A0 We don't have the power to alter their= LLSD, even if we wanted to (which we don't).=A0 This has been explaine= d here many times already.

The above probably highlights the urgency with which we need to adopt a= different name for VWRAP's ADT system.

=A0
My last post is only on topic of the IETF interest even if merely stated in the obvious truths, just not in=20 words you could twist so easily.


=A0I don'= t know what that means.


We only need simple agreement/disagreements, not staged assignments.=20 Because of that alone, I can't take you seriously on any scale, even=20 when the scope is pushed completely to the limits.


=A0I don't know what that means.

=A0
Please, just provide your draft-adt-00... so we can focus on consensus and = scale.


I don't k= now what you mean by "scale" here.=A0 Regarding the draft, we'= ;re still working out what the next draft of our ADT system should contain.= =A0 Your help would be appreciated, but if you aren't interested in imp= roving the ADT system for VWRAP then at least please don't block us fro= m working on it.


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


= On Sun, May 8, 2011 at 12:52 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
Morgaine, please = provide exact text here in the list of what you want updated. There are alr= eady enough motion to keep scalar data as scalar.

If that alone is too hard to comprehend, then your "designing for the = future" ignores complete backward compatibility and the many implement= ations that already exist. My last post is only on topic of the IETF intere= st even if merely stated in the obvious truths, just not in words you could= twist so easily.

We only need simple agreement/disagreements, not staged assignments. Becaus= e of that alone, I can't take you seriously on any scale, even when the= scope is pushed completely to the limits.

Please, just provide your draft-adt-00... so we can focus on consensus and = scale.


--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--00163646cede032ff404a2c2ff21-- From dzonatas@gmail.com Sun May 8 08:48:39 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DC9E0789 for ; Sun, 8 May 2011 08:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.933 X-Spam-Level: X-Spam-Status: No, score=-3.933 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqoRf71TDLOr for ; Sun, 8 May 2011 08:48:38 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 87E11E0787 for ; Sun, 8 May 2011 08:48:37 -0700 (PDT) Received: by pzk5 with SMTP id 5so2755609pzk.31 for ; Sun, 08 May 2011 08:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=M/56YbmW3CLtRRjOqe799yXP+vYOl/zyHVMYyy+/d7k=; b=iUCXc/nxnI94t+tMe78+dy2shzuDAaAyO/oJaneHZnAJ8TGwAN924oQspr8Xm8yO3N ELUtT22oQqQgFe37cBQXPvM1AhmptukTs7M4AJCgvVlZXp+vVfZYYhtn5yfmbUhnkJKh 0ujVDUpzWJ8/PrbvPEovUWwMwjdihD50vk9s4= 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=vYDUK2LsRXjzPk/C+sifOcp6AejQObOAVJJBtHxJNchJHUncMypTd2X0IEgaZQJKQY TKsyayEzxsBpfxw8Zk8PhXBMTc0oUME4oiVl3QYo+fUBYxiMdqyqHjTtbyygFLcJ7xoL K2VnScetKw9Pem+Kxkyl8F9sC+VTzJgbi+8II= Received: by 10.68.11.196 with SMTP id s4mr8270598pbb.301.1304869717407; Sun, 08 May 2011 08:48:37 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id p2sm3511081pbq.6.2011.05.08.08.48.35 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 08:48:36 -0700 (PDT) Message-ID: <4DC6BB19.1050305@gmail.com> Date: Sun, 08 May 2011 08:47:37 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> <4DC60610.3040606@gmail.com> <4DC61E3C.5080307@gmail.com> <4DC6840B.9050203@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sun, 08 May 2011 15:48:39 -0000 Start with the solution (and the charter). On 05/08/2011 05:38 AM, Morgaine wrote: > "I don't have exact text, we're working out the details first on the > list, and once we have those worked out, and we see a consensus > forming, then we can start writing an updated document ready for the > next draft." We need "best effort" first brought to the table. If you have something you can bring to this list and kill() if that something goes completely wrong, perfect enough. If you try to build something here first, then you don't have something OF YOUR OWN to kill. > "...please don't block us from working on it." Please, don't try to turn this around back in the opposite direction again and blame biosystematicals on me. If you want to go in the opposite direction, the bring what you already have to the table. > "You're confusing two different "LLSD"." We have not confused multiple licenses. Others on this list (and other WGs) have demonstrated awareness of this and don't cross-judge this documentation based on theirs or others implementation. Blackbox the details on another list. Clarify the protocol on this list. Simple. Also note, some of us are doctors and some of us are scientists. There are reasons we don't share the pen, as this principle alone kills the obvious argument. Please consider *at least this much* about the pen with everything you write here. If you want to write the draft, then be the doctor! Don't kill() others scientists. Dear Happy Mothers Day, thanks for the most awesome academy! -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Sun May 8 10:05:07 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D929E0783 for ; Sun, 8 May 2011 10:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zl5zWgMA1MzG for ; Sun, 8 May 2011 10:05:06 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id DAB31E06F0 for ; Sun, 8 May 2011 10:05:05 -0700 (PDT) Received: by qyk29 with SMTP id 29so557600qyk.10 for ; Sun, 08 May 2011 10:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=40gRJd5P2GmNCUqAY61h4DLA7TuxdgBmWS5BvEM6vMg=; b=wCPSHdzqOHTFBEddbEThwrcPski5eDJgdF01/sJ82kuQsXxW8LYI5bvNGJO1fQkMIH ySiUOcfh9nVo2d24nxg2M34oLF1AV06KTLLC3tHGv7YxKESPSz8J1Iuv9I9uG6kGh6Jp vOwsoqL707C41obaV0V3LeF5Ei3bnWmevcJrQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=oE4ZLm+VBpp0gwZ0X2Fmr39r4MHC4Qfjp+OmReNpI7zcqmnkhGEXPIQSjNDkKakIqY OkDocru2q5JvR1HWdHVF3JDYSNz3Fm5lh9YcNzTUdvHNAo+Zo89Wf0JqPVlhZh7WiGJt DOdEyLnE6Sov6oP4/HSvgwE7wdYO6fDKQh9Zg= MIME-Version: 1.0 Received: by 10.229.127.96 with SMTP id f32mr4279314qcs.139.1304873826897; Sun, 08 May 2011 09:57:06 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Sun, 8 May 2011 09:57:06 -0700 (PDT) In-Reply-To: <4DC6BB19.1050305@gmail.com> References: <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> <4DC60610.3040606@gmail.com> <4DC61E3C.5080307@gmail.com> <4DC6840B.9050203@gmail.com> <4DC6BB19.1050305@gmail.com> Date: Sun, 8 May 2011 17:57:06 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cdf65f2edcdcd04a2c69c9f Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sun, 08 May 2011 17:05:07 -0000 --000e0cdf65f2edcdcd04a2c69c9f Content-Type: text/plain; charset=ISO-8859-1 On Sun, May 8, 2011 at 4:47 PM, Dzonatas Sol wrote: > Start with the solution (and the charter). > > Sorry, but no. You start with the requirements, or you'll get the wrong solution. Starting with the solution was what we did with OGP, and look where it landed us. After 2 years of work, we had to throw most of it away because it didn't meet the central goal of providing interop between worlds. Let's not make that mistake again. The same applies to our ADT system. It has to meet important engineering requirements, and the big ones are flexibility, extensibility, and scalability, plus the efficiency that everybody needs. The initial ADT system of our first draft fails on all three relevant counts (scalability is affected only through efficiency), which is why we're addressing those defects now. > > We need "best effort" first brought to the table. If you have something > you can bring to this list and kill() if that something goes completely > wrong, perfect enough. If you try to build something here first, then you > don't have something OF YOUR OWN to kill. > No idea what most of that means, but the "best effort brought to the table" I did understand, and we're working that out currently to our best efforts. In particular, note the exchange of posts about this with Vaughn, including http://www.ietf.org/mail-archive/web/vwrap/current/msg00853.html , http://www.ietf.org/mail-archive/web/vwrap/current/msg00855.html and http://www.ietf.org/mail-archive/web/vwrap/current/msg00858.html . The discussion has been a good one, aided also by contributions from Joshua, Meadhbh, Dahlia and Boroondas. It has been a technical discussion, and it has been leading us forward. You clearly don't want to contribute technically on this topic, which is your choice, but don't accuse the rest of us of bringing nothing to the table. We're working on it, productively, and the discussion has been entirely technical with the other participants. > > > "...please don't block us from working on it." > > Please, don't try to turn this around back in the opposite direction again > and blame biosystematicals on me. If you want to go in the opposite > direction, the bring what you already have to the table. I've got no time for this. Stick to technical topics please. > > > > "You're confusing two different "LLSD"." > > We have not confused multiple licenses. Others on this list (and other WGs) > have demonstrated awareness of this and don't cross-judge this documentation > based on theirs or others implementation. > > Blackbox the details on another list. Clarify the protocol on this list. > Simple. Also note, some of us are doctors and some of us are scientists. > There are reasons we don't share the pen, as this principle alone kills the > obvious argument. Please consider *at least this much* about the pen with > everything you write here. If you want to write the draft, then be the > doctor! Don't kill() others scientists. Licenses have nothing to do with this. And stick to technical topics please. Morgaine. ====================== On Sun, May 8, 2011 at 4:47 PM, Dzonatas Sol wrote: > Start with the solution (and the charter). > > > On 05/08/2011 05:38 AM, Morgaine wrote: > >> "I don't have exact text, we're working out the details first on the list, >> and once we have those worked out, and we see a consensus forming, then we >> can start writing an updated document ready for the next draft." >> > > We need "best effort" first brought to the table. If you have something you > can bring to this list and kill() if that something goes completely wrong, > perfect enough. If you try to build something here first, then you don't > have something OF YOUR OWN to kill. > > > "...please don't block us from working on it." > > Please, don't try to turn this around back in the opposite direction again > and blame biosystematicals on me. If you want to go in the opposite > direction, the bring what you already have to the table. > > > > "You're confusing two different "LLSD"." > > We have not confused multiple licenses. Others on this list (and other WGs) > have demonstrated awareness of this and don't cross-judge this documentation > based on theirs or others implementation. > > Blackbox the details on another list. Clarify the protocol on this list. > Simple. Also note, some of us are doctors and some of us are scientists. > There are reasons we don't share the pen, as this principle alone kills the > obvious argument. Please consider *at least this much* about the pen with > everything you write here. If you want to write the draft, then be the > doctor! Don't kill() others scientists. > > Dear Happy Mothers Day, thanks for the most awesome academy! > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --000e0cdf65f2edcdcd04a2c69c9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, May 8, 2011 at 4:47 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
=
Start with the solution (and the charter).


Sorry, but no.=A0 You start with the requirements, or you&= #39;ll get the wrong solution.=A0 Starting with the solution was what we di= d with OGP, and look where it landed us.=A0 After 2 years of work, we had t= o throw most of it away because it didn't meet the central goal of prov= iding interop between worlds.=A0 Let's not make that mistake again.

The same applies to our ADT system.=A0 It has to meet important enginee= ring requirements, and the big ones are flexibility, extensibility, and sca= lability, plus the efficiency that everybody needs.=A0 The initial ADT syst= em of our first draft fails on all three relevant counts (scalability is af= fected only through efficiency), which is why we're addressing those de= fects now.
=A0

We need "best effort" first brought to the table. If you have som= ething=20 you can bring to this list and kill() if that something goes completely=20 wrong, perfect enough. If you try to build something here first, then=20 you don't have something OF YOUR OWN to kill.

=
No idea what most of that means, but the "best effort brought to t= he table" I did understand, and we're working that out currently t= o our best efforts.=A0 In particular, note the exchange of posts about this= with Vaughn, including http://www.ietf.org/mail-archive/web/vwrap/curren= t/msg00853.html ,=A0 http://www.ietf.org/mail-archive/web/vwrap/curre= nt/msg00855.html=A0 and http://www.ietf.org/mail-archive/web/vwrap/cu= rrent/msg00858.html .=A0 The discussion has been a good one, aided also= by contributions from Joshua, Meadhbh, Dahlia and Boroondas.=A0 It has bee= n a technical discussion, and it has been leading us forward.=A0 You clearl= y don't want to contribute technically on this topic, which is your cho= ice, but don't accuse the rest of us of bringing nothing to the table.= =A0 We're working on it, productively, and the discussion has been enti= rely technical with the other participants.
=A0

> "...please don't block us from working on it."

Please, don't try to turn this around back in the opposite direction=20 again and blame biosystematicals on me. If you want to go in the=20 opposite direction, the bring what you already have to the table.


I've got no time for this.=A0 Stick to technical topics= please.


> "You're confusing two different "LLSD"."

We have not confused multiple licenses. Others on this list (and other=20 WGs) have demonstrated awareness of this and don't cross-judge this=20 documentation based on theirs or others implementation.

Blackbox the details on another list. Clarify the protocol on this list. Simple. Also note, some of us are doctors and some of us are=20 scientists. There are reasons we don't share the pen, as this principle= =20 alone kills the obvious argument. Please consider *at least this much*=20 about the pen with everything you write here. If you want to write the=20 draft, then be the doctor! Don't kill() others scientists.
=

Licenses have nothing to do with this.=A0 And stick to technical to= pics please.


Morgaine.





=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Sun, May 8, 2011 at 4:47 PM, Dzonatas Sol= <dzonatas@gmail= .com> wrote:
Start with the solution (and the charter).


On 05/08/2011 05:38 AM, Morgaine wrote:
"I don't have exact text, we're working out the details first = on the list, and once we have those worked out, and we see a consensus form= ing, then we can start writing an updated document ready for the next draft= ."

We need "best effort" first brought to the table. If you have som= ething you can bring to this list and kill() if that something goes complet= ely wrong, perfect enough. If you try to build something here first, then y= ou don't have something OF YOUR OWN to kill.

> "...please don't block us from working on it."

Please, don't try to turn this around back in the opposite direction ag= ain and blame biosystematicals on me. If you want to go in the opposite dir= ection, the bring what you already have to the table.


> "You're confusing two different "LLSD"."

We have not confused multiple licenses. Others on this list (and other WGs)= have demonstrated awareness of this and don't cross-judge this documen= tation based on theirs or others implementation.

Blackbox the details on another list. Clarify the protocol on this list. Si= mple. Also note, some of us are doctors and some of us are scientists. Ther= e are reasons we don't share the pen, as this principle alone kills the= obvious argument. Please consider *at least this much* about the pen with = everything you write here. If you want to write the draft, then be the doct= or! Don't kill() others scientists.

Dear Happy Mothers Day, thanks for the most awesome academy!


--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--000e0cdf65f2edcdcd04a2c69c9f-- From dzonatas@gmail.com Sun May 8 10:31:43 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5583E06CE for ; Sun, 8 May 2011 10:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.924 X-Spam-Level: X-Spam-Status: No, score=-3.924 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIZjrRmQdMK4 for ; Sun, 8 May 2011 10:31:42 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 98904E068B for ; Sun, 8 May 2011 10:31:42 -0700 (PDT) Received: by pwi5 with SMTP id 5so2785574pwi.31 for ; Sun, 08 May 2011 10:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LF38nNzvuN1BUvLcpoYQ4CWx+TUvoPiO4uXZCDCtyww=; b=GDn1Zy1HDZkbfgKkPKSntfbvdSzF1KebXthUvpIYzvzaAxs322ATVaKXZLLTRryXtN d1Hswr1ug2yVgPyC8zfzAQvNmmNEDZ18LrWAO/eie1jtGzNTZ7HynuYD9lwok+RD33ci TR8xj19JlEQ9mIf/qY7AKDfrlDONOf2CWt40Y= 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=QwTok7LXNiP4WlWO3J4VgImI/cqPg+m4w21i4BrGjCyqEPuGWVp9XPkgsKX02KkYbT YofXw/OSFpg19Gvtqi/19/5IZu/mBIL6Y0EjXj0iVMHuwgW+A7HhtSsxp7xa00tpmr6V 9P+aZ6Ks0figoRYuYXY2zAUtKDcnRjVXugx0c= Received: by 10.68.29.69 with SMTP id i5mr8458369pbh.62.1304875902270; Sun, 08 May 2011 10:31:42 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id e4sm3556284pbj.4.2011.05.08.10.31.40 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 10:31:41 -0700 (PDT) Message-ID: <4DC6D343.4090202@gmail.com> Date: Sun, 08 May 2011 10:30:43 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> <4DC60610.3040606@gmail.com> <4DC61E3C.5080307@gmail.com> <4DC6840B.9050203@gmail.com> <4DC6BB19.1050305@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sun, 08 May 2011 17:31:43 -0000 On 05/08/2011 09:57 AM, Morgaine wrote: > It has to meet important engineering requirements, and the big ones > are flexibility, extensibility, and scalability, plus the efficiency > that everybody needs.� (previously) "I don't know what you mean by "scale" here." BIG technical topic: "scalability" versus "scale" versus "scalar". > Licenses have nothing to do with this.� And stick to technical topics > please. Again, start with the solution. SLDC.... -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Sun May 8 10:47:51 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB3CE0691 for ; Sun, 8 May 2011 10:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.913 X-Spam-Level: X-Spam-Status: No, score=-2.913 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDv1sNe78vHF for ; Sun, 8 May 2011 10:47:49 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6D43CE068B for ; Sun, 8 May 2011 10:47:49 -0700 (PDT) Received: by qwc23 with SMTP id 23so3392894qwc.31 for ; Sun, 08 May 2011 10:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ENXQvc8qDUzI8P5voC1XkpI33eiVKyti4ZCYpdKJxAA=; b=F9RD+P9sOtd0qj2sMOayolDwtMEUukvEktRRwZ8Jpn+n4tCpQlqVXQFEO+b7VWiW3E ZadZt8C+v7JsEFmVRLQMkTGhWOKDexy4+U6+z1q7twz8cTp7+CQtJ173lgHyCH2CU2in VnNmk6LtZNneOLGTzTXFSHuQRbWYFGduVMdDY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=lAie6myu8cA9L28vp30IWe+3NcfieVVAT6D7TOlRTEWHTG/6p3KTnmxiwmZt4i5/+W ofgLRhfUAGUHIyFPTLGE911Mbv7OeUngolpVPZDtRt1mMK1Ru9j3vILNbqDXWyQZOKXt OUdTP4Gy5spVfPVQJznSJ7584MKNHlTQYb/uA= MIME-Version: 1.0 Received: by 10.229.27.78 with SMTP id h14mr4041659qcc.253.1304876526790; Sun, 08 May 2011 10:42:06 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Sun, 8 May 2011 10:42:06 -0700 (PDT) In-Reply-To: References: <4DC1956A.5020204@gmail.com> <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> <4DC60610.3040606@gmail.com> <4DC61E3C.5080307@gmail.com> <4DC6840B.9050203@gmail.com> <4DC6BB19.1050305@gmail.com> Date: Sun, 8 May 2011 18:42:06 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=001636426b6bdaeb7f04a2c73dc4 Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sun, 08 May 2011 17:47:51 -0000 --001636426b6bdaeb7f04a2c73dc4 Content-Type: text/plain; charset=ISO-8859-1 I should have mentioned Carlo's contribution on this topic too, namely to gain extensibility through version negotiation at protocol initiation time. This allows us to avoid having to add extensible predefined types to the ADT system, a clear win. This doesn't mean that we should feel free to make VWRAP's ADT system v1.0 totally poor, but it does mean that if we fail to make it meet common requirements then our incompetence can be overcome by developers without coming back to the IETF. Morgaine. =================== On Sun, May 8, 2011 at 5:57 PM, Morgaine wrote: > On Sun, May 8, 2011 at 4:47 PM, Dzonatas Sol wrote: > >> Start with the solution (and the charter). >> >> > Sorry, but no. You start with the requirements, or you'll get the wrong > solution. Starting with the solution was what we did with OGP, and look > where it landed us. After 2 years of work, we had to throw most of it away > because it didn't meet the central goal of providing interop between > worlds. Let's not make that mistake again. > > The same applies to our ADT system. It has to meet important engineering > requirements, and the big ones are flexibility, extensibility, and > scalability, plus the efficiency that everybody needs. The initial ADT > system of our first draft fails on all three relevant counts (scalability is > affected only through efficiency), which is why we're addressing those > defects now. > > >> >> We need "best effort" first brought to the table. If you have something >> you can bring to this list and kill() if that something goes completely >> wrong, perfect enough. If you try to build something here first, then you >> don't have something OF YOUR OWN to kill. >> > > > No idea what most of that means, but the "best effort brought to the table" > I did understand, and we're working that out currently to our best efforts. > In particular, note the exchange of posts about this with Vaughn, including > http://www.ietf.org/mail-archive/web/vwrap/current/msg00853.html , > http://www.ietf.org/mail-archive/web/vwrap/current/msg00855.html and > http://www.ietf.org/mail-archive/web/vwrap/current/msg00858.html . The > discussion has been a good one, aided also by contributions from Joshua, > Meadhbh, Dahlia and Boroondas. It has been a technical discussion, and it > has been leading us forward. You clearly don't want to contribute > technically on this topic, which is your choice, but don't accuse the rest > of us of bringing nothing to the table. We're working on it, productively, > and the discussion has been entirely technical with the other participants. > > >> >> > "...please don't block us from working on it." >> >> Please, don't try to turn this around back in the opposite direction again >> and blame biosystematicals on me. If you want to go in the opposite >> direction, the bring what you already have to the table. > > > > I've got no time for this. Stick to technical topics please. > >> >> >> > "You're confusing two different "LLSD"." >> >> We have not confused multiple licenses. Others on this list (and other >> WGs) have demonstrated awareness of this and don't cross-judge this >> documentation based on theirs or others implementation. >> >> Blackbox the details on another list. Clarify the protocol on this list. >> Simple. Also note, some of us are doctors and some of us are scientists. >> There are reasons we don't share the pen, as this principle alone kills the >> obvious argument. Please consider *at least this much* about the pen with >> everything you write here. If you want to write the draft, then be the >> doctor! Don't kill() others scientists. > > > > Licenses have nothing to do with this. And stick to technical topics > please. > > > Morgaine. > > > > > > ====================== > > > On Sun, May 8, 2011 at 4:47 PM, Dzonatas Sol wrote: > >> Start with the solution (and the charter). >> >> >> On 05/08/2011 05:38 AM, Morgaine wrote: >> >>> "I don't have exact text, we're working out the details first on the >>> list, and once we have those worked out, and we see a consensus forming, >>> then we can start writing an updated document ready for the next draft." >>> >> >> We need "best effort" first brought to the table. If you have something >> you can bring to this list and kill() if that something goes completely >> wrong, perfect enough. If you try to build something here first, then you >> don't have something OF YOUR OWN to kill. >> >> > "...please don't block us from working on it." >> >> Please, don't try to turn this around back in the opposite direction again >> and blame biosystematicals on me. If you want to go in the opposite >> direction, the bring what you already have to the table. >> >> >> > "You're confusing two different "LLSD"." >> >> We have not confused multiple licenses. Others on this list (and other >> WGs) have demonstrated awareness of this and don't cross-judge this >> documentation based on theirs or others implementation. >> >> Blackbox the details on another list. Clarify the protocol on this list. >> Simple. Also note, some of us are doctors and some of us are scientists. >> There are reasons we don't share the pen, as this principle alone kills the >> obvious argument. Please consider *at least this much* about the pen with >> everything you write here. If you want to write the draft, then be the >> doctor! Don't kill() others scientists. >> >> Dear Happy Mothers Day, thanks for the most awesome academy! >> >> >> -- >> --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> > > --001636426b6bdaeb7f04a2c73dc4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I should have mentioned Carlo's contribution on this topic too, namely = to gain extensibility through version negotiation at protocol initiation ti= me.=A0 This allows us to avoid having to add extensible predefined types to= the ADT system, a clear win.

This doesn't mean that we should feel free to make VWRAP's ADT = system v1.0 totally poor, but it does mean that if we fail to make it meet = common requirements then our incompetence can be overcome by developers wit= hout coming back to the IETF.


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

On Sun, May 8, 2011 at 5:= 57 PM, Morgaine <morgaine.dinova@googlemail.com> wrote:
On Sun, May 8, 2011 at 4:47 PM, Dzonatas Sol <dzonatas@gmail.com>= wrote:
Start with the solution (and the charter).


Sorry, but no.=A0 You start with the requirements, or you'll = get the wrong solution.=A0 Starting with the solution was what we did with = OGP, and look where it landed us.=A0 After 2 years of work, we had to throw= most of it away because it didn't meet the central goal of providing i= nterop between worlds.=A0 Let's not make that mistake again.

The same applies to our ADT system.=A0 It has to meet important enginee= ring requirements, and the big ones are flexibility, extensibility, and sca= lability, plus the efficiency that everybody needs.=A0 The initial ADT syst= em of our first draft fails on all three relevant counts (scalability is af= fected only through efficiency), which is why we're addressing those de= fects now.
=A0

We need "best effort" first brought to the table. If you have som= ething=20 you can bring to this list and kill() if that something goes completely=20 wrong, perfect enough. If you try to build something here first, then=20 you don't have something OF YOUR OWN to kill.


No idea what most of that means, but the "best effort brough= t to the table" I did understand, and we're working that out curre= ntly to our best efforts.=A0 In particular, note the exchange of posts abou= t this with Vaughn, including http://www.ietf.org/mail-= archive/web/vwrap/current/msg00853.html ,=A0 http:/= /www.ietf.org/mail-archive/web/vwrap/current/msg00855.html=A0 and http://www.ietf.org/mail-archive/web/vwrap/current/msg00858.= html .=A0 The discussion has been a good one, aided also by contributio= ns from Joshua, Meadhbh, Dahlia and Boroondas.=A0 It has been a technical d= iscussion, and it has been leading us forward.=A0 You clearly don't wan= t to contribute technically on this topic, which is your choice, but don= 9;t accuse the rest of us of bringing nothing to the table.=A0 We're wo= rking on it, productively, and the discussion has been entirely technical w= ith the other participants.
=A0

> "...please don't block us from working on it."

Please, don't try to turn this around back in the opposite direction=20 again and blame biosystematicals on me. If you want to go in the=20 opposite direction, the bring what you already have to the table.


I've got no time for this.=A0 Stick to technical = topics please.


> "You're confusing two different "LLSD"."

We have not confused multiple licenses. Others on this list (and other=20 WGs) have demonstrated awareness of this and don't cross-judge this=20 documentation based on theirs or others implementation.

Blackbox the details on another list. Clarify the protocol on this list. Simple. Also note, some of us are doctors and some of us are=20 scientists. There are reasons we don't share the pen, as this principle= =20 alone kills the obvious argument. Please consider *at least this much*=20 about the pen with everything you write here. If you want to write the=20 draft, then be the doctor! Don't kill() others scientists.
=

Licenses have nothing to do with this.=A0 And stick to techni= cal topics please.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D


On Sun, May 8, 2011 at 4:47 PM, Dzonatas Sol= <dzonatas@gmail.com> wrote:
Start with the solution (and the charter).


On 05/08/2011 05:38 AM, Morgaine wrote:
"I don't have exact text, we're working out the details first = on the list, and once we have those worked out, and we see a consensus form= ing, then we can start writing an updated document ready for the next draft= ."

We need "best effort" first brought to the table. If you have som= ething you can bring to this list and kill() if that something goes complet= ely wrong, perfect enough. If you try to build something here first, then y= ou don't have something OF YOUR OWN to kill.

> "...please don't block us from working on it."

Please, don't try to turn this around back in the opposite direction ag= ain and blame biosystematicals on me. If you want to go in the opposite dir= ection, the bring what you already have to the table.


> "You're confusing two different "LLSD"."

We have not confused multiple licenses. Others on this list (and other WGs)= have demonstrated awareness of this and don't cross-judge this documen= tation based on theirs or others implementation.

Blackbox the details on another list. Clarify the protocol on this list. Si= mple. Also note, some of us are doctors and some of us are scientists. Ther= e are reasons we don't share the pen, as this principle alone kills the= obvious argument. Please consider *at least this much* about the pen with = everything you write here. If you want to write the draft, then be the doct= or! Don't kill() others scientists.

Dear Happy Mothers Day, thanks for the most awesome academy!


--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


--001636426b6bdaeb7f04a2c73dc4-- From dzonatas@gmail.com Sun May 8 16:15:34 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE18E0684 for ; Sun, 8 May 2011 16:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.915 X-Spam-Level: X-Spam-Status: No, score=-3.915 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83YIYjadVA94 for ; Sun, 8 May 2011 16:15:33 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5EBE0651 for ; Sun, 8 May 2011 16:15:33 -0700 (PDT) Received: by pvh1 with SMTP id 1so2867506pvh.31 for ; Sun, 08 May 2011 16:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7g/Oo3V+tmFLmqM27YoTJI20XGbhAfMkIO5RI56PLK4=; b=w7pDG+ZgSR1t7KL6CSyVV1tU1jVcLq1X+UwJwAaKs/GW1ofSJJWgkMm3cILB8nZNTw DsfpcOJ9ggcEJRRVOFHGU2hOGSD5oNUx5AnbRrgz2OaIzTXJ/d/ds6Opvy3yOOh+jkjj DWajZowo4b26FU7WTjVsaK6bjG83sPdkfa/jg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=fO9hKGQmsvwlXYD2P9JA7GilltV335poPEVixk9jVR0iG64osmlwPE/lgqiHxdw0Kp BIMbEZRctqEqlrTIDb9mlEuIgdTOs8xvufC2ChP5VoYdvnJ2U3tuqtGj3Ah7byQDH4B5 lXIhbdZKc/gfasjtQeCOUtIbPXkZ+WvbQLWIw= Received: by 10.68.38.42 with SMTP id d10mr7590631pbk.58.1304892855218; Sun, 08 May 2011 15:14:15 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id f5sm3298654pbt.92.2011.05.08.15.14.13 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 15:14:14 -0700 (PDT) Message-ID: <4DC7157C.9090705@gmail.com> Date: Sun, 08 May 2011 15:13:16 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Dzonatas Sol References: <4DC1A8C9.9090406@gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> <4DC60610.3040606@gmail.com> <4DC61E3C.5080307@gmail.com> <4DC6840B.9050203@gmail.com> <4DC6BB19.1050305@gmail.com> <4DC6D343.4090202@gmail.com> In-Reply-To: <4DC6D343.4090202@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Sun, 08 May 2011 23:15:34 -0000 Note, thinking-out-of-the-box discussion about hetero-generous region hubs. Besides the tag, there still is need for presence in the secondary region where the are assets are actually left in the original region. Please stay tune while we/they... unplug off-list and plug-in Monday's asset. SDLC... I vote to add (indeterminate named) multi-cast ability to such plug-in regions in the charter. The constraint is more obvious connections and update-frames of such regional topology. I think 'regional media extensions' is more in scope than abstract client-side media extension. Should we assume such media extensions are out of scope? On 05/08/2011 10:30 AM, Dzonatas Sol wrote: > > On 05/08/2011 09:57 AM, Morgaine wrote: >> It has to meet important engineering requirements, and the big ones >> are flexibility, extensibility, and scalability, plus the efficiency >> that everybody needs.� > > (previously) "I don't know what you mean by "scale" here." > > > BIG technical topic: "scalability" versus "scale" versus "scalar". > > > >> Licenses have nothing to do with this.� And stick to technical topics >> please. > > > Again, start with the solution. SLDC.... > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From bobby@sharedrealm.com Mon May 9 00:12:54 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCC2E06F6 for ; Mon, 9 May 2011 00:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njC1IuK3NtzO for ; Mon, 9 May 2011 00:12:53 -0700 (PDT) Received: from mail.neoawareness.com (mail.neoawareness.com [67.223.232.27]) by ietfa.amsl.com (Postfix) with ESMTP id B1A45E062A for ; Mon, 9 May 2011 00:12:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=neo.localnet) by mail.neoawareness.com with esmtpa (Exim 4.69) (envelope-from ) id 1QJKeB-0005uZ-17 for vwrap@ietf.org; Mon, 09 May 2011 07:12:51 +0000 From: "Robert G. Jakabosky" To: vwrap@ietf.org Date: Mon, 9 May 2011 00:12:49 -0700 User-Agent: KMail/1.13.5 (Linux/2.6.32-bpo.5-amd64; KDE/4.4.5; x86_64; ; ) References: <4DC6840B.9050203@gmail.com> In-Reply-To: <4DC6840B.9050203@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105090012.50031.bobby@sharedrealm.com> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bobby@sharedrealm.com X-SA-Exim-Scanned: No (on mail.neoawareness.com); SAEximRunCond expanded to false Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Mon, 09 May 2011 07:12:54 -0000 On Sunday 08, Dzonatas Sol wrote: > If that alone is too hard to comprehend, then your "designing for the > future" ignores complete backward compatibility and the many > implementations that already exist. -1 Why should VWRAP keep backwards compatibility to anything when we haven't even published a standard yet. The current LLSD spec is a draft and not set in stone. Current LLSD implementations may have to change before this standardization process is finished. -- Robert G. Jakabosky From sllists@boroon.dasgupta.ch Mon May 9 01:59:54 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AD6E069D for ; Mon, 9 May 2011 01:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8qsKIYU9rW5 for ; Mon, 9 May 2011 01:59:51 -0700 (PDT) Received: from datendelphin.net (india288.server4you.de [85.25.150.202]) by ietfa.amsl.com (Postfix) with ESMTP id 001D2E06C0 for ; Mon, 9 May 2011 01:59:50 -0700 (PDT) Received: from [172.30.132.224] (guest-docking-nat-2-226.ethz.ch [82.130.72.226]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by datendelphin.net (Postfix) with ESMTPSA id D01302E045 for ; Mon, 9 May 2011 11:03:19 +0200 (CEST) Message-ID: <4DC7AD04.5090608@boroon.dasgupta.ch> Date: Mon, 09 May 2011 10:59:48 +0200 From: Boroondas Gupte User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC5ABAB.5040306@boroon.dasgupta.ch> <4DC5BDD5.7080103@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] What does "ADT" mean? X-BeenThere: vwrap@ietf.org 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: Mon, 09 May 2011 08:59:54 -0000 Thanks for the clarification. On 05/08/2011 03:47 AM, Morgaine wrote: > ADT means Abstract Data Type. Ah, as I suspected. :-) > A system of abstract data types (such as LLSD) has no accepted name or > abbreviation, but commonly one says "ADT system", Well, Meadhbh (and others behind LLSD?) seem to have coined the term "abstract type system" for such systems, but "ADT system" is equally understandable now that "ADT" is understood, so we can use those two terms synonymous, I guess. > or where context allows an unambiguous interpretation, simply "ADT". > > No mystery there, it has been so for decades of common usage in > Computing. :-) The whole mystery was that I just wasn't aware that it was common to just say "ADT" instead of "ADT system" or "abstract type system", when it is clear that a system is meant rather than a single type. Cheers, Boroondas From morgaine.dinova@googlemail.com Mon May 9 04:59:23 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8ECE07D4 for ; Mon, 9 May 2011 04:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6l6p4NoKPlAW for ; Mon, 9 May 2011 04:59:22 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 46D1FE07A1 for ; Mon, 9 May 2011 04:59:22 -0700 (PDT) Received: by qwc23 with SMTP id 23so3759959qwc.31 for ; Mon, 09 May 2011 04:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=n4VuEKY49OF8aPh/PqdwWMYRrUAnXig+I6P7h1Zi0s8=; b=hLGh0hZLFisgx9zpsNiVPYtsImv2s3YXqJGYuk24d/UE0gPRQF60NPBHwblRnKcE0j vy/FzDCdoWfpb5o1PTbECFdf5GZimCMb9wQ3VUDPvia4gGRacvbL4i6Lxon6Z4HSvpuR w3f8fjl2pb6ioYhReXf91fWmblEKAJBa/FpW8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kmXwCSIKX0vA1mObIVhKfOeEWSz5Ww/cS6NkKaGaoDuFZbFrsmXoP2MX+gd5eE+M+h lsMM0v64HTW7c6Hu8v/6N994aKZStnPS7xdEmNDhugIhbHaOI06ufc7sa5l3m4yWB6i1 +y0m/NBFNfQ1Op9gq4gNVtXhRGR2rtpbly6iY= MIME-Version: 1.0 Received: by 10.229.102.85 with SMTP id f21mr4973768qco.25.1304942361269; Mon, 09 May 2011 04:59:21 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Mon, 9 May 2011 04:59:21 -0700 (PDT) In-Reply-To: <201105090012.50031.bobby@sharedrealm.com> References: <4DC6840B.9050203@gmail.com> <201105090012.50031.bobby@sharedrealm.com> Date: Mon, 9 May 2011 12:59:21 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=002354471a20e5acdd04a2d6918f Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Mon, 09 May 2011 11:59:23 -0000 --002354471a20e5acdd04a2d6918f Content-Type: text/plain; charset=ISO-8859-1 Indeed Robert. We're defining a new ADT system for VWRAP, and LLSD was merely the initial input. I think we should call the types system that we're defining something like VWRAP-ATS (VWRAP Abstract Types System), to avoid it being confused with the current LLSD. Despite repeated explanation that nothing we define here will alter the LLSD employed by Second Life (we don't have the power to do that), people still fail to distinguish between our ADT system and Linden's. Only a new name will fix that ambiguity. Morgaine. ========================== On Mon, May 9, 2011 at 8:12 AM, Robert G. Jakabosky wrote: > On Sunday 08, Dzonatas Sol wrote: > > If that alone is too hard to comprehend, then your "designing for the > > future" ignores complete backward compatibility and the many > > implementations that already exist. > > -1 > > Why should VWRAP keep backwards compatibility to anything when we haven't > even > published a standard yet. The current LLSD spec is a draft and not set in > stone. Current LLSD implementations may have to change before this > standardization process is finished. > > -- > Robert G. Jakabosky > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --002354471a20e5acdd04a2d6918f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Indeed Robert.=A0 We're defining a new ADT system for VWRAP, and LLSD w= as merely the initial input.

I think we should call the types system= that we're defining something like VWRAP-ATS (VWRAP Abstract Types Sys= tem), to avoid it being confused with the current LLSD.

Despite repeated explanation that nothing we define here will alter the= LLSD employed by Second Life (we don't have the power to do that), peo= ple still fail to distinguish between our ADT system and Linden's.=A0 O= nly a new name will fix that ambiguity.



Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


On Mon, May 9, 2011 at 8:12 AM, Robert G. Jakabosky <bobby@sharedrealm.com&= gt; wrote:
On Sunday 08, Dzonatas Sol wrote:
> If that alone is too hard to comprehend, then your "designing for= the
> future" ignores complete backward compatibility and the many
> implementations that already exist.

-1

Why should VWRAP keep backwards compatibility to anything when we haven'= ;t even
published a standard yet. =A0The current LLSD spec is a draft and not set i= n
stone. =A0Current LLSD implementations may have to change before this
standardization process is finished.

--
Robert G. Jakabosky
__________________________________= _____________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--002354471a20e5acdd04a2d6918f-- From morgaine.dinova@googlemail.com Mon May 9 06:49:28 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C99CE06B7 for ; Mon, 9 May 2011 06:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.919 X-Spam-Level: X-Spam-Status: No, score=-2.919 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTimN2Gjc0N9 for ; Mon, 9 May 2011 06:49:26 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B6821E0659 for ; Mon, 9 May 2011 06:49:26 -0700 (PDT) Received: by qwc23 with SMTP id 23so3853248qwc.31 for ; Mon, 09 May 2011 06:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cfGG7U4BfQx5jhP2oSUN1Pfa7kJWAemp7s7eZd+Sufo=; b=Yhre9ZcE4mUqy7ai9L3atZH2zPAwgazBgBnv7acd1RNkoxRDmCPSKXBtDiBenCJHOW HDBQTlitXKCj2Efufqa338Jf/1bBxHr3il2+aATR+9/+Ov07FtOZ0McFn8sZKGZMahQd ZyYxSEirhxycEA9pzWSJ2nqXpX+a6ldvWSZMs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qSsGSN2FombwTv0d81Nm2X//Oe0TI77prujN4GDTp9oS0SOUE6jQC5CMrwVFHXsCby 8UogWwOLkex7wkHIl3A8OJ5ITlWRgXmrThfGZC1HpdGXm3r9YmPlyySCRCWMBy/6uajm DxKA28Whgunt/V4FW0IyP8m2rNrPnW3tTkiFk= MIME-Version: 1.0 Received: by 10.224.179.142 with SMTP id bq14mr5594717qab.205.1304948965819; Mon, 09 May 2011 06:49:25 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Mon, 9 May 2011 06:49:25 -0700 (PDT) In-Reply-To: <4DC7AD04.5090608@boroon.dasgupta.ch> References: <4DC5ABAB.5040306@boroon.dasgupta.ch> <4DC5BDD5.7080103@gmail.com> <4DC7AD04.5090608@boroon.dasgupta.ch> Date: Mon, 9 May 2011 14:49:25 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=20cf302efce28ec5f604a2d81b4e Subject: Re: [vwrap] What does "ADT" mean? X-BeenThere: vwrap@ietf.org 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: Mon, 09 May 2011 13:49:28 -0000 --20cf302efce28ec5f604a2d81b4e Content-Type: text/plain; charset=ISO-8859-1 We can coin our own abbreviations too. :-) Since "abstract types system" is precise and unambiguous, would you like us to use "ATS" as a shorthand for this, an even less verbose way of saying "ADT system"? It's fine by me. :-) It would also lead naturally to VWRAP's ATS being known as VWRAP-ATS, which makes sense. Morgaine. ===================== On Mon, May 9, 2011 at 9:59 AM, Boroondas Gupte wrote: > Thanks for the clarification. > > On 05/08/2011 03:47 AM, Morgaine wrote: > > ADT means Abstract Data Type. > Ah, as I suspected. :-) > > > A system of abstract data types (such as LLSD) has no accepted name or > > abbreviation, but commonly one says "ADT system", > Well, Meadhbh (and others behind LLSD?) seem to have coined the term > "abstract type system" for such systems, but "ADT system" is equally > understandable now that "ADT" is understood, so we can use those two > terms synonymous, I guess. > > > or where context allows an unambiguous interpretation, simply "ADT". > > > > No mystery there, it has been so for decades of common usage in > > Computing. :-) > The whole mystery was that I just wasn't aware that it was common to > just say "ADT" instead of "ADT system" or "abstract type system", when > it is clear that a system is meant rather than a single type. > > Cheers, > Boroondas > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --20cf302efce28ec5f604a2d81b4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We can coin our own abbreviations too. :-)

Since "abstract type= s system" is precise and unambiguous, would you like us to use "A= TS" as a shorthand for this, an even less verbose way of saying "= ADT system"?=A0 It's fine by me. :-)

It would also lead naturally to VWRAP's ATS being known as VWRAP-AT= S, which makes sense.


Morgaine.




=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Mon, May 9, 2011 at 9:59 AM, Boroondas Gupte <sllists@boroon.dasgupta= .ch> wrote:
Thanks for the cl= arification.

On 05/08/2011 03:47 AM, Morgaine wrote:
> ADT means Abstract Data Type.
Ah, as I suspected. :-)

> A system of abstract data types (such as LLSD) has no accepted name or=
> abbreviation, but commonly one says "ADT system",
Well, Meadhbh (and others behind LLSD?) seem to have coined the term<= br> "abstract type system" for such systems, but "ADT system&quo= t; is equally
understandable now that "ADT" is understood, so we can use those = two
terms synonymous, I guess.

> or where context allows an unambiguous interpretation, simply "AD= T".
>
> No mystery there, it has been so for decades of common usage in
> Computing. :-)
The whole mystery was that I just wasn't aware that it was common= to
just say "ADT" instead of "ADT system" or "abstrac= t type system", when
it is clear that a system is meant rather than a single type.

Cheers,
Boroondas
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--20cf302efce28ec5f604a2d81b4e-- From ohmeadhbh@gmail.com Mon May 9 06:53:41 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E4BE0734 for ; Mon, 9 May 2011 06:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAbID72vDVOM for ; Mon, 9 May 2011 06:53:40 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id F317AE074D for ; Mon, 9 May 2011 06:53:39 -0700 (PDT) Received: by wwa36 with SMTP id 36so3939159wwa.13 for ; Mon, 09 May 2011 06:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=X0EwIBysJCNB52oEeAPJo0M7VXtPb8pbTnlTG86ojfE=; b=JdpnpE59FV/A2ODnHtA1w+Aot8AYyVd8mz+Enj8zWn48Xc+T668ZP46fROLFmfUkVu Gb/Q+nzaSMA80+TjzFAT6cAtsqsMqyQvhraLKAbppKEXA2B8p/Fqh2hpmrpmQ9q0vOIx D2m//ToZHu5aVzRD0epQkjW+vm6hFgxDtO5Tc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=C1edioLeKsGC6LlEfoFdIht+9bN+lors5v6rp/yyzxGmoxp+z4aceajqeEq90wwMTM a4VJib3VwJq4QRmfzLDndqvczG83/wrGkJoml2QVgaWrEIvvvYhpT2ipaNdjmmRqsueM YTMlA+aXCNR8eYr538Ci47vThLYq3FOlXAoY4= Received: by 10.216.79.5 with SMTP id h5mr306857wee.110.1304949218215; Mon, 09 May 2011 06:53:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.154.1 with HTTP; Mon, 9 May 2011 06:53:18 -0700 (PDT) In-Reply-To: <4DC7AD04.5090608@boroon.dasgupta.ch> References: <4DC5ABAB.5040306@boroon.dasgupta.ch> <4DC5BDD5.7080103@gmail.com> <4DC7AD04.5090608@boroon.dasgupta.ch> From: Meadhbh Hamrick Date: Mon, 9 May 2011 06:53:18 -0700 Message-ID: To: Boroondas Gupte Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org Subject: Re: [vwrap] What does "ADT" mean? X-BeenThere: vwrap@ietf.org 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: Mon, 09 May 2011 13:53:41 -0000 hmm... don't think me or mark lentczner coined the term "abstract type system." i was used by the OMG and Microsoft long before we used it. -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Mon, May 9, 2011 at 1:59 AM, Boroondas Gupte wrote: > Thanks for the clarification. > > On 05/08/2011 03:47 AM, Morgaine wrote: >> ADT means Abstract Data Type. > Ah, as I suspected. :-) > >> A system of abstract data types (such as LLSD) has no accepted name or >> abbreviation, but commonly one says "ADT system", > Well, Meadhbh (and others behind LLSD?) seem to have coined the term > "abstract type system" for such systems, but "ADT system" is equally > understandable now that "ADT" is understood, so we can use those two > terms synonymous, I guess. > >> or where context allows an unambiguous interpretation, simply "ADT". >> >> No mystery there, it has been so for decades of common usage in >> Computing. :-) > The whole mystery was that I just wasn't aware that it was common to > just say "ADT" instead of "ADT system" or "abstract type system", when > it is clear that a system is meant rather than a single type. > > Cheers, > Boroondas > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From morgaine.dinova@googlemail.com Mon May 9 06:58:59 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385B5E076A for ; Mon, 9 May 2011 06:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xM6KW9HhURYl for ; Mon, 9 May 2011 06:58:58 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id C59DAE0768 for ; Mon, 9 May 2011 06:58:57 -0700 (PDT) Received: by qwc23 with SMTP id 23so3863241qwc.31 for ; Mon, 09 May 2011 06:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=4te1CpznYp1kCkDEo2ReCGqo+6YkPVjjJsIN3cmK4Js=; b=Ee1D76RcusEYwoyEQ07bVLNzPcjKVdn7Xtkg7U4LCLdrS9FlSAPq6I1+TDcgr+WNlj c2EbwfGTCpF7++SO1cmpXCYtJxStYdz3IncN/o4VBjI1REmE0gJGeiEiAZGyg3nMcHeV knvyUUC/iZQh0ekohfOHuSrovRFc9uppaCGQk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=mO6h8nHMjFGw0JAE/putW4QRoHKEeVyQyFvvmAZ8aho63+4n7nZl4CW8GLxAm6PqDj 7nCGF+J2vH8Jfg8uQpve1GxtKCrxXkVIYImksrOXoO1gSiUqsWI2rjfNnyzi00X/pQPJ 25KdF5yp3ZLA7fEeY9p500dSmJR9OeR4PvxkE= MIME-Version: 1.0 Received: by 10.229.44.141 with SMTP id a13mr4923917qcf.101.1304949536881; Mon, 09 May 2011 06:58:56 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Mon, 9 May 2011 06:58:56 -0700 (PDT) In-Reply-To: References: <4DC5ABAB.5040306@boroon.dasgupta.ch> <4DC5BDD5.7080103@gmail.com> <4DC7AD04.5090608@boroon.dasgupta.ch> Date: Mon, 9 May 2011 14:58:56 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=001636831fa0987e3d04a2d83d62 Subject: Re: [vwrap] What does "ADT" mean? X-BeenThere: vwrap@ietf.org 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: Mon, 09 May 2011 13:58:59 -0000 --001636831fa0987e3d04a2d83d62 Content-Type: text/plain; charset=ISO-8859-1 Aye, that phrase has been in use for as long as types systems have existed. Morgaine. ====================== On Mon, May 9, 2011 at 2:53 PM, Meadhbh Hamrick wrote: > hmm... don't think me or mark lentczner coined the term "abstract type > system." i was used by the OMG and Microsoft long before we used it. > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Mon, May 9, 2011 at 1:59 AM, Boroondas Gupte > wrote: > > Thanks for the clarification. > > > > On 05/08/2011 03:47 AM, Morgaine wrote: > >> ADT means Abstract Data Type. > > Ah, as I suspected. :-) > > > >> A system of abstract data types (such as LLSD) has no accepted name or > >> abbreviation, but commonly one says "ADT system", > > Well, Meadhbh (and others behind LLSD?) seem to have coined the term > > "abstract type system" for such systems, but "ADT system" is equally > > understandable now that "ADT" is understood, so we can use those two > > terms synonymous, I guess. > > > >> or where context allows an unambiguous interpretation, simply "ADT". > >> > >> No mystery there, it has been so for decades of common usage in > >> Computing. :-) > > The whole mystery was that I just wasn't aware that it was common to > > just say "ADT" instead of "ADT system" or "abstract type system", when > > it is clear that a system is meant rather than a single type. > > > > Cheers, > > Boroondas > > _______________________________________________ > > vwrap mailing list > > vwrap@ietf.org > > https://www.ietf.org/mailman/listinfo/vwrap > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --001636831fa0987e3d04a2d83d62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Aye, that phrase has been in use for as long as types systems have existed.=


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Mon, Ma= y 9, 2011 at 2:53 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com> wrote:
hmm... don't = think me or mark lentczner coined the term "abstract type
system." i was used by the OMG and Microsoft long before we used it. --
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadh= bh.org/ * OhMeadhbh@gmail.com



On Mon, May 9, 2011 at 1:59 AM, Boroondas Gupte
<sllists@boroon.dasgupta.c= h> wrote:
> Thanks for the clarification.<= br> >
> On 05/08/2011 03:47 AM, Morgaine wrote:
>> ADT means Abstract Data Type.
> Ah, as I suspected. :-)
>
>> A system of abstract data types (such as LLSD) has no accepted nam= e or
>> abbreviation, but commonly one says "ADT system",
> Well, Meadhbh (and others behind LLSD?) seem to have coined the term > "abstract type system" for such systems, but "ADT syste= m" is equally
> understandable now that "ADT" is understood, so we can use t= hose two
> terms synonymous, I guess.
>
>> or where context allows an unambiguous interpretation, simply &quo= t;ADT".
>>
>> No mystery there, it has been so for decades of common usage in >> Computing. :-)
> The whole mystery was that I just wasn't aware that it was common = to
> just say "ADT" instead of "ADT system" or "ab= stract type system", when
> it is clear that a system is meant rather than a single type.
>
> Cheers,
> Boroondas
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--001636831fa0987e3d04a2d83d62-- From dzonatas@gmail.com Mon May 9 07:29:57 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7914E0692 for ; Mon, 9 May 2011 07:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.907 X-Spam-Level: X-Spam-Status: No, score=-3.907 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8QHt6wIkbX1 for ; Mon, 9 May 2011 07:29:56 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9F8E0726 for ; Mon, 9 May 2011 07:29:52 -0700 (PDT) Received: by pvh1 with SMTP id 1so3211417pvh.31 for ; Mon, 09 May 2011 07:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vnd1vt7iPP+Ke9Q4nBONnXDdNm01ruFdXTXiqjID3eU=; b=YqSEQa89wpgQq/Uv9Wt5pGkwYBiZfYGzshKbafot0tJBACK3SZnC5YhLd6p90XTxSj +ivyigpMh/AUGYBXiZCJEtfpoeovsq0Qrc0A80dICGYOs/cADO5VYE43gTfi0CoUQsiD QKmp9rZ/YmWhfjldFM6BDot+nNFetA28sD24E= 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=Kaf8gCr1hEZhyvXquS/5ucvkptrWunREtbMzNfxnKxYnilbeBHtx9oUtpee8DqHqtC bYT+r3MbLGC0w7JMyyP6oW546ur1nUmoexefabhaKkj1up2EBg7JhwMb6DLGPb20T1b1 VoCcgaUfres/Gl1bSFi3kobwMA9BfnrNiARP0= Received: by 10.68.66.98 with SMTP id e2mr9790725pbt.447.1304950929744; Mon, 09 May 2011 07:22:09 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id s5sm4136251pba.64.2011.05.09.07.22.07 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 07:22:07 -0700 (PDT) Message-ID: <4DC7F856.7020702@gmail.com> Date: Mon, 09 May 2011 07:21:10 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC6840B.9050203@gmail.com> <201105090012.50031.bobby@sharedrealm.com> In-Reply-To: <201105090012.50031.bobby@sharedrealm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Mon, 09 May 2011 14:29:57 -0000 On 05/09/2011 12:12 AM, Robert G. Jakabosky wrote: > On Sunday 08, Dzonatas Sol wrote: > >> If that alone is too hard to comprehend, then your "designing for the >> future" ignores complete backward compatibility and the many >> implementations that already exist. >> > -1 > > Why should VWRAP keep backwards compatibility to anything when we haven't even > published a standard yet. The current LLSD spec is a draft and not set in > stone. Current LLSD implementations may have to change before this > standardization process is finished. > > Standards and implementation is like any 2 step process that remains separate. If you give priority to one over the other then it'll cost you or someone more. Just because we create the blackbox process to accomplish this doesn't mean we ignore each others needs or what has been already done. Why make-up standard for something that never has been implemented? You'll probably find you didn't even need the standard and that there is something else that already fits your need. We can't create the blackbox process without implementation. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Mon May 9 07:42:35 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9B8E071C for ; Mon, 9 May 2011 07:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zN46gB7RIcEq for ; Mon, 9 May 2011 07:42:35 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 04019E0785 for ; Mon, 9 May 2011 07:42:34 -0700 (PDT) Received: by pvh1 with SMTP id 1so3218087pvh.31 for ; Mon, 09 May 2011 07:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ae2AO35ZtoGocZOzwK1Li5SMd/TqKV+WXqb2cvJ4hcc=; b=OaZksPB5zNIMXvZ1Nasgg/AK9UQUUlyFq1jHq3azEh+zCLdangsea5vjAyeuEsBoGh Pbrk7wAv+ibO5G1g3LrxRgYnstf0H5VFqeJO+vKZj/GjFSku7a8MvYBovLxfMKyP7KYp eI/HupIULRyYEgN1sRz0Jzmu0QrHcBfnL4NBQ= 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=lVkGOBDnbLA1C/zEBVsvIBPaFyKKtX9mjXPbNT0AGLT2zqubg5925ufoKL13wJ1uk9 TGuMw14b7tpfsnMQVQ4aFbMg7doNYNoH/i6jNbKNCEXJb8y+BytleBEDaz8FeFwjf3Ln ed52NkFtcL0Kw0KS2E8lXcetK0kA2b9p9qDLQ= Received: by 10.142.191.1 with SMTP id o1mr3574997wff.396.1304952154483; Mon, 09 May 2011 07:42:34 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id 25sm8199521wfb.10.2011.05.09.07.42.33 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 07:42:33 -0700 (PDT) Message-ID: <4DC7FD20.3090909@gmail.com> Date: Mon, 09 May 2011 07:41:36 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC5ABAB.5040306@boroon.dasgupta.ch> <4DC5BDD5.7080103@gmail.com> <4DC7AD04.5090608@boroon.dasgupta.ch> In-Reply-To: <4DC7AD04.5090608@boroon.dasgupta.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] What does "ADT" mean? X-BeenThere: vwrap@ietf.org 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: Mon, 09 May 2011 14:42:35 -0000 Maybe as synonymous as the words "standard" and "innovation". On 05/09/2011 01:59 AM, Boroondas Gupte wrote: > >> A system of abstract data types (such as LLSD) has no accepted name or >> abbreviation, but commonly one says "ADT system", >> > Well, Meadhbh (and others behind LLSD?) seem to have coined the term > "abstract type system" for such systems, but "ADT system" is equally > understandable now that "ADT" is understood, so we can use those two > terms synonymous, I guess. > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Mon May 9 07:47:47 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A34E07F5 for ; Mon, 9 May 2011 07:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.892 X-Spam-Level: X-Spam-Status: No, score=-3.892 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K556vzYEe4F1 for ; Mon, 9 May 2011 07:47:46 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 227BEE07F1 for ; Mon, 9 May 2011 07:47:46 -0700 (PDT) Received: by pxi2 with SMTP id 2so3257732pxi.38 for ; Mon, 09 May 2011 07:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=szuECAFVbCzz1mbs/Kiv+kJLFi8a/6wQKcuXMaSSu4w=; b=A+LDBzugo86BWMEFf1PUFUYXS6xuE2L+63pfP4IOqYTV70htB5poML14j61cL3km6V Y/4bbUy9xinW8j4LsiYUDFxaNHCozBBv0QKo+K4/Jua2Vd+2slJdC13zfpYU6f1f8dyb AEmoadwdRlrOu4w1Jv6Qk/rK5duclr1+eBkdk= 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=thcIkWbfYzJqH8WgwOXvEbBUYJ0DYgAbB84vGPmlBQCRmrGZKRIr96hndBHif8UY5Z hkj3CfAgih5K1SmPDvSD8he31jZFwVSN4nHyacBtJXz6cwRLvdD//FZpsYBrJKdx/mLH 4khJ9vBosJDfr0z5ezPQ8f0A/AtG4mYBRrmjg= Received: by 10.68.44.202 with SMTP id g10mr9755222pbm.379.1304952076550; Mon, 09 May 2011 07:41:16 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id f4sm4149782pbd.13.2011.05.09.07.41.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 07:41:15 -0700 (PDT) Message-ID: <4DC7FCD2.1090805@gmail.com> Date: Mon, 09 May 2011 07:40:18 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC5ABAB.5040306@boroon.dasgupta.ch> <4DC5BDD5.7080103@gmail.com> <4DC7AD04.5090608@boroon.dasgupta.ch> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] What does "ADT" mean? X-BeenThere: vwrap@ietf.org 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: Mon, 09 May 2011 14:47:47 -0000 It's derived from Abstract Oriented Design. I published a paper on such to USENET in the '90s, so this isn't anything new to me. The paper merely pinpointed the need for real object oriented design to be active before abstract oriented design can be achieved. That's said passive because the main point is the flat model most people think is object oriented design is not sufficient for true OOP. AOD is something even JavaVM couldn't achieve while limited to its flat text orientation model for program design. JVM added some hooks into the language to simulate such, yet even that attempt proved JavaVM wasn't so original and based upon many ideas they never credited nor implemented first (which finally forced Sun to open source). On 05/09/2011 06:58 AM, Morgaine wrote: > Aye, that phrase has been in use for as long as types systems have > existed. > > > Morgaine. > > > > ====================== > > On Mon, May 9, 2011 at 2:53 PM, Meadhbh Hamrick > wrote: > > hmm... don't think me or mark lentczner coined the term "abstract type > system." i was used by the OMG and Microsoft long before we used it. > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > > On Mon, May 9, 2011 at 1:59 AM, Boroondas Gupte > > > wrote: > > Thanks for the clarification. > > > > On 05/08/2011 03:47 AM, Morgaine wrote: > >> ADT means Abstract Data Type. > > Ah, as I suspected. :-) > > > >> A system of abstract data types (such as LLSD) has no accepted > name or > >> abbreviation, but commonly one says "ADT system", > > Well, Meadhbh (and others behind LLSD?) seem to have coined the term > > "abstract type system" for such systems, but "ADT system" is equally > > understandable now that "ADT" is understood, so we can use those two > > terms synonymous, I guess. > > > >> or where context allows an unambiguous interpretation, simply > "ADT". > >> > >> No mystery there, it has been so for decades of common usage in > >> Computing. :-) > > The whole mystery was that I just wasn't aware that it was common to > > just say "ADT" instead of "ADT system" or "abstract type > system", when > > it is clear that a system is meant rather than a single type. > > > > Cheers, > > Boroondas > > _______________________________________________ > > vwrap mailing list > > vwrap@ietf.org > > https://www.ietf.org/mailman/listinfo/vwrap > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Mon May 9 08:03:50 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D51DE080B for ; Mon, 9 May 2011 08:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.885 X-Spam-Level: X-Spam-Status: No, score=-3.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmuh8rSLZ3Yr for ; Mon, 9 May 2011 08:03:49 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 84466E0807 for ; Mon, 9 May 2011 08:03:49 -0700 (PDT) Received: by pwi5 with SMTP id 5so3233776pwi.31 for ; Mon, 09 May 2011 08:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=j8mCEPZUb5xtMCoAOh5dUyxcWdFNqukDECssnqPof74=; b=IRKmpckLIZokO5mNEQ4kteDwFU5V42dYLXRGqPkLuru32OBhL2lB/MhaQr0726qySh /Bi9T1fm02hufPVsLdCNbnjkuaVHA21Rp4rjX/T106rr8A2sscCwBGzIWnqy7zzhgk/V 9b334Ohj+KmeEWXutHAE9i+JLldabD5uvDHto= 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=jzXXtqch204KCpMyDhFuKK1tn6AWZuA5Lk4l0SeXEyfZPAlfOmcdZWM9wJLU3967ni 3/VzilWQp/5Hjg2iZsvvYTlxKmcjzk+LaN2OSaFkryhVnMSm5oxPG8Cr2Vb1QLYhc3y3 0XZ+6kykjtSTBZgJ1Pn/BIVDD521EplFXpcpY= Received: by 10.68.44.130 with SMTP id e2mr9865860pbm.515.1304953428895; Mon, 09 May 2011 08:03:48 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id l7sm4158585pbo.44.2011.05.09.08.03.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 08:03:47 -0700 (PDT) Message-ID: <4DC8021A.3030702@gmail.com> Date: Mon, 09 May 2011 08:02:50 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC6840B.9050203@gmail.com> <201105090012.50031.bobby@sharedrealm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [vwrap] The tag... is the group still interested in LLSD or DSD? X-BeenThere: vwrap@ietf.org 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: Mon, 09 May 2011 15:03:50 -0000 Morgaine, you haven't shown to trust LLSD as-is. We need that much published so we can move on with what developers have already done for the last few years to share implementation of LLSD. They just have their hands tied and can't express their interest. Then you can play with another WIP/RFC after that much is done. I don't see why you continue to argue to get rid of LLSD as-is. How can we trust you and what you want to write? You have ignored those that want to keep LLSD as-is. This is why I motioned earlier to go ahead and publish the type system as-is because your desire to innovate from that "standard" (as-is) weighs-in on the reason why to keep LLSD as-is. It makes more sense this way.... historical. On 05/09/2011 04:59 AM, Morgaine wrote: > Indeed Robert.� We're defining a new ADT system for VWRAP, and LLSD > was merely the initial input. > > I think we should call the types system that we're defining something > like VWRAP-ATS (VWRAP Abstract Types System), to avoid it being > confused with the current LLSD. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From sllists@boroon.dasgupta.ch Mon May 9 13:10:29 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01A1E06DB for ; Mon, 9 May 2011 13:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wFn30fJvHjn for ; Mon, 9 May 2011 13:10:29 -0700 (PDT) Received: from datendelphin.net (india288.server4you.de [85.25.150.202]) by ietfa.amsl.com (Postfix) with ESMTP id A3FE5E06D9 for ; Mon, 9 May 2011 13:10:28 -0700 (PDT) Received: from [192.168.1.107] (adsl-84-227-57-27.adslplus.ch [84.227.57.27]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by datendelphin.net (Postfix) with ESMTPSA id 331AD2E045 for ; Mon, 9 May 2011 22:13:58 +0200 (CEST) Message-ID: <4DC84A2D.8030305@boroon.dasgupta.ch> Date: Mon, 09 May 2011 22:10:21 +0200 From: Boroondas Gupte User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC5ABAB.5040306@boroon.dasgupta.ch> <4DC5BDD5.7080103@gmail.com> <4DC7AD04.5090608@boroon.dasgupta.ch> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050804000509020501000206" Subject: [vwrap] "ATS" (was: What does "ADT" mean?) X-BeenThere: vwrap@ietf.org 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: Mon, 09 May 2011 20:10:29 -0000 This is a multi-part message in MIME format. --------------050804000509020501000206 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 05/09/2011 03:49 PM, Morgaine wrote: > We can coin our own abbreviations too. :-) > > Since "abstract types system" is precise and unambiguous, would you > like us to use "ATS" as a shorthand for this, an even less verbose way > of saying "ADT system"? It's fine by me. :-) I just googled around and "ATS" collides with the name of a programming language (and a lot of completely unrelated stuff, off course), but that is unlikely to cause confusion, so it's fine with me, too. > It would also lead naturally to VWRAP's ATS being known as VWRAP-ATS, > which makes sense. Yep. Cheers, Boroondas --------------050804000509020501000206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 05/09/2011 03:49 PM, Morgaine wrote:
We can coin our own abbreviations too. :-)

Since "abstract types system" is precise and unambiguous, would you like us to use "ATS" as a shorthand for this, an even less verbose way of saying "ADT system"?  It's fine by me. :-)
I just googled around and "ATS" collides with the name of a programming language (and a lot of completely unrelated stuff, off course), but that is unlikely to cause confusion, so it's fine with me, too.

It would also lead naturally to VWRAP's ATS being known as VWRAP-ATS, which makes sense.
Yep.

Cheers,
Boroondas
--------------050804000509020501000206-- From sllists@boroon.dasgupta.ch Mon May 9 13:36:28 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C206BE08D9 for ; Mon, 9 May 2011 13:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYqLfTbDrBMT for ; Mon, 9 May 2011 13:36:28 -0700 (PDT) Received: from datendelphin.net (india288.server4you.de [85.25.150.202]) by ietfa.amsl.com (Postfix) with ESMTP id 03D38E07C8 for ; Mon, 9 May 2011 13:36:27 -0700 (PDT) Received: from [192.168.1.107] (adsl-84-227-57-27.adslplus.ch [84.227.57.27]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by datendelphin.net (Postfix) with ESMTPSA id EDD832E045 for ; Mon, 9 May 2011 22:39:57 +0200 (CEST) Message-ID: <4DC85049.40600@boroon.dasgupta.ch> Date: Mon, 09 May 2011 22:36:25 +0200 From: Boroondas Gupte User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: vwrap@ietf.org Content-Type: multipart/alternative; boundary="------------070403090305010506040808" Subject: [vwrap] What abstract type systems already exist? X-BeenThere: vwrap@ietf.org 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: Mon, 09 May 2011 20:36:28 -0000 This is a multi-part message in MIME format. --------------070403090305010506040808 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 05/08/2011 03:47 AM, Morgaine wrote: > ADT means Abstract Data Type. > [...] > No mystery there, it has been so for decades of common usage in > Computing. :-) On 05/09/2011 03:53 PM, Meadhbh Hamrick wrote: > hmm... don't think me or mark lentczner coined the term "abstract type > system." i was used by the OMG and Microsoft long before we used it. On 05/09/2011 03:58 PM, Morgaine wrote: > Aye, that phrase has been in use for as long as types systems have > existed. As the concepts of both, ADTs and ATSs have apparently existed longer already than I assumed, I guess there must be ATSs other than LLSD. As a basis for decisions, it'd be useful to have some overview. So my question is: *What abstract type systems do currently exist *("exist" as in published and sufficiently documented. Don't have to be formally standardized, though if they are, that's a plus.)*and how do they compare to LLSD?* For each such ATS, it'd be useful to know: * How flexible is it? (Could it be used for VWRAP? For that, its set of types probably must already be designed for general purpose or (like LLSD) with typical virtual world data in mind.) * Is it extensible? How does the extension mechanism work? * Are there serializations defined for it? If so, which ones? * How entangled is the ATS itself with the serializations? * How simple is it? (Both conceptually and for implementors of (de)serializers etc.) Once we have collected that, we'd be in a better position whether to use LLSD (as-is) or one of the other systems or whether to create our own (probably based on LLSD and/or other ones). Cheers, Boroondas --------------070403090305010506040808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 05/08/2011 03:47 AM, Morgaine wrote:
ADT means Abstract Data Type.
[...]
No mystery there, it has been so for decades of common usage in Computing. :-)
On 05/09/2011 03:53 PM, Meadhbh Hamrick wrote: 
hmm... don't think me or mark lentczner coined the term "abstract type
system." i was used by the OMG and Microsoft long before we used it.
On 05/09/2011 03:58 PM, Morgaine wrote:
Aye, that phrase has been in use for as long as types systems have existed.

As the concepts of both, ADTs and ATSs have apparently existed longer already than I assumed, I guess there must be ATSs other than LLSD. As a basis for decisions, it'd be useful to have some overview. So my question is:
What abstract type systems do currently exist ("exist" as in published and sufficiently documented. Don't have to be formally standardized, though if they are, that's a plus.) and how do they compare to LLSD?

For each such ATS, it'd be useful to know:
  • How flexible is it?
    (Could it be used for VWRAP? For that, its set of types probably must already be designed for general purpose or (like LLSD) with typical virtual world data in mind.)
  • Is it extensible? How does the extension mechanism work?
  • Are there serializations defined for it? If so, which ones?
  • How entangled is the ATS itself with the serializations?
  • How simple is it? (Both conceptually and for implementors of (de)serializers etc.)
Once we have collected that, we'd be in a better position whether to use LLSD (as-is) or one of the other systems or whether to create our own (probably based on LLSD and/or other ones).

Cheers,
Boroondas
--------------070403090305010506040808-- From dzonatas@gmail.com Mon May 9 16:06:09 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025D8E0744 for ; Mon, 9 May 2011 16:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5JqW-qM49xI for ; Mon, 9 May 2011 16:06:07 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 99D35E072C for ; Mon, 9 May 2011 16:06:07 -0700 (PDT) Received: by pwi5 with SMTP id 5so3467646pwi.31 for ; Mon, 09 May 2011 16:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JBagKiSEd/a8kevC/VKb1TnhX7rHTRqCUlcbbdEmJZ4=; b=H76nBx+OdQ8NJlxgv16kTWvVowMAoe89PSmPaT/hJXeCgEV+8vTgSB/SwzhaJ81m8M 7ZIL6j4MaX76pgp4yJz58uxawBFyHffUYFxPl40AL1Bb3dOx03FXTQ9f17289u4dWAEa wX7wvq/YfuNBCOQO6a9X4dgv66XxMw8sa369k= 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=PrKVRz7NWfTDrzJHCuZGnO6fYTNtvYf4ym2keOIzCiLaYrq2OVG2SfVesbkfvGkwfU gS4otS7vt8cyJ48Ei+9fA5cy6KRfz41dhsCU7GhSdoSM6ZR7UZfXHiD292kBaapPxfPA k5UCQVKSpt0i0b1P1CxVwoXrJMuxqgUFTkuBo= Received: by 10.68.10.136 with SMTP id i8mr293882pbb.248.1304981926686; Mon, 09 May 2011 15:58:46 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id y7sm4387547pbg.43.2011.05.09.15.58.45 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 15:58:45 -0700 (PDT) Message-ID: <4DC8716C.7080201@gmail.com> Date: Mon, 09 May 2011 15:57:48 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC85049.40600@boroon.dasgupta.ch> In-Reply-To: <4DC85049.40600@boroon.dasgupta.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] What abstract type systems already exist? X-BeenThere: vwrap@ietf.org 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: Mon, 09 May 2011 23:06:09 -0000 On 05/09/2011 01:36 PM, Boroondas Gupte wrote: > > *What abstract type systems do currently exist *("exist" as in > published and sufficiently documented. Don't have to be formally > standardized, though if they are, that's a plus.)* and how do they > compare to LLSD?* http://www.w3schools.com/dtd/ We know Meadhbh wants DSD and we obviously can avoid DTD in every message. I see the main pivot that Meadhbh wants is less symbology, yet that still means a solution for others. I'm thinking something like the XML2RFC editor has an ideal solution, but I'm scientist, so it's not my pen to determine that way. However, let's look at DTD: > > For each such ATS, it'd be useful to know: > > * How flexible is it? > (Could it be used for VWRAP? For that, its set of types probably > must already be designed for general purpose or (like LLSD) with > typical virtual world data in mind.) > It's very flexible, however people often don't know how to implement optimizations properly. They usually just present the end result, like LLSD. Consider something like SVG/XHTML, and there should be no complaints of what is possible. We could express this more in terms of ontology with WebGL and likewise and maybe the ideal more clique-in. > * Is it extensible? How does the extension mechanism work? > If some definition doesn't work, then we could put XSL+DTD into the works to transform and extend. > * > > > * Are there serializations defined for it? If so, which ones? > Serialize XML data? Easy, just remove the tags. I don't know why people consider XML as THE serialized data. XML just helps format the data. > * How entangled is the ATS itself with the serializations? > I think people use XML the wrong way and abuse it. When people add attributes to XML tags not for flow issues, then that usually is a sign of XML abuse. > * How simple is it? (Both conceptually and for implementors of > (de)serializers etc.) > > Consider the example: -------------------------------------------------------- ]> Tove Jani Reminder Don't forget me this weekend -------------------------------------------------------- When serialized looks like this: -------------------------------------------------------- Tove Jani Reminder Don't forget me this weekend -------------------------------------------------------- The reader only needs to apply the DTD to deserialize back into XML. There are differences between "strict" DTD and non-strict. Strict typed allow dynamic placement of data such the DTD only has to specify the types once. The reader parsers the data and translates them into types. That level of transmission and optimization should be negotiable, however. Why is this WG concerned with reinventing ASCII? For those that don't know we could say that means Abstracted Serialized Codex Internationational Interchange, yet we still deal with backword compatibility to double nybble types (DNT). -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Mon May 9 16:08:01 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9C0E0744 for ; Mon, 9 May 2011 16:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjHw+OZzvUXW for ; Mon, 9 May 2011 16:07:59 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3B4E072C for ; Mon, 9 May 2011 16:07:58 -0700 (PDT) Received: by qyk7 with SMTP id 7so4395701qyk.10 for ; Mon, 09 May 2011 16:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6DrLHHyKxY5wzzTorEMQTdqApQ1yA6EJcton0VMqPxs=; b=ISrrapvSB6rXUVfpoo088iTLoEZ2CBNgR75O6Apv3E/iihzBPBCJjKxigMdHw6kDtr guJtIUvfONVK7+X1Ir8rV26eTPDEblsJTIIpRaF3BL2U5Ppvub4vy37HOPXGIeYSYU9g bqTWnNgEXZysV5B2pG/ZjAqVSxdiYeOGb5Cl0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Kd4mPczQ8VDMiUKMJVGQTE8OTfkEnQFcmpO+pwfvk/eRHhwhEZIRdnEMNYA9DbYO/Q RhtTyzabY4P9sfRCn0w/DSvLZTo7c/2wdT4kQ6IyjTcK57mLxGX3Gq8BlXFa1y+40mSv eebf+CBRk2kCSDbJ1ptR36Uw6JJaMQgiAFE9Y= MIME-Version: 1.0 Received: by 10.229.27.78 with SMTP id h14mr5181994qcc.253.1304982477489; Mon, 09 May 2011 16:07:57 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Mon, 9 May 2011 16:07:57 -0700 (PDT) In-Reply-To: <4DC85049.40600@boroon.dasgupta.ch> References: <4DC85049.40600@boroon.dasgupta.ch> Date: Tue, 10 May 2011 00:07:57 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=001636426b6b02483904a2dfe9d1 Subject: Re: [vwrap] What abstract type systems already exist? X-BeenThere: vwrap@ietf.org 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: Mon, 09 May 2011 23:08:02 -0000 --001636426b6b02483904a2dfe9d1 Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 9, 2011 at 9:36 PM, Boroondas Gupte wrote: > > *What abstract type systems do currently exist *("exist" as in published > and sufficiently documented. Don't have to be formally standardized, though > if they are, that's a plus.)* and how do they compare to LLSD?* > Fantastic question! It could easily form the basis of a worthy MSc thesis too. :-) For our purposes, since we have a very practical goal, I'll narrow this response down to a very short one by eliminating all those that are programming language-specific (many languages allow you to define your own ADTs within them), and focus on the most popular language-agnostic ADTs that have numerous implementations and language bindings. It's going to be an impressively short response because I'm just going to link to a useful Wikipedia article. :P It needs to be stated that because our interest is in practical implementations only, in practice your question becomes almost identical to asking about popular serialization systems. Behind every serialization system there is a types system, but the opposite is not necessarily true. Before I do that though, let me point out the single most widely deployed, best documented, and most standardized abstract types and serialization system on the planet, which also happens to be one of the oldest on the Internet, *ASN.1* --- http://en.wikipedia.org/wiki/ASN.1 (official standards documents are linked in the article). How does ASN.1 compare to LLSD? It's hugely more flexible, much more efficient, arbitrarily extensible, and unlimited in the precision of its primitive types. (The recent newcomers Protocol Buffers and Thrift actually borrow quite a few tricks from it.) Beyond that, take a quick look at the Wikipedia article on "Comparison of data serialization formats", which lists a very useful selection of those that are "notable": http://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats . As you'll note, quite a few of them have official standards, some informational RFCs, and others have high popularity despite only informal documentation. There is certainly no lack of candidates. :-) Morgaine. ======================= On Mon, May 9, 2011 at 9:36 PM, Boroondas Gupte wrote: > On 05/08/2011 03:47 AM, Morgaine wrote: > > ADT means Abstract Data Type. > [...] > No mystery there, it has been so for decades of common usage in Computing. > :-) > > On 05/09/2011 03:53 PM, Meadhbh Hamrick wrote: > > hmm... don't think me or mark lentczner coined the term "abstract type > system." i was used by the OMG and Microsoft long before we used it. > > On 05/09/2011 03:58 PM, Morgaine wrote: > > Aye, that phrase has been in use for as long as types systems have existed. > > > As the concepts of both, ADTs and ATSs have apparently existed longer > already than I assumed, I guess there must be ATSs other than LLSD. As a > basis for decisions, it'd be useful to have some overview. So my question > is: > *What abstract type systems do currently exist *("exist" as in published > and sufficiently documented. Don't have to be formally standardized, though > if they are, that's a plus.)* and how do they compare to LLSD?* > > For each such ATS, it'd be useful to know: > > - How flexible is it? > (Could it be used for VWRAP? For that, its set of types probably must > already be designed for general purpose or (like LLSD) with typical virtual > world data in mind.) > - Is it extensible? How does the extension mechanism work? > - Are there serializations defined for it? If so, which ones? > - How entangled is the ATS itself with the serializations? > - How simple is it? (Both conceptually and for implementors of > (de)serializers etc.) > > Once we have collected that, we'd be in a better position whether to use > LLSD (as-is) or one of the other systems or whether to create our own > (probably based on LLSD and/or other ones). > > Cheers, > Boroondas > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > --001636426b6b02483904a2dfe9d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, May 9, 2011 at 9:36 PM, Boroondas Gupte <sllists@boroon.dasgupta.ch>= wrote:
=20 =20 =20

What abstract type systems do currently exist ("exist"= as in published and sufficiently documented. Don't have to be formally standardized, though if they are, that's a plus.) and how do the= y compare to LLSD?


Fantastic question!=A0= It could easily form the basis of a worthy MSc thesis too. :-)

For = our purposes, since we have a very practical goal, I'll narrow this res= ponse down to a very short one by eliminating all those that are programmin= g language-specific (many languages allow you to define your own ADTs withi= n them), and focus on the most popular language-agnostic ADTs that have num= erous implementations and language bindings.=A0 It's going to be an imp= ressively short response because I'm just going to link to a useful Wik= ipedia article. :P

It needs to be stated that because our interest is in practical impleme= ntations only, in practice your question becomes almost identical to asking= about popular serialization systems.=A0 Behind every serialization system = there is a types system, but the opposite is not necessarily true.

Before I do that though, let me point out the single most widely deploy= ed, best documented, and most standardized abstract types and serialization= system on the planet, which also happens to be one of the oldest on the In= ternet, ASN.1=A0 --- = http://en.wikipedia.org/wiki/ASN.1 (official standards documents are li= nked in the article).

How does ASN.1 compare to LLSD?=A0 It's hugely more flexible, much = more efficient, arbitrarily extensible, and unlimited in the precision of i= ts primitive types.=A0 (The recent newcomers Protocol Buffers and Thrift ac= tually borrow quite a few tricks from it.)

Beyond that, take a quick look at the Wikipedia article on "Compar= ison of data serialization formats", which lists a very useful selecti= on of those that are "notable":=A0 http://en.wikipedia.org= /wiki/Comparison_of_data_serialization_formats .=A0 As you'll note,= quite a few of them have official standards, some informational RFCs, and = others have high popularity despite only informal documentation.

There is certainly no lack of candidates. :-)


Morgaine.
<= br>


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

On Mon, May 9, 2011 at 9:36 PM,= Boroondas Gupte <sllists@boroon.dasgupta.ch> wrote:
=20 =20 =20
On 05/08/2011 03:47 AM, Morgaine wrote:
ADT means Abstract Data Type.
[...]
No mystery there, it has been so for decades of common usage in Computing. :-)
On 05/09/2011 03:53 PM, Meadhbh Hamrick wrote: 
hmm... don't think me or mark lentczner coined the term &quo=
t;abstract type
system." i was used by the OMG and Microsoft long before we used it.
On 05/09/2011 03:58 PM, Morgaine wrote:
Aye, that phrase has been in use for as long = as types systems have existed.

As the concepts of both, ADTs and ATSs have apparently existed longer already than I assumed, I guess there must be ATSs other than LLSD. As a basis for decisions, it'd be useful to have some overview. So my question is:
What abstract type systems do currently exist ("exist"= as in published and sufficiently documented. Don't have to be formally standardized, though if they are, that's a plus.) and how do the= y compare to LLSD?

For each such ATS, it'd be useful to know:
  • How flexible is it?
    (Could it be used for VWRAP? For that, its set of types probably must already be designed for general purpose or (like LLSD) with typical virtual world data in mind.)
  • Is it extensible? How does the extension mechanism work?
  • Are there serializations defined for it? If so, which ones?
  • How entangled is the ATS itself with the serializations?
  • How simple is it? (Both conceptually and for implementors of (de)serializers etc.)
Once we have collected that, we'd be in a better position whether t= o use LLSD (as-is) or one of the other systems or whether to create our own (probably based on LLSD and/or other ones).

Cheers,
Boroondas

_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


--001636426b6b02483904a2dfe9d1-- From josh@lindenlab.com Mon May 9 16:57:24 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E74E0836 for ; Mon, 9 May 2011 16:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: 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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEOjx9iNzNRZ for ; Mon, 9 May 2011 16:57:19 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id A9E0FE0851 for ; Mon, 9 May 2011 16:57:19 -0700 (PDT) Received: by pzk5 with SMTP id 5so3481125pzk.31 for ; Mon, 09 May 2011 16:57:19 -0700 (PDT) Received: by 10.142.207.20 with SMTP id e20mr4252009wfg.129.1304985064312; Mon, 09 May 2011 16:51:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.132.10 with HTTP; Mon, 9 May 2011 16:50:44 -0700 (PDT) In-Reply-To: <4DC85049.40600@boroon.dasgupta.ch> References: <4DC85049.40600@boroon.dasgupta.ch> From: Joshua Bell Date: Mon, 9 May 2011 16:50:44 -0700 Message-ID: To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd2285a32118d04a2e08353 Subject: Re: [vwrap] What abstract type systems already exist? X-BeenThere: vwrap@ietf.org 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: Mon, 09 May 2011 23:57:24 -0000 --000e0cd2285a32118d04a2e08353 Content-Type: text/plain; charset=UTF-8 On Mon, May 9, 2011 at 1:36 PM, Boroondas Gupte wrote: > *What abstract type systems do currently exist *("exist" as in published > and sufficiently documented. Don't have to be formally standardized, though > if they are, that's a plus.)* and how do they compare to LLSD?* > This is an excellent question. For what it's worth, it's possible that at least the first part of this question has been explored as it relates to virtual worlds by the IEEE P1828 working group http://standards.ieee.org/develop/project/1828.html on virtual worlds. I'm on the mailing list (as are some other VWRAP list members, I believe) but confess to not having spent any significant time engaged with the group. What I do know is that P1828 members have performed a number of technology surveys. The working group is not focused on any particular architecture for virtual worlds (as chartered, VWRAP has a fairly specific approach in mind), and is instead looking broadly at possible technologies to embrace as "best practices" for virtual worlds. The P1828 working group's discussion list is http://listserv.ieee.org/cgi-bin/wa?A0=VWSTANDARDWKGRP - you might find it worthwhile to peruse archives and/or engage in discussions with that group regarding this and other issues where consensus on a new or converging design is not the driving factor (as it tends to be within IETF groups) but exploring existing technologies for suitability within a problem domain. NOTE: The IEEE doubtless has different intellectual property rules applying to discussion on its lists than the IETF, so make sure to read whatever equivalent of the Note Well exists over yonder. -- Josh --000e0cd2285a32118d04a2e08353 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, May 9, 2011 at 1:36 PM, Boroondas Gupte = <sllists= @boroon.dasgupta.ch> wrote:
What abstract type systems d= o currently exist ("exist" as in published and sufficiently documented. Don't have to be formally standardized, though if they are, that's a plus.) and how do the= y compare to LLSD?

This is an= excellent question.

For what it's worth, it&#= 39;s possible that at least the first part of this question has been explor= ed as it relates to virtual worlds by the IEEE P1828 working group=C2=A0http://standar= ds.ieee.org/develop/project/1828.html=C2=A0on virtual worlds. I'm o= n the mailing list (as are some other VWRAP list members, I believe) but co= nfess to not having spent any significant time engaged with the group.=C2= =A0

What I do know is that P1828 members have performed a n= umber of technology surveys. The working group is not focused on any partic= ular architecture for virtual worlds (as chartered, VWRAP has a fairly spec= ific approach in mind), and is instead looking broadly at possible technolo= gies to embrace as "best practices" for virtual worlds. The P1828= working group's discussion list is=C2=A0http://listserv.ieee.org/cgi-bin/wa?= A0=3DVWSTANDARDWKGRP=C2=A0- you might find it worthwhile to peruse arch= ives and/or engage in discussions with that group regarding this and other = issues where consensus on a new or converging design is not the driving fac= tor (as it tends to be within IETF groups) but exploring existing technolog= ies for=C2=A0suitability=C2=A0within a problem domain.

NOTE: The IEEE doubtless has different intellectual pro= perty rules applying to discussion on its lists than the IETF, so make sure= to read whatever equivalent of the Note Well exists over yonder.

-- Josh

--000e0cd2285a32118d04a2e08353-- From dzonatas@gmail.com Mon May 9 17:06:52 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1C3E0681 for ; Mon, 9 May 2011 17:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.865 X-Spam-Level: X-Spam-Status: No, score=-4.865 tagged_above=-999 required=5 tests=[AWL=0.734, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KU3mjzpr6IlL for ; Mon, 9 May 2011 17:06:48 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D97FE0848 for ; Mon, 9 May 2011 17:06:48 -0700 (PDT) Received: by pzk5 with SMTP id 5so3484535pzk.31 for ; Mon, 09 May 2011 17:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iHTWuzbRhpjO0N9ZqYu3UR3+5z5j7AVVuj3X2NAoR9g=; b=NhVhPaf7tCsQZiQ6vzGjsQvlYW99utYw4/Hv1jc3CA7d2qw3WML9JHRGabzz/vlHPH sO5DdEa9HwhGaN0bHBhzwJKmRySnGW5Z4j6iAmBKfT6hwFuvDSaKvwWerzAUhx783cRG Przqoz8SK7eBGpQuLYi301CJgwTrYxnbEM9dM= 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=f5eJ2qPqhdyhD9Le9vum1KlLAO13HypvWKw5IGCseDlzofkb2YxD4zu2wL9SfJu1bf FDhkLS0z+FiLSkr9/7TPGPVT3EBBkXOaemDRfk1D3LgEx7qplp4ojA3WB8z4gKUXWJRy J9YEi7D7ETCY2FYIAErGxvWYSWXAwnO8OokmE= Received: by 10.68.26.201 with SMTP id n9mr10746935pbg.152.1304986007942; Mon, 09 May 2011 17:06:47 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id u10sm4419535pbt.69.2011.05.09.17.06.46 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 17:06:47 -0700 (PDT) Message-ID: <4DC8815E.4090003@gmail.com> Date: Mon, 09 May 2011 17:05:50 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC85049.40600@boroon.dasgupta.ch> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [vwrap] What abstract type systems already exist? X-BeenThere: vwrap@ietf.org 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: Tue, 10 May 2011 00:06:52 -0000 On 05/09/2011 04:07 PM, Morgaine wrote: > On Mon, May 9, 2011 at 9:36 PM, Boroondas Gupte > > wrote: > > > *What abstract type systems do currently exist *("exist" as in > published and sufficiently documented. Don't have to be formally > standardized, though if they are, that's a plus.)* and how do they > compare to LLSD?* > > > > Fantastic question!� It could easily form the basis of a worthy MSc > thesis too. :-) [...] As much as I would want to agree with you there, I think you overlooked that would not be democratical to Science of the Letters, so I cannot. I hope the chairs take note of this stand. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Mon May 9 21:23:03 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D73E06E2 for ; Mon, 9 May 2011 21:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEEs3Y1CX-QC for ; Mon, 9 May 2011 21:23:02 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id E8D27E0791 for ; Mon, 9 May 2011 21:23:01 -0700 (PDT) Received: by qyk7 with SMTP id 7so4492095qyk.10 for ; Mon, 09 May 2011 21:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NyzWyuZaODYlXBTL/66g9cprGkmIT/6+E27XTtJK6Qk=; b=VCcy7WkcrNb0Dft/ZNAVDKKQWFrGdP5bzT7IsrmSLqmY8DgDHB7eWKfuVC7mRbog2f TL3MZILpL7C44Wa6/g8C7T9skO4l2YExNvLcKCMT1NQ6UovpefrQV5QQB6Idb17irca1 w2q6vtiKffzJldSBN8dMKmeVcoTcvdIOYMMcU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bgkFYjD5PacCKlDZBTxACaZmp6IRER/B4TOc997XFbx0mET5cnTSEprODCqJMmqz8W DICli3wAh1n3RcybC+EczWNf1JJTmrBtRECl2AerFT/w2klyoiClVwNNxppL4DNIi9ho IwEjFxqTKmhLdqwv73630yO1nfFh9/aTGrdRw= MIME-Version: 1.0 Received: by 10.229.44.141 with SMTP id a13mr5537670qcf.101.1305000904518; Mon, 09 May 2011 21:15:04 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Mon, 9 May 2011 21:15:04 -0700 (PDT) In-Reply-To: References: <4DC85049.40600@boroon.dasgupta.ch> Date: Tue, 10 May 2011 05:15:04 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=001636831fa0586dda04a2e4336d Subject: Re: [vwrap] What abstract type systems already exist? X-BeenThere: vwrap@ietf.org 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: Tue, 10 May 2011 04:23:03 -0000 --001636831fa0586dda04a2e4336d Content-Type: text/plain; charset=ISO-8859-1 Joshua, it was interesting to read in the P1828 working group's description that they are concerned with "interoperability of avatars and objects between and among virtual world environments". That could apply just as well to us. Do you recall whether the P1828 group has a concept resembling our shared asset services to achieve that? Morgaine. ======================= On Tue, May 10, 2011 at 12:50 AM, Joshua Bell wrote: > On Mon, May 9, 2011 at 1:36 PM, Boroondas Gupte < > sllists@boroon.dasgupta.ch> wrote: > >> *What abstract type systems do currently exist *("exist" as in published >> and sufficiently documented. Don't have to be formally standardized, though >> if they are, that's a plus.)* and how do they compare to LLSD?* >> > > This is an excellent question. > > For what it's worth, it's possible that at least the first part of this > question has been explored as it relates to virtual worlds by the IEEE P1828 > working group http://standards.ieee.org/develop/project/1828.html on > virtual worlds. I'm on the mailing list (as are some other VWRAP list > members, I believe) but confess to not having spent any significant time > engaged with the group. > > What I do know is that P1828 members have performed a number of technology > surveys. The working group is not focused on any particular architecture for > virtual worlds (as chartered, VWRAP has a fairly specific approach in mind), > and is instead looking broadly at possible technologies to embrace as "best > practices" for virtual worlds. The P1828 working group's discussion list is > http://listserv.ieee.org/cgi-bin/wa?A0=VWSTANDARDWKGRP - you might find it > worthwhile to peruse archives and/or engage in discussions with that group > regarding this and other issues where consensus on a new or converging > design is not the driving factor (as it tends to be within IETF groups) but > exploring existing technologies for suitability within a problem domain. > > NOTE: The IEEE doubtless has different intellectual property rules applying > to discussion on its lists than the IETF, so make sure to read whatever > equivalent of the Note Well exists over yonder. > > -- Josh > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > --001636831fa0586dda04a2e4336d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Joshua, it was interesting to read in the P1828 working group's descrip= tion that they are concerned with "interoperability of avatars a= nd objects between and among virtual world environments".=A0 That coul= d apply just as well to us.

Do you recall whether the P1828 group has a concept resembling o= ur shared asset services to achieve that?


Morgaine.


<= br>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

On Tue, May 10, 2011 at 12:50 AM, = Joshua Bell <jos= h@lindenlab.com> wrote:
On Mon, May 9, 2011 at 1:36 PM, Boroondas Gupte= <sllists@boroon.dasgupta.ch> wrote:
=20 =20 =20
What abstract type systems d= o currently exist ("exist" as in published and sufficiently documented. Don't have to be formally standardized, though if they are, that's a plus.) and how do the= y compare to LLSD?

This= is an excellent question.

For what it's worth= , it's possible that at least the first part of this question has been = explored as it relates to virtual worlds by the IEEE P1828 working group=A0= http://standards.ieee.org/develop/project/1828.html=A0on virtual= worlds. I'm on the mailing list (as are some other VWRAP list members,= I believe) but confess to not having spent any significant time engaged wi= th the group.=A0

What I do know is that P1828 members have performed a n= umber of technology surveys. The working group is not focused on any partic= ular architecture for virtual worlds (as chartered, VWRAP has a fairly spec= ific approach in mind), and is instead looking broadly at possible technolo= gies to embrace as "best practices" for virtual worlds. The P1828= working group's discussion list is=A0http://listserv.ieee.= org/cgi-bin/wa?A0=3DVWSTANDARDWKGRP=A0- you might find it worthwhile to= peruse archives and/or engage in discussions with that group regarding thi= s and other issues where consensus on a new or converging design is not the= driving factor (as it tends to be within IETF groups) but exploring existi= ng technologies for=A0suitability=A0within a problem domain.

NOTE: The IEEE doubtless has different intellectual pro= perty rules applying to discussion on its lists than the IETF, so make sure= to read whatever equivalent of the Note Well exists over yonder.

-- Josh


_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


--001636831fa0586dda04a2e4336d-- From bobby@sharedrealm.com Tue May 10 03:35:44 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48548E0873 for ; Tue, 10 May 2011 03:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgV9vHLxyWPw for ; Tue, 10 May 2011 03:35:43 -0700 (PDT) Received: from mail.neoawareness.com (mail.neoawareness.com [67.223.232.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2A860E0829 for ; Tue, 10 May 2011 03:35:43 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=neo.localnet) by mail.neoawareness.com with esmtpa (Exim 4.69) (envelope-from ) id 1QJeWL-0004dg-Gc for vwrap@ietf.org; Tue, 10 May 2011 04:26:05 +0000 From: "Robert G. Jakabosky" To: vwrap@ietf.org Date: Mon, 9 May 2011 21:26:04 -0700 User-Agent: KMail/1.13.5 (Linux/2.6.32-bpo.5-amd64; KDE/4.4.5; x86_64; ; ) References: <4DC85049.40600@boroon.dasgupta.ch> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201105092126.04429.bobby@sharedrealm.com> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bobby@sharedrealm.com X-SA-Exim-Scanned: No (on mail.neoawareness.com); SAEximRunCond expanded to false Subject: Re: [vwrap] What abstract type systems already exist? X-BeenThere: vwrap@ietf.org 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: Tue, 10 May 2011 10:35:44 -0000 On Monday 09, Joshua Bell wrote: > On Mon, May 9, 2011 at 1:36 PM, Boroondas Gupte > > wrote: > > *What abstract type systems do currently exist *("exist" as in published > > and sufficiently documented. Don't have to be formally standardized, > > though if they are, that's a plus.)* and how do they compare to LLSD?* > > This is an excellent question. > > For what it's worth, it's possible that at least the first part of this > question has been explored as it relates to virtual worlds by the IEEE > P1828 working group http://standards.ieee.org/develop/project/1828.html on > virtual worlds. I'm on the mailing list (as are some other VWRAP list > members, I believe) but confess to not having spent any significant time > engaged with the group. > > What I do know is that P1828 members have performed a number of technology > surveys. The working group is not focused on any particular architecture > for virtual worlds (as chartered, VWRAP has a fairly specific approach in > mind), and is instead looking broadly at possible technologies to embrace > as "best practices" for virtual worlds. The P1828 working group's > discussion list is http://listserv.ieee.org/cgi-bin/wa?A0=VWSTANDARDWKGRP > - you might find it worthwhile to peruse archives and/or engage in > discussions with that group regarding this and other issues where > consensus on a new or converging design is not the driving factor (as it > tends to be within IETF groups) but exploring existing technologies for > suitability within a problem domain. I talked with chairperson of that IEEE working group and he said that the archive it only accessible to members of that working group, but there is a public wiki with some information from the group: http://www.metaversestandards.org/index.php?title=Main_Page -- Robert G. Jakabosky From morgaine.dinova@googlemail.com Tue May 10 07:01:49 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8306AE0736 for ; Tue, 10 May 2011 07:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.928 X-Spam-Level: X-Spam-Status: No, score=-2.928 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFLDTLRKW0YO for ; Tue, 10 May 2011 07:01:47 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9D0E0684 for ; Tue, 10 May 2011 07:01:47 -0700 (PDT) Received: by qyk7 with SMTP id 7so4742513qyk.10 for ; Tue, 10 May 2011 07:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7bUl3IOCbREn5J2dkZOf6UpikZ+n/iZMNFAnmQYP7HE=; b=iWkKcFvCWIjRIjpI6a1bAVTopwCb6zUMjt9uj0VoRc0ULvIoLmKMoCasMlTVGI3hS2 0Vje1P1OKmhEqBt/19frqVrxYxQelYOFqflMaawk/KAk2+f0Oeu7Ai2uHVxsbXXCo96H pF+oAxn3pY14mYngQXfN26yJ9CdywvTDjTVhc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hf+hHxE+JCL9kCYROIt/Ehi94/QxUMkpJMkmjEhniz+WSwPI8KYpbfFuC52c13QSOU kZ2BqqymIkWQbZysDwAtT5/u352CZGhWq3G3jUz5F/PeY/PjyFpuRH99551N036vcG4B ArtwEcBrsJc0jBHjTAioZzr6cjkQrAphfpp9U= MIME-Version: 1.0 Received: by 10.229.44.141 with SMTP id a13mr6042848qcf.101.1305035653486; Tue, 10 May 2011 06:54:13 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Tue, 10 May 2011 06:54:13 -0700 (PDT) In-Reply-To: <201105092126.04429.bobby@sharedrealm.com> References: <4DC85049.40600@boroon.dasgupta.ch> <201105092126.04429.bobby@sharedrealm.com> Date: Tue, 10 May 2011 14:54:13 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=001636831fa08b996004a2ec4a1d Subject: Re: [vwrap] What abstract type systems already exist? X-BeenThere: vwrap@ietf.org 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: Tue, 10 May 2011 14:01:49 -0000 --001636831fa08b996004a2ec4a1d Content-Type: text/plain; charset=ISO-8859-1 Thanks for finding the P1828 wiki, Robert. I looked through it to try to answer my question about whether they talk about anything like our shared asset services, but the wiki seems to be mostly full of placeholder terms and external references, which is in line with what Joshua said about technological surveys. Notice that even our VWRAP group is part of their scope. Under *Existing Working Groups* --> *Groups Developing Standards* --> *VWRAP*, they link the article that Joshua, David and I wrote for IEEE Internet Computing magazine in Feb 2010: http://internetmessagingtechnology.org/pubs/VWRAP-for-Virtual-Worlds-Interoperability-mic2010010073.pdf It'll be interesting to see what they do in this space once it goes beyond technology surveys. Morgaine. ====================== On Tue, May 10, 2011 at 5:26 AM, Robert G. Jakabosky wrote: > On Monday 09, Joshua Bell wrote: > > On Mon, May 9, 2011 at 1:36 PM, Boroondas Gupte > > > > wrote: > > > *What abstract type systems do currently exist *("exist" as in > published > > > and sufficiently documented. Don't have to be formally standardized, > > > though if they are, that's a plus.)* and how do they compare to LLSD?* > > > > This is an excellent question. > > > > For what it's worth, it's possible that at least the first part of this > > question has been explored as it relates to virtual worlds by the IEEE > > P1828 working group http://standards.ieee.org/develop/project/1828.htmlon > > virtual worlds. I'm on the mailing list (as are some other VWRAP list > > members, I believe) but confess to not having spent any significant time > > engaged with the group. > > > > What I do know is that P1828 members have performed a number of > technology > > surveys. The working group is not focused on any particular architecture > > for virtual worlds (as chartered, VWRAP has a fairly specific approach in > > mind), and is instead looking broadly at possible technologies to embrace > > as "best practices" for virtual worlds. The P1828 working group's > > discussion list is > http://listserv.ieee.org/cgi-bin/wa?A0=VWSTANDARDWKGRP > > - you might find it worthwhile to peruse archives and/or engage in > > discussions with that group regarding this and other issues where > > consensus on a new or converging design is not the driving factor (as it > > tends to be within IETF groups) but exploring existing technologies for > > suitability within a problem domain. > > I talked with chairperson of that IEEE working group and he said that the > archive it only accessible to members of that working group, but there is a > public wiki with some information from the group: > http://www.metaversestandards.org/index.php?title=Main_Page > > -- > Robert G. Jakabosky > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --001636831fa08b996004a2ec4a1d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for finding the P1828 wiki, Robert.

I looked through it to tr= y to answer my question about whether they talk about anything like our sha= red asset services, but the wiki seems to be mostly full of placeholder ter= ms and external references, which is in line with what Joshua said about te= chnological surveys.

Notice that even our VWRAP group is part of their scope.=A0 Under Ex= isting Working Groups --> Groups Developing Standards --> = VWRAP, they link the article that Joshua, David and I wrote for IEEE= Internet Computing magazine in Feb 2010:=A0=A0 http://internetmessagingtechnology.org/pubs/VWRAP-for-Virtual= -Worlds-Interoperability-mic2010010073.pdf

It'll be interesting to see what they do in this space once it goes= beyond technology surveys.


Morgaine.



=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Tue, May 10, 2011 at 5:26 AM, Robert G. Jakabosky <bobby@sharedrealm= .com> wrote:
On Monday 09, Joshua Bell wrote:
> On Mon, May 9, 2011 at 1:36 PM, Boroondas Gupte
>
> <sllists@boroon.dasgu= pta.ch>wrote:
> > *What abstract type systems do currently exist *("exist"= ; as in published
> > and sufficiently documented. Don't have to be formally standa= rdized,
> > though if they are, that's a plus.)* and how do they compare = to LLSD?*
>
> This is an excellent question.
>
> For what it's worth, it's possible that at least the first par= t of this
> question has been explored as it relates to virtual worlds by the IEEE=
> P1828 working group http://standards.ieee.org/develop/project/1= 828.html on
> virtual worlds. I'm on the mailing list (as are some other VWRAP l= ist
> members, I believe) but confess to not having spent any significant ti= me
> engaged with the group.
>
> What I do know is that P1828 members have performed a number of techno= logy
> surveys. The working group is not focused on any particular architectu= re
> for virtual worlds (as chartered, VWRAP has a fairly specific approach= in
> mind), and is instead looking broadly at possible technologies to embr= ace
> as "best practices" for virtual worlds. The P1828 working gr= oup's
> discussion list is http://listserv.ieee.org/cgi-bin/wa?A= 0=3DVWSTANDARDWKGRP
> - you might find it worthwhile to peruse archives and/or engage in
> discussions with that group regarding this and other issues where
> consensus on a new or converging design is not the driving factor (as = it
> tends to be within IETF groups) but exploring existing technologies fo= r
> suitability within a problem domain.

I talked with chairperson of that IEEE working group and he said that= the
archive it only accessible to members of that working group, but there is a=
public wiki with some information from the group:
http://www.metaversestandards.org/index.php?title=3DMain_P= age

--
Robert G. Jakabosky
__________________________________= _____________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--001636831fa08b996004a2ec4a1d-- From bobby@sharedrealm.com Tue May 10 10:05:44 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4B9E0875 for ; Tue, 10 May 2011 10:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEwQ+Uv6lA31 for ; Tue, 10 May 2011 10:05:42 -0700 (PDT) Received: from mail.neoawareness.com (mail.neoawareness.com [67.223.232.27]) by ietfa.amsl.com (Postfix) with ESMTP id D878AE0834 for ; Tue, 10 May 2011 10:05:42 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=neo.localnet) by mail.neoawareness.com with esmtpa (Exim 4.69) (envelope-from ) id 1QJcEk-0006Js-OF for vwrap@ietf.org; Tue, 10 May 2011 01:59:46 +0000 From: "Robert G. Jakabosky" To: vwrap@ietf.org Date: Mon, 9 May 2011 18:59:45 -0700 User-Agent: KMail/1.13.5 (Linux/2.6.32-bpo.5-amd64; KDE/4.4.5; x86_64; ; ) References: <4DC85049.40600@boroon.dasgupta.ch> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201105091859.45796.bobby@sharedrealm.com> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bobby@sharedrealm.com X-SA-Exim-Scanned: No (on mail.neoawareness.com); SAEximRunCond expanded to false Subject: Re: [vwrap] What abstract type systems already exist? X-BeenThere: vwrap@ietf.org 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: Tue, 10 May 2011 17:05:44 -0000 On Monday 09, Joshua Bell wrote: > What I do know is that P1828 members have performed a number of technology > surveys. The working group is not focused on any particular architecture > for virtual worlds (as chartered, VWRAP has a fairly specific approach in > mind), and is instead looking broadly at possible technologies to embrace > as "best practices" for virtual worlds. The P1828 working group's > discussion list is http://listserv.ieee.org/cgi-bin/wa?A0=VWSTANDARDWKGRP > - you might find it worthwhile to peruse archives and/or engage in > discussions with that group regarding this and other issues where > consensus on a new or converging design is not the driving factor (as it > tends to be within IETF groups) but exploring existing technologies for > suitability within a problem domain. The archive is to not be publicly accessible, it seems you have to subscribe to the list before you can access it. -- Robert G. Jakabosky From barryleiba.mailing.lists@gmail.com Tue May 10 18:12:13 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E6DE06E6 for ; Tue, 10 May 2011 18:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.378 X-Spam-Level: X-Spam-Status: No, score=-100.378 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9zgkvVQQFpb for ; Tue, 10 May 2011 18:12:13 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 780DEE06C0 for ; Tue, 10 May 2011 18:12:09 -0700 (PDT) Received: by gxk19 with SMTP id 19so12260gxk.31 for ; Tue, 10 May 2011 18:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=giEojaDzt8GJVTNcWlL00yV/QeYvgpoEyXhBIvzJcSo=; b=EDGg9d6UH+LaEDTGhy0eUDTGUPOUUK/6tUEoYNoOuEvm4Ut0U1KgoZgT7IS3ecim0j CYYAVsD2aqJbZY/72UEKNj0946uPXtTOagtZhKLq+l1wrtWJ8su7jnwtCYgi9cEGNgJS jvkzjKwra3kIRCu8fX3tBgNKvb+r4goNTwijk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=aE+LcdwNYTAmDPAUuB5vm6cTuq9Nqv8MDNYKdKq5GlTen5slxswNal2L5H6p+tuWTc yMGIZcYtb96Kul1fZCdjz3bIvwPheLrhHpYXqHKwkx3PPvY7TZB80QyfC61KB+gfZ0HJ K+hGFLhJQM+k6J5tjLt8LE+SLWb6T/K/obnek= MIME-Version: 1.0 Received: by 10.236.182.229 with SMTP id o65mr9842708yhm.216.1305076328565; Tue, 10 May 2011 18:12:08 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.137.13 with HTTP; Tue, 10 May 2011 18:12:07 -0700 (PDT) Date: Tue, 10 May 2011 21:12:07 -0400 X-Google-Sender-Auth: ZUsUYEOE0D0hyZVf-KEcq1Sr-fY Message-ID: From: Barry Leiba To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap-ads@tools.ietf.org Subject: [vwrap] VWRAP, after discussion with the Area Director X-BeenThere: vwrap@ietf.org 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: Wed, 11 May 2011 01:12:13 -0000 I'm encouraged by Morgaine's assessment of the progress the group is making in discussions. I like that it's taking a broader view, looking toward interoperation among different virtual worlds. The discussion of the technology is going in a good direction. Where it's going is to a very different place than what was set out in the VWRAP charter. The IESG will need to re-evaluate the work when the group has things grounded and can propose a new charter, for the new direction. They'll need to see who's invested in the new work -- who will do the protocol design, who will take on the editing, and who will give it the review it needs to be a good standard. In the meantime, this mailing list is the right place for the discussion to continue. The IESG will close out the current charter, and will leave the mailing list open. Remember that the IETF gets most of its work done on mailing lists, and not all of them are associated with current working groups. There won't be chairs monitoring it... which means that there won't be chairs bugging you about IETF process stuff, but also that there won't be chairs nudging you along, so be careful not to let that stall the work. I suggest that the group put its focus on converging on two initial documents: 1. A new introduction and overview document, laying out what problems/situations/scenarios you'll be addressing, how you'll go about it, and what things will look like in the end. This should lead directly to a proposal for a new charter. 2. A protocol requirements document, specifying what the protocol(s) will have to do (and won't have to do). This will be a strong basis for the protocol design, which could be done in that new working group. Please keep this going. I hope we'll see a charter proposal for a new working group fairly soon. Barry, as chair From stpeter@stpeter.im Tue May 10 19:24:48 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3732E070A for ; Tue, 10 May 2011 19:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AdTJkrZhQOk for ; Tue, 10 May 2011 19:24:48 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1A9E06E3 for ; Tue, 10 May 2011 19:24:48 -0700 (PDT) Received: from squire.local (dsl-175-253.dynamic-dsl.frii.net [216.17.175.253]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 21446400ED; Tue, 10 May 2011 20:24:47 -0600 (MDT) Message-ID: <4DC9F366.30308@stpeter.im> Date: Tue, 10 May 2011 20:24:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060009040307080806030407" Cc: vwrap@ietf.org, vwrap-ads@tools.ietf.org Subject: Re: [vwrap] VWRAP, after discussion with the Area Director X-BeenThere: vwrap@ietf.org 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: Wed, 11 May 2011 02:24:49 -0000 This is a cryptographically signed message in MIME format. --------------ms060009040307080806030407 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Barry. Speaking as the Area Director responsible for the VWRAP WG, I'd like to make it fully clear that we plan to proceed as follows: 1. Close the working group in its current instantiation 2. Keep the vwrap@ietf.org mailing list open 3. Continue discussions on the list The hope is that folks here can converge on a new direction, leading to formation of a new working group, or at least to publication of individual Internet-Drafts that provide a framwork for future efforts. Peter On 5/10/11 7:12 PM, Barry Leiba wrote: > I'm encouraged by Morgaine's assessment of the progress the group is > making in discussions. I like that it's taking a broader view, > looking toward interoperation among different virtual worlds. The > discussion of the technology is going in a good direction. >=20 > Where it's going is to a very different place than what was set out in > the VWRAP charter. The IESG will need to re-evaluate the work when > the group has things grounded and can propose a new charter, for the > new direction. They'll need to see who's invested in the new work -- > who will do the protocol design, who will take on the editing, and who > will give it the review it needs to be a good standard. In the > meantime, this mailing list is the right place for the discussion to > continue. >=20 > The IESG will close out the current charter, and will leave the > mailing list open. Remember that the IETF gets most of its work done > on mailing lists, and not all of them are associated with current > working groups. There won't be chairs monitoring it... which means > that there won't be chairs bugging you about IETF process stuff, but > also that there won't be chairs nudging you along, so be careful not > to let that stall the work. >=20 > I suggest that the group put its focus on converging on two initial doc= uments: >=20 > 1. A new introduction and overview document, laying out what > problems/situations/scenarios you'll be addressing, how you'll go > about it, and what things will look like in the end. This should lead > directly to a proposal for a new charter. >=20 > 2. A protocol requirements document, specifying what the protocol(s) > will have to do (and won't have to do). This will be a strong basis > for the protocol design, which could be done in that new working > group. >=20 > Please keep this going. I hope we'll see a charter proposal for a new > working group fairly soon. >=20 > Barry, as chair > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap --------------ms060009040307080806030407 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUx MTAyMjQzOFowIwYJKoZIhvcNAQkEMRYEFKU+JMNr5a3bK+eHs+6TTRehmpMHMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQC3XnedCbds1EjEsFYLPM5zu79CnIV3dS/IH01HVwQMFE42twtgLARC3q3v mGX7w/TeD4SDXnh8fykJxDPZl5+eWouOn4j/9y8nU3i3O0xMGpN9ZPdbXp215qwqI4YXLNf7 BpWk5AvQAaXblGFJk87PD37ryITVSaaH1eUebZ/zJt1KU6cV2bWXxBTk1+x72IouT52+ZSOk CNA4MYwRzEPwpHizIrFeaNe9fDtBumk1Xc3xiap1jBuNKEU1GQcuoksCPpC0LN53x3CCdZKs u+mH/YgRYvTYyBkMguP+qj9OkEix7X+fWKqALEgqexXtojys4aOUmHokP/Fry5nea8KNAAAA AAAA --------------ms060009040307080806030407-- From morgaine.dinova@googlemail.com Tue May 10 23:00:35 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FCFE0756 for ; Tue, 10 May 2011 23:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.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] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuGe6cOAnqqb for ; Tue, 10 May 2011 23:00:34 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0D22FE0763 for ; Tue, 10 May 2011 23:00:33 -0700 (PDT) Received: by qwc23 with SMTP id 23so106147qwc.31 for ; Tue, 10 May 2011 23:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1/xuY/qryb25MbTtEukf+BVfl+blkHpFlCm1m0x3KlQ=; b=XUtVEEJ3IVTHiPXlbEcJFLfQyKvVflZsMNIcVczygaS7VrkQHWdIqSsDQOTfmbD18w xm5421z4ZgiETfzGyCMTiERqocV0aXTZgPOEbkXWuFbI/dkpFzLBKGODgEFVCz/O2+1L zRo6yDmBj0px3MhzVKE9sloJ8g2YqjClGPof0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jd8gUXaLolPDYqVA7EQlPC65PXlsTNM4xoAYFY+XzME9hx1HTNJVwC5EfiQ50asIBB CTGdsvZm57Y8Lywr6YjNrjGjCeb3syhLkK9/PczCvteNA+RkUst9Xmm4jd2EjmxpadA4 EVJ+ZBZAq9Lns7yGHGzf81AN0ru7uQrKdXgC8= MIME-Version: 1.0 Received: by 10.229.119.134 with SMTP id z6mr5183570qcq.63.1305093632876; Tue, 10 May 2011 23:00:32 -0700 (PDT) Received: by 10.229.66.212 with HTTP; Tue, 10 May 2011 23:00:32 -0700 (PDT) In-Reply-To: <4DC9F366.30308@stpeter.im> References: <4DC9F366.30308@stpeter.im> Date: Wed, 11 May 2011 07:00:32 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd5c94e62e1b304a2f9ca14 Cc: Barry Leiba , vwrap-ads@tools.ietf.org Subject: Re: [vwrap] VWRAP, after discussion with the Area Director X-BeenThere: vwrap@ietf.org 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: Wed, 11 May 2011 06:00:35 -0000 --000e0cd5c94e62e1b304a2f9ca14 Content-Type: text/plain; charset=ISO-8859-1 Thank you, Barry and Peter. :-) It is sad to witness what amounts to the end of an era, but I think that you have made the right decision. It probably became inevitable once it emerged that the intended goal at time of chartering was not the one that most participants desired and expected. A WG charter needs to be well aligned with the goals of its people, or a rough consensus becomes unlikely. For my part, I intend to work towards the goals that you both outlined. Whether we will be successful remains to be seen, and manpower is against us. Perhaps we will need to split into more than one group to allow progress to be made, because it has become very clear that there is a strong disparity of goals between those who are content with existing protocols and those who wish to design for a better tomorrow. This just saps everyone's energy and wastes the little manpower we have available. As you are going to cease monitoring the mailing list in a chairing capacity soon, I want to thank you both now for performing your IETF duties very effectively and fairly for us over the past months and years, putting up with our little arguments, smoothing the waters where needed, and keeping us focused on the goals of an IETF WG. It has been a pleasure working with you both, and I hope that you won't shy away from the occasional non-Chair visit to the list. Your advice is always appreciated. Best regards :-) Morgaine. ======================= On Wed, May 11, 2011 at 3:24 AM, Peter Saint-Andre wrote: > Thanks, Barry. > > Speaking as the Area Director responsible for the VWRAP WG, I'd like to > make it fully clear that we plan to proceed as follows: > > 1. Close the working group in its current instantiation > > 2. Keep the vwrap@ietf.org mailing list open > > 3. Continue discussions on the list > > The hope is that folks here can converge on a new direction, leading to > formation of a new working group, or at least to publication of > individual Internet-Drafts that provide a framwork for future efforts. > > Peter > > On 5/10/11 7:12 PM, Barry Leiba wrote: > > I'm encouraged by Morgaine's assessment of the progress the group is > > making in discussions. I like that it's taking a broader view, > > looking toward interoperation among different virtual worlds. The > > discussion of the technology is going in a good direction. > > > > Where it's going is to a very different place than what was set out in > > the VWRAP charter. The IESG will need to re-evaluate the work when > > the group has things grounded and can propose a new charter, for the > > new direction. They'll need to see who's invested in the new work -- > > who will do the protocol design, who will take on the editing, and who > > will give it the review it needs to be a good standard. In the > > meantime, this mailing list is the right place for the discussion to > > continue. > > > > The IESG will close out the current charter, and will leave the > > mailing list open. Remember that the IETF gets most of its work done > > on mailing lists, and not all of them are associated with current > > working groups. There won't be chairs monitoring it... which means > > that there won't be chairs bugging you about IETF process stuff, but > > also that there won't be chairs nudging you along, so be careful not > > to let that stall the work. > > > > I suggest that the group put its focus on converging on two initial > documents: > > > > 1. A new introduction and overview document, laying out what > > problems/situations/scenarios you'll be addressing, how you'll go > > about it, and what things will look like in the end. This should lead > > directly to a proposal for a new charter. > > > > 2. A protocol requirements document, specifying what the protocol(s) > > will have to do (and won't have to do). This will be a strong basis > > for the protocol design, which could be done in that new working > > group. > > > > Please keep this going. I hope we'll see a charter proposal for a new > > working group fairly soon. > > > > Barry, as chair > > _______________________________________________ > > vwrap mailing list > > vwrap@ietf.org > > https://www.ietf.org/mailman/listinfo/vwrap > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > --000e0cd5c94e62e1b304a2f9ca14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you, Barry and Peter. :-)

It is sad to witness what amounts to= the end of an era, but I think that you have made the right decision.
<= br>It probably became inevitable once it emerged that the intended goal at = time of chartering was not the one that most participants desired and expec= ted.=A0 A WG charter needs to be well aligned with the goals of its people,= or a rough consensus becomes unlikely.

For my part, I intend to work towards the goals that you both outlined.= =A0 Whether we will be successful remains to be seen, and manpower is again= st us.=A0 Perhaps we will need to split into more than one group to allow p= rogress to be made, because it has become very clear that there is a strong= disparity of goals between those who are content with existing protocols a= nd those who wish to design for a better tomorrow.=A0 This just saps everyo= ne's energy and wastes the little manpower we have available.

As you are going to cease monitoring the mailing list in a chairing cap= acity soon, I want to thank you both now for performing your IETF duties ve= ry effectively and fairly for us over the past months and years, putting up= with our little arguments, smoothing the waters where needed, and keeping = us focused on the goals of an IETF WG.

It has been a pleasure working with you both, and I hope that you won&#= 39;t shy away from the occasional non-Chair visit to the list.=A0 Your advi= ce is always appreciated.

Best regards :-)


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D


On Wed, May 11, 2011 at 3:24 A= M, Peter Saint-Andre <stpeter@stpeter.im> wrote:
Thanks, Barry.
Speaking as the Area Director responsible for the VWRAP WG, I'd like to=
make it fully clear that we plan to proceed as follows:

1. Close the working group in its current instantiation

2. Keep the vwrap@ietf.org mailing li= st open

3. Continue discussions on the list

The hope is that folks here can converge on a new direction, leading to
formation of a new working group, or at least to publication of
individual Internet-Drafts that provide a framwork for future efforts.

Peter

On 5/10/11 7:12 PM, Barry Leiba wrote:
> I'm encouraged by Morgaine's assessment of the progress the gr= oup is
> making in discussions. =A0I like that it's taking a broader view,<= br> > looking toward interoperation among different virtual worlds. =A0The > discussion of the technology is going in a good direction.
>
> Where it's going is to a very different place than what was set ou= t in
> the VWRAP charter. =A0The IESG will need to re-evaluate the work when<= br> > the group has things grounded and can propose a new charter, for the > new direction. =A0They'll need to see who's invested in the ne= w work --
> who will do the protocol design, who will take on the editing, and who=
> will give it the review it needs to be a good standard. =A0In the
> meantime, this mailing list is the right place for the discussion to > continue.
>
> The IESG will close out the current charter, and will leave the
> mailing list open. =A0Remember that the IETF gets most of its work don= e
> on mailing lists, and not all of them are associated with current
> working groups. =A0There won't be chairs monitoring it... which me= ans
> that there won't be chairs bugging you about IETF process stuff, b= ut
> also that there won't be chairs nudging you along, so be careful n= ot
> to let that stall the work.
>
> I suggest that the group put its focus on converging on two initial do= cuments:
>
> 1. A new introduction and overview document, laying out what
> problems/situations/scenarios you'll be addressing, how you'll= go
> about it, and what things will look like in the end. =A0This should le= ad
> directly to a proposal for a new charter.
>
> 2. A protocol requirements document, specifying what the protocol(s) > will have to do (and won't have to do). =A0This will be a strong b= asis
> for the protocol design, which could be done in that new working
> group.
>
> Please keep this going. =A0I hope we'll see a charter proposal for= a new
> working group fairly soon.
>
> Barry, as chair
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap


_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


--000e0cd5c94e62e1b304a2f9ca14-- From kari.lippert@gmail.com Wed May 11 04:01:39 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E005FE07EA for ; Wed, 11 May 2011 04:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ab4CKNx-mYku for ; Wed, 11 May 2011 04:01:38 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4D291E07E4 for ; Wed, 11 May 2011 04:01:38 -0700 (PDT) Received: by wwk4 with SMTP id 4so4284645wwk.1 for ; Wed, 11 May 2011 04:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/tc5hL92KyTIYLfsHyVf89V4XvrDrCl8/Xe/yNwnkZk=; b=M7+fNVERMKeAxb6Xn2xJN00oTzK8ztHsl99fBIiKUg0MKWZDf9s5BBxAqQL/awUxTt 2QkCYz0aLQjng48QAHTfHOKhYBVw2Thl3uM0uRTf6kOnKN5nHglTtyico5eyVqeJKXmM X6X69qawU/bm6QeHXtt8ccIP4lOrGarafHv74= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=exrAD30urlQKt5wvjA7CsgB7bsTcqfRNVuR8RLlFQ4IdYXHhrqslXV6UIcgpt0Yx2Y WY+YiFaNO9tYcgTuag5M6MKDpuQGHZMj4HSTQjPrCgEcwUQokSD0J2B/+h5QoqD/G6Yk /g4AUL3COWQ4CB4tqxo0RoDF11JsfJ5oiI1vI= MIME-Version: 1.0 Received: by 10.227.23.211 with SMTP id s19mr3686117wbb.34.1305111696849; Wed, 11 May 2011 04:01:36 -0700 (PDT) Received: by 10.227.195.137 with HTTP; Wed, 11 May 2011 04:01:36 -0700 (PDT) In-Reply-To: References: <4DC9F366.30308@stpeter.im> Date: Wed, 11 May 2011 07:01:36 -0400 Message-ID: From: Kari Lippert To: Morgaine Content-Type: multipart/alternative; boundary=0022159759c2153bbb04a2fdff6f Cc: vwrap@ietf.org, Barry Leiba , vwrap-ads@tools.ietf.org Subject: Re: [vwrap] VWRAP, after discussion with the Area Director X-BeenThere: vwrap@ietf.org 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: Wed, 11 May 2011 11:01:40 -0000 --0022159759c2153bbb04a2fdff6f Content-Type: text/plain; charset=ISO-8859-1 What Moargaine said :) Interesting idea about splitting... will that bring true progress, or only the illusion? Kari On Wed, May 11, 2011 at 2:00 AM, Morgaine wrote: > Thank you, Barry and Peter. :-) > > It is sad to witness what amounts to the end of an era, but I think that > you have made the right decision. > > It probably became inevitable once it emerged that the intended goal at > time of chartering was not the one that most participants desired and > expected. A WG charter needs to be well aligned with the goals of its > people, or a rough consensus becomes unlikely. > > For my part, I intend to work towards the goals that you both outlined. > Whether we will be successful remains to be seen, and manpower is against > us. Perhaps we will need to split into more than one group to allow > progress to be made, because it has become very clear that there is a strong > disparity of goals between those who are content with existing protocols and > those who wish to design for a better tomorrow. This just saps everyone's > energy and wastes the little manpower we have available. > > As you are going to cease monitoring the mailing list in a chairing > capacity soon, I want to thank you both now for performing your IETF duties > very effectively and fairly for us over the past months and years, putting > up with our little arguments, smoothing the waters where needed, and keeping > us focused on the goals of an IETF WG. > > It has been a pleasure working with you both, and I hope that you won't shy > away from the occasional non-Chair visit to the list. Your advice is always > appreciated. > > Best regards :-) > > > Morgaine. > > > > ======================= > > > > On Wed, May 11, 2011 at 3:24 AM, Peter Saint-Andre wrote: > >> Thanks, Barry. >> >> Speaking as the Area Director responsible for the VWRAP WG, I'd like to >> make it fully clear that we plan to proceed as follows: >> >> 1. Close the working group in its current instantiation >> >> 2. Keep the vwrap@ietf.org mailing list open >> >> 3. Continue discussions on the list >> >> The hope is that folks here can converge on a new direction, leading to >> formation of a new working group, or at least to publication of >> individual Internet-Drafts that provide a framwork for future efforts. >> >> Peter >> >> On 5/10/11 7:12 PM, Barry Leiba wrote: >> > I'm encouraged by Morgaine's assessment of the progress the group is >> > making in discussions. I like that it's taking a broader view, >> > looking toward interoperation among different virtual worlds. The >> > discussion of the technology is going in a good direction. >> > >> > Where it's going is to a very different place than what was set out in >> > the VWRAP charter. The IESG will need to re-evaluate the work when >> > the group has things grounded and can propose a new charter, for the >> > new direction. They'll need to see who's invested in the new work -- >> > who will do the protocol design, who will take on the editing, and who >> > will give it the review it needs to be a good standard. In the >> > meantime, this mailing list is the right place for the discussion to >> > continue. >> > >> > The IESG will close out the current charter, and will leave the >> > mailing list open. Remember that the IETF gets most of its work done >> > on mailing lists, and not all of them are associated with current >> > working groups. There won't be chairs monitoring it... which means >> > that there won't be chairs bugging you about IETF process stuff, but >> > also that there won't be chairs nudging you along, so be careful not >> > to let that stall the work. >> > >> > I suggest that the group put its focus on converging on two initial >> documents: >> > >> > 1. A new introduction and overview document, laying out what >> > problems/situations/scenarios you'll be addressing, how you'll go >> > about it, and what things will look like in the end. This should lead >> > directly to a proposal for a new charter. >> > >> > 2. A protocol requirements document, specifying what the protocol(s) >> > will have to do (and won't have to do). This will be a strong basis >> > for the protocol design, which could be done in that new working >> > group. >> > >> > Please keep this going. I hope we'll see a charter proposal for a new >> > working group fairly soon. >> > >> > Barry, as chair >> > _______________________________________________ >> > vwrap mailing list >> > vwrap@ietf.org >> > https://www.ietf.org/mailman/listinfo/vwrap >> >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > -- http://kjlippert.wordpress.com/ http://community.webshots.com/user/MissGnomer --0022159759c2153bbb04a2fdff6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What Moargaine said :)

Interesting idea about splitting.= .. will that bring true progress, or only the illusion?

Kari



On W= ed, May 11, 2011 at 2:00 AM, Morgaine <morgaine.dinova@googlemail.com> wrote:
Thank you, Barry and Peter. :-)

It i= s sad to witness what amounts to the end of an era, but I think that you ha= ve made the right decision.

It probably became inevitable once it emerged that the intended goal at= time of chartering was not the one that most participants desired and expe= cted.=A0 A WG charter needs to be well aligned with the goals of its people= , or a rough consensus becomes unlikely.

For my part, I intend to work towards the goals that you both outlined.= =A0 Whether we will be successful remains to be seen, and manpower is again= st us.=A0 Perhaps we will need to split into more than one group to allow p= rogress to be made, because it has become very clear that there is a strong= disparity of goals between those who are content with existing protocols a= nd those who wish to design for a better tomorrow.=A0 This just saps everyo= ne's energy and wastes the little manpower we have available.

As you are going to cease monitoring the mailing list in a chairing cap= acity soon, I want to thank you both now for performing your IETF duties ve= ry effectively and fairly for us over the past months and years, putting up= with our little arguments, smoothing the waters where needed, and keeping = us focused on the goals of an IETF WG.

It has been a pleasure working with you both, and I hope that you won&#= 39;t shy away from the occasional non-Chair visit to the list.=A0 Your advi= ce is always appreciated.

Best regards :-)


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D



On Wed, May 11, 2011 at 3:24 AM, Peter Saint-Andre <stpeter@st= peter.im> wrote:
Thanks, Barry.

Speaking as the Area Director responsible for the VWRAP WG, I'd like to=
make it fully clear that we plan to proceed as follows:

1. Close the working group in its current instantiation

2. Keep the vwrap@ietf.= org mailing list open

3. Continue discussions on the list

The hope is that folks here can converge on a new direction, leading to
formation of a new working group, or at least to publication of
individual Internet-Drafts that provide a framwork for future efforts.

Peter

On 5/10/11 7:12 PM, Barry Leiba wrote:
> I'm encouraged by Morgaine's assessment of the progress the gr= oup is
> making in discussions. =A0I like that it's taking a broader view,<= br> > looking toward interoperation among different virtual worlds. =A0The > discussion of the technology is going in a good direction.
>
> Where it's going is to a very different place than what was set ou= t in
> the VWRAP charter. =A0The IESG will need to re-evaluate the work when<= br> > the group has things grounded and can propose a new charter, for the > new direction. =A0They'll need to see who's invested in the ne= w work --
> who will do the protocol design, who will take on the editing, and who=
> will give it the review it needs to be a good standard. =A0In the
> meantime, this mailing list is the right place for the discussion to > continue.
>
> The IESG will close out the current charter, and will leave the
> mailing list open. =A0Remember that the IETF gets most of its work don= e
> on mailing lists, and not all of them are associated with current
> working groups. =A0There won't be chairs monitoring it... which me= ans
> that there won't be chairs bugging you about IETF process stuff, b= ut
> also that there won't be chairs nudging you along, so be careful n= ot
> to let that stall the work.
>
> I suggest that the group put its focus on converging on two initial do= cuments:
>
> 1. A new introduction and overview document, laying out what
> problems/situations/scenarios you'll be addressing, how you'll= go
> about it, and what things will look like in the end. =A0This should le= ad
> directly to a proposal for a new charter.
>
> 2. A protocol requirements document, specifying what the protocol(s) > will have to do (and won't have to do). =A0This will be a strong b= asis
> for the protocol design, which could be done in that new working
> group.
>
> Please keep this going. =A0I hope we'll see a charter proposal for= a new
> working group fairly soon.
>
> Barry, as chair
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org=
> https://www.ietf.org/mailman/listinfo/vwrap


_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap



_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap




--


http://kjlippert.wordpress.com/
http://community.web= shots.com/user/MissGnomer
--0022159759c2153bbb04a2fdff6f-- From dwl@us.ibm.com Wed May 11 09:00:38 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E931E0831; Wed, 11 May 2011 09:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.635 X-Spam-Level: X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TldPf2u5h+dk; Wed, 11 May 2011 09:00:37 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5D48DE0838; Wed, 11 May 2011 09:00:33 -0700 (PDT) Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e5.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4BFXjEG030530; Wed, 11 May 2011 11:33:45 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4BG0WYs087568; Wed, 11 May 2011 12:00:32 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4BG0UEw015887; Wed, 11 May 2011 12:00:31 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4BG0TQ6015674; Wed, 11 May 2011 12:00:29 -0400 In-Reply-To: <4DC9F366.30308@stpeter.im> References: <4DC9F366.30308@stpeter.im> X-KeepSent: 8257D76E:DE156681-8525788D:00579803; type=4; name=$KeepSent To: Peter Saint-Andre X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: David W Levine Date: Wed, 11 May 2011 12:00:28 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V853_CD4_03082011|March 08, 2011) at 05/11/2011 12:00:29 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBF21EDFC41E938f9e8a93df938690918c0ABBF21EDFC41E93" Cc: vwrap@ietf.org, vwrap-bounces@ietf.org, Barry Leiba , vwrap-ads@tools.ietf.org Subject: Re: [vwrap] VWRAP, after discussion with the Area Director X-BeenThere: vwrap@ietf.org 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: Wed, 11 May 2011 16:00:38 -0000 --0__=0ABBF21EDFC41E938f9e8a93df938690918c0ABBF21EDFC41E93 Content-type: multipart/alternative; Boundary="1__=0ABBF21EDFC41E938f9e8a93df938690918c0ABBF21EDFC41E93" --1__=0ABBF21EDFC41E938f9e8a93df938690918c0ABBF21EDFC41E93 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I think this makes perfect, if sad sense. The (now deprecated) Charter = no longer reflects what is being done. As I recall from the distant past, a charter, roughtly needs: Some language setting a pretty clear scope, some language describing th= e basic approach, and some concrete milestones. One way forward would be to work on a new charter. Another would be for= various people who have an interest to put out internet drafts on the ongoing mailing list to drive discussion. I real= ly think if people want to move the ball forward, one or the other or both, is required. There's clealy still some interest, but= it's not exactly focused. - David p.s. Finally back to full speed, full time typing, after a 3 month down= time due to carpal tunnel, surgery and recovery. You are all free to debate whether this is a good thing, or a bad thing. = From: Peter Saint-Andre = = To: Barry Leiba = = Cc: vwrap@ietf.org, vwrap-ads@tools.ietf.org = = Date: 05/10/2011 10:25 PM = = Subject: Re: [vwrap] VWRAP, after discussion with the Area Directo= r = Sent by: vwrap-bounces@ietf.org = = Thanks, Barry. Speaking as the Area Director responsible for the VWRAP WG, I'd like to= make it fully clear that we plan to proceed as follows: 1. Close the working group in its current instantiation 2. Keep the vwrap@ietf.org mailing list open 3. Continue discussions on the list The hope is that folks here can converge on a new direction, leading to= formation of a new working group, or at least to publication of individual Internet-Drafts that provide a framwork for future efforts. Peter On 5/10/11 7:12 PM, Barry Leiba wrote: > I'm encouraged by Morgaine's assessment of the progress the group is > making in discussions. I like that it's taking a broader view, > looking toward interoperation among different virtual worlds. The > discussion of the technology is going in a good direction. > > Where it's going is to a very different place than what was set out i= n > the VWRAP charter. The IESG will need to re-evaluate the work when > the group has things grounded and can propose a new charter, for the > new direction. They'll need to see who's invested in the new work --= > who will do the protocol design, who will take on the editing, and wh= o > will give it the review it needs to be a good standard. In the > meantime, this mailing list is the right place for the discussion to > continue. > > The IESG will close out the current charter, and will leave the > mailing list open. Remember that the IETF gets most of its work done= > on mailing lists, and not all of them are associated with current > working groups. There won't be chairs monitoring it... which means > that there won't be chairs bugging you about IETF process stuff, but > also that there won't be chairs nudging you along, so be careful not > to let that stall the work. > > I suggest that the group put its focus on converging on two initial documents: > > 1. A new introduction and overview document, laying out what > problems/situations/scenarios you'll be addressing, how you'll go > about it, and what things will look like in the end. This should lea= d > directly to a proposal for a new charter. > > 2. A protocol requirements document, specifying what the protocol(s) > will have to do (and won't have to do). This will be a strong basis > for the protocol design, which could be done in that new working > group. > > Please keep this going. I hope we'll see a charter proposal for a ne= w > working group fairly soon. > > Barry, as chair > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap [attachment "smime.p7s" deleted by David W Levine/Watson/IBM] _______________________________________________ vwrap mailing list vwrap@ietf.org https://www.ietf.org/mailman/listinfo/vwrap = --1__=0ABBF21EDFC41E938f9e8a93df938690918c0ABBF21EDFC41E93 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I think this makes perfect, if = sad sense. The (now deprecated) Charter no longer reflects what is
being done.

As I recall from the distant past,= a charter, roughtly needs:

Some language setting a pretty cle= ar scope, some language describing the basic approach, and some concret= e milestones.

One way forward would be to work o= n a new charter. Another would be for various people who have an intere= st to put out
internet drafts on the ongoing mai= ling list to drive discussion. I really think if people want to move th= e ball forward, one or
the other or both, is required. Th= ere's clealy still some interest, but it's not exactly focused. =

- David

p.s. Finally back to full speed, f= ull time typing, after a 3 month down time due to carpal tunnel, surger= y and recovery. You are
all free to debate whether this is= a good thing, or a bad thing.



3D"InactivePeter Saint-Andre ---05/10/2011 10:25:55 PM---Thanks, Barry.= Speaking as the Area Director responsible for the VWRAP WG, I'd like t= o

= =
3D=
    From:
3D""
Peter Saint-Andre <stpeter@stpe= ter.im>
3D=
    To:
3D""
Barry Leiba <barryleiba@compute= r.org>
3D=
    Cc:
3D""
vwrap@ietf.org, vwrap-ads@tools.ie= tf.org
3D=
    Date:
3D""
05/10/2011 10:25 PM
3D=
    Subject:
3D""
Re: [vwrap] VWRAP, after discussio= n with the Area Director
3D=
    Sent by:
3D""
vwrap-bounces@ietf.org




Thanks, Barry.

Speaking as the Area Director responsible for the VWRAP WG, I'd like to=
make it fully clear that we plan to proceed as follows:

1. Close the working group in its current instantiation

2. Keep the vwrap@ietf.org mailing list open

3. Continue discussions on the list

The hope is that folks here can converge on a new direction, leading to=
formation of a new working group, or at least to publication of
individual Internet-Drafts that provide a framwork for future efforts.<= br>
Peter

On 5/10/11 7:12 PM, Barry Leiba wrote:
> I'm encouraged by Morgaine's assessment of the progress the group = is
> making in discussions. I like that it's taking a broader view, > looking toward interoperation among different virtual worlds. The=
> discussion of the technology is going in a good direction.
>
> Where it's going is to a very different place than what was set ou= t in
> the VWRAP charter. The IESG will need to re-evaluate the work whe= n
> the group has things grounded and can propose a new charter, for t= he
> new direction. They'll need to see who's invested in the new work= --
> who will do the protocol design, who will take on the editing, and= who
> will give it the review it needs to be a good standard. In the > meantime, this mailing list is the right place for the discussion = to
> continue.
>
> The IESG will close out the current charter, and will leave the > mailing list open. Remember that the IETF gets most of its work d= one
> on mailing lists, and not all of them are associated with current<= br> > working groups. There won't be chairs monitoring it... which mean= s
> that there won't be chairs bugging you about IETF process stuff, b= ut
> also that there won't be chairs nudging you along, so be careful n= ot
> to let that stall the work.
>
> I suggest that the group put its focus on converging on two initia= l documents:
>
> 1. A new introduction and overview document, laying out what
> problems/situations/scenarios you'll be addressing, how you'll go<= br> > about it, and what things will look like in the end. This should = lead
> directly to a proposal for a new charter.
>
> 2. A protocol requirements document, specifying what the protocol(= s)
> will have to do (and won't have to do). This will be a strong bas= is
> for the protocol design, which could be done in that new working > group.
>
> Please keep this going. I hope we'll see a charter proposal for a= new
> working group fairly soon.
>
> Barry, as chair
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap<= /font>

[attachment "smime.p7s" deleted by David W Levine/Watson/IBM]= _______________________________________________
vwrap mailing list
vwrap@ietf.org
https://www.ietf.org/mailman/listinfo/vwrap


= --1__=0ABBF21EDFC41E938f9e8a93df938690918c0ABBF21EDFC41E93-- --0__=0ABBF21EDFC41E938f9e8a93df938690918c0ABBF21EDFC41E93 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBF21EDFC41E938f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBF21EDFC41E938f9e8a93df938690918c0ABBF21EDFC41E93 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=0ABBF21EDFC41E938f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBF21EDFC41E938f9e8a93df938690918c0ABBF21EDFC41E93-- From dzonatas@gmail.com Wed May 11 09:24:31 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BB1E0828 for ; Wed, 11 May 2011 09:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTVr-yVabBBE for ; Wed, 11 May 2011 09:24:30 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 796E6E06FA for ; Wed, 11 May 2011 09:24:30 -0700 (PDT) Received: by pxi2 with SMTP id 2so415779pxi.38 for ; Wed, 11 May 2011 09:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lLV6my/ZKYid8BTLDnaS9ezpvR/UfKLRKmsUfL9bv/Q=; b=fejQLSwqqGRo4qIp4Fm/xESE6HRdO3zo6DXmJuE63gPsjkiTnS7zhgyx1ZpmvzuWdR FTxhxWafxBLzN0l8mF1fuQPveOEcbYYsHvcjlp2RFJEH9Vs5wqSeq7vbIMbWFZwwL8H2 o6DeWzxAURCpsK3yrEIydVmQe/TR5qxa1ft1w= 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=SJwAoNdP0QZ38RGeuxy5gvdlNcXeWGTvbvFdD6VljeXX1QuhLivRWi8emkc4F59ZMR nidLYoWpURdiCEyZiHCfV/KaquJRhks+ap8jITCVuYXq6MPXE5glVU0t/N8qHv3Y3OyJ WMaLZaZR6Shu/+5ptcEor5bfkU9H8pUCLBjJ4= Received: by 10.68.69.67 with SMTP id c3mr13563676pbu.365.1305131069964; Wed, 11 May 2011 09:24:29 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id e2sm66497pbk.90.2011.05.11.09.24.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2011 09:24:29 -0700 (PDT) Message-ID: <4DCAB806.9090708@gmail.com> Date: Wed, 11 May 2011 09:23:34 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: vwrap@ietf.org References: <4DC9F366.30308@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] VWRAP, after discussion with the Area Director X-BeenThere: vwrap@ietf.org 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: Wed, 11 May 2011 16:24:31 -0000 I think this quote is appropriate: "Does the land under our feet complain about what language we speak?" For the first milestone, let one new straw-man take the stand. On 05/11/2011 09:00 AM, David W Levine wrote: > > I think this makes perfect, if sad sense. The (now deprecated) Charter > no longer reflects what is > being done. > > As I recall from the distant past, a charter, roughtly needs: > > Some language setting a pretty clear scope, some language describing > the basic approach, and some concrete milestones. > > One way forward would be to work on a new charter. Another would be > for various people who have an interest to put out > internet drafts on the ongoing mailing list to drive discussion. I > really think if people want to move the ball forward, one or > the other or both, is required. There's clealy still some interest, > but it's not exactly focused. > > - David > > p.s. Finally back to full speed, full time typing, after a 3 month > down time due to carpal tunnel, surgery and recovery. You are > all free to debate whether this is a good thing, or a bad thing. > > > > Inactive hide details for Peter Saint-Andre ---05/10/2011 10:25:55 > PM---Thanks, Barry. Speaking as the Area Director responsiblPeter > Saint-Andre ---05/10/2011 10:25:55 PM---Thanks, Barry. Speaking as the > Area Director responsible for the VWRAP WG, I'd like to > > > From: > > > Peter Saint-Andre > > To: > > > Barry Leiba > > Cc: > > > vwrap@ietf.org, vwrap-ads@tools.ietf.org > > Date: > > > 05/10/2011 10:25 PM > > Subject: > > > Re: [vwrap] VWRAP, after discussion with the Area Director > > Sent by: > > > vwrap-bounces@ietf.org > > ------------------------------------------------------------------------ > > > > Thanks, Barry. > > Speaking as the Area Director responsible for the VWRAP WG, I'd like to > make it fully clear that we plan to proceed as follows: > > 1. Close the working group in its current instantiation > > 2. Keep the vwrap@ietf.org mailing list open > > 3. Continue discussions on the list > > The hope is that folks here can converge on a new direction, leading to > formation of a new working group, or at least to publication of > individual Internet-Drafts that provide a framwork for future efforts. > > Peter > > On 5/10/11 7:12 PM, Barry Leiba wrote: > > I'm encouraged by Morgaine's assessment of the progress the group is > > making in discussions. I like that it's taking a broader view, > > looking toward interoperation among different virtual worlds. The > > discussion of the technology is going in a good direction. > > > > Where it's going is to a very different place than what was set out in > > the VWRAP charter. The IESG will need to re-evaluate the work when > > the group has things grounded and can propose a new charter, for the > > new direction. They'll need to see who's invested in the new work -- > > who will do the protocol design, who will take on the editing, and who > > will give it the review it needs to be a good standard. In the > > meantime, this mailing list is the right place for the discussion to > > continue. > > > > The IESG will close out the current charter, and will leave the > > mailing list open. Remember that the IETF gets most of its work done > > on mailing lists, and not all of them are associated with current > > working groups. There won't be chairs monitoring it... which means > > that there won't be chairs bugging you about IETF process stuff, but > > also that there won't be chairs nudging you along, so be careful not > > to let that stall the work. > > > > I suggest that the group put its focus on converging on two initial > documents: > > > > 1. A new introduction and overview document, laying out what > > problems/situations/scenarios you'll be addressing, how you'll go > > about it, and what things will look like in the end. This should lead > > directly to a proposal for a new charter. > > > > 2. A protocol requirements document, specifying what the protocol(s) > > will have to do (and won't have to do). This will be a strong basis > > for the protocol design, which could be done in that new working > > group. > > > > Please keep this going. I hope we'll see a charter proposal for a new > > working group fairly soon. > > > > Barry, as chair > > _______________________________________________ > > vwrap mailing list > > vwrap@ietf.org > > https://www.ietf.org/mailman/listinfo/vwrap > > [attachment "smime.p7s" deleted by David W Levine/Watson/IBM] > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Wed May 11 13:23:19 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10CEE07AC for ; Wed, 11 May 2011 13:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp8PM5IjSSLv for ; Wed, 11 May 2011 13:23:19 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 30FF7E07AA for ; Wed, 11 May 2011 13:23:19 -0700 (PDT) Received: by pxi2 with SMTP id 2so540730pxi.38 for ; Wed, 11 May 2011 13:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=bamK+9u/9TrG3FrTHgUNP4J0Jn6tydffKKo6pZoDXWg=; b=cn9XLQLVpMcwwd09c3QBVCEAXHl9RCrxOzejQ2xuerAa98YCPNqgD2GiPfSNjjW2qK bw0l09lpYzLdK+SOv9ELnRknnGYEHp9cIgLjYtYyNnjpOBiE+cBU0zwNiz3IH2VLnfpP Leq7NraIgUFFGsoXHa7WHBYeiP39qQJm2+QUU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=WS+gVCvN2FHcqwAwm2SICl2e75qDg4oZBdtqtPN7xEjUCbEn9e31NL1aM66AJz6CRx y3WiImDbicbpKZKSbzGvx1hliFvS74K5rrYvyo6PphMS50h+IsCgFys7u8k6hTCLoHca uAEh8Q2bfbmv2fEI3oY59m/4tollSVn4EValU= Received: by 10.68.54.170 with SMTP id k10mr13684096pbp.522.1305145398689; Wed, 11 May 2011 13:23:18 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id 8sm184987pbw.23.2011.05.11.13.23.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2011 13:23:16 -0700 (PDT) Message-ID: <4DCAEFFE.9080405@gmail.com> Date: Wed, 11 May 2011 13:22:22 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: "vwrap@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [vwrap] Activity for charter: Proxies, Gateways, BSD, GPL... X-BeenThere: vwrap@ietf.org 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: Wed, 11 May 2011 20:23:20 -0000 I'm fascinated with XML2RFC editor more for arithmetic simulation than just virtual land farms. They both can lead into accessible arithmetic computation. This has been quite the mushroom piece, yet there is no easy way to just hand people the experience of the requirements between BSD code and GPL code, and present all the ramifications with given experience, and how to navigate back the peace in standards. I "think" we should limit VWRAP to proxies and gateways. With that, we should also assume original assets are not transferred upon request. If not, how to achieve that goal. Note: BSD versus GPL debates are out of scope (and so is any anxiety induction of the same effect). As Morgaine pointed out, there is disparity between the groups, so without prejudice I picked these two in order for us to straw-man the flow between IETF-VWRAP-BSD and IETF-VWRAP-GPL, and document that flow with XML2RFC. We are not dumb about this, so please no . The flow of BSD to GPL is easier than GPL to BSD. I don't think that is as obvious, however ICANN's recent move to allow trademarks to overtake .net domains does provide useful means to accomplish that goal even within RFC nature. Simply, for example, we can proxy or gateway the email address "agent@region©site™" to user@region.site.net by default from ICANN's spawned flow. This provides backwards compatibility with plain text RFCs and forward compatibility with XML2RFC. If we also include arithmetic atomicals formatter (or such arithmetic patterns) that 3D games have taken for granted then we can cancel anxiety in the above two flows. Imagine two media regions. The first media region allows only BSD content with ambiguous context. The second media region allows only GPL context with default GPL content. Content-Type: Message; license=... If we write XML2RFC.NET then we can quantize the fallacies of the proxies and gateways between the two media types, and achieve similar affect of the previous charter. We need some kind of default intent for non-arithmetic flows that do not apply to the above for the first obvious fallacy, which may be summarized as for polymerization of outstanding license issues. No date set for this kind of milestone. I figure any BSD to GPL proxy and can default the "Expiration:" date with exceptions upon trademarks. Does that make the economy easier? -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Wed May 11 16:07:45 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D97E0696 for ; Wed, 11 May 2011 16:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aX5TbuQCZyy for ; Wed, 11 May 2011 16:07:45 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 253ABE06DA for ; Wed, 11 May 2011 16:07:45 -0700 (PDT) Received: by pzk5 with SMTP id 5so610013pzk.31 for ; Wed, 11 May 2011 16:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tGjGXoeleouyeWhZB3rQ1xdMFLx1XvOUodhiCqnNFvg=; b=wolysj4j+tPn5CuveOqY+qm0UFsVlWBaYzRNipy47Zh0eqEJ3byp19rQ/BtjcjA75n PZ1z8UU2a48dTodHPnZ2rEv/b93MP/1OKPjC+Ssa84kgt1t+V8Ee13bWeMZViGJKyoJ6 8bunspU7sphpCZvOrF1yu3XMOCraH0kVRz4Q4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=aF8ktQBfCFyj02a7BvjvK587i+0zVlaUz6z76jFzvxg06R+Ii7mLBh4QKGKyLvXGGD r9NDfO4QneZiUbsSLE9HjglXduwoes7N6XwxI0Wy7/EuVTl/veYqscZXv+bK4HJRYF/C WQPAlPCR0Ff3DrB6FVziBiSlur7gLQWI/zLNk= Received: by 10.68.4.33 with SMTP id h1mr14053126pbh.63.1305155264048; Wed, 11 May 2011 16:07:44 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id p2sm264013pbq.6.2011.05.11.16.07.42 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2011 16:07:43 -0700 (PDT) Message-ID: <4DCB1689.4070507@gmail.com> Date: Wed, 11 May 2011 16:06:49 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Dzonatas Sol References: <4DCAEFFE.9080405@gmail.com> In-Reply-To: <4DCAEFFE.9080405@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Activity for charter: Proxies, Gateways, BSD, GPL... X-BeenThere: vwrap@ietf.org 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: Wed, 11 May 2011 23:07:46 -0000 I should also note here something that may be unfamiliar in context versus content in accessibility issues. There are now not only kinetic devices that can view and gather motion data as there are also external headgear devices that sense areas of brain activity data. Those devices are one the consumer market now. The point here is the capability to communicate in other forms of speech or mime without spoken words, and, yes, we can achieve independence. Let me know if that sounds quantum far. On 05/11/2011 01:22 PM, Dzonatas Sol wrote: > I'm fascinated with XML2RFC editor more for arithmetic simulation than > just virtual land farms. They both can lead into accessible arithmetic > computation. This has been quite the mushroom piece, yet there is no > easy way to just hand people the experience of the requirements > between BSD code and GPL code, and present all the ramifications with > given experience, and how to navigate back the peace in standards. > > I "think" we should limit VWRAP to proxies and gateways. With that, we > should also assume original assets are not transferred upon request. > If not, how to achieve that goal. > > Note: BSD versus GPL debates are out of scope (and so is any anxiety > induction of the same effect). > > As Morgaine pointed out, there is disparity between the groups, so > without prejudice I picked these two in order for us to straw-man the > flow between IETF-VWRAP-BSD and IETF-VWRAP-GPL, and document that flow > with XML2RFC. We are not dumb about this, so please no . > > The flow of BSD to GPL is easier than GPL to BSD. I don't think that > is as obvious, however ICANN's recent move to allow trademarks to > overtake .net domains does provide useful means to accomplish that > goal even within RFC nature. > > Simply, for example, we can proxy or gateway the email address > "agent@region©site™" to user@region.site.net by default from ICANN's > spawned flow. This provides backwards compatibility with plain text > RFCs and forward compatibility with XML2RFC. > > If we also include arithmetic atomicals formatter (or such arithmetic > patterns) that 3D games have taken for granted then we can cancel > anxiety in the above two flows. > > Imagine two media regions. The first media region allows only BSD > content with ambiguous context. The second media region allows only > GPL context with default GPL content. > > Content-Type: Message; license=... > > If we write XML2RFC.NET then we can quantize the fallacies of the > proxies and gateways between the two media types, and achieve similar > affect of the previous charter. We need some kind of default intent > for non-arithmetic flows that do not apply to the above for the first > obvious fallacy, which may be summarized as for polymerization of > outstanding license issues. > > No date set for this kind of milestone. I figure any BSD to GPL proxy > and can default the "Expiration:" date with exceptions upon trademarks. > > Does that make the economy easier? > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Wed May 11 18:35:08 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91545E0873 for ; Wed, 11 May 2011 18:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjAqwyVIxioy for ; Wed, 11 May 2011 18:35:07 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id B5EA8E06FD for ; Wed, 11 May 2011 18:35:07 -0700 (PDT) Received: by pxi2 with SMTP id 2so670644pxi.38 for ; Wed, 11 May 2011 18:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GWZXuF0eq5GnQi63pjjRZSs+6+MLWNLyt/Dbzpr6z1M=; b=yGpJFTpZ1aYj+kUjbhsF4/1GzOACCaYGx4JVhfjz9d0gyT5T/A+6SpXFv82EAvtmUh 4NA+a0qjCF9eGcfZG5mDCcF2Vm3cgbk6gauF5bdYUqjSi2Ai4NGrt5FrTj1qAA/FJPV/ e+xhJesolgLJfApCQUE++s7fLVQZPg9xzNY+E= 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=yE9VBAlMdgHZhBmbmNUp+84Mdv/XendohJ8BZbS+ZT6wZsS/sXyGxO3iW+vPa6Lg/J DvzK2tvgl2HTC8Yc1fg1QJpP0hHg41fBnNwCf6qH9mkYkbO4/Nrr80zqEMZz2ee+vqyi xyMASCbwfUpFPr22faEndpnQ6+1hgSZpwTFRU= Received: by 10.142.120.15 with SMTP id s15mr5672087wfc.141.1305164107421; Wed, 11 May 2011 18:35:07 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id t9sm334896pbo.3.2011.05.11.18.35.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2011 18:35:06 -0700 (PDT) Message-ID: <4DCB390A.7070807@gmail.com> Date: Wed, 11 May 2011 18:34:02 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: "vwrap@ietf.org" References: <4DCAEFFE.9080405@gmail.com> <4DCB1689.4070507@gmail.com> In-Reply-To: <4DCB1689.4070507@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [vwrap] Activity for charter: Proxies, Gateways, BSD, GPL... X-BeenThere: vwrap@ietf.org 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: Thu, 12 May 2011 01:35:08 -0000 Others questioned me about this activity off-list. Please, considered that people do not like to explain the full scale of disability issues over and over to every incidence of new layman that have not experienced such disabilities themselves (or aware of their own). People write standards for engineering quality, and it seems people often get that process backwards. This is why I suggest the XML2RFC.NET as an example to help in this issue. We can use our own viewers and tools to lexically analyze standards and the process. We don't assume one size fits all, so I use the oxymoron "poly-scale" as something exists that best fits meaning on any scale. Somehow, I get the common complaint that two monomers do not belong in physical simulations. I disagree because this is the ordinary world and not some metaphysical game. On 05/11/2011 04:06 PM, Dzonatas Sol wrote: > I should also note here something that may be unfamiliar in context > versus content in accessibility issues. There are now not only kinetic > devices that can view and gather motion data as there are also > external headgear devices that sense areas of brain activity data. > Those devices are one the consumer market now. The point here is the > capability to communicate in other forms of speech or mime without > spoken words, and, yes, we can achieve independence. > > Let me know if that sounds quantum far. > > On 05/11/2011 01:22 PM, Dzonatas Sol wrote: >> I'm fascinated with XML2RFC editor more for arithmetic simulation >> than just virtual land farms. They both can lead into accessible >> arithmetic computation. This has been quite the mushroom piece, yet >> there is no easy way to just hand people the experience of the >> requirements between BSD code and GPL code, and present all the >> ramifications with given experience, and how to navigate back the >> peace in standards. >> >> I "think" we should limit VWRAP to proxies and gateways. With that, >> we should also assume original assets are not transferred upon >> request. If not, how to achieve that goal. >> >> Note: BSD versus GPL debates are out of scope (and so is any anxiety >> induction of the same effect). >> >> As Morgaine pointed out, there is disparity between the groups, so >> without prejudice I picked these two in order for us to straw-man the >> flow between IETF-VWRAP-BSD and IETF-VWRAP-GPL, and document that >> flow with XML2RFC. We are not dumb about this, so please no . >> >> The flow of BSD to GPL is easier than GPL to BSD. I don't think that >> is as obvious, however ICANN's recent move to allow trademarks to >> overtake .net domains does provide useful means to accomplish that >> goal even within RFC nature. >> >> Simply, for example, we can proxy or gateway the email address >> "agent@region©site™" to user@region.site.net by default from ICANN's >> spawned flow. This provides backwards compatibility with plain text >> RFCs and forward compatibility with XML2RFC. >> >> If we also include arithmetic atomicals formatter (or such arithmetic >> patterns) that 3D games have taken for granted then we can cancel >> anxiety in the above two flows. >> >> Imagine two media regions. The first media region allows only BSD >> content with ambiguous context. The second media region allows only >> GPL context with default GPL content. >> >> Content-Type: Message; license=... >> >> If we write XML2RFC.NET then we can quantize the fallacies of the >> proxies and gateways between the two media types, and achieve similar >> affect of the previous charter. We need some kind of default intent >> for non-arithmetic flows that do not apply to the above for the first >> obvious fallacy, which may be summarized as for polymerization of >> outstanding license issues. >> >> No date set for this kind of milestone. I figure any BSD to GPL proxy >> and can default the "Expiration:" date with exceptions upon trademarks. >> >> Does that make the economy easier? >> > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From wwwrun@ietfa.amsl.com Wed May 18 17:02:47 2011 Return-Path: X-Original-To: vwrap@ietf.org Delivered-To: vwrap@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 8D4F0E0741; Wed, 18 May 2011 17:02:47 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110519000247.8D4F0E0741@ietfa.amsl.com> Date: Wed, 18 May 2011 17:02:47 -0700 (PDT) Cc: vwrap@ietf.org, barryleiba@computer.org Subject: [vwrap] WG Action: Conclusion of Virtual World Region Agent Protocol (VWRAP) X-BeenThere: vwrap@ietf.org 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: Thu, 19 May 2011 00:02:47 -0000 The Virtual World Region Agent Protocol (VWRAP) working group in the Applications Area has concluded. The IESG contact person is Peter Saint-Andre. The mailing list will remain active. The VWRAP working group was chartered to produce a comprehensive application protocol defining the interactions between virtual agents (avatars) and collaborative, three-dimensional virtual environments (virtual worlds). Unfortunately, the technology and market landscape changed significantly after the working group was chartered, and the working group lost several key participants, resulting in a lack of energy to complete the chartered deliverables. Although the remaining participants have discussed the possibility of focusing on a smaller scope (interoperability among virtual world technologies instead of a comprehensive virtual worlds protocol), those discussions remain preliminary at this time. Nevertheless, the mailing list will remain open to encourage further exploration of these topics. - Peter Saint-Andre, Responsible Area Director