From jef@openmetaverse.org Mon Aug 2 10:50:13 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918E33A6B9D for ; Mon, 2 Aug 2010 10:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.304 X-Spam-Level: X-Spam-Status: No, score=0.304 tagged_above=-999 required=5 tests=[AWL=-2.280, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmV-RLlUVTT3 for ; Mon, 2 Aug 2010 10:50:12 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 1399A3A6B45 for ; Mon, 2 Aug 2010 10:50:11 -0700 (PDT) Received: by wwf26 with SMTP id 26so10029002wwf.1 for ; Mon, 02 Aug 2010 10:50:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.137.149 with SMTP id w21mr5233787wbt.169.1280771439045; Mon, 02 Aug 2010 10:50:39 -0700 (PDT) Received: by 10.216.175.76 with HTTP; Mon, 2 Aug 2010 10:50:38 -0700 (PDT) X-Originating-IP: [4.59.176.6] Date: Mon, 2 Aug 2010 13:50:38 -0400 Message-ID: From: Jon Freedman To: "vwrap@ietf.org" Content-Type: multipart/alternative; boundary=0016e65b6142a9c8b3048cdad6d7 Subject: Re: [vwrap] Moving ahead with draft-ietf-vwrap-intro X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2010 17:50:13 -0000 --0016e65b6142a9c8b3048cdad6d7 Content-Type: text/plain; charset=ISO-8859-1 Hello Everyone, I want to throw in my two pieces of abstract virtual world currency into the mix. After perusing the vwrap-intro draft in depth, I have a few comments. I realize that some of this may have been raised before in previous discussions. The overall document and standardization roadmap makes is great. The technology and specifications laid out are generic enough that they should be able to encompass many forms of virtual worlds and the applications which inevitably evolve upon stable platforms. In my humble opinion the requirement of HTTP/REST semantics and suggestion for the use of XMPP as a messaging protocol are great to see. On the surface, the draft supports multiple means of deploying a virtual world. This ranges from local development environments to large distributed/scalable grids. Everyone seems to agree that support of multiple models is important, and I feel that this document does address that need. My only concern in this area is highly related to my overall concern with the document as it currently stands. I am wondering if it acceptable for me to give the document a quick overall pass to help improve some of the language use ? I realize this is a draft so hopefully this is a good time for such endeavours. Many sections lack clarity and multiple virtual world colloquialisms are used. Assuming there are no issues, I will send a txt version of my edits to this list within a few days. Cheers, -- Jonathan Freedman President Open Metaverse Foundation +1 (514) 582-1533 -- Jonathan Freedman President Open Metaverse Foundation +1 (514) 582-1533 --0016e65b6142a9c8b3048cdad6d7 Content-Type: text/html; charset=ISO-8859-1 
Hello Everyone,

I want to throw in my two pieces of abstract virtual world currency into the
mix. After perusing the vwrap-intro draft in depth, I have a few comments. I
realize that some of this may have been raised before in previous
discussions.

The overall document and standardization roadmap makes is great. The
technology and specifications laid out are generic enough that they should
be able to encompass many forms of virtual worlds and the applications which
inevitably evolve upon stable platforms. In my humble opinion the
requirement of HTTP/REST semantics and suggestion for the use of XMPP as a
messaging protocol are great to see.

On the surface, the draft supports multiple means of deploying a virtual
world. This ranges from local development environments to large
distributed/scalable grids. Everyone seems to agree that support of multiple
models is important, and I feel that this document does address that need.
My only concern in this area is highly related to my overall concern with
the document as it currently stands.

I am wondering if it acceptable for me to give the document a quick overall
pass to help improve some of the language use ? I realize this is a draft so
hopefully this is a good time for such endeavours. Many sections lack
clarity and multiple virtual world colloquialisms are used. Assuming there
are no issues, I will send a txt version of my edits to this list within a
few days.

Cheers,

-- 
Jonathan Freedman
President
Open Metaverse Foundation
+1 (514) 582-1533

--
Jonathan Freedman
President
Open Metaverse Foundation
+1 (514) 582-1533
--0016e65b6142a9c8b3048cdad6d7-- From josh@lindenlab.com Mon Aug 2 10:53:10 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73FDE3A6B9D for ; Mon, 2 Aug 2010 10:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.044 X-Spam-Level: X-Spam-Status: No, score=0.044 tagged_above=-999 required=5 tests=[AWL=-0.580, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnGkTyOaJhQk for ; Mon, 2 Aug 2010 10:53:09 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 4B8C13A6B45 for ; Mon, 2 Aug 2010 10:53:09 -0700 (PDT) Received: by vws10 with SMTP id 10so2302741vws.31 for ; Mon, 02 Aug 2010 10:53:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.158.11 with SMTP id d11mr4422566vcx.251.1280771616458; Mon, 02 Aug 2010 10:53:36 -0700 (PDT) Received: by 10.220.203.9 with HTTP; Mon, 2 Aug 2010 10:53:36 -0700 (PDT) In-Reply-To: <4C542CAC.1090301@gmail.com> References: <4C542CAC.1090301@gmail.com> Date: Mon, 2 Aug 2010 10:53:36 -0700 Message-ID: From: Joshua Bell To: "vwrap@ietf.org" Content-Type: multipart/alternative; boundary=e0cb4e887a3f3cc820048cdae17d Subject: Re: [vwrap] Working Draft: SNOW-375 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2010 17:53:10 -0000 --e0cb4e887a3f3cc820048cdae17d Content-Type: text/plain; charset=UTF-8 On Sat, Jul 31, 2010 at 7:01 AM, Dzonatas Sol wrote: > SNOW-375 is at a point to feature freeze and to fill-in development on > whats already included. Icesphere (C# based client to Snowglobe & Second > Life) uses SNOW-375 as a ReST based API. This shares concepts with VWRAP. > > Currently writing the resource dictionary, but here is an excerpt of > documentation just put together: > Looking forward to it! On the web page ( http://icyspherical.blogspot.com/2010/07/overview-snow-375-is-api-to-snowglobe.html ), you mention: >>>> Payloads that contain nested XML structures may not work well with JSON, so only LLSD is supported. This could be resolved with JSON specific queries, yet Snowglobe would still internally have to convert LLSD to JSON, so that would be an implementation detail on the transport layer. <<<< Can you elaborate here? Do you mean payloads that contain XML fragments, where an XML document serialization would be more natural than JSON with XML islands? Or...? I'm a big fan of JSON despite the sparse types meaning it's not a perfect serialization format for LLSD, and have been a heavy user of XML, so understanding your issue is important to me. Joshua > > Overview > > SNOW-375 is an API to the Snowglobe code base to query reflexive > information that affects Avatar, Agent, Assets, Inventory, Gestures, and > other states of the client as it interacts with the virtual world. In order > to enable the widest range of devices and scripts to communicate with the > client, the API is language-agnostic. The flexibility of client-side > scripting is a significant feature of SNOW-375. > > SNOW-375 allows for a multi-headed client architecture instead of a single > monolithic design. There are many possibilities to this besides client-side > scripting, like augmented reality devices, gesture recognition devices, > social networking, advanced heads-up displays, integrated desktop programs > (desklets), joysticks, machinima tools, and many more. Multi-headed clients > are also significant, yet its transport layer may be platform dependent. > > > Read more: > http://icyspherical.blogspot.com/2010/07/overview-snow-375-is-api-to-snowglobe.html > > -- > --- 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 > --e0cb4e887a3f3cc820048cdae17d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 31, 2010 at 7:01 AM, Dzonatas Sol <dzonatas@gmail.co= m> wrote:
SNOW-375 is at a point to feature freeze and to fill-in development on what= s already included. Icesphere (C# based client to Snowglobe & Second Li= fe) uses SNOW-375 as a ReST based API. This shares concepts with VWRAP.

Currently writing the resource dictionary, but here is an excerpt of docume= ntation just put together:

Looking forw= ard to it!


>>>>
Payloads that= contain nested XML structures may not work well with JSON, so only LLSD is= supported. This could be resolved with JSON specific queries, yet Snowglob= e would still internally have to convert LLSD to JSON, so that would be an = implementation detail on the transport layer.
<<<<

Can you elaborate here? Do y= ou mean payloads that contain XML fragments, where an XML document serializ= ation would be more natural than JSON with XML islands? Or...?

I'm a big fan of JSON despite the sparse types meaning i= t's not a perfect serialization format for LLSD, and have been a heavy = user of XML, so understanding your issue is important to me.

Joshua


=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;">
=C2=A0 Overview

SNOW-375 is an API to the Snowglobe code base to query reflexive informatio= n that affects Avatar, Agent, Assets, Inventory, Gestures, and other states= of the client as it interacts with the virtual world. In order to enable t= he widest range of devices and scripts to communicate with the client, the = API is language-agnostic. The flexibility of client-side scripting is a sig= nificant feature of SNOW-375.

SNOW-375 allows for a multi-headed client architecture instead of a single = monolithic design. There are many possibilities to this besides client-side= scripting, like augmented reality devices, gesture recognition devices, so= cial networking, advanced heads-up displays, integrated desktop programs (d= esklets), joysticks, machinima tools, and many more. Multi-headed clients a= re also significant, yet its transport layer may be platform dependent.


Read more: http://icyspherical.blogs= pot.com/2010/07/overview-snow-375-is-api-to-snowglobe.html

--
--- 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

--e0cb4e887a3f3cc820048cdae17d-- From ohmeadhbh@gmail.com Mon Aug 2 11:56:38 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C79F3A687C for ; Mon, 2 Aug 2010 11:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.655 X-Spam-Level: X-Spam-Status: No, score=-0.655 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRNE7CPlSmOj for ; Mon, 2 Aug 2010 11:56:37 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id EC76A3A69D3 for ; Mon, 2 Aug 2010 11:56:36 -0700 (PDT) Received: by wwj40 with SMTP id 40so3441826wwj.13 for ; Mon, 02 Aug 2010 11:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=seTcvD4APkecZxgt2+5q7C5zjZPuC9KRyJ00VbekfFk=; b=lOgMrSUci9ivfKyRHNSyXFPLD4ET5kvwFoG3Spjk5Sb57NPTYfgK0ZaUYyUD4aYITG eKdX2J33IVpHDSxT/JvKxBMtdmk27uHW6xbrS5Og+K3GV1MOlTWzfBr7E21rtHKvqA/t VUBjpQSzdFK7G7bQbk26pNm60ix7x0nNQlTFQ= 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=NESsFfr7EWRRcBYz0klHcu7RLPq34088M/KqfAOpcIg+JygCUI8atxGMs6S5Sv//gw EenVxFDcHpkQENjuXuvrw9s1b5XHYKfq/m2JmZB9FSYaqFqINd8ZROjQ+n3zz5F3oUKr KVgKdBLjO2Lexg0ibRdLcjoVGYAJax/v8SOE4= Received: by 10.216.150.219 with SMTP id z69mr3046144wej.75.1280775424204; Mon, 02 Aug 2010 11:57:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.166.144 with HTTP; Mon, 2 Aug 2010 11:56:44 -0700 (PDT) In-Reply-To: References: From: Meadhbh Hamrick Date: Mon, 2 Aug 2010 11:56:44 -0700 Message-ID: To: Jon Freedman Content-Type: text/plain; charset=ISO-8859-1 Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Moving ahead with draft-ietf-vwrap-intro X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2010 18:56:38 -0000 to quote a famous footware company's ads: "just do it!" please feel free to rewrite sections or just point out where you think the language is improper or could be improved. we _are_ trying to move this document along in the process, so sooner is better than later. i think we're hoping to have a document that reflects consensus, while at the same time constrains the problem domain somewhat. so, i think clarifying use cases or terminology would be readily welcomed. proposing we rebuild the whole infrastructure will result in quarrelsome quibbling. i'm guessing you're not proposing something so radical, so go for it! public comment and ideas for how to improve the specs are part of what we're trying to do on this list. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Mon, Aug 2, 2010 at 10:50 AM, Jon Freedman wrote: > Hello Everyone, > > I want to throw in my two pieces of abstract virtual world currency into the > mix. After perusing the vwrap-intro draft in depth, I have a few comments. I > realize that some of this may have been raised before in previous > discussions. > > The overall document and standardization roadmap makes is great. The > technology and specifications laid out are generic enough that they should > be able to encompass many forms of virtual worlds and the applications which > inevitably evolve upon stable platforms. In my humble opinion the > requirement of HTTP/REST semantics and suggestion for the use of XMPP as a > messaging protocol are great to see. > > On the surface, the draft supports multiple means of deploying a virtual > world. This ranges from local development environments to large > distributed/scalable grids. Everyone seems to agree that support of multiple > models is important, and I feel that this document does address that need. > My only concern in this area is highly related to my overall concern with > the document as it currently stands. > > I am wondering if it acceptable for me to give the document a quick overall > pass to help improve some of the language use ? I realize this is a draft so > hopefully this is a good time for such endeavours. Many sections lack > clarity and multiple virtual world colloquialisms are used. Assuming there > are no issues, I will send a txt version of my edits to this list within a > few days. > > Cheers, > > -- > Jonathan Freedman > President > Open Metaverse Foundation > +1 (514) 582-1533 > > -- > Jonathan Freedman > President > Open Metaverse Foundation > +1 (514) 582-1533 > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > From dzonatas@gmail.com Mon Aug 2 13:15:26 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 483503A6C52 for ; Mon, 2 Aug 2010 13:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FYuGUNvJxuf for ; Mon, 2 Aug 2010 13:15:24 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 7C47F3A68F2 for ; Mon, 2 Aug 2010 13:15:24 -0700 (PDT) Received: by pwj1 with SMTP id 1so1659080pwj.31 for ; Mon, 02 Aug 2010 13:15:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=hsmD6CkS1CbA2khzR++MxTd6fZjiuU22673+YOZst4g=; b=DlKqm88PXDCQI26CLWE9vwe9Q57LOcCAtPhpENg6h00ziPTL8eb2vGWNQ+lyXwx8uP 6REuQCHNFJiCrb7Wim66oawmq6s7zW6ttqRcz2Pzzx03SfYfN0lfSlpHlXXcwKeRXUj6 EFWqBhCBFuVwHucl8yTNYM0xHy6a8MLObLbfs= 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=N0Dkx13uuCmkimhAcE7oveOpbhunT9XbLbXcN8zoU6Djkcbs3Ekb7DclQnrJmNL15M vEG11ElX4hTPuRYk/YvwQrSPfCvgGDiepWtiVCR5JsRJWkNS6mBOjXoNiRUY2hPcXp4e rSIivYmRXNxfAUyu1fdZcU2FdsroEW2Rq1MMU= Received: by 10.142.161.3 with SMTP id j3mr5938197wfe.145.1280780152357; Mon, 02 Aug 2010 13:15:52 -0700 (PDT) Received: from [192.168.0.50] (adsl-68-124-103-250.dsl.scrm01.pacbell.net [68.124.103.250]) by mx.google.com with ESMTPS id w27sm8126102wfd.5.2010.08.02.13.15.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 13:15:51 -0700 (PDT) Message-ID: <4C572A6E.8070905@gmail.com> Date: Mon, 02 Aug 2010 13:28:30 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Joshua Bell References: <4C542CAC.1090301@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] Working Draft: SNOW-375 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2010 20:15:26 -0000 Joshua Bell wrote: > > >>>> > Payloads that contain nested XML structures may not work well with > JSON, so only LLSD is supported. This could be resolved with JSON > specific queries, yet Snowglobe would still internally have to convert > LLSD to JSON, so that would be an implementation detail on the > transport layer. > <<<< > > Can you elaborate here? Do you mean payloads that contain XML > fragments, where an XML document serialization would be more natural > than JSON with XML islands? Or...? > > I'm a big fan of JSON despite the sparse types meaning it's not a > perfect serialization format for LLSD, and have been a heavy user of > XML, so understanding your issue is important to me. > > In such cases for XML, I currently assume that full secure encapsulation/canonicalization is needed to pass on sanity to non-XML formats. If we assume XML only, then one valid XML structure is directly implantable into another XML structure where allowed (ambiguous tags, variable DTDs, intra-tags). I don't see a way for JSON to support intra-tags. I have written raw XML parsers that fold and unfold structures dynamically, and the parser knows nothing about its data or types. I could apply such technique instead of encapsulation. When people say they don't like XML, I know they actually mean they don't like DTDs, which should have been a separate standard than raw XML. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Mon Aug 2 13:27:12 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EEB33A698C for ; Mon, 2 Aug 2010 13:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkXivfZ09DlA for ; Mon, 2 Aug 2010 13:27:10 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id E0F693A6907 for ; Mon, 2 Aug 2010 13:27:10 -0700 (PDT) Received: by pwj1 with SMTP id 1so1661361pwj.31 for ; Mon, 02 Aug 2010 13:27:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=dB7wiijX0ym/1y95CjbNUc64eh/VXP602J9lDAovGRw=; b=kxWQdj22OqcnSF7biwJTHc9tx4Lh4xP9UmUBhpT5WdX6d4Js8prW/fJz2UIzrC3BwL R13yU9xXud9UaW4FHOVnZcMV3ooDV6imEdb4EWf3oI4armaGKhqdl1kr7ZD2ifqqLynn qJhEu6QyqKbcT56ehiSfp3ATxwqz6QeDVEB0o= 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=wWoAfMuxbkT0MtT5ycUAiX51mswK6wVabY+SluIgArZyUTwkVlF0X7NxaEa9BPLwZU NrSQ8w2RGiVAxqz2It94y1tPcOF531e7nxpIlLKxU28tVfs1frThi7yhVgw6QFgn5vXE wH+NzCn3Xf920srbs8FeGzHVSxmtB7F6714Iw= Received: by 10.114.77.13 with SMTP id z13mr7870552waa.196.1280780858760; Mon, 02 Aug 2010 13:27:38 -0700 (PDT) Received: from [192.168.0.50] (adsl-68-124-103-250.dsl.scrm01.pacbell.net [68.124.103.250]) by mx.google.com with ESMTPS id d38sm12073621wam.20.2010.08.02.13.27.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 13:27:38 -0700 (PDT) Message-ID: <4C572D31.9050601@gmail.com> Date: Mon, 02 Aug 2010 13:40:17 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Jon Freedman References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Moving ahead with draft-ietf-vwrap-intro X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2010 20:27:12 -0000 Jon Freedman wrote: > Hello Everyone, > > I want to throw in my two pieces of abstract virtual world currency into the > mix. After perusing the vwrap-intro draft in depth, I have a few comments. I > realize that some of this may have been raised before in previous > discussions. One concern I see is if we do add such types to the standard then every related structure may have to be passed by transports that always assume a certain level of authentication and security. That would subsequently make stateless connections harder by default. I agree if it is possible to do such then it would be great, but there would be practical consequences if the data can't dance. I think it should only be introduced as an optional extension where the connection is already stateful. That would at least help guarantee the general meaning of currency, yet I'm sure we could think of specific currencies that can have stateless transports. I have demonstrated one, so I wouldn't want to break that content. =) -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From josh@lindenlab.com Mon Aug 2 13:48:34 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2F543A6C32 for ; Mon, 2 Aug 2010 13:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.096 X-Spam-Level: X-Spam-Status: No, score=0.096 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16roPhxgCP3T for ; Mon, 2 Aug 2010 13:48:33 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 394663A69DC for ; Mon, 2 Aug 2010 13:48:33 -0700 (PDT) Received: by vws10 with SMTP id 10so2495783vws.31 for ; Mon, 02 Aug 2010 13:49:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.121.210 with SMTP id i18mr4581518vcr.148.1280782140562; Mon, 02 Aug 2010 13:49:00 -0700 (PDT) Received: by 10.220.203.9 with HTTP; Mon, 2 Aug 2010 13:49:00 -0700 (PDT) In-Reply-To: <4C572A6E.8070905@gmail.com> References: <4C542CAC.1090301@gmail.com> <4C572A6E.8070905@gmail.com> Date: Mon, 2 Aug 2010 13:49:00 -0700 Message-ID: From: Joshua Bell To: "vwrap@ietf.org" Content-Type: multipart/alternative; boundary=001636d34ceb85ea8e048cdd5495 Subject: Re: [vwrap] Working Draft: SNOW-375 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2010 20:48:34 -0000 --001636d34ceb85ea8e048cdd5495 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 2, 2010 at 1:28 PM, Dzonatas Sol wrote: > > In such cases for XML, I currently assume that full secure > encapsulation/canonicalization is needed to pass on sanity to non-XML > formats. If we assume XML only, then one valid XML structure is directly > implantable into another XML structure where allowed (ambiguous tags, > variable DTDs, intra-tags). I don't see a way for JSON to support > intra-tags. > > Assuming I'm understanding you correctly... As in LLSD, everything in JSON is a key or value. So you could easily have: { "somekey": "somedata", "otherdata": /* your data here */ } ... where the overall JSON payload's value is a map, and value of that map's key "otherdata" is an arbitrary JSON value in place of the C-style comment (the above is not valid JSON as written, of course). There is no capability in JSON for the included data to change the meaning of the container, so this is as "secure" as in a similar XML usage. (If you had a buggy output mechanism that didn't output values as valid fragments, then obviously the payload could render the container invalid. But this is as true with XML as with JSON - or SQL or ... /me thinks of little Bobby Tables http://xkcd.com/327/.) I have written raw XML parsers that fold and unfold structures dynamically, > and the parser knows nothing about its data or types. I could apply such > technique instead of encapsulation. > Although a JSON parser must be aware of the JSON types (object, array, string, number, true, false, null), it does not need to be aware of the interpretation of the data any more than an XML parser that is not also a validator. While this may seem slightly more complicated than XML (its just tags, right?), a fully conforming JSON parser is simpler than a fully conforming XML parser since XML is more feature-rich (whitespace rules, attributes, character entities, CDATA, namespaces, mixed content, ids, etc). So, although XML may be superior in other ways, I don't believe this is a case where JSON is inferior to XML - if I'm understanding your point correctly. > When people say they don't like XML, I know they actually mean they don't > like DTDs, which should have been a separate standard than raw XML. In my experience, everyone has a favorite XML schema language, and thinks the others are evil. :) XML has a tremendous amount of power, but most of the time you need only a small fraction of that power. (e.g. LLSD's XML serialization doesn't need namespaces, mixed content, etc). Contrariwise, XML's expressiveness lets you precisely serialize all of LLSD's types, whereas many LLSD types collapse to JSON strings. --001636d34ceb85ea8e048cdd5495 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 2, 2010 at 1:28 PM, Dzonatas Sol <dzonatas@gmail.com= > wrote:

In such cases for XML, I currently assume that full secure encapsulation/ca= nonicalization is needed to pass on sanity to non-XML formats. If we assume= XML only, then one valid XML structure is directly implantable into anothe= r XML structure where allowed (ambiguous tags, variable DTDs, intra-tags). = I don't see a way for JSON to support intra-tags.


Assuming I'm understanding you cor= rectly...

As in LLSD, everything in JSON is a key = or value. So you could easily have:

{ "someke= y": "somedata",
=C2=A0=C2=A0"otherdata": /* your data here */
}

... where the overall JSON payload's value is a = map, and value of that map's key "otherdata" is an arbitrary = JSON value in place of the C-style comment (the above is not valid JSON as = written, of course). There is no capability in JSON for the included data t= o change the meaning of the container, so this is as "secure" as = in a similar XML usage.
=C2=A0
(If you had a buggy output mechanism that didn't = output values as valid fragments, then obviously the payload could render t= he container invalid. But this is as true with XML as with JSON - or SQL or= ... /me thinks of little Bobby Tables=C2=A0http://xkcd.com/327/.)

I have written raw XML parsers that fold and unfold structures dynamically,= and the parser knows nothing about its data or types. I could apply such t= echnique instead of encapsulation.

Although a JSON parser must be aware of the JSON types (object, array, stri= ng, number, true, false, null), it does not need to be aware of the interpr= etation of the data any more than an XML parser that is not also a validato= r. While this may seem slightly more complicated than XML (its just tags, r= ight?), a fully conforming JSON parser is simpler than a fully conforming X= ML parser since XML is more feature-rich (whitespace rules, attributes, cha= racter entities, CDATA, namespaces, mixed content, ids, etc).

So, although XML may be superior in other ways, I don&#= 39;t believe this is a case where JSON is inferior to XML - if I'm unde= rstanding your point correctly.
=C2=A0
When people say they don't like XML, I know they actually mean they don= 't like DTDs, which should have been a separate standard than raw XML.<= /blockquote>

In my experience, everyone has a favorite X= ML schema language, and thinks the others are evil. :)

XML has a tremendous amount of power, but most of the t= ime you need only a small fraction of that power. (e.g. LLSD's XML seri= alization doesn't need namespaces, mixed content, etc). Contrariwise, X= ML's expressiveness lets you precisely serialize all of LLSD's type= s, whereas many LLSD types collapse to JSON strings.

--001636d34ceb85ea8e048cdd5495-- From dzonatas@gmail.com Mon Aug 2 14:31:35 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 347E63A6C6D for ; Mon, 2 Aug 2010 14:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDY4y2AM9itS for ; Mon, 2 Aug 2010 14:31:29 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 68F9B3A686B for ; Mon, 2 Aug 2010 14:31:29 -0700 (PDT) Received: by pwj1 with SMTP id 1so1673342pwj.31 for ; Mon, 02 Aug 2010 14:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=fIpn34aGKEcwPePFtMZFIRKGMNyjrjUQI8HzRE2uB6U=; b=w9fvlJfLlAH9nJKqF4wyFMqvuwPK5CgIK33RDRNQTPBVQnh78kGQRVkIWlnZeRML8b MfLQbRWDkAKqIlI94d/w2yyiIQwr9pTEmw1P/dwfmcqthkOH3VfDnK+llUD+sW+/O8Lg 548WQAiZTpU6ajGbEGM7/UG/PcuTUS5b2ySo8= 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=QXguBOS/dderWFQNjTItjbDQzOOaIj1KuJ7cZigJNKaL8LT3s8CcUse6CU1BiOo1ga xy7TPNYTs0vty7ahbn6Hn2r785JoXelz0blwqStvV9nz4ZnmALHQoMFII3BuyJfgUpBP a8mIsOMLrZsqIqdx8zYbua2xxjXpxm23Kje1s= Received: by 10.142.246.18 with SMTP id t18mr4556697wfh.270.1280784717351; Mon, 02 Aug 2010 14:31:57 -0700 (PDT) Received: from [192.168.0.50] (adsl-68-124-103-250.dsl.scrm01.pacbell.net [68.124.103.250]) by mx.google.com with ESMTPS id f2sm8204141wfp.23.2010.08.02.14.31.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 14:31:56 -0700 (PDT) Message-ID: <4C573C43.5060905@gmail.com> Date: Mon, 02 Aug 2010 14:44:35 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Joshua Bell References: <4C542CAC.1090301@gmail.com> <4C572A6E.8070905@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] Working Draft: SNOW-375 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2010 21:31:35 -0000 Joshua Bell wrote: > > Although a JSON parser must be aware of the JSON types (object, array, > string, number, true, false, null), it does not need to be aware of > the interpretation of the data any more than an XML parser that is not > also a validator. While this may seem slightly more complicated than > XML (its just tags, right?), a fully conforming JSON parser is simpler > than a fully conforming XML parser since XML is more feature-rich > (whitespace rules, attributes, character entities, CDATA, namespaces, > mixed content, ids, etc). Only attributes is part of raw XML, everything else you mentioned above is based on DTD. When you say XML parser without a validator, the above sounds like you don't mean raw XML. > > In my experience, everyone has a favorite XML schema language, and > thinks the others are evil. :) Raw XML has no schema other than where to delineate. > > XML has a tremendous amount of power, but most of the time you need > only a small fraction of that power. (e.g. LLSD's XML serialization > doesn't need namespaces, mixed content, etc). Contrariwise, XML's > expressiveness lets you precisely serialize all of LLSD's types, > whereas many LLSD types collapse to JSON strings. I count only 3 characters that a raw XML parser needs to know to do one forward sweep and perfectly index the entire structure. 4 characters if you want the sweep to give a nested index. There is no secret about that. It's part of the published standard. Even the built-in XML parser to C# understands that. Hidden treasure? =) Actually, I like the XML Parser of System.NET since it's easy to write code that gives a very detailed stack trace (when wanted) based on every tag, how to expect content, and how each tag should close. Look at my C# Snowglobe.Scalar class to see how I have split out each tag to a different function. It's makes it very functional and easy to group documentation in the source rather in the XML. Raw XML has always meant to exist for such usage. DTD is just more formal "human readable," but not as "machine readable" as originally described by XML. The DTD was really only meant to be used for completely unknown exportations to describe the document in a formal language other than source code. If you trust how your neighbor handles the data then there no reason to use a DTD or any concept of it. Raw XML is only meant to be one step away from binary data, where raw XML is portable byte order and binary data is obviously not "native" once transmitted. I don't see how JSON is an improvement from that. --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Tue Aug 3 09:17:49 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15A213A6974 for ; Tue, 3 Aug 2010 09:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LlaTm4qY+No for ; Tue, 3 Aug 2010 09:17:48 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id EB3453A6937 for ; Tue, 3 Aug 2010 09:17:47 -0700 (PDT) Received: by pvd12 with SMTP id 12so1940266pvd.31 for ; Tue, 03 Aug 2010 09:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=vZ2rHxYK4mnj379dnpCEqPqHFY1DVJ9GraELNHtc9WQ=; b=vwovI2gkCBqlu2s/2JAnmB8KRHFTDbbzei20IcbROBpXezxb/JohN0mAJXMwAgDy/Q jo1xBPDyuOmsRRwiyXFWFkfre9RDa74yCMxIhJXlXSHoXAG/ETLo6ZJps3YdMFAeUpsK Rz3Av5ilgQKdAdYbQNaIJb87AcKeqa/PI3xgs= 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=LXqZqVXUVaEcnVU0qIKVDih9AzLPFAssGYnaesipF2GnpJdRGqKIXKv0meUoKfCgcG wFcoAk1Cfro2aEFV667VbnzhUIIue6hBicz65oPH23i97dZJiJnh8xhVC2tg5C0js4wS iOayy0++7Y82Ykq09zV8wZyd342EtBIEx2JAQ= Received: by 10.142.215.7 with SMTP id n7mr6780802wfg.194.1280852296646; Tue, 03 Aug 2010 09:18:16 -0700 (PDT) Received: from [192.168.0.50] (adsl-68-124-103-250.dsl.scrm01.pacbell.net [68.124.103.250]) by mx.google.com with ESMTPS id y16sm9351100wff.2.2010.08.03.09.18.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Aug 2010 09:18:15 -0700 (PDT) Message-ID: <4C58443F.80502@gmail.com> Date: Tue, 03 Aug 2010 09:30:55 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Dzonatas Sol , "vwrap@ietf.org" References: <4C542CAC.1090301@gmail.com> <4C572A6E.8070905@gmail.com> <4C573C43.5060905@gmail.com> In-Reply-To: <4C573C43.5060905@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] Working Draft: SNOW-375 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2010 16:17:49 -0000 Dzonatas Sol wrote: > > I don't see how JSON is an improvement from that. > > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > In fact, JSON's best feature is being able to do the eval(), yet those of us that written VMs should already know this. Verification killed that feature when they tried to use it in out-of-domain style. On that note, I suggest to change the VWRAP docs where if people request JSON (i.e. "application/json-*" ) that they actually want RSS or ATOM styled structures. Instead, only offer RSS or ATOM structured JSON (i.e. "application/json-atom" ). If they want more raw than that, then it just makes sense to use XML. It's too costly for "us", and they don't realize it. There may be other formats besides RSS or ATOM, so its not a moratorium, yet these two are popular solutions already well established. I'm sure different audiences are going to quibble, but I leave it up to you to decide on support steps to change and how to present them. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Tue Aug 3 09:52:15 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359163A69EF for ; Tue, 3 Aug 2010 09:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmt1wEz+Gjp0 for ; Tue, 3 Aug 2010 09:52:14 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 1E4853A6878 for ; Tue, 3 Aug 2010 09:52:14 -0700 (PDT) Received: by pzk6 with SMTP id 6so1990419pzk.31 for ; Tue, 03 Aug 2010 09:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=aA+wevM8g0WAoS9mwrIYUrMLl11VM9KDOfZFFEXu2Fo=; b=g6/3iw+3xbMhRmqDfoe3ytQ0yqRuo8b+iAmkECHZXd5I9ayH66ksbhAVRq1C30A8JC scxhbc25tfaj6BpMaTT/gXguXoKafPlq3eIsCByvW7Nam+wA7CzuUhKdl6lwrkk34CRz l43UQaTkSADq/FslIPSTvue7vETCr4C4L38M8= 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=TVHkrJxAGhUYI5arC0JXAo2S4ybQRjT8lReX2Lod45oeXxc8RraOju+btpmOCgd+HG /Gqfrk89SZ4ulsVKBjJPGMD9e0+XTBJtlNdNibGT9YXX5WW2ER2tFjRNarA9cX8J9gBj +sDpluGsbWCN9qMeiic3LFMto0Nc/zN74GH2c= Received: by 10.142.180.20 with SMTP id c20mr6947091wff.39.1280854362883; Tue, 03 Aug 2010 09:52:42 -0700 (PDT) Received: from [192.168.0.50] (adsl-68-124-103-250.dsl.scrm01.pacbell.net [68.124.103.250]) by mx.google.com with ESMTPS id q27sm9379688wfc.6.2010.08.03.09.52.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Aug 2010 09:52:42 -0700 (PDT) Message-ID: <4C584C52.6040309@gmail.com> Date: Tue, 03 Aug 2010 10:05:22 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Dzonatas Sol , "vwrap@ietf.org" References: <4C542CAC.1090301@gmail.com> <4C572A6E.8070905@gmail.com> <4C573C43.5060905@gmail.com> <4C58443F.80502@gmail.com> In-Reply-To: <4C58443F.80502@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] Working Draft: SNOW-375 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2010 16:52:15 -0000 And one more thing... (yes, I was "listening") To expand on Zha's use-cases: We should have a "application/xml-org-ietf-vwrap-" prefix for mime types. That'll help with transitions, so I think this group already knows their postfixes. Dzonatas Sol wrote: > Dzonatas Sol wrote: >> >> I don't see how JSON is an improvement from that. >> >> --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> > > In fact, JSON's best feature is being able to do the eval(), yet those > of us that written VMs should already know this. Verification killed > that feature when they tried to use it in out-of-domain style. > > On that note, I suggest to change the VWRAP docs where if people > request JSON (i.e. "application/json-*" ) that they actually want RSS > or ATOM styled structures. Instead, only offer RSS or ATOM structured > JSON (i.e. "application/json-atom" ). If they want more raw than that, > then it just makes sense to use XML. It's too costly for "us", and > they don't realize it. > > There may be other formats besides RSS or ATOM, so its not a > moratorium, yet these two are popular solutions already well > established. I'm sure different audiences are going to quibble, but I > leave it up to you to decide on support steps to change and how to > present them. > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Wed Aug 4 06:01:39 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED26B3A68B3 for ; Wed, 4 Aug 2010 06:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.927 X-Spam-Level: X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukqAxqEWZ4H6 for ; Wed, 4 Aug 2010 06:01:38 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 7C4523A67B3 for ; Wed, 4 Aug 2010 06:01:38 -0700 (PDT) Received: by pzk6 with SMTP id 6so2269608pzk.31 for ; Wed, 04 Aug 2010 06:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=/j0ZwY4DlZYZ551RuNjT6JqsF0Gnckf9rt8yepusM8U=; b=lJfcy/K6+4wT1FsY5/jklf1MjumJdRDGYDyjZnm8bkp5v8Ro52WQ2RsSvC/Z1zB+fr CZqIj6EFngn0Z+aZCQ3ZWUUBPTCgvIvrOv5RKsGc91umZmtFN6eJcVMzXmlCI0TF26tm WkcWE8DwBefN9fqOjmq2a6+p73c/4OBGN0AVo= 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=ZigXwBxLCMW+se5kqDJTamke5NpHRAuwnCsdbzQI2BoOscL2WnkL4AG5Tknv/x+JmD xUfEnMgk3MaphhlunwAGqpQ7JnjA/ctaLuBB3p3kp0xibsmv7enMtSB2MPi1gqa2TIiD m63do/oxFbQWy+J8F4PQkQOphJJL99p1oQzz0= Received: by 10.142.211.5 with SMTP id j5mr7744918wfg.36.1280926927457; Wed, 04 Aug 2010 06:02:07 -0700 (PDT) Received: from [192.168.0.50] (adsl-68-124-103-250.dsl.scrm01.pacbell.net [68.124.103.250]) by mx.google.com with ESMTPS id n2sm10557939wfl.13.2010.08.04.06.02.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Aug 2010 06:02:04 -0700 (PDT) Message-ID: <4C5967C6.4080501@gmail.com> Date: Wed, 04 Aug 2010 06:14:46 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Dzonatas Sol , "vwrap@ietf.org" References: <4C542CAC.1090301@gmail.com> <4C572A6E.8070905@gmail.com> <4C573C43.5060905@gmail.com> <4C58443F.80502@gmail.com> <4C584C52.6040309@gmail.com> In-Reply-To: <4C584C52.6040309@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [vwrap] xml-org-ietf-vwrap- Re: Working Draft: SNOW-375 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2010 13:01:40 -0000 I went a step further to bring back a decade old idea off the shelf... to actually implement some of these RFCs in the system other than user land. (Patents expiring... "Win7" probably last major "WNT" edition... XP support extended... DirectX11 is vapor except "Render-Morphium" code ... X11 looks ready for next leap.) I'm going to suggest that IETF VWRAP makes a good foundation to bring XML to the "kernel" level. Those of us that have worked on that idea know that Linux kernel is also kernel modules and subsystems, and that there hasn't really been a reason to implement RING1, so its only been RING0 and RING3. I think those still mean something. This suggestion would simplify shared media, its synchronization, and atomicity. Don't expect it to be framebuffer speed, because that's unidirectional. We can assume shared media is bidirectional, so the concepts of the synchronization are very similar to VWRAP. The critical issue to resolve is that it doesn't need to support general mime types already specified. It could just filter everything out, and we could just start with the mime type noted below. I would like VMS... mainframe environment be aware of this kind of UNIX step and decide if they need a diagnostic mode (RING2/RING0), which they would need to suggest. The shared media may be "reactive". If I hear nothing about it from this, then I'll assume either it wasn't heard or there is no concern, which justifies our time. (I'm not gonna answer leading questions about this.) For backword compatibility, the .NET/Mono wrap around ".exes" make a good model to embed such XML. Then the obvious follow-up is to make an IL.XML more formal, but that is something this group doesn't need to maintain (which was a made obvious business concern.) Thanks for reading, Dzonatas P.S. I was recently reminded Bell Labs still holds interest in a certain nuclear license. Mesh networks is inevitable. Don't blame me for talking about it. Dzonatas Sol wrote: > And one more thing... (yes, I was "listening") > > To expand on Zha's use-cases: > > We should have a "application/xml-org-ietf-vwrap-" prefix for mime types. > > That'll help with transitions, so I think this group already knows > their postfixes. > > > Dzonatas Sol wrote: >> Dzonatas Sol wrote: >>> >>> I don't see how JSON is an improvement from that. >>> >>> --- https://twitter.com/Dzonatas_Sol --- >>> Web Development, Software Engineering, Virtual Reality, Consultant >>> >>> >> >> In fact, JSON's best feature is being able to do the eval(), yet >> those of us that written VMs should already know this. Verification >> killed that feature when they tried to use it in out-of-domain style. >> >> On that note, I suggest to change the VWRAP docs where if people >> request JSON (i.e. "application/json-*" ) that they actually want RSS >> or ATOM styled structures. Instead, only offer RSS or ATOM structured >> JSON (i.e. "application/json-atom" ). If they want more raw than >> that, then it just makes sense to use XML. It's too costly for "us", >> and they don't realize it. >> >> There may be other formats besides RSS or ATOM, so its not a >> moratorium, yet these two are popular solutions already well >> established. I'm sure different audiences are going to quibble, but I >> leave it up to you to decide on support steps to change and how to >> present them. >> > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From mike.dickson@hp.com Wed Aug 4 06:36:17 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1753A6A67 for ; Wed, 4 Aug 2010 06:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Vmj2raFeI0k for ; Wed, 4 Aug 2010 06:36:14 -0700 (PDT) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by core3.amsl.com (Postfix) with ESMTP id 9056F3A6A53 for ; Wed, 4 Aug 2010 06:35:56 -0700 (PDT) Received: from G3W0630.americas.hpqcorp.net (g3w0630.americas.hpqcorp.net [16.233.58.74]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id CBB5E386AA; Wed, 4 Aug 2010 13:36:22 +0000 (UTC) Received: from G4W0659.americas.hpqcorp.net (16.234.40.187) by G3W0630.americas.hpqcorp.net (16.233.58.74) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 4 Aug 2010 13:34:46 +0000 Received: from GVW0433EXB.americas.hpqcorp.net ([16.234.32.148]) by G4W0659.americas.hpqcorp.net ([16.234.40.187]) with mapi; Wed, 4 Aug 2010 13:34:46 +0000 From: "Dickson, Mike (ISS Software)" To: Dzonatas Sol , "vwrap@ietf.org" Date: Wed, 4 Aug 2010 13:34:15 +0000 Thread-Topic: [vwrap] xml-org-ietf-vwrap- Re: Working Draft: SNOW-375 Thread-Index: Acsz1UT2qfOuRNt2RqOsg1Zl6GMm2gAA9maA Message-ID: <4646639E08F58B42836FAC24C94624DD85E085CDAE@GVW0433EXB.americas.hpqcorp.net> References: <4C542CAC.1090301@gmail.com> <4C572A6E.8070905@gmail.com> <4C573C43.5060905@gmail.com> <4C58443F.80502@gmail.com> <4C584C52.6040309@gmail.com> <4C5967C6.4080501@gmail.com> In-Reply-To: <4C5967C6.4080501@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [vwrap] xml-org-ietf-vwrap- Re: Working Draft: SNOW-375 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2010 13:36:17 -0000 Ummm.. Huh? I'm having serious problems parsing this. I *think* you mashing together t= he concept of mime types and plugins with some protection domains and sandb= oxing (which you refer to in terms of processor protection rings). Unless y= ou really are advocating pushing stuff into the kernel.. Anyway, this is all implementation details. How does it relate to the prot= ocol specs? Sorry if this came of grumpy. I don't mean it that way. I seriously don't u= nderstand the point your trying to make. And I have a fair bit of experien= ce with all the related topics. Mike -----Original Message----- From: vwrap-bounces@ietf.org [mailto:vwrap-bounces@ietf.org] On Behalf Of D= zonatas Sol Sent: Wednesday, August 04, 2010 9:15 AM To: Dzonatas Sol; vwrap@ietf.org Subject: [vwrap] xml-org-ietf-vwrap- Re: Working Draft: SNOW-375 I went a step further to bring back a decade old idea off the shelf...=20 to actually implement some of these RFCs in the system other than user=20 land. (Patents expiring... "Win7" probably last major "WNT" edition...=20 XP support extended... DirectX11 is vapor except "Render-Morphium" code=20 ... X11 looks ready for next leap.) I'm going to suggest that IETF VWRAP makes a good foundation to bring=20 XML to the "kernel" level. Those of us that have worked on that idea=20 know that Linux kernel is also kernel modules and subsystems, and that=20 there hasn't really been a reason to implement RING1, so its only been=20 RING0 and RING3. I think those still mean something. This suggestion would simplify shared media, its synchronization, and=20 atomicity. Don't expect it to be framebuffer speed, because that's=20 unidirectional. We can assume shared media is bidirectional, so the=20 concepts of the synchronization are very similar to VWRAP. The critical issue to resolve is that it doesn't need to support general=20 mime types already specified. It could just filter everything out, and=20 we could just start with the mime type noted below. I would like VMS... =20 mainframe environment be aware of this kind of UNIX step and decide if=20 they need a diagnostic mode (RING2/RING0), which they would need to=20 suggest. The shared media may be "reactive". If I hear nothing about it=20 from this, then I'll assume either it wasn't heard or there is no=20 concern, which justifies our time. (I'm not gonna answer leading=20 questions about this.) For backword compatibility, the .NET/Mono wrap around ".exes" make a=20 good model to embed such XML. Then the obvious follow-up is to make an=20 IL.XML more formal, but that is something this group doesn't need to=20 maintain (which was a made obvious business concern.) Thanks for reading, Dzonatas P.S. I was recently reminded Bell Labs still holds interest in a certain=20 nuclear license. Mesh networks is inevitable. Don't blame me for talking=20 about it. Dzonatas Sol wrote: > And one more thing... (yes, I was "listening") > > To expand on Zha's use-cases: > > We should have a "application/xml-org-ietf-vwrap-" prefix for mime types. > > That'll help with transitions, so I think this group already knows=20 > their postfixes. > > > Dzonatas Sol wrote: >> Dzonatas Sol wrote: >>> >>> I don't see how JSON is an improvement from that. >>> >>> --- https://twitter.com/Dzonatas_Sol --- >>> Web Development, Software Engineering, Virtual Reality, Consultant >>> >>> >> >> In fact, JSON's best feature is being able to do the eval(), yet=20 >> those of us that written VMs should already know this. Verification=20 >> killed that feature when they tried to use it in out-of-domain style. >> >> On that note, I suggest to change the VWRAP docs where if people=20 >> request JSON (i.e. "application/json-*" ) that they actually want RSS=20 >> or ATOM styled structures. Instead, only offer RSS or ATOM structured=20 >> JSON (i.e. "application/json-atom" ). If they want more raw than=20 >> that, then it just makes sense to use XML. It's too costly for "us",=20 >> and they don't realize it. >> >> There may be other formats besides RSS or ATOM, so its not a=20 >> moratorium, yet these two are popular solutions already well=20 >> established. I'm sure different audiences are going to quibble, but I=20 >> leave it up to you to decide on support steps to change and how to=20 >> present them. >> > > --=20 --- 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 Aug 4 17:46:51 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067513A6956 for ; Wed, 4 Aug 2010 17:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.165 X-Spam-Level: X-Spam-Status: No, score=-1.165 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urRT33jbGSqZ for ; Wed, 4 Aug 2010 17:46:49 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id A6E2B3A6873 for ; Wed, 4 Aug 2010 17:46:49 -0700 (PDT) Received: by pvd12 with SMTP id 12so2559054pvd.31 for ; Wed, 04 Aug 2010 17:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+QFE2o0ee3VUtl+jrdVPzZHfJC/H92dlMZTZr2JplVE=; b=uxnvABZWnSL2pTp0+BsooMfiKYOMQZ385BZC1OnfIyshyLpYBaauDTZiyQOvWKylqO MqAZBogaIcFNrWVeAAz4JVcGPgPs7ZOiWHqxHxAOv91UXfNnmyVEbEGWbxIRnjeopFr7 4tNGYcawfkB6npgOyZIbA77OOHZ7F0PFX9T5Q= 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=chzf8LZRU2GPpM704/G3G+Kr96K290uNIeOMPcuTrC9ZhbTjCMH2/WxM2xQN/p/0r4 HBqc7ZxHmBQdapGAiOwbSHgewVl21SwWquC6VD7/cLMTN4Y+1DPlISNvcVPTpLNvhDdt +VgNyM+3855wv3Y3EYdsh8FgCUsOB4A9AVClI= Received: by 10.142.171.9 with SMTP id t9mr8412871wfe.320.1280969239670; Wed, 04 Aug 2010 17:47:19 -0700 (PDT) Received: from [192.168.0.50] (adsl-68-124-103-250.dsl.scrm01.pacbell.net [68.124.103.250]) by mx.google.com with ESMTPS id w27sm11176722wfd.17.2010.08.04.17.47.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Aug 2010 17:47:17 -0700 (PDT) Message-ID: <4C5A0D0F.6070900@gmail.com> Date: Wed, 04 Aug 2010 17:59:59 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: "Dickson, Mike (ISS Software)" References: <4C542CAC.1090301@gmail.com> <4C572A6E.8070905@gmail.com> <4C573C43.5060905@gmail.com> <4C58443F.80502@gmail.com> <4C584C52.6040309@gmail.com> <4C5967C6.4080501@gmail.com> <4646639E08F58B42836FAC24C94624DD85E085CDAE@GVW0433EXB.americas.hpqcorp.net> In-Reply-To: <4646639E08F58B42836FAC24C94624DD85E085CDAE@GVW0433EXB.americas.hpqcorp.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "vwrap@ietf.org" Subject: Re: [vwrap] xml-org-ietf-vwrap- Re: Working Draft: SNOW-375 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2010 00:46:51 -0000 Dickson, Mike (ISS Software) wrote: > How does it relate to the protocol specs? > The protocol needs to be aware of springboard functions, which are only used for organizational needs. As functions are implemented in the subsystem and accessible from user land, there has always been an increased chance they'll be used as a standard. A review of the use-cases, we can select a few for AOT mode, and which ones fallback to user land. This then relates the a newer concept of the shell. I'm familiar with the usual outcomes that have tried that and then tried to undo it. Those of us that have done it and have kept it stable over the years or have no need to change it know where we started. Our methods aren't probably different, so there is again another increased chance to rebuild each other. There is no way to simplify synchronization and atomicity in the protocol itself, yet we can, for example, start with a ReSTful way to handle mime-types as resources and stress that the media matches a certain format, XML. From here, the protocol can present itself in timeslices, banked-memory schemes, or micro-kernels. There is also the lockless cache method, yet this method is best for the kernel developers to decide if the subsystem is allowed such technique. I've tested a combination of these schemes already. I cannot release specifics, yet the code is open source. They each add to performance, so there is no best method. I'm not gonna taint the protocol, yet the trust level still amazes me. I would call the work a peacemaker. I'll admit, I showed some professors and it blew their mind when I told them a full stateful system transfer occurred in less than 100 cycles -- but I unloaded immediately after the proof because I knew they couldn't explain what just happened. Earned Highest Honors. I didn't do the hard work, I just added the cache and buffered the events to keep the system responsive. Time skew became more common, and it provided a way to work on it. I optimized it further on context, yet I never published that code. I always kept in mind... should we...with no concept of context... as a subsystem? I just create the pen... -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Wed Aug 4 18:39:12 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2B193A67F4 for ; Wed, 4 Aug 2010 18:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yG0KxhKF1zPL for ; Wed, 4 Aug 2010 18:39:11 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 723663A6784 for ; Wed, 4 Aug 2010 18:39:11 -0700 (PDT) Received: by pxi20 with SMTP id 20so2579830pxi.31 for ; Wed, 04 Aug 2010 18:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=gcnkySfQwtD7eFEvVtEisQBeHrwvdIt5ROVZMxj7rEw=; b=wMnIube9B6D8ADtR7XJfugJFXaKlXM84YVzeCNB87awn95mCW6hIitpNUyzCvjLjtR p+yJu9gwWZFAITpw/nrB4lhzFo405giJykMl+eQeM/WoOLx1KmkWIoaUQlNICZ5OwbBb imm93xaPNyi2ZZqkyZ44fEx87cPK032Z7csZY= 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=j97gHKANiYxmoU2F0oz6eCvFHODD95i8aZmZu2ZQu1SiGwxX/0arbVgsb55Cz1Y2lQ JmFosZRZS2odeSvE2fbkzDmm5qcf5fojivqkKR+X2rpEAyMqyD2tvbmbvbuVLpLw4cVC L85oDbxmBafdX/zze/VkqmINyJJBVkbNb5YDk= Received: by 10.114.113.5 with SMTP id l5mr11699982wac.53.1280972381519; Wed, 04 Aug 2010 18:39:41 -0700 (PDT) Received: from [192.168.0.50] (adsl-68-124-103-250.dsl.scrm01.pacbell.net [68.124.103.250]) by mx.google.com with ESMTPS id d35sm17109186waa.9.2010.08.04.18.39.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Aug 2010 18:39:39 -0700 (PDT) Message-ID: <4C5A1956.8090401@gmail.com> Date: Wed, 04 Aug 2010 18:52:22 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Dzonatas Sol References: <4C542CAC.1090301@gmail.com> <4C572A6E.8070905@gmail.com> <4C573C43.5060905@gmail.com> <4C58443F.80502@gmail.com> <4C584C52.6040309@gmail.com> <4C5967C6.4080501@gmail.com> <4646639E08F58B42836FAC24C94624DD85E085CDAE@GVW0433EXB.americas.hpqcorp.net> <4C5A0D0F.6070900@gmail.com> In-Reply-To: <4C5A0D0F.6070900@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "vwrap@ietf.org" Subject: Re: [vwrap] xml-org-ietf-vwrap- Re: Working Draft: SNOW-375 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2010 01:39:12 -0000 Dzonatas Sol wrote: > > I always kept in mind... should we...with no concept of context... as > a subsystem? I just create the pen... > I almost forgot to mention purpose. Have you noticed on the latest multi-core systems that they have 3D intraconnects? I'm thinking... well the first option is that subsystem mode would be the core underneath... which could do the same to the next one underneath. So an array of 12x12x12 cores could do 2D meshed distribution with with nested execution in parallel. I did mention AOT, so "upwards" would be an exercise for you. Based on QM, I would consider the bottomost core as a crystal-state. "Crystalized" is the atomic saved state I wrote into a VM. That's my own direction... -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Wed Aug 4 19:21:16 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7601E3A6A12 for ; Wed, 4 Aug 2010 19:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPxogmhFFcCW for ; Wed, 4 Aug 2010 19:21:15 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 4AFDF3A6A06 for ; Wed, 4 Aug 2010 19:21:15 -0700 (PDT) Received: by pzk6 with SMTP id 6so2629194pzk.31 for ; Wed, 04 Aug 2010 19:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=eMfOnTg8HXt+6YKjt2dgYvVypd5GOuJCUAMSm0tCPLo=; b=ENEkq3G+niUdGFmPzGQfqkTT+E7QzwjHzIxaq9dJSF/ygXTWdNEQ5n9VKexKirw2OE wOAZdX5dWuY48kjQza9kIHgglrZJJp5//m10UkPIS6RhaNT2gbQJDOAf1RXD7FplgjFL p8xFtocq4W7PG6+ZeON3UYp/P3DI1MGuwRxEY= 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=i2gNmg5T7Ho6OgB5dMgHUH0WSPXre1FL04dR2+8D2U4TNxgFmhZ4k3ldd5MFkjyuG0 BQ4zg38wTYqDd4h1AVh4b91ydgMMjrYklvtxbuvkb8nBXatz3IyeFPNB0LCj5BYhzQjb BcLrlKm5qyS7snJwOACztvMWBvSPMPVh1E3A0= Received: by 10.142.215.7 with SMTP id n7mr8559469wfg.194.1280974905326; Wed, 04 Aug 2010 19:21:45 -0700 (PDT) Received: from [192.168.0.50] (adsl-68-124-103-250.dsl.scrm01.pacbell.net [68.124.103.250]) by mx.google.com with ESMTPS id f2sm11263147wfp.23.2010.08.04.19.21.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Aug 2010 19:21:44 -0700 (PDT) Message-ID: <4C5A2332.4060405@gmail.com> Date: Wed, 04 Aug 2010 19:34:26 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Dzonatas Sol References: <4C542CAC.1090301@gmail.com> <4C572A6E.8070905@gmail.com> <4C573C43.5060905@gmail.com> <4C58443F.80502@gmail.com> <4C584C52.6040309@gmail.com> <4C5967C6.4080501@gmail.com> <4646639E08F58B42836FAC24C94624DD85E085CDAE@GVW0433EXB.americas.hpqcorp.net> <4C5A0D0F.6070900@gmail.com> <4C5A1956.8090401@gmail.com> In-Reply-To: <4C5A1956.8090401@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "vwrap@ietf.org" Subject: Re: [vwrap] xml-org-ietf-vwrap- Re: Working Draft: SNOW-375 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2010 02:21:16 -0000 Dzonatas Sol wrote: > Based on QM, I would consider the bottomost core as a crystal-state. > "Crystalized" is the atomic saved state I wrote into a VM. That's my > own direction... > Another thing before I forget... people want to "spin" the cube to think that would make it do certain calculations faster, yet the problem with that is those calculations are based on O((n_dimensions)*XYZ) style. I reiterate from time to time that it would be faster to just use something similar to pi r square, then it doesn't matter how many dimensions. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Thu Aug 5 04:54:44 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA513A6875 for ; Thu, 5 Aug 2010 04:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U-YTZviXG7T for ; Thu, 5 Aug 2010 04:54:43 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 00F1A3A686B for ; Thu, 5 Aug 2010 04:54:42 -0700 (PDT) Received: by pwj2 with SMTP id 2so35707pwj.31 for ; Thu, 05 Aug 2010 04:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=2O9xmiGkzACxXTFf4v37AhDI+El88dwFuB+loLZeE70=; b=pQkExTY8WkPO5eWSnoLeOQglxh2Yqr9xwnGgaDn6Q98HMoAi3mu9o3O2dJ5LYUh2Yu zvab6I9+Up61rM28YYGNjkcFT+lwX/StGslhDVw+mItZQXaoB6dNAOAX/MEk5DziRctB DLgzsL4HXAnYeaQWSPyIHweT0uIm0mupk4OQo= 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=Rp2NQCiDyoIHFtAxO0NIvLfdCbq0Zxspv+qUqbnZR9Q+XGuTBcE2yk5b9q9763CPxE 4wxgT6x2TVXxuqZ4wy9uEaIZRW8NJZnPNTnlxgzYhROjp99o5l0ha61cqCkS8CqhaRpr A8tWn0Qdf7kU5GzKyR3b9Gkmkp0mXAVm78exY= Received: by 10.142.215.7 with SMTP id n7mr9110179wfg.63.1281009313367; Thu, 05 Aug 2010 04:55:13 -0700 (PDT) Received: from [192.168.0.50] (adsl-68-124-103-250.dsl.scrm01.pacbell.net [68.124.103.250]) by mx.google.com with ESMTPS id w8sm104071wfd.19.2010.08.05.04.55.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Aug 2010 04:55:11 -0700 (PDT) Message-ID: <4C5AA99A.8040800@gmail.com> Date: Thu, 05 Aug 2010 05:07:54 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Dzonatas Sol References: <4C542CAC.1090301@gmail.com> <4C572A6E.8070905@gmail.com> <4C573C43.5060905@gmail.com> <4C58443F.80502@gmail.com> <4C584C52.6040309@gmail.com> <4C5967C6.4080501@gmail.com> <4646639E08F58B42836FAC24C94624DD85E085CDAE@GVW0433EXB.americas.hpqcorp.net> <4C5A0D0F.6070900@gmail.com> <4C5A1956.8090401@gmail.com> <4C5A2332.4060405@gmail.com> In-Reply-To: <4C5A2332.4060405@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "vwrap@ietf.org" Subject: Re: [vwrap] xml-org-ietf-vwrap- Re: Working Draft: SNOW-375 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2010 11:54:44 -0000 I read some news today, and wondered how I can talk about something. One thing lead to another and... I think the terminology "hyperintraconnects" is practical to use in the protocol, which we've had proof for in Proton Exchange Membranes for awhile. I think these patents are not going to expire, yet that doesn't mean we don't like to share. The stock market can't even keep up with the actual that the value is consistently lower than whats used. Any economist can take one look at two different market caps and know the truth. There used to be a concept for bubble memory, yet I think they meant the effect of sublimation effects in the motions of the matter in comparison to paravirtualization in multi-core events. It's easier to understand that way... ..it could be written in kids books. Dzonatas Sol wrote: > Dzonatas Sol wrote: >> Based on QM, I would consider the bottomost core as a crystal-state. >> "Crystalized" is the atomic saved state I wrote into a VM. That's my >> own direction... >> > > Another thing before I forget... people want to "spin" the cube to > think that would make it do certain calculations faster, yet the > problem with that is those calculations are based on > O((n_dimensions)*XYZ) style. I reiterate from time to time that it > would be faster to just use something similar to pi r square, then it > doesn't matter how many dimensions. > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Thu Aug 5 06:11:42 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECEC33A6B15 for ; Thu, 5 Aug 2010 06:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOA2N82iXtQT for ; Thu, 5 Aug 2010 06:11:41 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id F2BF53A6AF6 for ; Thu, 5 Aug 2010 06:11:40 -0700 (PDT) Received: by pzk6 with SMTP id 6so2804934pzk.31 for ; Thu, 05 Aug 2010 06:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=eNj99GA7z40CaqqqBdaZirZ9eVovPanYhyciuB8Em5I=; b=wQGoaz9937GZgd9uxo3LV3Z0lDkq7/gM1lzBxHIgzN+7un46Pw5YCYN/OWdM51rs65 SgL0xXjpOsncrE3M7rRqB9WcClkrU1Hu53qv4Wwbhgnby4MN/pVYjPDXX7eHhlUGI7xF LxLTJB325Wz81RjIfRYad9WzlLRs6D6mYFrbU= 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=jawj01glKRikgrcn53iTACCaMmU7LUxoGCbyOtrfr0WOMQKoiPn2bkF9FgWem/lTC7 Te+diokSSWL/HBaSfNQ4WAcSY2Z65HX31wqnVX8AFpXl1kVzaRKuTGUTVyKpaSqKP/Z0 sjaculNIvS31g6mf6gy58H6FndW23bUrrvTHg= Received: by 10.142.50.19 with SMTP id x19mr9105012wfx.128.1281013931384; Thu, 05 Aug 2010 06:12:11 -0700 (PDT) Received: from [192.168.0.50] (adsl-68-124-103-250.dsl.scrm01.pacbell.net [68.124.103.250]) by mx.google.com with ESMTPS id y16sm186085wff.14.2010.08.05.06.12.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Aug 2010 06:12:10 -0700 (PDT) Message-ID: <4C5ABBA5.6040307@gmail.com> Date: Thu, 05 Aug 2010 06:24:53 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Dzonatas Sol References: <4C542CAC.1090301@gmail.com> <4C572A6E.8070905@gmail.com> <4C573C43.5060905@gmail.com> <4C58443F.80502@gmail.com> <4C584C52.6040309@gmail.com> <4C5967C6.4080501@gmail.com> <4646639E08F58B42836FAC24C94624DD85E085CDAE@GVW0433EXB.americas.hpqcorp.net> <4C5A0D0F.6070900@gmail.com> <4C5A1956.8090401@gmail.com> <4C5A2332.4060405@gmail.com> <4C5AA99A.8040800@gmail.com> In-Reply-To: <4C5AA99A.8040800@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "vwrap@ietf.org" Subject: Re: [vwrap] xml-org-ietf-vwrap- Re: Working Draft: SNOW-375 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2010 13:11:43 -0000 Dzonatas Sol wrote: > ..it could be written in kids books. If you wondering what I am doing here in this mail-list besides Icesphere and VWRAP, then there is overall issue about spam. After I reviewed all the different scheme to secure hosts and different HELO styles, I thought... the answer is right here. Just filter out the general mime types, and there is no need to encapsulate or move to something else besides RFC822. Most likely then the headers could be minimized and the specific ones moves to there own mime-type, and you probably get the general idea. On that note, I also suggested in AWG yesterday a V + USB device. Maybe a mime-type like "application/xml-org-ietf-vwrap-v+usb" just to show it is enabled compared to a V - USB that is similar to a DTD version. Hyperintraconnect that and we've sublimed a step. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Thu Aug 5 13:41:14 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989773A6999 for ; Thu, 5 Aug 2010 13:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.394 X-Spam-Level: X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wARevH9twnSC for ; Thu, 5 Aug 2010 13:41:13 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id B81583A699D for ; Thu, 5 Aug 2010 13:41:13 -0700 (PDT) Received: by pwj2 with SMTP id 2so289043pwj.31 for ; Thu, 05 Aug 2010 13:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=BS/1OUiZ7Kd61y1MiJhoBPMckKIbA6mqbxwHiWDZgYI=; b=tSvRxCGN2HZZaRAr2yCGsYk5VMzqPb0UCmGqbnl5bglCvU8kJov85zpjKUNu5r9aCF wgA+S+4r2mf2AqmsANlxVyl/fWsm6ldNTGtbZlKsEXKnsebagMJvDxIwzZm4dMxV4/ij GbbtJiYe3LiFr106sMz49WHZduQQAIDvJOgj0= 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=pV/hWRttmuY44NSqngDBKTS1ZVKy5ZT3uoVjJ8gKhg8VXYHHNCdlsASvT3TlBpYP5p F7cqXgSyiiUwgTKeGBbyelUhVX7KEq7/Y/gnFw4Tg9TEim/zrQ7Z9lrBf67goAHg5DJm X6/BibSkVFrJ8xsc0B2Yttyg00eXGeWUUmxfU= Received: by 10.142.147.7 with SMTP id u7mr9556477wfd.219.1281040904499; Thu, 05 Aug 2010 13:41:44 -0700 (PDT) Received: from [192.168.0.50] (adsl-68-124-103-250.dsl.scrm01.pacbell.net [68.124.103.250]) by mx.google.com with ESMTPS id v38sm568948wfh.0.2010.08.05.13.41.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Aug 2010 13:41:43 -0700 (PDT) Message-ID: <4C5B2502.5040602@gmail.com> Date: Thu, 05 Aug 2010 13:54:26 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Dzonatas Sol References: <4C542CAC.1090301@gmail.com> <4C572A6E.8070905@gmail.com> <4C573C43.5060905@gmail.com> <4C58443F.80502@gmail.com> <4C584C52.6040309@gmail.com> <4C5967C6.4080501@gmail.com> <4646639E08F58B42836FAC24C94624DD85E085CDAE@GVW0433EXB.americas.hpqcorp.net> <4C5A0D0F.6070900@gmail.com> <4C5A1956.8090401@gmail.com> <4C5A2332.4060405@gmail.com> <4C5AA99A.8040800@gmail.com> <4C5ABBA5.6040307@gmail.com> In-Reply-To: <4C5ABBA5.6040307@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "vwrap@ietf.org" Subject: Re: [vwrap] xml-org-ietf-vwrap- Re: Working Draft: SNOW-375 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2010 20:41:14 -0000 Dzonatas Sol wrote: > Hyperintraconnect that and we've sublimed a step. > > Decade ago the I presented the idea to make .NET a domain supported by whatever means it can. Anotherwords, there is no TLD for .NET, yet bind has always worked the same. I actually never took the time to do an upstream lock to prove the complete model, yet others filled in the gaps. The .NET model also contains forward-looking permission system for for protocol. These domains are atomic ready. They can be part of the subsystem in the 12x12x12 multi-core... or .NET core. Study corporate PEM manufacturers for contacts about the software and hardware for battery systems. I don't think they'll publish a complete model until there is "no-engine" and only what they can distribute it by battery systems and drive system. It's been long-term. Salutations. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Thu Aug 5 17:48:33 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E49623A68BC for ; Thu, 5 Aug 2010 17:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyqPL90OTy0q for ; Thu, 5 Aug 2010 17:48:32 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id C40CF3A6861 for ; Thu, 5 Aug 2010 17:48:32 -0700 (PDT) Received: by pxi20 with SMTP id 20so3088199pxi.31 for ; Thu, 05 Aug 2010 17:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=it/3Ztp/yG5yC+7LG/P94ccTdf25RReT4mUyj62TCNw=; b=e1qL2W3IW6XeJQfYeSR4DAW08BYSI+LQpKQAHgmS0wreZvHzpOwcOeZJiRv4esoz1b xtUd7XuRoA4y1jgLFANCjwRNrmZjmUkd4tIWklqeIOjPATznGgr8SEqjc3iS43H+MQcu eWPspJ2NKDiahshZ30M4E4JG63zrcE1E0IRgU= 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=m1VY5yNNXDIzHjfYSranKjbik/LIeHnBnyGSKnY+j0wehyEAqllteNg6wuo4JIenOl 7RvF2PQb53GWKiiSOIC39eYgzFMXlgqTLKbTeqzbnNAU+ZmS4w8BRUtlLmEfx0GgOwv3 qtUv/7uQag6du1KJDEnmLSJAZyNlThZYkCKng= Received: by 10.142.12.16 with SMTP id 16mr1723478wfl.187.1281055743573; Thu, 05 Aug 2010 17:49:03 -0700 (PDT) Received: from [192.168.0.50] (adsl-68-124-103-250.dsl.scrm01.pacbell.net [68.124.103.250]) by mx.google.com with ESMTPS id v38sm750773wfh.12.2010.08.05.17.49.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Aug 2010 17:49:02 -0700 (PDT) Message-ID: <4C5B5EFA.8070704@gmail.com> Date: Thu, 05 Aug 2010 18:01:46 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Dzonatas Sol References: <4C542CAC.1090301@gmail.com> <4C572A6E.8070905@gmail.com> <4C573C43.5060905@gmail.com> <4C58443F.80502@gmail.com> <4C584C52.6040309@gmail.com> <4C5967C6.4080501@gmail.com> <4646639E08F58B42836FAC24C94624DD85E085CDAE@GVW0433EXB.americas.hpqcorp.net> <4C5A0D0F.6070900@gmail.com> <4C5A1956.8090401@gmail.com> <4C5A2332.4060405@gmail.com> <4C5AA99A.8040800@gmail.com> <4C5ABBA5.6040307@gmail.com> <4C5B2502.5040602@gmail.com> In-Reply-To: <4C5B2502.5040602@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "vwrap@ietf.org" Subject: Re: [vwrap] xml-org-ietf-vwrap- Re: Working Draft: SNOW-375 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2010 00:48:34 -0000 Dzonatas Sol wrote: > Salutations. > Something was asked of me by PC... gotta put a face on it. P.S. I hope his daughter makes President. =) -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Fri Aug 6 08:51:52 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29EC928C0F5 for ; Fri, 6 Aug 2010 08:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.292 X-Spam-Level: X-Spam-Status: No, score=-1.292 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WenwHw+gpe04 for ; Fri, 6 Aug 2010 08:51:51 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 0982E28C0F4 for ; Fri, 6 Aug 2010 08:51:51 -0700 (PDT) Received: by pvg7 with SMTP id 7so51872pvg.31 for ; Fri, 06 Aug 2010 08:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=tddHMM8UAf3rfNwgfDn+ChYwtIPJ206Q1ym+WAL7fOE=; b=ce5unJA3lBGXO4Ntf0vmAOEbeM2zWZsKl6MjtK59wdDLYKc4/MaHEwLEFpGSRM90PT cgnh7vYcA807vnx/3X8kfn2rf3gPQZT36eMqOCw6lD9Xs4xSciYr2wIk10F5vKJbcqVn +k8AlUksbhl/joY7zwITOQ5at3mOL32g1nLMI= 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=AP10GRrZInhl5uiO7igBeI6tDQXI/SofX5rZyKo+38tQ2RUBByMgH0B2G2QdHxYyo8 Dl96IdjAnGgcebrgkmaATxT924Qka3Y1Kr3yHZjxxH2M1dSz342hQ1Y9q7yyYMk12k0b Gl1jMylkQcY+KxH896KP3w/Hy2knZzdByKNAU= Received: by 10.142.169.12 with SMTP id r12mr10533035wfe.38.1281109940429; Fri, 06 Aug 2010 08:52:20 -0700 (PDT) Received: from [192.168.0.50] (adsl-68-124-103-250.dsl.scrm01.pacbell.net [68.124.103.250]) by mx.google.com with ESMTPS id c13sm924036wfh.23.2010.08.06.08.52.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 06 Aug 2010 08:52:19 -0700 (PDT) Message-ID: <4C5C32B0.20100@gmail.com> Date: Fri, 06 Aug 2010 09:05:04 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: "vwrap@ietf.org" References: <4C542CAC.1090301@gmail.com> <4C572A6E.8070905@gmail.com> <4C573C43.5060905@gmail.com> <4C58443F.80502@gmail.com> <4C584C52.6040309@gmail.com> <4C5967C6.4080501@gmail.com> <4646639E08F58B42836FAC24C94624DD85E085CDAE@GVW0433EXB.americas.hpqcorp.net> <4C5A0D0F.6070900@gmail.com> <4C5A1956.8090401@gmail.com> <4C5A2332.4060405@gmail.com> <4C5AA99A.8040800@gmail.com> <4C5ABBA5.6040307@gmail.com> <4C5B2502.5040602@gmail.com> <4C5B5EFA.8070704@gmail.com> In-Reply-To: <4C5B5EFA.8070704@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [vwrap] Post-Mortem Re: xml-org-ietf-vwrap- Re: Working Draft: SNOW-375 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2010 15:51:52 -0000 Dzonatas Sol wrote: > > Something was asked of me by PC... > "Today Congress took an important step [up] ensuring that teachers stay in the classroom and cash-strapped states get the relief they need." -- Barack Obama [Fixt.] https://twitter.com/BarackObama/status/20335558327 'We are going to rebuild this economy [easier] than before, and at the heart of it are going to be three powerful words: "Made in America."' -- Barack Obama [Fixt.] https://twitter.com/BarackObama/status/20337776197 "To the naysayers in Washington who said walk away from the [engine] industry, my message to them is this: Don’t bet against the American worker." -- Barack Obama [Corrected.] https://twitter.com/BarackObama/status/20407571308 -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Mon Aug 9 11:05:56 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 076A83A67A2 for ; Mon, 9 Aug 2010 11:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZfTEEsQAV8X for ; Mon, 9 Aug 2010 11:05:54 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id AB57D3A6B11 for ; Mon, 9 Aug 2010 11:05:54 -0700 (PDT) Received: by pzk6 with SMTP id 6so4401722pzk.31 for ; Mon, 09 Aug 2010 11:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=hyzcw+AlLulTmVXaCsB8oET0JCktGP4zuCg+926tWrs=; b=tAFHUyNMmzFliEb5C5iHykjlFlo8scVPQNoBqLSZyvDJsN6zi24oeFg895TaIGzuwk leFfUO7kEZPjePwh9O5wAh5qxy0SJHx0U9kPkD16bkJcitckutN2ef/she4w9jf7HyUI 0PHlL3Dv/fh+w1raq8wuTVYsU9cTucaZ9v6So= 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=KnXDpgg5PvPlpccSTpVq+3IpEWx4TaJL0RGy6aUi94B8jjKACAgeOeTl9BqL2/pb2K F7hbkEzpanWRILvvBTS7TkqZX6stmq47i04EJfPxnYoL3KSq9gxTDh7+XHr6nuBm1yPX YrzRH2X3lJSyWmxAfLoACYWWg0/oc+bSUoI7Y= Received: by 10.114.66.5 with SMTP id o5mr18902435waa.219.1281377187946; Mon, 09 Aug 2010 11:06:27 -0700 (PDT) Received: from [192.168.0.50] ([68.121.61.75]) by mx.google.com with ESMTPS id c10sm10838365wam.13.2010.08.09.11.06.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Aug 2010 11:06:26 -0700 (PDT) Message-ID: <4C6046A3.1080303@gmail.com> Date: Mon, 09 Aug 2010 11:19:15 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: "Dickson, Mike (ISS Software)" , "vwrap@ietf.org" , Joshua Bell , Barry Leiba , PRESIDENT@WHITEHOUSE.GOV, wh.obama@gmail.com, mime-to-others-undisclosed@your-own-free.will References: <4C542CAC.1090301@gmail.com> <4C572A6E.8070905@gmail.com> <4C573C43.5060905@gmail.com> <4C58443F.80502@gmail.com> <4C584C52.6040309@gmail.com> <4C5967C6.4080501@gmail.com> <4646639E08F58B42836FAC24C94624DD85E085CDAE@GVW0433EXB.americas.hpqcorp.net> <4C5A0D0F.6070900@gmail.com> <4C5A1956.8090401@gmail.com> <4C5A2332.4060405@gmail.com> <4C5AA99A.8040800@gmail.com> <4C5ABBA5.6040307@gmail.com> <4C5B2502.5040602@gmail.com> <4C5B5EFA.8070704@gmail.com> In-Reply-To: <4C5B5EFA.8070704@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] xml-org-ietf-vwrap- Re: Working Draft: SNOW-375 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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 Aug 2010 18:05:56 -0000 Dzonatas Sol wrote: > > P.S. I hope his daughter makes President. =) > One thing people on this list didn't understand about the purpose or reason of my posts is... "for the kids." For some reason they wanted to professionalize it without kids in mind, which is actually unprofessional. Yesterday, I know of someone's birthday... that's been missing from my life. I think about "THIS" all the time... ---- mime:posted-to-opensource-dev ---- Your request to the opensource-dev mailing list Posting of your message titled "Re: [opensource-dev] Fixing the Assets" has been rejected by the list moderator. The moderator gave the following reason for rejecting your request: "Your message is not relevant to the topic of this list, and has been rejected." Any questions or comments should be directed to the list administrator at: opensource-dev-owner@lists.secondlife.com ---- mime:posted-to-opensource-as-part-of-thread ---- Indeed. That's why the legal courtsystems have to completely reveal themselves as religions.... now! More specifically... the "judges"... "... duh!" P.S. "Impersonators?" *ahem* Next... ---- mime:posted-to-opensource-as-part-of-thread-in-reply-to ---- Fractured Crystal wrote: Drugs are bad. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From sllists@boroon.dasgupta.ch Tue Aug 17 07:30:44 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7E063A699C for ; Tue, 17 Aug 2010 07:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.427 X-Spam-Level: X-Spam-Status: No, score=0.427 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVgFkycPtbD4 for ; Tue, 17 Aug 2010 07:30:43 -0700 (PDT) Received: from datendelphin.net (india288.server4you.de [85.25.150.202]) by core3.amsl.com (Postfix) with ESMTP id 20D0D3A6988 for ; Tue, 17 Aug 2010 07:30:41 -0700 (PDT) Received: from [192.168.1.66] (adsl-62-167-136-12.adslplus.ch [62.167.136.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by datendelphin.net (Postfix) with ESMTPSA id 2B3622E006; Tue, 17 Aug 2010 16:31:51 +0200 (CEST) Message-ID: <4C6A9D2D.2090801@boroon.dasgupta.ch> Date: Tue, 17 Aug 2010 16:31:09 +0200 From: Boroondas Gupte User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) Gecko/20100729 Lightning/1.0b2pre Thunderbird/3.1.1 MIME-Version: 1.0 To: Second Life User Experience Mailing List References: <4C69BE39.1090106@fishkill.ibm.com> <201008170924.50215.Lance.Corrimal@eregion.de> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000404070209070605070602" Cc: vwrap@ietf.org, Second Life Open Source Development Mailing List Subject: [vwrap] [IDEA] Access to Object content without rezzing. (was: [opensource-dev] Open Viewer Development Announcement) X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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, 17 Aug 2010 14:30:44 -0000 This is a multi-part message in MIME format. --------------000404070209070605070602 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [I'm cross posting this to several mailing lists to solicit feedback. To avoid clutter, please *do not reply to all of them* when answering, unless there's a valid reason to do so. To avoid scattering the discussion, please *do reply to sl-ux@lists.secondlife.com * when answering. Thanks!] On 08/17/2010 01:52 PM, mysticaldemina@xrgrid.com wrote : > [...] V1.23 as well, makes designing take much > longer than it should. Like having to rezz objects to edit their contents. > Ever have to rezz hundreds of boxes to update something? Or correct the > permissions. Have to rezz a box to get to its contents I think is one of > the most difficult things for new people. Having to rezz objects to get to > stuff, then copy to inventory, then find it in inventory, etc. I have made a suggestion on how to solve this UI-wise at VWR-2427 Allow objects containing other items to be expanded within the Inventory . I'd like to hear about other approaches, too! The main problem when coming up with complete solution for these use cases is, though, that they'll probably require some fundamental changes on the (non-opensource) server side: As far as I know, currently, Object Inventory is served by the Region, and the Region only knows about rezzed Objects. So either a way would have to be added for the Region to proxy non-rezzed Objects to the client or clients would have to be granted direct (or other indirect) access to the asset storage system. I think the same goes for the Object assets themselves, so these restrictions not only apply to manipulating an Object's content, but also to editing the Object itself without rezzing it (e.g. changing it's size, shape or color). I don't know if the AD /RD separation of OGP/AWG/VWRAP will help here, thus CCing their mailing list. Maybe someone from there can shed some light on this. cheers Boroondas --------------000404070209070605070602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [I'm cross posting this to several mailing lists to solicit feedback. To avoid clutter, please do not reply to all of them when answering, unless there's a valid reason to do so. To avoid scattering the discussion, please do reply to sl-ux@lists.secondlife.com when answering. Thanks!]

On 08/17/2010 01:52 PM, mysticaldemina@xrgrid.com wrote: 
[...] V1.23 as well, makes designing take much
longer than it should.  Like having to rezz objects to edit their contents.
Ever have to rezz hundreds of boxes to update something? Or correct the
permissions.  Have to rezz a box to get to its contents I think is one of
the most difficult things for new people.  Having to rezz objects to get to
stuff, then copy to inventory, then find it in inventory, etc.
I have made a suggestion on how to solve this UI-wise at VWR-2427 Allow objects containing other items to be expanded within the Inventory. I'd like to hear about other approaches, too!

The main problem when coming up with complete solution for these use cases is, though, that they'll probably require some fundamental changes on the (non-opensource) server side:

As far as I know, currently, Object Inventory is served by the Region, and the Region only knows about rezzed Objects. So either a way would have to be added for the Region to proxy non-rezzed Objects to the client or clients would have to be granted direct (or other indirect) access to the asset storage system.

I think the same goes for the Object assets themselves, so these restrictions not only apply to manipulating an Object's content, but also to editing the Object itself without rezzing it (e.g. changing it's size, shape or color).

I don't know if the AD/RD separation of OGP/AWG/VWRAP will help here, thus CCing their mailing list. Maybe someone from there can shed some light on this.

cheers
Boroondas
--------------000404070209070605070602-- From john.hurliman@intel.com Mon Aug 30 12:38:40 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006653A69E4 for ; Mon, 30 Aug 2010 12:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+uLN6j+vppZ for ; Mon, 30 Aug 2010 12:38:36 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by core3.amsl.com (Postfix) with ESMTP id 8EA1C3A696B for ; Mon, 30 Aug 2010 12:38:36 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 30 Aug 2010 12:39:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.56,294,1280732400"; d="scan'208";a="601957333" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by fmsmga002.fm.intel.com with ESMTP; 30 Aug 2010 12:39:05 -0700 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx604.amr.corp.intel.com ([10.31.0.170]) with mapi; Mon, 30 Aug 2010 13:39:05 -0600 From: "Hurliman, John" To: "opensim-dev@lists.berlios.de" Date: Mon, 30 Aug 2010 13:39:01 -0600 Thread-Topic: [Opensim-dev] Global identifiers Thread-Index: ActIYUCzUlzRvVfgR6WanAOtocx3UAAEmjaA Message-ID: <62BFE5680C037E4DA0B0A08946C0933D012641677A@rrsmsx506.amr.corp.intel.com> References: <4c7ad44d.5f25e30a.782a.0516@mx.google.com>, <1283121840.13484.119.camel@mdickson-linux>, <4C7AE587.30102@t-data.com>, <1283125132.13484.126.camel@mdickson-linux>, <4C7AF48B.3010202@metaverseink.com>, <1283127395.13484.137.camel@mdickson-linux>, <4C7AFB77.907@metaverseink.com>, , <4C7B1E96.5030309@metaverseink.com> <4C7BA1A8.5070102@t-data.com> <4C7BDD91.9070100@metaverseink.com> In-Reply-To: <4C7BDD91.9070100@metaverseink.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "vwrap@ietf.org" Subject: Re: [vwrap] [Opensim-dev] Global identifiers X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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, 30 Aug 2010 19:38:40 -0000 I'd like to throw in my two cents to this discussion as the Virtual Worlds = Infrastructure team at Intel has spent some time thinking about this issue,= presenting on it at IETF-77, and trying to prototype something that actual= ly works (not an easy feat!). Let me preface by saying that while compatibility with the Linden viewer ma= y be a short term benefit, ultimately it is not relevant to the discussion.= Whatever method we decide on will be made to work with current and future = viewers through any means it takes, which might be another layer of viewer = compatibility abstraction sitting on top of our "clean" model or it might j= ust work naturally with whatever we use. The question of internally storing local identifiers or global identifiers = is primarily an optimization question in my mind. We already have a great s= ystem in OpenSim for storing account metadata, referencing it, requesting i= t, caching it, etc. This is an optimized system that I know we've spent a l= ot of time on because I've personally submitted and received patches that a= llowed it to deal with the load of identifying the permissions for 15,000+ = objects in a scene created and owned by dozens of different avatars and gro= ups. If we can leverage this existing system we'll be a long ways ahead on = building something that will scale to millions of independent grids. The wo= rk on OpenSim Archives (OARs), Inventory Archives (IARs), and HyperGrid hav= e already paved most of the way on how we can do this. Any time a new ident= ity is recognized by a grid whether it be an incoming HG teleport, an OAR l= oad, a prim being rezzed from a foreign grid with an unrecognized creator, = or any other means, you create a local identity that points to the global i= dentifier. This is the only time when you can guarantee the global identifi= er will resolve and foreign account details can be fetched. With this extra= bit of work up front, we can leverage the current identity system we have = with very little effort. Extra icing on the cake can be added like periodic= ally attempting to pull the latest account info into the local accounts or = improving the profile display for identities with a foreign origin to link = to their home grid or home identity for example, but the difficult part of = the problem has already been solved. No rewriting APIs to handle a second t= ype of account identifier, no dealing with the question of whether a global= identifier will currently resolve or not, no additional abstraction layer = to make things play nicely with the current protocols. Prims will show thei= r creator names 100% of the time and it will use the same caching systems a= nd optimizations that make local accounts work. An open question with this approach is whether you need to use global ident= ifiers when dealing with cross-grid scenarios, or whether there is always e= nough context to derive a global identifier. Some examples: * A HyperGrid user is teleporting from grid A to grid B. Does grid B have e= nough information to build the global identifier "gridA/user"? * A HyperGrid user rezzes an object into grid B that exists in their invent= ory on grid A. The object has a creator that is unrecognized to grid B. Sho= uld grid B pull the creator profile from grid A (which may actually be stor= ing a local copy of the real creator identity from grid X)? Note that this = isn't a question about trust because we're already trusting grid A to provi= de creator information for the object, it's just about where we pull profil= e info from. * An OAR file is loaded and contains an unrecognized identity. Should ident= ities in OAR files be encoded as global identifiers, or a header added to t= he OAR file to say "all of this content came from grid A", or the full prof= iles of all the identities in the OAR embedded right into the archive? P.S. I'm CCing this to the VWRAP list as the participants there will be int= erested in how these architecture decisions are progressing in OpenSim, and= may be able to lend more insight to the discussion. -John > -----Original Message----- > From: opensim-dev-bounces@lists.berlios.de [mailto:opensim-dev- > bounces@lists.berlios.de] On Behalf Of diva@metaverseink.com > Sent: Monday, August 30, 2010 9:34 AM > To: opensim-dev@lists.berlios.de > Subject: Re: [Opensim-dev] Global identifiers > > Let me throw another thought into this. It is related to the subtle > differences of URLs and URNs, and Bob Wellman's suggestion. > > So far we are more or less converging to > protocol://authority/resource_type/resource_id[/cacheable_info] > with the [/cacheable_info] sill up for discussion. Independent on how > you break this down in persistent storage, this is an URL, and one with > specific assumptions about the existence of a resource_id. > > However, in the future we would like to interoperate with systems that > aren't virtual worlds as such. In most of those systems, the resources > are named with names that may not even be URLs and even if they are, > they may not have "resource_id" at all. For example, > > Cristiano Ronaldo's Facebook handle is > http://www.facebook.com/Cristiano > > A Collada model has > John.Smith > (Wondering how Linden Lab is going to deal with this... ) > > > So this would not comply with the form above. > > Now, in practice, we have been designing under a fixed-point: the LL > viewer. The LL viewer MUST have UUIDs for every resource that is sent > from the server the client. So, in practice what this means is that > every external resource reference must be assigned a local UUID if it > doesn't come with one, which sounds like a very reasonable thing to do, > and some people here already mentioned it. > > Nevertheless, the Collada example breaks the assumption that every > named > resource out there has an authority (locator) that we can refer back > to. > It may not. We can continue down the road of fixing missing information > with default information. So, for example, if something comes in as > John.Smith, our reference to it could be > http://ourgrid/user/some_uuid/John+Smith -- even though there is no > such > account. But that's a slippery slope. > > This further supports the argument of having a table that maps between > local UUIDs and external references. And maybe external references may > take more than just one URI form, not just the one we have been talking > about > protocol://authority/resource_type/resource_id[/cacheable_info] > > Maybe it can also be a URN. > > Nevertheless, the semantics is important, because when an authority > (locator) is present, the receiving grid may want to invoke it. > > > > Melanie wrote: > > While you have a case with using a central table, rather than > > storing the URL string, and therefore the name, all over the place, > > your request schema would not work. > > > > First off, it overcomplicates (IMO) things if you even attempt to > > show the current name of an identity. My plan has been to show the > > name AT CREATION TIME on a prim, e.g. the displyed creator name of a > > prim will not change, even if the underlying identity changes their > > name. This removes much complaxity. > > > > Second, your system breaks when a prim is taken to a new grid after > > the grid it was created on has vanished from the internet. In that > > case, even the initial lookup will fail and you have no data to > display. > > > > Therefore, I'd prefer to go with my initial recommendation and > > indeed store the URL, including the name, "all over the place". The > > client view can always decide to ignore that part and to a table > > lookup, or even contact the grid of origin. > > > > It seems that a lot of people here are all for omitting information > > that would be helpful for the 90% case in order to make their > > particular corner case the norm. 90% of avatars never change names. > > > > Melanie > > > > Bob Wellman wrote: > >> Can I subvert this discussion back to the original question of > Global Identifiers? > >> > >> > >> > >> I have been following the discussion on Global Identifiers with > interest and I see strong differences of opinion but merits in both > arguments. I agree that hard coding meaning into the URI seems like an > inflexible way forward but I also see that minimising lookup traffic > between grids is desirable too. So I have been trying to think is there > a middle way to compromise on this. I have the kernel of an idea I > would like to put forward for discussion. > >> > >> Let us say we invent a new table in the local grids database (called > UserLookup maybe) and the key to that table is the URI diva proposed > (without the user name part) sent intially. Sorry Melanie but please > read on before deciding. > >> > >> Draft table design here: > >> > >> 1) Original URI (key) > >> 2) Original User name > >> 3) Last verification date. > >> 4) Current user name > >> 5) Current URI (optional idea see later) > >> > >> When the original URI is received (or later referenced) we do a > check against this table to see if a lookup is available and proceed as > follows: > >> 1) If the lookup is not on file... we immediately send to the other > grid for verification and the user name and we add the lookup to the > table with original user name and current user name the same. > >> 2) If the lookup is on file but out of date ... we send to the other > grid for verification (this can be dleayed if need be) and take the > latest feedback of user name and update the lookup with current name. > >> 3) If the lookup is on file but not out of date (most times this > will be the case) ... we do nothing. > >> > >> What constitutes out of date will be configurable in Opensim.ini > (out-of-date=3D x days). In Melanie's case she will set forever as > avatars must not be changeable. For others this can be tailored to > their requirements of speed versus flexibility. > >> > >> The user service already looks up the Prims user UUID to decode the > name for local avatars so it just would be changed to do this new > lookup at the same time. I think of it this way ...The user service > currently answer the question "who is this" and would now answer "who > in the global community is this". > >> > >> This method keeps the database design 3rd normal form rather than > storing key decodes all over the database, as to not do this will at > some stage cause database chaos just like it did in appearance sometime > ago. Can you tell I have a database design background...LOL > >> > >> If a grid goes bust or is temporary offline we have the last know > user info to rely on using just local grid lookup, which covers the > very valid argument Melanie made that we need to know identity even if > the other grids no longer there. > >> > >> We can also have the ability to recognise that verification has not > been available for a long time so cross grid IM is probably no longer > available to this agent. In the case of an avatar moving grid maybe > the forwarding address can be sent back and the current URI stored (the > fifth column) at the next look up verification. If the forwarding > doesnt ecist or is only temporary, it does matter, as we have last > known address stored at our grid, which is the best thats possible. > Maintaining an IM link of freindship to an agent that moves grids > becomes feasible too. So this keeps things flexible for those that > think this is the correct approach long term. > >> > >> In summary this method reduces the need for massive cross grid > lookups and still keeps the link between the URI and the user name > flexible. > >> > >> Just my opinion (and I expect to be overruled) but felt I should say > this anyway if only to purge my guilt of saying nothing just to avoid a > slap down ...LOL > >> > >> Thanks for reading it.. Bob Wellman (PMgrid) > >> > >> > >> > >>> Date: Sun, 29 Aug 2010 19:59:34 -0700 > >>> From: diva@metaverseink.com > >>> To: opensim-dev@lists.berlios.de > >>> Subject: Re: [Opensim-dev] Global identifiers > >>> > >>> See my previous email about what changed. > >>> > >>> We seem to have quite different concepts of what a standards > process is. > >>> In my book, a standards process is something that happens *after* > >>> implementations exist, and preferably several competing ones; in > the > >>> people in VWRAP's book, it seems to mean "let's design something > >>> together from scratch and on paper". > >>> > >>> Let's see how well these two concepts can co-exist. Maybe they > can't! > >>> > >>> Meadhbh Hamrick wrote: > >>>> what's changed? > >>>> > >>>> last year you (diva) seemed to have no interest in merging VWRAP > with > >>>> Hypergrid. if i remember correctly, hypergrid was going to go off > and > >>>> do an implementation while VWRAP went another way to try to > >>>> incrementally build a standard and some code to implement it. > >>>> > >>>> there's still, of course, room for you at the table. but if i > remember > >>>> correctly, you seemed to have problems with LLSD/LLIDL (now about > to > >>>> get renamed DSD) and you had a security model that didn't work > with > >>>> zha's use cases. > >>>> > >>>> if you're interested in making the case for why VWRAP should adopt > the > >>>> hypergrid security model and drop DSD, you're welcome to > participate > >>>> in the VWRAP mailing list. > >>>> > >>>> and i encourage you to actually do so before dropping a spec on > the group. > >>>> > >>>> -cheers > >>>> -meadhbh > >>>> > >>>> -- > >>>> meadhbh hamrick * it's pronounced "maeve" > >>>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > >>>> > >>>> > >>>> > >>>> On Sun, Aug 29, 2010 at 5:29 PM, wrote: > >>>>> Melanie is just right, as usual... well, as in 90% of the time :) > >>>>> The cacheable_data was a brilliant idea, and if you had > experience with > >>>>> OpenSim in the wild, in how volatile these worlds are and how > much these > >>>>> particular remote lookups lag the sims, you would come to > appreciate it, > >>>>> instead of being put off by her dominatrix attitude. > >>>>> > >>>>> OpenSim core has been contributing center-front in VWRAP: John > Hurliman is a > >>>>> core developer of OpenSim. > >>>>> > >>>>> Mike Dickson wrote: > >>>>>> That's great to hear. And the first I've heard of it. I'm on the > VWRAP > >>>>>> mailing list and yes, John has made some very substantive > contributions > >>>>>> to the discussion. I haven't seen anything from OpenSim core > during any > >>>>>> part of the discussion to date. I'm a pretty smart guy but not > >>>>>> omnipotent. I've simply interpreted the lack of participation as > lack > >>>>>> of interest and past comments would tend to support that (I can > dig them > >>>>>> out if you like). And there is no "general feeling" in VWRAP as > to your > >>>>>> proposal since its never been presented or discussed there. > >>>>>> > >>>>>> I'm not interested in a war, just open dialog and a sincere > interest in > >>>>>> interoperability. I'll be glad to read the proposal when its > made. In > >>>>>> the meantime I'd appreciate you not attribute negative motives > to > >>>>>> anything I've said. I've been simply trying to make technical > arguments > >>>>>> against an approach I think is wrong headed and not though out. > I've > >>>>>> seen discussion here pretty much get cut off when a core member > >>>>>> "dictates" the solution. Melanie seems to have made up her mind. > Fine. > >>>>>> Go build it. Best of luck to you. In the meantime I'll look > forward to > >>>>>> the Hypergrid proposal to VWRAP and reserve my comments for that > time. > >>>>>> BTW, I've found the VWRAP discussions to be pretty open and > devoid of > >>>>>> politics. People will assert politics over almost anything of > course > >>>>>> but the dialog has been mostly open and good natured (and quiet > lately). > >>>>>> It will be good to have you at the table. Given OpenSim gets a > fair bit > >>>>>> of attention it would have been nice if you'd been there all > along. > >>>>>> > >>>>>> Mike > >>>>>> > >>>>>> On Mon, 2010-08-30 at 00:00 +0000, diva@metaverseink.com wrote: > >>>>>>> Mike, > >>>>>>> > >>>>>>> That's an interesting statement to make, considering that John > Hurliman > >>>>>>> and I are working on writing up the *working* Hypergrid 1.5 as > a proposal to > >>>>>>> VWRAP, since we have both concluded that the concepts being > talked there > >>>>>>> lately, without any implementation behind them, are essentially > >>>>>>> indistinguishable from the working HG 1.5 that lots of people > are already > >>>>>>> using. > >>>>>>> > >>>>>>> It seems that you are trying really hard to make this look like > a war > >>>>>>> between OpenSimulator and VWRAP. I don't think that's the > general feeling in > >>>>>>> VWRAP, I think it's just you. The proposal to VWRAP will > happen. Hopefully, > >>>>>>> most people there will be able to assess the technical issues, > independent > >>>>>>> of the political ones. (emphasis on *hopefully*) > >>>>>>> > >>>>>>> Diva / Crista > >>>>>>> > >>>>>>> Mike Dickson wrote: > >>>>>>>> Fine, then do what you like. The code's all available. If I > don't like > >>>>>>>> it I can change it. Of course that sort of shoots holes in > >>>>>>>> interoperability. But then I didn't feel that hyper-grid > belonged in > >>>>>>>> core either for the same reason. > >>>>>>>> I think you've way over trivialized the whole set of > interactions > >>>>>>>> between agent, asset and simulator services in situations > where those > >>>>>>>> services are defined by different principals. As Meadbh said, > this > >>>>>>>> feels like optimizing to solve a specific problem before > you've really > >>>>>>>> looked at the larger issues. It might be instructive just to > simply walk > >>>>>>>> through some use cases and see where things fall apart. Alot > of that > >>>>>>>> discussion has already taken place on the VWRAP list but > OpenSim core > >>>>>>>> seems to be dead set against involvement in that. > >>>>>>>> > >>>>>>>> I don't see a way to contribute here beyond the opinion I've > already > >>>>>>>> voiced so I'll drop this. > >>>>>>>> > >>>>>>>> Mike > >>>>>>>> > >>>>>>>> On Sun, 2010-08-29 at 22:56 +0000, Melanie wrote: > >>>>>>>>> Sorry, i disagree. The information included is defined by the > >>>>>>>>> REQUIRED data on the recipient, not on what data the sender > wants to > >>>>>>>>> provide. the recipient NEEDS a displayable field. It can't be > optional. > >>>>>>>>> > >>>>>>>>> Melanie > >>>>>>>>> > >>>>>>>>> Mike Dickson wrote: > >>>>>>>>>> If the decision is to go ahead and do cache-able data then > I'd agree, > >>>>>>>>>> do > >>>>>>>>>> it as attribute NVP's and make them optional. The > originating agennt > >>>>>>>>>> service is then free to define the semantics of the > attributes it > >>>>>>>>>> exposes. > >>>>>>>>>> Mike > >>>>>>>>>> > >>>>>>>>>> On Sun, 2010-08-29 at 21:42 +0000, Ai Austin wrote: > >>>>>>>>>>>> From: diva@metaverseink.com > >>>>>>>>>>>> > protocol://authority/resource_type/resource_id[/cacheable_data] > >>>>>>>>>>> +1 > >>>>>>>>>>> > >>>>>>>>>>> consider ensuring that at least the name is provided in a > form that > >>>>>>>>>>> can be resolved fast and locally by including the avatar > firstname+lastname > >>>>>>>>>>> - in whatever form the providing grid wishes to address > issues raised by > >>>>>>>>>>> others - so long as the strings are "legal" in the > creator/owner fields. > >>>>>>>>>>> > >>>>>>>>>>> would it be worth making sure that the "cachable data" is > in the form > >>>>>>>>>>> of keyword=3Dvalue pairs, and hence put in a "parameter" form > after ? rather > >>>>>>>>>>> than a final /? > >>>>>>>>>>> > >>>>>>>>>>> > protocol://authority/resource_type/resource_id[?key_value_pair[,...]] > >>>>>>>>>>> > >>>>>>>>>>> with a minimum suggested (or required?) > >>>>>>>>>>> avatarname=3Dfirstname+lastname if the resource_type =3D user > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> Opensim-dev mailing list > >>>>>>>>>>> Opensim-dev@lists.berlios.de > >>>>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Opensim-dev mailing list > >>>>>>>>>> Opensim-dev@lists.berlios.de > >>>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Opensim-dev mailing list > >>>>>>>>> Opensim-dev@lists.berlios.de > >>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>>>>>>> _______________________________________________ > >>>>>>>> Opensim-dev mailing list > >>>>>>>> Opensim-dev@lists.berlios.de > >>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Opensim-dev mailing list > >>>>>>> Opensim-dev@lists.berlios.de > >>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>>>> _______________________________________________ > >>>>> Opensim-dev mailing list > >>>>> Opensim-dev@lists.berlios.de > >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>>>> > >>> _______________________________________________ > >>> Opensim-dev mailing list > >>> Opensim-dev@lists.berlios.de > >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > >> > >> > >> -------------------------------------------------------------------- > ---- > >> > >> _______________________________________________ > >> Opensim-dev mailing list > >> Opensim-dev@lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev@lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From ohmeadhbh@gmail.com Mon Aug 30 13:33:19 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D69B3A6A26 for ; Mon, 30 Aug 2010 13:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3vrNbb+CZpp for ; Mon, 30 Aug 2010 13:32:07 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 3EA1A3A6876 for ; Mon, 30 Aug 2010 13:31:27 -0700 (PDT) Received: by ewy22 with SMTP id 22so3734838ewy.31 for ; Mon, 30 Aug 2010 13:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=icIDLT56xzW6iemX32+vabDLDxHKu+p2hOhnFNCrEhQ=; b=kU/mA1dNc1yoarzBJcLz/SGhkh1e+BeI5LLnN77kQxX3l7tsgHXWl8PyQuGGcCeu+i CWEu8wm9yjWcFt91ldsh3DTX4mG8HkFlEgZTJE/iMzojxb6ZBnZw01qJxn366KKQ7Kqp Z5BEy3xp8vUzesnNuKFeUD0YLzN7k4b7o9MHg= 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=sg9xEpsFd/cYrYwW4jDbQXk0wa4sM+jO0Ro4Yn0EgrxIYhOqRpOyMbw30RCBY0uY3p PAdMVfe6ss3ogjSoCtBqyAmDBsZj5CsvVINfmIrZM2QzFSClaTAVzb0IiWsZHXPOErHY iY+4obK9hIn/xkCX7seawkL+B5d02pc5qRh1I= Received: by 10.216.188.135 with SMTP id a7mr770060wen.39.1283200313214; Mon, 30 Aug 2010 13:31:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.30.203 with HTTP; Mon, 30 Aug 2010 13:31:33 -0700 (PDT) In-Reply-To: References: From: Meadhbh Hamrick Date: Mon, 30 Aug 2010 13:31:33 -0700 Message-ID: To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Moving ahead with draft-ietf-vwrap-intro X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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, 30 Aug 2010 20:33:30 -0000 hey morgaine... were you able to make any edits to the intro doc? i think we're wanting to move forward with some of these docs. can we set a deadline? or can you send me what you've got, even if it's just a list of issues with the most recent draft? like i said, i want to make sure the intro draft does not give the tourist model short shrift; but we have to do it in a way that supports other people's use cases as well (like david's yellow zone, a closed federation, and the lindenesque walled garden.) if you could get me your list of issues, i'll volunteer to edit the doc. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Thu, Jul 22, 2010 at 1:45 PM, Morgaine wrote: > Barry, I've been reviewing the Intro document for several days now, and > there are important issues there that will need a certain amount of chang= e. > I don't expect it to be very contentious (basically the old OGP worldview > needs to be brought into line with what's already been discussed in the > group), but I will need some more days of work on it next week. > > Hopefully it won't take me too long. > > > 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=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Thu, Jul 22, 2010 at 5:13 PM, Meadhbh Hamrick > wrote: >> >> i don't think there are any outstanding issues with the intro draft. >> >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> On Thu, Jul 22, 2010 at 9:05 AM, Barry Leiba >> wrote: >> > Since there's been no discussion, yet, about "Introduction and Goals" >> > =A0 http://tools.ietf.org/html/draft-ietf-vwrap-intro >> > ...we should consider moving ahead with it. =A0To that end: >> > >> > 1. Meadhbh, is there anything outstanding that you think needs to be >> > addressed? =A0Any specific input you need from the working group? >> > >> > 2. David, can you get the IPR statement on Meadhbh's original version >> > =A0 https://datatracker.ietf.org/ipr/1294/ >> > ...updated, if it's still applicable to the WG version? =A0If it's not >> > still applicable, we'd need you to tell us that. >> > >> > 3. Working group: please review the document and discuss any issues >> > with it. =A0Joshua and I will also appreciate comments saying "I've >> > reviewed it, and it's ready to go." >> > >> > 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 > > From john.hurliman@intel.com Mon Aug 30 13:39:41 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CE633A6A21 for ; Mon, 30 Aug 2010 13:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sr2ucJWj0EMB for ; Mon, 30 Aug 2010 13:39:38 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by core3.amsl.com (Postfix) with ESMTP id B82CA3A6A39 for ; Mon, 30 Aug 2010 13:38:58 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 30 Aug 2010 13:38:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.56,294,1280732400"; d="scan'208";a="318878848" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by azsmga001.ch.intel.com with ESMTP; 30 Aug 2010 13:38:44 -0700 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx603.amr.corp.intel.com ([10.31.0.57]) with mapi; Mon, 30 Aug 2010 14:38:44 -0600 From: "Hurliman, John" To: "opensim-dev@lists.berlios.de" Date: Mon, 30 Aug 2010 14:38:42 -0600 Thread-Topic: [Opensim-dev] Global identifiers Thread-Index: ActIfy5OA8GrOA8SQgKB/RYUBadhHAAAl2KQ Message-ID: <62BFE5680C037E4DA0B0A08946C0933D01264167EA@rrsmsx506.amr.corp.intel.com> References: <4c7ad44d.5f25e30a.782a.0516@mx.google.com>, <1283121840.13484.119.camel@mdickson-linux>, <4C7AE587.30102@t-data.com>, <1283125132.13484.126.camel@mdickson-linux>, <4C7AF48B.3010202@metaverseink.com>, <1283127395.13484.137.camel@mdickson-linux>, <4C7AFB77.907@metaverseink.com>, , <4C7B1E96.5030309@metaverseink.com> <4C7BA1A8.5070102@t-data.com> <4C7BDD91.9070100@metaverseink.com> <62BFE5680C037E4DA0B0A08946C0933D012641677A@rrsmsx506.amr.corp.intel.com> <4C7C0FC4.10305@t-data.com> In-Reply-To: <4C7C0FC4.10305@t-data.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "vwrap@ietf.org" Subject: Re: [vwrap] [Opensim-dev] Global identifiers X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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, 30 Aug 2010 20:39:41 -0000 > -----Original Message----- > From: opensim-dev-bounces@lists.berlios.de [mailto:opensim-dev- > bounces@lists.berlios.de] On Behalf Of Melanie > Sent: Monday, August 30, 2010 1:09 PM > To: opensim-dev@lists.berlios.de > Cc: vwrap@ietf.org > Subject: Re: [Opensim-dev] Global identifiers > > Hi, > > Hurliman, John wrote: > [...] > > * A HyperGrid user is teleporting from grid A to grid B. Does grid B > have enough information to build the global identifier "gridA/user"? > > They may not teleport in from their home grid. Also, they may be > carrying objects from other creators, that may have passed through > any number of grids, any number of which may not exist anymore. > This is a good argument in support of fetching information from the most re= cent grid containing an identity instead of trying to go back to a point of= origin. By embedding metadata like a display name in a URL/URN this is eff= ectively what you are doing, we're just talking about what the on-the-wire = format looks like at that point. I don't have any strong preference about h= ow global identities are passed around between foreign grids and through ex= port formats. > > * A HyperGrid user rezzes an object into grid B that exists in their > inventory on grid A. The object has a creator that is unrecognized to > grid B. Should grid B pull the creator profile from grid A (which may > actually be storing a local copy of the real creator identity from grid > X)? Note that this isn't a question about trust because we're already > trusting grid A to provide creator information for the object, it's > just about where we pull profile info from. > > Grid X may no longer exist. That is why I am so strongly for having > enough information contained in the URL to be able to at least > display a name, and, for performance reasons, do no lookups at all > unless the request is for more than name display (e.g. communication). > It sounds like we are on the same page for everything, there's just the que= stion of how to represent global identities coming into a grid before they = are translated into a local identity. I'll defer to the expertise of others= here. I'm generally more in favor of using URLs (even if they are non-opaq= ue) instead of a new URN format. If a grid only cares about storing the dis= play name in the profile and is happy to leave the rest of the profile data= blank then no request would be needed at all here, it can just create the = local account with a new UUID and the given name and continue on. > > * An OAR file is loaded and contains an unrecognized identity. Should > identities in OAR files be encoded as global identifiers, or a header > added to the OAR file to say "all of this content came from grid A", or > the full profiles of all the identities in the OAR embedded right into > the archive? > > Oar and Iar should always translate the identifiers to global > format, and may be written to translate loaded data back to local > format if it originated with the grid loaded into. > > > > > P.S. I'm CCing this to the VWRAP list as the participants there will > be interested in how these architecture decisions are progressing in > OpenSim, and may be able to lend more insight to the discussion. > > > > -John > > > > > >> -----Original Message----- > >> From: opensim-dev-bounces@lists.berlios.de [mailto:opensim-dev- > >> bounces@lists.berlios.de] On Behalf Of diva@metaverseink.com > >> Sent: Monday, August 30, 2010 9:34 AM > >> To: opensim-dev@lists.berlios.de > >> Subject: Re: [Opensim-dev] Global identifiers > >> > >> Let me throw another thought into this. It is related to the subtle > >> differences of URLs and URNs, and Bob Wellman's suggestion. > >> > >> So far we are more or less converging to > >> protocol://authority/resource_type/resource_id[/cacheable_info] > >> with the [/cacheable_info] sill up for discussion. Independent on > how > >> you break this down in persistent storage, this is an URL, and one > with > >> specific assumptions about the existence of a resource_id. > >> > >> However, in the future we would like to interoperate with systems > that > >> aren't virtual worlds as such. In most of those systems, the > resources > >> are named with names that may not even be URLs and even if they are, > >> they may not have "resource_id" at all. For example, > >> > >> Cristiano Ronaldo's Facebook handle is > >> http://www.facebook.com/Cristiano > >> > >> A Collada model has > >> John.Smith > >> (Wondering how Linden Lab is going to deal with this... ) > >> > >> > >> So this would not comply with the form above. > >> > >> Now, in practice, we have been designing under a fixed-point: the LL > >> viewer. The LL viewer MUST have UUIDs for every resource that is > sent > >> from the server the client. So, in practice what this means is that > >> every external resource reference must be assigned a local UUID if > it > >> doesn't come with one, which sounds like a very reasonable thing to > do, > >> and some people here already mentioned it. > >> > >> Nevertheless, the Collada example breaks the assumption that every > >> named > >> resource out there has an authority (locator) that we can refer back > >> to. > >> It may not. We can continue down the road of fixing missing > information > >> with default information. So, for example, if something comes in as > >> John.Smith, our reference to it could be > >> http://ourgrid/user/some_uuid/John+Smith -- even though there is no > >> such > >> account. But that's a slippery slope. > >> > >> This further supports the argument of having a table that maps > between > >> local UUIDs and external references. And maybe external references > may > >> take more than just one URI form, not just the one we have been > talking > >> about > >> protocol://authority/resource_type/resource_id[/cacheable_info] > >> > >> Maybe it can also be a URN. > >> > >> Nevertheless, the semantics is important, because when an authority > >> (locator) is present, the receiving grid may want to invoke it. > >> > >> > >> > >> Melanie wrote: > >> > While you have a case with using a central table, rather than > >> > storing the URL string, and therefore the name, all over the > place, > >> > your request schema would not work. > >> > > >> > First off, it overcomplicates (IMO) things if you even attempt to > >> > show the current name of an identity. My plan has been to show the > >> > name AT CREATION TIME on a prim, e.g. the displyed creator name of > a > >> > prim will not change, even if the underlying identity changes > their > >> > name. This removes much complaxity. > >> > > >> > Second, your system breaks when a prim is taken to a new grid > after > >> > the grid it was created on has vanished from the internet. In that > >> > case, even the initial lookup will fail and you have no data to > >> display. > >> > > >> > Therefore, I'd prefer to go with my initial recommendation and > >> > indeed store the URL, including the name, "all over the place". > The > >> > client view can always decide to ignore that part and to a table > >> > lookup, or even contact the grid of origin. > >> > > >> > It seems that a lot of people here are all for omitting > information > >> > that would be helpful for the 90% case in order to make their > >> > particular corner case the norm. 90% of avatars never change > names. > >> > > >> > Melanie > >> > > >> > Bob Wellman wrote: > >> >> Can I subvert this discussion back to the original question of > >> Global Identifiers? > >> >> > >> >> > >> >> > >> >> I have been following the discussion on Global Identifiers with > >> interest and I see strong differences of opinion but merits in both > >> arguments. I agree that hard coding meaning into the URI seems like > an > >> inflexible way forward but I also see that minimising lookup traffic > >> between grids is desirable too. So I have been trying to think is > there > >> a middle way to compromise on this. I have the kernel of an idea I > >> would like to put forward for discussion. > >> >> > >> >> Let us say we invent a new table in the local grids database > (called > >> UserLookup maybe) and the key to that table is the URI diva proposed > >> (without the user name part) sent intially. Sorry Melanie but please > >> read on before deciding. > >> >> > >> >> Draft table design here: > >> >> > >> >> 1) Original URI (key) > >> >> 2) Original User name > >> >> 3) Last verification date. > >> >> 4) Current user name > >> >> 5) Current URI (optional idea see later) > >> >> > >> >> When the original URI is received (or later referenced) we do a > >> check against this table to see if a lookup is available and proceed > as > >> follows: > >> >> 1) If the lookup is not on file... we immediately send to the > other > >> grid for verification and the user name and we add the lookup to the > >> table with original user name and current user name the same. > >> >> 2) If the lookup is on file but out of date ... we send to the > other > >> grid for verification (this can be dleayed if need be) and take the > >> latest feedback of user name and update the lookup with current > name. > >> >> 3) If the lookup is on file but not out of date (most times this > >> will be the case) ... we do nothing. > >> >> > >> >> What constitutes out of date will be configurable in Opensim.ini > >> (out-of-date=3D x days). In Melanie's case she will set forever as > >> avatars must not be changeable. For others this can be tailored to > >> their requirements of speed versus flexibility. > >> >> > >> >> The user service already looks up the Prims user UUID to decode > the > >> name for local avatars so it just would be changed to do this new > >> lookup at the same time. I think of it this way ...The user service > >> currently answer the question "who is this" and would now answer > "who > >> in the global community is this". > >> >> > >> >> This method keeps the database design 3rd normal form rather than > >> storing key decodes all over the database, as to not do this will at > >> some stage cause database chaos just like it did in appearance > sometime > >> ago. Can you tell I have a database design background...LOL > >> >> > >> >> If a grid goes bust or is temporary offline we have the last know > >> user info to rely on using just local grid lookup, which covers the > >> very valid argument Melanie made that we need to know identity even > if > >> the other grids no longer there. > >> >> > >> >> We can also have the ability to recognise that verification has > not > >> been available for a long time so cross grid IM is probably no > longer > >> available to this agent. In the case of an avatar moving grid maybe > >> the forwarding address can be sent back and the current URI stored > (the > >> fifth column) at the next look up verification. If the forwarding > >> doesnt ecist or is only temporary, it does matter, as we have last > >> known address stored at our grid, which is the best thats possible. > >> Maintaining an IM link of freindship to an agent that moves grids > >> becomes feasible too. So this keeps things flexible for those that > >> think this is the correct approach long term. > >> >> > >> >> In summary this method reduces the need for massive cross grid > >> lookups and still keeps the link between the URI and the user name > >> flexible. > >> >> > >> >> Just my opinion (and I expect to be overruled) but felt I should > say > >> this anyway if only to purge my guilt of saying nothing just to > avoid a > >> slap down ...LOL > >> >> > >> >> Thanks for reading it.. Bob Wellman (PMgrid) > >> >> > >> >> > >> >> > >> >>> Date: Sun, 29 Aug 2010 19:59:34 -0700 > >> >>> From: diva@metaverseink.com > >> >>> To: opensim-dev@lists.berlios.de > >> >>> Subject: Re: [Opensim-dev] Global identifiers > >> >>> > >> >>> See my previous email about what changed. > >> >>> > >> >>> We seem to have quite different concepts of what a standards > >> process is. > >> >>> In my book, a standards process is something that happens > *after* > >> >>> implementations exist, and preferably several competing ones; in > >> the > >> >>> people in VWRAP's book, it seems to mean "let's design something > >> >>> together from scratch and on paper". > >> >>> > >> >>> Let's see how well these two concepts can co-exist. Maybe they > >> can't! > >> >>> > >> >>> Meadhbh Hamrick wrote: > >> >>>> what's changed? > >> >>>> > >> >>>> last year you (diva) seemed to have no interest in merging > VWRAP > >> with > >> >>>> Hypergrid. if i remember correctly, hypergrid was going to go > off > >> and > >> >>>> do an implementation while VWRAP went another way to try to > >> >>>> incrementally build a standard and some code to implement it. > >> >>>> > >> >>>> there's still, of course, room for you at the table. but if i > >> remember > >> >>>> correctly, you seemed to have problems with LLSD/LLIDL (now > about > >> to > >> >>>> get renamed DSD) and you had a security model that didn't work > >> with > >> >>>> zha's use cases. > >> >>>> > >> >>>> if you're interested in making the case for why VWRAP should > adopt > >> the > >> >>>> hypergrid security model and drop DSD, you're welcome to > >> participate > >> >>>> in the VWRAP mailing list. > >> >>>> > >> >>>> and i encourage you to actually do so before dropping a spec on > >> the group. > >> >>>> > >> >>>> -cheers > >> >>>> -meadhbh > >> >>>> > >> >>>> -- > >> >>>> meadhbh hamrick * it's pronounced "maeve" > >> >>>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > >> >>>> > >> >>>> > >> >>>> > >> >>>> On Sun, Aug 29, 2010 at 5:29 PM, wrote: > >> >>>>> Melanie is just right, as usual... well, as in 90% of the time > :) > >> >>>>> The cacheable_data was a brilliant idea, and if you had > >> experience with > >> >>>>> OpenSim in the wild, in how volatile these worlds are and how > >> much these > >> >>>>> particular remote lookups lag the sims, you would come to > >> appreciate it, > >> >>>>> instead of being put off by her dominatrix attitude. > >> >>>>> > >> >>>>> OpenSim core has been contributing center-front in VWRAP: John > >> Hurliman is a > >> >>>>> core developer of OpenSim. > >> >>>>> > >> >>>>> Mike Dickson wrote: > >> >>>>>> That's great to hear. And the first I've heard of it. I'm on > the > >> VWRAP > >> >>>>>> mailing list and yes, John has made some very substantive > >> contributions > >> >>>>>> to the discussion. I haven't seen anything from OpenSim core > >> during any > >> >>>>>> part of the discussion to date. I'm a pretty smart guy but > not > >> >>>>>> omnipotent. I've simply interpreted the lack of participation > as > >> lack > >> >>>>>> of interest and past comments would tend to support that (I > can > >> dig them > >> >>>>>> out if you like). And there is no "general feeling" in VWRAP > as > >> to your > >> >>>>>> proposal since its never been presented or discussed there. > >> >>>>>> > >> >>>>>> I'm not interested in a war, just open dialog and a sincere > >> interest in > >> >>>>>> interoperability. I'll be glad to read the proposal when its > >> made. In > >> >>>>>> the meantime I'd appreciate you not attribute negative > motives > >> to > >> >>>>>> anything I've said. I've been simply trying to make technical > >> arguments > >> >>>>>> against an approach I think is wrong headed and not though > out. > >> I've > >> >>>>>> seen discussion here pretty much get cut off when a core > member > >> >>>>>> "dictates" the solution. Melanie seems to have made up her > mind. > >> Fine. > >> >>>>>> Go build it. Best of luck to you. In the meantime I'll look > >> forward to > >> >>>>>> the Hypergrid proposal to VWRAP and reserve my comments for > that > >> time. > >> >>>>>> BTW, I've found the VWRAP discussions to be pretty open and > >> devoid of > >> >>>>>> politics. People will assert politics over almost anything of > >> course > >> >>>>>> but the dialog has been mostly open and good natured (and > quiet > >> lately). > >> >>>>>> It will be good to have you at the table. Given OpenSim gets > a > >> fair bit > >> >>>>>> of attention it would have been nice if you'd been there all > >> along. > >> >>>>>> > >> >>>>>> Mike > >> >>>>>> > >> >>>>>> On Mon, 2010-08-30 at 00:00 +0000, diva@metaverseink.com > wrote: > >> >>>>>>> Mike, > >> >>>>>>> > >> >>>>>>> That's an interesting statement to make, considering that > John > >> Hurliman > >> >>>>>>> and I are working on writing up the *working* Hypergrid 1.5 > as > >> a proposal to > >> >>>>>>> VWRAP, since we have both concluded that the concepts being > >> talked there > >> >>>>>>> lately, without any implementation behind them, are > essentially > >> >>>>>>> indistinguishable from the working HG 1.5 that lots of > people > >> are already > >> >>>>>>> using. > >> >>>>>>> > >> >>>>>>> It seems that you are trying really hard to make this look > like > >> a war > >> >>>>>>> between OpenSimulator and VWRAP. I don't think that's the > >> general feeling in > >> >>>>>>> VWRAP, I think it's just you. The proposal to VWRAP will > >> happen. Hopefully, > >> >>>>>>> most people there will be able to assess the technical > issues, > >> independent > >> >>>>>>> of the political ones. (emphasis on *hopefully*) > >> >>>>>>> > >> >>>>>>> Diva / Crista > >> >>>>>>> > >> >>>>>>> Mike Dickson wrote: > >> >>>>>>>> Fine, then do what you like. The code's all available. If I > >> don't like > >> >>>>>>>> it I can change it. Of course that sort of shoots holes in > >> >>>>>>>> interoperability. But then I didn't feel that hyper-grid > >> belonged in > >> >>>>>>>> core either for the same reason. > >> >>>>>>>> I think you've way over trivialized the whole set of > >> interactions > >> >>>>>>>> between agent, asset and simulator services in situations > >> where those > >> >>>>>>>> services are defined by different principals. As Meadbh > said, > >> this > >> >>>>>>>> feels like optimizing to solve a specific problem before > >> you've really > >> >>>>>>>> looked at the larger issues. It might be instructive just > to > >> simply walk > >> >>>>>>>> through some use cases and see where things fall apart. > Alot > >> of that > >> >>>>>>>> discussion has already taken place on the VWRAP list but > >> OpenSim core > >> >>>>>>>> seems to be dead set against involvement in that. > >> >>>>>>>> > >> >>>>>>>> I don't see a way to contribute here beyond the opinion > I've > >> already > >> >>>>>>>> voiced so I'll drop this. > >> >>>>>>>> > >> >>>>>>>> Mike > >> >>>>>>>> > >> >>>>>>>> On Sun, 2010-08-29 at 22:56 +0000, Melanie wrote: > >> >>>>>>>>> Sorry, i disagree. The information included is defined by > the > >> >>>>>>>>> REQUIRED data on the recipient, not on what data the > sender > >> wants to > >> >>>>>>>>> provide. the recipient NEEDS a displayable field. It can't > be > >> optional. > >> >>>>>>>>> > >> >>>>>>>>> Melanie > >> >>>>>>>>> > >> >>>>>>>>> Mike Dickson wrote: > >> >>>>>>>>>> If the decision is to go ahead and do cache-able data > then > >> I'd agree, > >> >>>>>>>>>> do > >> >>>>>>>>>> it as attribute NVP's and make them optional. The > >> originating agennt > >> >>>>>>>>>> service is then free to define the semantics of the > >> attributes it > >> >>>>>>>>>> exposes. > >> >>>>>>>>>> Mike > >> >>>>>>>>>> > >> >>>>>>>>>> On Sun, 2010-08-29 at 21:42 +0000, Ai Austin wrote: > >> >>>>>>>>>>>> From: diva@metaverseink.com > >> >>>>>>>>>>>> > >> protocol://authority/resource_type/resource_id[/cacheable_data] > >> >>>>>>>>>>> +1 > >> >>>>>>>>>>> > >> >>>>>>>>>>> consider ensuring that at least the name is provided in > a > >> form that > >> >>>>>>>>>>> can be resolved fast and locally by including the avatar > >> firstname+lastname > >> >>>>>>>>>>> - in whatever form the providing grid wishes to address > >> issues raised by > >> >>>>>>>>>>> others - so long as the strings are "legal" in the > >> creator/owner fields. > >> >>>>>>>>>>> > >> >>>>>>>>>>> would it be worth making sure that the "cachable data" > is > >> in the form > >> >>>>>>>>>>> of keyword=3Dvalue pairs, and hence put in a "parameter" > form > >> after ? rather > >> >>>>>>>>>>> than a final /? > >> >>>>>>>>>>> > >> >>>>>>>>>>> > >> > protocol://authority/resource_type/resource_id[?key_value_pair[,...]] > >> >>>>>>>>>>> > >> >>>>>>>>>>> with a minimum suggested (or required?) > >> >>>>>>>>>>> avatarname=3Dfirstname+lastname if the resource_type =3D > user > >> >>>>>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>>>>> _______________________________________________ > >> >>>>>>>>>>> Opensim-dev mailing list > >> >>>>>>>>>>> Opensim-dev@lists.berlios.de > >> >>>>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> >>>>>>>>>> _______________________________________________ > >> >>>>>>>>>> Opensim-dev mailing list > >> >>>>>>>>>> Opensim-dev@lists.berlios.de > >> >>>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>> _______________________________________________ > >> >>>>>>>>> Opensim-dev mailing list > >> >>>>>>>>> Opensim-dev@lists.berlios.de > >> >>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> >>>>>>>> _______________________________________________ > >> >>>>>>>> Opensim-dev mailing list > >> >>>>>>>> Opensim-dev@lists.berlios.de > >> >>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> >>>>>>>> > >> >>>>>>> _______________________________________________ > >> >>>>>>> Opensim-dev mailing list > >> >>>>>>> Opensim-dev@lists.berlios.de > >> >>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> >>>>> _______________________________________________ > >> >>>>> Opensim-dev mailing list > >> >>>>> Opensim-dev@lists.berlios.de > >> >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> >>>>> > >> >>> _______________________________________________ > >> >>> Opensim-dev mailing list > >> >>> Opensim-dev@lists.berlios.de > >> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> >> > >> >> > >> >> > >> >> ----------------------------------------------------------------- > --- > >> ---- > >> >> > >> >> _______________________________________________ > >> >> Opensim-dev mailing list > >> >> Opensim-dev@lists.berlios.de > >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > _______________________________________________ > >> > Opensim-dev mailing list > >> > Opensim-dev@lists.berlios.de > >> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > >> _______________________________________________ > >> Opensim-dev mailing list > >> Opensim-dev@lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev@lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From melanie@t-data.com Mon Aug 30 13:07:59 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA9B3A69F4 for ; Mon, 30 Aug 2010 13:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9RZ0wZV3toA for ; Mon, 30 Aug 2010 13:07:57 -0700 (PDT) Received: from www.3dhosting.de (www.3dhosting.de [85.25.142.92]) by core3.amsl.com (Postfix) with ESMTP id 75E043A687C for ; Mon, 30 Aug 2010 13:07:55 -0700 (PDT) Received: (qmail 1883 invoked from network); 30 Aug 2010 20:08:22 -0000 Received: from unknown (HELO guardian.t-data.com) (192.168.201.12) by www.3dhosting.de with SMTP; 30 Aug 2010 20:08:22 -0000 Received: (qmail 11052 invoked from network); 30 Aug 2010 19:34:16 -0000 Received: from unknown (HELO lap4.t-data.com) (melanie@t-data.com@192.168.201.214) by guardian.t-data.com with SMTP; 30 Aug 2010 19:34:16 -0000 Message-ID: <4C7C0FC4.10305@t-data.com> Date: Mon, 30 Aug 2010 22:08:36 +0200 From: Melanie User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060907 Thunderbird/1.5.0.7 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: opensim-dev@lists.berlios.de References: <4c7ad44d.5f25e30a.782a.0516@mx.google.com>, <1283121840.13484.119.camel@mdickson-linux>, <4C7AE587.30102@t-data.com>, <1283125132.13484.126.camel@mdickson-linux>, <4C7AF48B.3010202@metaverseink.com>, <1283127395.13484.137.camel@mdickson-linux>, <4C7AFB77.907@metaverseink.com>, , <4C7B1E96.5030309@metaverseink.com> <4C7BA1A8.5070102@t-data.com> <4C7BDD91.9070100@metaverseink.com> <62BFE5680C037E4DA0B0A08946C0933D012641677A@rrsmsx506.amr.corp.intel.com> In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D012641677A@rrsmsx506.amr.corp.intel.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 30 Aug 2010 13:42:26 -0700 Cc: "vwrap@ietf.org" Subject: Re: [vwrap] [Opensim-dev] Global identifiers X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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, 30 Aug 2010 20:39:46 -0000 Hi, Hurliman, John wrote: [...] > * A HyperGrid user is teleporting from grid A to grid B. Does grid B have enough information to build the global identifier "gridA/user"? They may not teleport in from their home grid. Also, they may be carrying objects from other creators, that may have passed through any number of grids, any number of which may not exist anymore. > * A HyperGrid user rezzes an object into grid B that exists in their inventory on grid A. The object has a creator that is unrecognized to grid B. Should grid B pull the creator profile from grid A (which may actually be storing a local copy of the real creator identity from grid X)? Note that this isn't a question about trust because we're already trusting grid A to provide creator information for the object, it's just about where we pull profile info from. Grid X may no longer exist. That is why I am so strongly for having enough information contained in the URL to be able to at least display a name, and, for performance reasons, do no lookups at all unless the request is for more than name display (e.g. communication). > * An OAR file is loaded and contains an unrecognized identity. Should identities in OAR files be encoded as global identifiers, or a header added to the OAR file to say "all of this content came from grid A", or the full profiles of all the identities in the OAR embedded right into the archive? Oar and Iar should always translate the identifiers to global format, and may be written to translate loaded data back to local format if it originated with the grid loaded into. > > P.S. I'm CCing this to the VWRAP list as the participants there will be interested in how these architecture decisions are progressing in OpenSim, and may be able to lend more insight to the discussion. > > -John > > >> -----Original Message----- >> From: opensim-dev-bounces@lists.berlios.de [mailto:opensim-dev- >> bounces@lists.berlios.de] On Behalf Of diva@metaverseink.com >> Sent: Monday, August 30, 2010 9:34 AM >> To: opensim-dev@lists.berlios.de >> Subject: Re: [Opensim-dev] Global identifiers >> >> Let me throw another thought into this. It is related to the subtle >> differences of URLs and URNs, and Bob Wellman's suggestion. >> >> So far we are more or less converging to >> protocol://authority/resource_type/resource_id[/cacheable_info] >> with the [/cacheable_info] sill up for discussion. Independent on how >> you break this down in persistent storage, this is an URL, and one with >> specific assumptions about the existence of a resource_id. >> >> However, in the future we would like to interoperate with systems that >> aren't virtual worlds as such. In most of those systems, the resources >> are named with names that may not even be URLs and even if they are, >> they may not have "resource_id" at all. For example, >> >> Cristiano Ronaldo's Facebook handle is >> http://www.facebook.com/Cristiano >> >> A Collada model has >> John.Smith >> (Wondering how Linden Lab is going to deal with this... ) >> >> >> So this would not comply with the form above. >> >> Now, in practice, we have been designing under a fixed-point: the LL >> viewer. The LL viewer MUST have UUIDs for every resource that is sent >> from the server the client. So, in practice what this means is that >> every external resource reference must be assigned a local UUID if it >> doesn't come with one, which sounds like a very reasonable thing to do, >> and some people here already mentioned it. >> >> Nevertheless, the Collada example breaks the assumption that every >> named >> resource out there has an authority (locator) that we can refer back >> to. >> It may not. We can continue down the road of fixing missing information >> with default information. So, for example, if something comes in as >> John.Smith, our reference to it could be >> http://ourgrid/user/some_uuid/John+Smith -- even though there is no >> such >> account. But that's a slippery slope. >> >> This further supports the argument of having a table that maps between >> local UUIDs and external references. And maybe external references may >> take more than just one URI form, not just the one we have been talking >> about >> protocol://authority/resource_type/resource_id[/cacheable_info] >> >> Maybe it can also be a URN. >> >> Nevertheless, the semantics is important, because when an authority >> (locator) is present, the receiving grid may want to invoke it. >> >> >> >> Melanie wrote: >> > While you have a case with using a central table, rather than >> > storing the URL string, and therefore the name, all over the place, >> > your request schema would not work. >> > >> > First off, it overcomplicates (IMO) things if you even attempt to >> > show the current name of an identity. My plan has been to show the >> > name AT CREATION TIME on a prim, e.g. the displyed creator name of a >> > prim will not change, even if the underlying identity changes their >> > name. This removes much complaxity. >> > >> > Second, your system breaks when a prim is taken to a new grid after >> > the grid it was created on has vanished from the internet. In that >> > case, even the initial lookup will fail and you have no data to >> display. >> > >> > Therefore, I'd prefer to go with my initial recommendation and >> > indeed store the URL, including the name, "all over the place". The >> > client view can always decide to ignore that part and to a table >> > lookup, or even contact the grid of origin. >> > >> > It seems that a lot of people here are all for omitting information >> > that would be helpful for the 90% case in order to make their >> > particular corner case the norm. 90% of avatars never change names. >> > >> > Melanie >> > >> > Bob Wellman wrote: >> >> Can I subvert this discussion back to the original question of >> Global Identifiers? >> >> >> >> >> >> >> >> I have been following the discussion on Global Identifiers with >> interest and I see strong differences of opinion but merits in both >> arguments. I agree that hard coding meaning into the URI seems like an >> inflexible way forward but I also see that minimising lookup traffic >> between grids is desirable too. So I have been trying to think is there >> a middle way to compromise on this. I have the kernel of an idea I >> would like to put forward for discussion. >> >> >> >> Let us say we invent a new table in the local grids database (called >> UserLookup maybe) and the key to that table is the URI diva proposed >> (without the user name part) sent intially. Sorry Melanie but please >> read on before deciding. >> >> >> >> Draft table design here: >> >> >> >> 1) Original URI (key) >> >> 2) Original User name >> >> 3) Last verification date. >> >> 4) Current user name >> >> 5) Current URI (optional idea see later) >> >> >> >> When the original URI is received (or later referenced) we do a >> check against this table to see if a lookup is available and proceed as >> follows: >> >> 1) If the lookup is not on file... we immediately send to the other >> grid for verification and the user name and we add the lookup to the >> table with original user name and current user name the same. >> >> 2) If the lookup is on file but out of date ... we send to the other >> grid for verification (this can be dleayed if need be) and take the >> latest feedback of user name and update the lookup with current name. >> >> 3) If the lookup is on file but not out of date (most times this >> will be the case) ... we do nothing. >> >> >> >> What constitutes out of date will be configurable in Opensim.ini >> (out-of-date= x days). In Melanie's case she will set forever as >> avatars must not be changeable. For others this can be tailored to >> their requirements of speed versus flexibility. >> >> >> >> The user service already looks up the Prims user UUID to decode the >> name for local avatars so it just would be changed to do this new >> lookup at the same time. I think of it this way ...The user service >> currently answer the question "who is this" and would now answer "who >> in the global community is this". >> >> >> >> This method keeps the database design 3rd normal form rather than >> storing key decodes all over the database, as to not do this will at >> some stage cause database chaos just like it did in appearance sometime >> ago. Can you tell I have a database design background...LOL >> >> >> >> If a grid goes bust or is temporary offline we have the last know >> user info to rely on using just local grid lookup, which covers the >> very valid argument Melanie made that we need to know identity even if >> the other grids no longer there. >> >> >> >> We can also have the ability to recognise that verification has not >> been available for a long time so cross grid IM is probably no longer >> available to this agent. In the case of an avatar moving grid maybe >> the forwarding address can be sent back and the current URI stored (the >> fifth column) at the next look up verification. If the forwarding >> doesnt ecist or is only temporary, it does matter, as we have last >> known address stored at our grid, which is the best thats possible. >> Maintaining an IM link of freindship to an agent that moves grids >> becomes feasible too. So this keeps things flexible for those that >> think this is the correct approach long term. >> >> >> >> In summary this method reduces the need for massive cross grid >> lookups and still keeps the link between the URI and the user name >> flexible. >> >> >> >> Just my opinion (and I expect to be overruled) but felt I should say >> this anyway if only to purge my guilt of saying nothing just to avoid a >> slap down ...LOL >> >> >> >> Thanks for reading it.. Bob Wellman (PMgrid) >> >> >> >> >> >> >> >>> Date: Sun, 29 Aug 2010 19:59:34 -0700 >> >>> From: diva@metaverseink.com >> >>> To: opensim-dev@lists.berlios.de >> >>> Subject: Re: [Opensim-dev] Global identifiers >> >>> >> >>> See my previous email about what changed. >> >>> >> >>> We seem to have quite different concepts of what a standards >> process is. >> >>> In my book, a standards process is something that happens *after* >> >>> implementations exist, and preferably several competing ones; in >> the >> >>> people in VWRAP's book, it seems to mean "let's design something >> >>> together from scratch and on paper". >> >>> >> >>> Let's see how well these two concepts can co-exist. Maybe they >> can't! >> >>> >> >>> Meadhbh Hamrick wrote: >> >>>> what's changed? >> >>>> >> >>>> last year you (diva) seemed to have no interest in merging VWRAP >> with >> >>>> Hypergrid. if i remember correctly, hypergrid was going to go off >> and >> >>>> do an implementation while VWRAP went another way to try to >> >>>> incrementally build a standard and some code to implement it. >> >>>> >> >>>> there's still, of course, room for you at the table. but if i >> remember >> >>>> correctly, you seemed to have problems with LLSD/LLIDL (now about >> to >> >>>> get renamed DSD) and you had a security model that didn't work >> with >> >>>> zha's use cases. >> >>>> >> >>>> if you're interested in making the case for why VWRAP should adopt >> the >> >>>> hypergrid security model and drop DSD, you're welcome to >> participate >> >>>> in the VWRAP mailing list. >> >>>> >> >>>> and i encourage you to actually do so before dropping a spec on >> the group. >> >>>> >> >>>> -cheers >> >>>> -meadhbh >> >>>> >> >>>> -- >> >>>> meadhbh hamrick * it's pronounced "maeve" >> >>>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >>>> >> >>>> >> >>>> >> >>>> On Sun, Aug 29, 2010 at 5:29 PM, wrote: >> >>>>> Melanie is just right, as usual... well, as in 90% of the time :) >> >>>>> The cacheable_data was a brilliant idea, and if you had >> experience with >> >>>>> OpenSim in the wild, in how volatile these worlds are and how >> much these >> >>>>> particular remote lookups lag the sims, you would come to >> appreciate it, >> >>>>> instead of being put off by her dominatrix attitude. >> >>>>> >> >>>>> OpenSim core has been contributing center-front in VWRAP: John >> Hurliman is a >> >>>>> core developer of OpenSim. >> >>>>> >> >>>>> Mike Dickson wrote: >> >>>>>> That's great to hear. And the first I've heard of it. I'm on the >> VWRAP >> >>>>>> mailing list and yes, John has made some very substantive >> contributions >> >>>>>> to the discussion. I haven't seen anything from OpenSim core >> during any >> >>>>>> part of the discussion to date. I'm a pretty smart guy but not >> >>>>>> omnipotent. I've simply interpreted the lack of participation as >> lack >> >>>>>> of interest and past comments would tend to support that (I can >> dig them >> >>>>>> out if you like). And there is no "general feeling" in VWRAP as >> to your >> >>>>>> proposal since its never been presented or discussed there. >> >>>>>> >> >>>>>> I'm not interested in a war, just open dialog and a sincere >> interest in >> >>>>>> interoperability. I'll be glad to read the proposal when its >> made. In >> >>>>>> the meantime I'd appreciate you not attribute negative motives >> to >> >>>>>> anything I've said. I've been simply trying to make technical >> arguments >> >>>>>> against an approach I think is wrong headed and not though out. >> I've >> >>>>>> seen discussion here pretty much get cut off when a core member >> >>>>>> "dictates" the solution. Melanie seems to have made up her mind. >> Fine. >> >>>>>> Go build it. Best of luck to you. In the meantime I'll look >> forward to >> >>>>>> the Hypergrid proposal to VWRAP and reserve my comments for that >> time. >> >>>>>> BTW, I've found the VWRAP discussions to be pretty open and >> devoid of >> >>>>>> politics. People will assert politics over almost anything of >> course >> >>>>>> but the dialog has been mostly open and good natured (and quiet >> lately). >> >>>>>> It will be good to have you at the table. Given OpenSim gets a >> fair bit >> >>>>>> of attention it would have been nice if you'd been there all >> along. >> >>>>>> >> >>>>>> Mike >> >>>>>> >> >>>>>> On Mon, 2010-08-30 at 00:00 +0000, diva@metaverseink.com wrote: >> >>>>>>> Mike, >> >>>>>>> >> >>>>>>> That's an interesting statement to make, considering that John >> Hurliman >> >>>>>>> and I are working on writing up the *working* Hypergrid 1.5 as >> a proposal to >> >>>>>>> VWRAP, since we have both concluded that the concepts being >> talked there >> >>>>>>> lately, without any implementation behind them, are essentially >> >>>>>>> indistinguishable from the working HG 1.5 that lots of people >> are already >> >>>>>>> using. >> >>>>>>> >> >>>>>>> It seems that you are trying really hard to make this look like >> a war >> >>>>>>> between OpenSimulator and VWRAP. I don't think that's the >> general feeling in >> >>>>>>> VWRAP, I think it's just you. The proposal to VWRAP will >> happen. Hopefully, >> >>>>>>> most people there will be able to assess the technical issues, >> independent >> >>>>>>> of the political ones. (emphasis on *hopefully*) >> >>>>>>> >> >>>>>>> Diva / Crista >> >>>>>>> >> >>>>>>> Mike Dickson wrote: >> >>>>>>>> Fine, then do what you like. The code's all available. If I >> don't like >> >>>>>>>> it I can change it. Of course that sort of shoots holes in >> >>>>>>>> interoperability. But then I didn't feel that hyper-grid >> belonged in >> >>>>>>>> core either for the same reason. >> >>>>>>>> I think you've way over trivialized the whole set of >> interactions >> >>>>>>>> between agent, asset and simulator services in situations >> where those >> >>>>>>>> services are defined by different principals. As Meadbh said, >> this >> >>>>>>>> feels like optimizing to solve a specific problem before >> you've really >> >>>>>>>> looked at the larger issues. It might be instructive just to >> simply walk >> >>>>>>>> through some use cases and see where things fall apart. Alot >> of that >> >>>>>>>> discussion has already taken place on the VWRAP list but >> OpenSim core >> >>>>>>>> seems to be dead set against involvement in that. >> >>>>>>>> >> >>>>>>>> I don't see a way to contribute here beyond the opinion I've >> already >> >>>>>>>> voiced so I'll drop this. >> >>>>>>>> >> >>>>>>>> Mike >> >>>>>>>> >> >>>>>>>> On Sun, 2010-08-29 at 22:56 +0000, Melanie wrote: >> >>>>>>>>> Sorry, i disagree. The information included is defined by the >> >>>>>>>>> REQUIRED data on the recipient, not on what data the sender >> wants to >> >>>>>>>>> provide. the recipient NEEDS a displayable field. It can't be >> optional. >> >>>>>>>>> >> >>>>>>>>> Melanie >> >>>>>>>>> >> >>>>>>>>> Mike Dickson wrote: >> >>>>>>>>>> If the decision is to go ahead and do cache-able data then >> I'd agree, >> >>>>>>>>>> do >> >>>>>>>>>> it as attribute NVP's and make them optional. The >> originating agennt >> >>>>>>>>>> service is then free to define the semantics of the >> attributes it >> >>>>>>>>>> exposes. >> >>>>>>>>>> Mike >> >>>>>>>>>> >> >>>>>>>>>> On Sun, 2010-08-29 at 21:42 +0000, Ai Austin wrote: >> >>>>>>>>>>>> From: diva@metaverseink.com >> >>>>>>>>>>>> >> protocol://authority/resource_type/resource_id[/cacheable_data] >> >>>>>>>>>>> +1 >> >>>>>>>>>>> >> >>>>>>>>>>> consider ensuring that at least the name is provided in a >> form that >> >>>>>>>>>>> can be resolved fast and locally by including the avatar >> firstname+lastname >> >>>>>>>>>>> - in whatever form the providing grid wishes to address >> issues raised by >> >>>>>>>>>>> others - so long as the strings are "legal" in the >> creator/owner fields. >> >>>>>>>>>>> >> >>>>>>>>>>> would it be worth making sure that the "cachable data" is >> in the form >> >>>>>>>>>>> of keyword=value pairs, and hence put in a "parameter" form >> after ? rather >> >>>>>>>>>>> than a final /? >> >>>>>>>>>>> >> >>>>>>>>>>> >> protocol://authority/resource_type/resource_id[?key_value_pair[,...]] >> >>>>>>>>>>> >> >>>>>>>>>>> with a minimum suggested (or required?) >> >>>>>>>>>>> avatarname=firstname+lastname if the resource_type = user >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> _______________________________________________ >> >>>>>>>>>>> Opensim-dev mailing list >> >>>>>>>>>>> Opensim-dev@lists.berlios.de >> >>>>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>>>>>>>>> _______________________________________________ >> >>>>>>>>>> Opensim-dev mailing list >> >>>>>>>>>> Opensim-dev@lists.berlios.de >> >>>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> _______________________________________________ >> >>>>>>>>> Opensim-dev mailing list >> >>>>>>>>> Opensim-dev@lists.berlios.de >> >>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>>>>>>> _______________________________________________ >> >>>>>>>> Opensim-dev mailing list >> >>>>>>>> Opensim-dev@lists.berlios.de >> >>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> Opensim-dev mailing list >> >>>>>>> Opensim-dev@lists.berlios.de >> >>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>>>> _______________________________________________ >> >>>>> Opensim-dev mailing list >> >>>>> Opensim-dev@lists.berlios.de >> >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>>>> >> >>> _______________________________________________ >> >>> Opensim-dev mailing list >> >>> Opensim-dev@lists.berlios.de >> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> >> >> >> >> >> -------------------------------------------------------------------- >> ---- >> >> >> >> _______________________________________________ >> >> Opensim-dev mailing list >> >> Opensim-dev@lists.berlios.de >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev@lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> > >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > From john.hurliman@intel.com Mon Aug 30 13:44:41 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 764713A6849 for ; Mon, 30 Aug 2010 13:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[AWL=2.377, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rybpdhEp3480 for ; Mon, 30 Aug 2010 13:44:40 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id 59A5E3A6858 for ; Mon, 30 Aug 2010 13:44:40 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 30 Aug 2010 13:45:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.56,294,1280732400"; d="scan'208";a="601977801" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by fmsmga002.fm.intel.com with ESMTP; 30 Aug 2010 13:45:11 -0700 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by rrsmsx604.amr.corp.intel.com (10.31.0.170) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 30 Aug 2010 14:45:11 -0600 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Mon, 30 Aug 2010 14:45:10 -0600 From: "Hurliman, John" To: "opensim-dev@lists.berlios.de" Date: Mon, 30 Aug 2010 14:45:08 -0600 Thread-Topic: [Opensim-dev] Global identifiers Thread-Index: ActIgymnhrV6xBvZSmC8nf1p1mOrFAAADCMg Message-ID: <62BFE5680C037E4DA0B0A08946C0933D0126416801@rrsmsx506.amr.corp.intel.com> References: <4c7ad44d.5f25e30a.782a.0516@mx.google.com>, <1283121840.13484.119.camel@mdickson-linux>, <4C7AE587.30102@t-data.com>, <1283125132.13484.126.camel@mdickson-linux>, <4C7AF48B.3010202@metaverseink.com>, <1283127395.13484.137.camel@mdickson-linux>, <4C7AFB77.907@metaverseink.com>, , <4C7B1E96.5030309@metaverseink.com> <4C7BA1A8.5070102@t-data.com> <4C7BDD91.9070100@metaverseink.com> <62BFE5680C037E4DA0B0A08946C0933D012641677A@rrsmsx506.amr.corp.intel.com> <4C7C1637.5040400@metaverseink.com> In-Reply-To: <4C7C1637.5040400@metaverseink.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "vwrap@ietf.org" Subject: Re: [vwrap] [Opensim-dev] Global identifiers X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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, 30 Aug 2010 20:44:41 -0000 My interpretation (please correct me if I'm wrong) is that there is rough c= onsensus on the overall strategy, but an open question of how to encode glo= bal identities when cross-grid communication (or out-of-grid archiving) hap= pens. There is probably also a hidden question of how to mark a local accou= nt as linked to a foreign identity, which may solve the friending issue. If= I am friends with your avatar and we are both on grid B but your avatar ac= tually originated from grid A, that link in the profile is what can tip off= the presence service to try a remote presence check (assuming the user is = not online in the local grid). My only interest in these low level question= s like how the global identifiers and profile links look is what the final = decision is so I can implement it in the OpenSim SimianGrid connectors. John > -----Original Message----- > From: opensim-dev-bounces@lists.berlios.de [mailto:opensim-dev- > bounces@lists.berlios.de] On Behalf Of diva@metaverseink.com > Sent: Monday, August 30, 2010 1:36 PM > To: opensim-dev@lists.berlios.de > Cc: vwrap@ietf.org > Subject: Re: [Opensim-dev] Global identifiers >=20 > I have different answers than Melanie. >=20 > > An open question with this approach is whether you need to use global > identifiers when dealing with cross-grid scenarios, or whether there is > always enough context to derive a global identifier. Some examples: > > > > * A HyperGrid user is teleporting from grid A to grid B. Does grid B > have enough information to build the global identifier "gridA/user"? >=20 > Yes. It already does that on the spot. We don't need persistent global > identifiers for agents. >=20 > The issue we are now talking about is if someone in grid B makes > friends > with this user. In this case, we need to add an entry to grid B's > Friends service referring to an external user, and vice-versa. That's > when we need global identifier for this user (not its agent). >=20 > > * A HyperGrid user rezzes an object into grid B that exists in their > inventory on grid A. The object has a creator that is unrecognized to > grid B. Should grid B pull the creator profile from grid A (which may > actually be storing a local copy of the real creator identity from grid > X)? Note that this isn't a question about trust because we're already > trusting grid A to provide creator information for the object, it's > just about where we pull profile info from. >=20 > Yes, it should. And since the code that does that is exactly the same > code that prepares inventory items for archiving, this should be no > different than archiving itself. >=20 > > * An OAR file is loaded and contains an unrecognized identity. Should > identities in OAR files be encoded as global identifiers, or a header > added to the OAR file to say "all of this content came from grid A", or > the full profiles of all the identities in the OAR embedded right into > the archive? >=20 > I don't think it can be bulk in the general case, although that could > be > option in some cases. I'm looking at my inventory right now and it's a > rainbow of stuff I got from all sorts of places. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From diva@metaverseink.com Mon Aug 30 13:40:58 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 657733A684C for ; Mon, 30 Aug 2010 13:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVieqZqpFpvV for ; Mon, 30 Aug 2010 13:40:57 -0700 (PDT) Received: from smtp.techcoastworks.com (techcoastworks.com [206.82.208.116]) by core3.amsl.com (Postfix) with ESMTP id 526C93A6814 for ; Mon, 30 Aug 2010 13:40:56 -0700 (PDT) Received: from [192.168.1.105] (adsl-75-34-226-217.dsl.irvnca.sbcglobal.net [75.34.226.217]) (authenticated bits=0) by smtp.techcoastworks.com (8.12.11.20060308/8.12.11) with ESMTP id o7UKIweA012959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Aug 2010 13:18:59 -0700 Message-ID: <4C7C1637.5040400@metaverseink.com> Date: Mon, 30 Aug 2010 13:36:07 -0700 From: diva@metaverseink.com Organization: Metaverse Ink User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: opensim-dev@lists.berlios.de References: <4c7ad44d.5f25e30a.782a.0516@mx.google.com>, <1283121840.13484.119.camel@mdickson-linux>, <4C7AE587.30102@t-data.com>, <1283125132.13484.126.camel@mdickson-linux>, <4C7AF48B.3010202@metaverseink.com>, <1283127395.13484.137.camel@mdickson-linux>, <4C7AFB77.907@metaverseink.com>, , <4C7B1E96.5030309@metaverseink.com> <4C7BA1A8.5070102@t-data.com> <4C7BDD91.9070100@metaverseink.com> <62BFE5680C037E4DA0B0A08946C0933D012641677A@rrsmsx506.amr.corp.intel.com> In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D012641677A@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 30 Aug 2010 13:58:53 -0700 Cc: "vwrap@ietf.org" Subject: Re: [vwrap] [Opensim-dev] Global identifiers X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: diva@metaverseink.com 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, 30 Aug 2010 20:55:57 -0000 I have different answers than Melanie. > An open question with this approach is whether you need to use global identifiers when dealing with cross-grid scenarios, or whether there is always enough context to derive a global identifier. Some examples: > > * A HyperGrid user is teleporting from grid A to grid B. Does grid B have enough information to build the global identifier "gridA/user"? Yes. It already does that on the spot. We don't need persistent global identifiers for agents. The issue we are now talking about is if someone in grid B makes friends with this user. In this case, we need to add an entry to grid B's Friends service referring to an external user, and vice-versa. That's when we need global identifier for this user (not its agent). > * A HyperGrid user rezzes an object into grid B that exists in their inventory on grid A. The object has a creator that is unrecognized to grid B. Should grid B pull the creator profile from grid A (which may actually be storing a local copy of the real creator identity from grid X)? Note that this isn't a question about trust because we're already trusting grid A to provide creator information for the object, it's just about where we pull profile info from. Yes, it should. And since the code that does that is exactly the same code that prepares inventory items for archiving, this should be no different than archiving itself. > * An OAR file is loaded and contains an unrecognized identity. Should identities in OAR files be encoded as global identifiers, or a header added to the OAR file to say "all of this content came from grid A", or the full profiles of all the identities in the OAR embedded right into the archive? I don't think it can be bulk in the general case, although that could be option in some cases. I'm looking at my inventory right now and it's a rainbow of stuff I got from all sorts of places. From diva@metaverseink.com Mon Aug 30 14:08:42 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E2773A6876 for ; Mon, 30 Aug 2010 14:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKjRJqby+BnW for ; Mon, 30 Aug 2010 14:08:40 -0700 (PDT) Received: from smtp.techcoastworks.com (techcoastworks.com [206.82.208.116]) by core3.amsl.com (Postfix) with ESMTP id 140FB3A6855 for ; Mon, 30 Aug 2010 14:08:40 -0700 (PDT) Received: from [192.168.1.105] (adsl-75-34-226-217.dsl.irvnca.sbcglobal.net [75.34.226.217]) (authenticated bits=0) by smtp.techcoastworks.com (8.12.11.20060308/8.12.11) with ESMTP id o7UKptTR013101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Aug 2010 13:51:56 -0700 Message-ID: <4C7C1DF1.3080301@metaverseink.com> Date: Mon, 30 Aug 2010 14:09:05 -0700 From: diva@metaverseink.com Organization: Metaverse Ink User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: opensim-dev@lists.berlios.de References: <4c7ad44d.5f25e30a.782a.0516@mx.google.com>, <1283121840.13484.119.camel@mdickson-linux>, <4C7AE587.30102@t-data.com>, <1283125132.13484.126.camel@mdickson-linux>, <4C7AF48B.3010202@metaverseink.com>, <1283127395.13484.137.camel@mdickson-linux>, <4C7AFB77.907@metaverseink.com>, , <4C7B1E96.5030309@metaverseink.com> <4C7BA1A8.5070102@t-data.com> <4C7BDD91.9070100@metaverseink.com> <62BFE5680C037E4DA0B0A08946C0933D012641677A@rrsmsx506.amr.corp.intel.com> <4C7C1637.5040400@metaverseink.com> <62BFE5680C037E4DA0B0A08946C0933D0126416801@rrsmsx506.amr.corp.intel.com> In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D0126416801@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "vwrap@ietf.org" Subject: Re: [vwrap] [Opensim-dev] Global identifiers X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: diva@metaverseink.com 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, 30 Aug 2010 21:08:42 -0000 Hurliman, John wrote: > My interpretation (please correct me if I'm wrong) is that there is rough consensus on the overall strategy, but an open question of how to encode global identities when cross-grid communication (or out-of-grid archiving) happens. That's what's going on. Up to now, all global identifiers (that already exist) have been volatile; nothing has persisted. As I found myself writing code that would inject global identifiers into a DB table, I thought we should all talk about the form of such identifiers. > There is probably also a hidden question of how to mark a local account as linked to a foreign identity, which may solve the friending issue. If I am friends with your avatar and we are both on grid B but your avatar actually originated from grid A, that link in the profile is what can tip off the presence service to try a remote presence check (assuming the user is not online in the local grid). My only interest in these low level questions like how the global identifiers and profile links look is what the final decision is so I can implement it in the OpenSim SimianGrid connectors. Well, we distinguish "user accounts" from "grid users" -- these are 2 different interfaces, although implementers may decide to collapse them. But they are different concepts. User accounts are the locally-registered users; in some cases, like for example, the UCI grid, there's only some people who can get accounts there, namely people associated with the university. Grid users are users that are referenced by things that happen in the grid. So we already have an interface for that, although now I'm thinking that perhaps we need to separate its UserID field into 2 things: a local UUID and a reference to the external name. And I guess that's my main issue at this point. > > John > >> -----Original Message----- >> From: opensim-dev-bounces@lists.berlios.de [mailto:opensim-dev- >> bounces@lists.berlios.de] On Behalf Of diva@metaverseink.com >> Sent: Monday, August 30, 2010 1:36 PM >> To: opensim-dev@lists.berlios.de >> Cc: vwrap@ietf.org >> Subject: Re: [Opensim-dev] Global identifiers >> >> I have different answers than Melanie. >> >>> An open question with this approach is whether you need to use global >> identifiers when dealing with cross-grid scenarios, or whether there is >> always enough context to derive a global identifier. Some examples: >>> * A HyperGrid user is teleporting from grid A to grid B. Does grid B >> have enough information to build the global identifier "gridA/user"? >> >> Yes. It already does that on the spot. We don't need persistent global >> identifiers for agents. >> >> The issue we are now talking about is if someone in grid B makes >> friends >> with this user. In this case, we need to add an entry to grid B's >> Friends service referring to an external user, and vice-versa. That's >> when we need global identifier for this user (not its agent). >> >>> * A HyperGrid user rezzes an object into grid B that exists in their >> inventory on grid A. The object has a creator that is unrecognized to >> grid B. Should grid B pull the creator profile from grid A (which may >> actually be storing a local copy of the real creator identity from grid >> X)? Note that this isn't a question about trust because we're already >> trusting grid A to provide creator information for the object, it's >> just about where we pull profile info from. >> >> Yes, it should. And since the code that does that is exactly the same >> code that prepares inventory items for archiving, this should be no >> different than archiving itself. >> >>> * An OAR file is loaded and contains an unrecognized identity. Should >> identities in OAR files be encoded as global identifiers, or a header >> added to the OAR file to say "all of this content came from grid A", or >> the full profiles of all the identities in the OAR embedded right into >> the archive? >> >> I don't think it can be bulk in the general case, although that could >> be >> option in some cases. I'm looking at my inventory right now and it's a >> rainbow of stuff I got from all sorts of places. >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > From mysticaldemina@xrgrid.com Mon Aug 30 14:47:06 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910703A68A5 for ; Mon, 30 Aug 2010 14:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Asd+dTh-pNgv for ; Mon, 30 Aug 2010 14:47:04 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id D226F3A6866 for ; Mon, 30 Aug 2010 14:47:03 -0700 (PDT) Received: from [72.94.50.178] (helo=TWEEDY64) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OqCCJ-00047R-P3; Mon, 30 Aug 2010 17:47:23 -0400 From: To: , References: <4c7ad44d.5f25e30a.782a.0516@mx.google.com>, <1283121840.13484.119.camel@mdickson-linux>, <4C7AE587.30102@t-data.com>, <1283125132.13484.126.camel@mdickson-linux>, <4C7AF48B.3010202@metaverseink.com>, <1283127395.13484.137.camel@mdickson-linux>, <4C7AFB77.907@metaverseink.com>, , <4C7B1E96.5030309@metaverseink.com> <4C7BA1A8.5070102@t-data.com> <4C7BDD91.9070100@metaverseink.com> <62BFE5680C037E4DA0B0A08946C0933D012641677A@rrsmsx506.amr.corp.intel.com> <4C7C1637.5040400@metaverseink.com><62BFE5680C037E4DA0B0A08946C0933D0126416801@rrsmsx506.amr.corp.intel.com> <4C7C1DF1.3080301@metaverseink.com> In-Reply-To: <4C7C1DF1.3080301@metaverseink.com> Date: Mon, 30 Aug 2010 17:47:08 -0400 Message-ID: <178ABBCA30DB4E86B365568C521481BB@TWEEDY64> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: ActIh59D1yFEsAK6T1ivTaYRFjb4lgAARt4Q X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 X-ELNK-Trace: be22ee791caf5f441aa676d7e74259b793d4f437769de15029253d3e2127bb4920765dd79bc93fa8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 72.94.50.178 X-Mailman-Approved-At: Mon, 30 Aug 2010 14:58:46 -0700 Cc: vwrap@ietf.org Subject: Re: [vwrap] [Opensim-dev] Global identifiers X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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, 30 Aug 2010 21:47:06 -0000 ETL systems have dealt with this stuff for years and usually there is one main rule, external references are kept separate from internal references and you never carry external references into your internal stuff. As such internal objects often contain a reference or a flag that identifies their external source. So for OpenSim what that means to me is there are profiles, but some profiles are proxies to profiles on external grids. Once these profiles are created they should act and perform like any other locally made profile except for the fact that some of its functions are proxies to the real instance. So I think you have most of this from what I would follow. I would say you need two pieces of information, the external source, and their identifier. The two fields can take completely different forms depending on the external system. If the source was Facebook, it could look completely different than a iphone telephone application that may be external system of ATT and an identifier of a telephone number. Mainly I think you need to make a wall between this external information and the use of the profile internally. If this profile rezzes an object there are several pieces of information I understand you would like to keep, the creator and the owner. To me I see no difference in this, when the object is taken from inventory and an instance is made of it, both of these profiles need to exist locally, but if both are proxies then their profiles will contain the needed references to the external system and identifier. I would say they need to point to the original system and identifier since just like email, no matter how many emails get passed around, the email still refers back to the system of origin. The prim has no system of origin, it only has a creator and an owner. The textures, other prims and other items would all follow the same process. The items would have to be copied locally, local instances made for them and I would think would follow the same caching rules any other item in the world follows. Now if you would take that item back into inventory and travel to another grid and rezz it. I think the question is what you give as the external source and identifier for the creator and owner. I would suggest any proxies would give the external system and identifier and not chain proxy to proxy unless there is a reason to do it, and the assets should be copied from the original source. I think that solves a lot of legal issues to, because you may have rights to use a cached item, but you may not have rights to transfer it. I see IM, friends and everything else working the same. So I probably didn't help you with your original question about global identifiers. From my experience with ETL and large enterprise systems I suggest you have one you like to use but I see there being many forms of these fields because of all the varieties of systems. There may well be authentication codes that go with them to, like OAuth keys giving permissions to access these external items. Regards, M -----Original Message----- From: opensim-dev-bounces@lists.berlios.de [mailto:opensim-dev-bounces@lists.berlios.de] On Behalf Of diva@metaverseink.com Sent: Monday, August 30, 2010 5:09 PM To: opensim-dev@lists.berlios.de Cc: vwrap@ietf.org Subject: Re: [Opensim-dev] Global identifiers Hurliman, John wrote: > My interpretation (please correct me if I'm wrong) is that there is rough consensus on the overall strategy, but an open question of how to encode global identities when cross-grid communication (or out-of-grid archiving) happens. That's what's going on. Up to now, all global identifiers (that already exist) have been volatile; nothing has persisted. As I found myself writing code that would inject global identifiers into a DB table, I thought we should all talk about the form of such identifiers. > There is probably also a hidden question of how to mark a local account as linked to a foreign identity, which may solve the friending issue. If I am friends with your avatar and we are both on grid B but your avatar actually originated from grid A, that link in the profile is what can tip off the presence service to try a remote presence check (assuming the user is not online in the local grid). My only interest in these low level questions like how the global identifiers and profile links look is what the final decision is so I can implement it in the OpenSim SimianGrid connectors. Well, we distinguish "user accounts" from "grid users" -- these are 2 different interfaces, although implementers may decide to collapse them. But they are different concepts. User accounts are the locally-registered users; in some cases, like for example, the UCI grid, there's only some people who can get accounts there, namely people associated with the university. Grid users are users that are referenced by things that happen in the grid. So we already have an interface for that, although now I'm thinking that perhaps we need to separate its UserID field into 2 things: a local UUID and a reference to the external name. And I guess that's my main issue at this point. > > John > >> -----Original Message----- >> From: opensim-dev-bounces@lists.berlios.de [mailto:opensim-dev- >> bounces@lists.berlios.de] On Behalf Of diva@metaverseink.com >> Sent: Monday, August 30, 2010 1:36 PM >> To: opensim-dev@lists.berlios.de >> Cc: vwrap@ietf.org >> Subject: Re: [Opensim-dev] Global identifiers >> >> I have different answers than Melanie. >> >>> An open question with this approach is whether you need to use global >> identifiers when dealing with cross-grid scenarios, or whether there is >> always enough context to derive a global identifier. Some examples: >>> * A HyperGrid user is teleporting from grid A to grid B. Does grid B >> have enough information to build the global identifier "gridA/user"? >> >> Yes. It already does that on the spot. We don't need persistent global >> identifiers for agents. >> >> The issue we are now talking about is if someone in grid B makes >> friends >> with this user. In this case, we need to add an entry to grid B's >> Friends service referring to an external user, and vice-versa. That's >> when we need global identifier for this user (not its agent). >> >>> * A HyperGrid user rezzes an object into grid B that exists in their >> inventory on grid A. The object has a creator that is unrecognized to >> grid B. Should grid B pull the creator profile from grid A (which may >> actually be storing a local copy of the real creator identity from grid >> X)? Note that this isn't a question about trust because we're already >> trusting grid A to provide creator information for the object, it's >> just about where we pull profile info from. >> >> Yes, it should. And since the code that does that is exactly the same >> code that prepares inventory items for archiving, this should be no >> different than archiving itself. >> >>> * An OAR file is loaded and contains an unrecognized identity. Should >> identities in OAR files be encoded as global identifiers, or a header >> added to the OAR file to say "all of this content came from grid A", or >> the full profiles of all the identities in the OAR embedded right into >> the archive? >> >> I don't think it can be bulk in the general case, although that could >> be >> option in some cases. I'm looking at my inventory right now and it's a >> rainbow of stuff I got from all sorts of places. >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev From diva@metaverseink.com Tue Aug 31 10:56:30 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1083A68C8 for ; Tue, 31 Aug 2010 10:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNX484TCqbSJ for ; Tue, 31 Aug 2010 10:56:28 -0700 (PDT) Received: from smtp.techcoastworks.com (techcoastworks.com [206.82.208.116]) by core3.amsl.com (Postfix) with ESMTP id EBEC73A68DF for ; Tue, 31 Aug 2010 10:56:27 -0700 (PDT) Received: from [192.168.1.105] (adsl-75-34-226-217.dsl.irvnca.sbcglobal.net [75.34.226.217]) (authenticated bits=0) by smtp.techcoastworks.com (8.12.11.20060308/8.12.11) with ESMTP id o7VHdf2Z017619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Aug 2010 10:39:42 -0700 Message-ID: <4C7D4264.6080008@metaverseink.com> Date: Tue, 31 Aug 2010 10:56:52 -0700 From: diva@metaverseink.com Organization: Metaverse Ink User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: opensim-dev@lists.berlios.de, "vwrap@ietf.org" References: <4c7cba86.0e28e30a.7473.4a51@mx.google.com> <1283261970.16697.10.camel@mdickson-linux> <4C7D0B9A.3030904@t-data.com> <4C7D1AE8.1090301@metaverseink.com> <4C7D21F6.6020105@metaverseink.com> In-Reply-To: <4C7D21F6.6020105@metaverseink.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] [Opensim-dev] Global identifiers X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: diva@metaverseink.com 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, 31 Aug 2010 17:56:30 -0000 One last thing, possibly of interest to the folks in VWRAP: Another thing that happened to OpenSim as it reached 0.7 was the reconceptualization of the software itself. As a consequence of this reconceptualization, interoperability architectures such as the Hypergrid are built as optional components that don't affect the core of the walled-garden code. As such, for those who don't like the Hypergrid for whatever reason, you can experiment with your own ideas of interoperability without having to tip toe around it. I suggest you understand HG1.5 first, as not to reimplement it again. Then, if what you want to do is really different, and not just a layer of *policy* above HG1.5 (policy specifications will be supported soon), follow the same philosophy of modularizing things properly, as that will give your architecture a chance for people to use as plugin. If you run into a missing hook, just let me know. Bottom line wrt interop, two major things happened: 1) the hypergrid 1.5, a system-to-system (S2S) architecture with the trust/security model explained below; and 2) the clean up of the framework, allowing anyone to experiment with interop. diva@metaverseink.com wrote: > One more thing, a bit less important than the others, as the others > pertain to grid-level content, and this one pertains to user-level content: > > - WRT to the user agent itself (i.e. name, appearance, etc.), the user's > user agent service (a grid-level service) is the party responsible for > creating user agents that are launched at foreign grids. As such, that > component is the authority that defines what agent data to send. If the > user agent service of one grid so wishes, all of its users' agents can > be anonymized and stripped off their clothes before going out. > > - HG 1.5 has another, symmetric, grid-level component called the > Gatekeeper which has the role of deciding what comes in to its grid. So > if the Gatekeeper so wishes, it can anonymize all foreign user agents > and strip them off their clothes before allowing them in. > > In other words, the user agent service and the gatekeeper service are > the yin and yang of the Hypergrid. > > diva@metaverseink.com wrote: >> [unrelated to the narrow issue at hand, but since people want to know, >> here goes] >> >> HG 1.5 has a trust/security model. The base case is one where grids >> are peers, and the traveling of one user agent from his home grid to >> another establishes the *base trust* in the following manner: >> >> - Everything that the agent references from his home grid is made >> available to the foreign grid where the user is. In other words, the >> user is the driver of trust. >> >> - Everything else that is not referenced by the visiting agent is out >> of reach. "Out of reach" is a soft security model, i.e. the resources >> are available on the internet, but you need to know their identifiers >> in order to get them. Their identifiers behave as capabilities. This >> is the part that still needs work, as Melanie thinks 'soft' is not >> enough. >> >> This trust model is the base upon which trust policies can be defined. >> In other words, we now have the basis to add additional grid-level >> specifications that overwrite the user's actions. >> >> Melanie wrote: >>> Hi, >>> >>> HG 1.5 doesn't address these concerns. Also, please remember that >>> assets need to be freely available to all, else they can't be >>> displayed. The observer gets a copy, too. >>> >>> Animations, textures, sounds, etc. need to be given to all observers. >>> >>> Melanie >>> >>> Mike Dickson wrote: >>>> Right. I think some of the use cases related to how content is shared >>>> have been glossed over. In a completely open model which is what has >>>> been discussed this is all pretty straightforward. But if I'm running >>>> an asset service (as part of a grid or separately) I might want to >>>> provide access controls as part of that service. The same with user >>>> services. I may have a trust relationship with one agent service and >>>> allow content to be transferred to agents that service represents. But >>>> for another agent service for which no such relationship exists I'd >>>> like >>>> to deny access to content. And even in the transfer case does the new >>>> user get a new copy or a reference. That concept isn't supported now >>>> but >>>> in a distributed grid its an important distinction. I might wish to >>>> know >>>> that copies of objects rezzed in a simulator always come from a >>>> specific >>>> asset service. >>>> >>>> In short I think how the security model works is way more important >>>> than >>>> a caching optimization being applied to a URI/URL. Its important to >>>> understand what levels of trust between services are supported and >>>> under >>>> what conditions an access is supported. As an Agent Service I may >>>> consider even the "Names" of my users to be confidential and only to be >>>> revealed to services for which a trust relationship exists. >>>> >>>> Mike >>>> >>>> On Tue, 2010-08-31 at 13:23 +0000, mysticaldemina@xrgrid.com wrote: >>>>> Hi, >>>>> >>>>> As a content creator this concerns me. I believe if I license my >>>>> content to >>>>> an avatar, and then they go to another grid that any content pulled >>>>> should >>>>> be from the grid that I have the content loaded into. I think I >>>>> should be >>>>> in control of my content. I also think I should be able to block >>>>> grids that >>>>> my content is being accessed from. If you don't always maintain the >>>>> original content location there will be no control. If I give >>>>> someone a >>>>> copy of my content, then that is something else, they are now the >>>>> owner of >>>>> it and are free to do as they please with it, at least within any >>>>> license I >>>>> give them. But that is a legal stuff not a technically programmed >>>>> one. At >>>>> least I don't expect all situations to be programmed. >>>>> >>>>> Also when asset services start happening this will become more of >>>>> an issue. >>>>> I will have XRMarketplace.com live soon and plan to start selling >>>>> content >>>>> and provide that content as an asset server. How will I maintain >>>>> any kind >>>>> of control over the use of my content if people don't have to pull >>>>> copies >>>>> from me? >>>>> >>>>> I also think, and haven't seen in the new hypergrid, if someone >>>>> goes to a >>>>> new grid I may not allow any of my content to go there unless that >>>>> avatars >>>>> gets an authorization from me which should be attached to his proxy >>>>> profile >>>>> for access into my grid/asset server. >>>>> >>>>> The other thing to think about is how updates or corrections are >>>>> propagated. >>>>> SL has a terrible system of only supporting copies so any updates >>>>> or copies >>>>> have to be sent to everyone. Seems content replacement needs to be >>>>> supported and if content is all over the place this will get even >>>>> crazier. >>>>> Also to support dynamic content there needs to be a ways to refresh or >>>>> update content. I suggest there needs to be an expiration date on the >>>>> content just like how images and HTML pages on the web work so that >>>>> cached >>>>> content will know to pull a new copy. And if the expiration date >>>>> is 0, at >>>>> the time it was pulled, it will always get refreshed. >>>>> >>>>> This is maybe should have its own discussion thread but seems to be >>>>> part of >>>>> how this is all going to work. >>>>> >>>>> M. >>>>> >>>>> -----Original Message----- >>>>> From: opensim-dev-bounces@lists.berlios.de >>>>> [mailto:opensim-dev-bounces@lists.berlios.de] On Behalf Of Ai Austin >>>>> Sent: Tuesday, August 31, 2010 4:17 AM >>>>> To: opensim-dev@lists.berlios.de >>>>> Subject: Re: [Opensim-dev] Global identifiers >>>>> >>>>> myticaldemina makes a lot of good points... one thing that could be >>>>> problematic though relates to this comment... >>>>> >>>>>> From: >>>>>> ...I would suggest any >>>>>> proxies would give the external system and identifier and not >>>>>> chain proxy >>>>> to >>>>>> proxy unless there is a reason to do it, and the assets should be >>>>>> copied >>>>> >from the original source. >>>>> >>>>> >>>>> I agree with the first half... no chains, just hand over the >>>>> external system "authority" and its given identifier pair for the >>>>> identity involved. >>>>> >>>>> But I don't agree at all with the idea that you then have to get >>>>> the asset from that original authority. The permissions could have >>>>> changed, corruptions could have occurred or much more likely the >>>>> authority simply will no longer be there. The asset "as is" (with >>>>> its textures, scripted content and what not) should be provided to >>>>> the destination location/grid if the object permissions allow it, >>>>> with proper transfer of the permissions to next owner exactly as if >>>>> an avatar to avatar transfer or rez in world took place on the >>>>> local grid, without trying to reload the asset from an original >>>>> source. >>>>> . >>>>> >>>>> >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> Opensim-dev@lists.berlios.de >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>>> >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> Opensim-dev@lists.berlios.de >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev@lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > From josh@lindenlab.com Tue Aug 31 11:28:13 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084113A69D3 for ; Tue, 31 Aug 2010 11:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.373 X-Spam-Level: X-Spam-Status: No, score=-101.373 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1ze6WNR1w9G for ; Tue, 31 Aug 2010 11:28:10 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id E68D03A69C5 for ; Tue, 31 Aug 2010 11:28:09 -0700 (PDT) Received: by wwb17 with SMTP id 17so58650wwb.13 for ; Tue, 31 Aug 2010 11:28:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.128.13 with SMTP id i13mr6952749wbs.31.1283279317612; Tue, 31 Aug 2010 11:28:37 -0700 (PDT) Received: by 10.227.131.214 with HTTP; Tue, 31 Aug 2010 11:28:37 -0700 (PDT) In-Reply-To: <4C7D4264.6080008@metaverseink.com> References: <4c7cba86.0e28e30a.7473.4a51@mx.google.com> <1283261970.16697.10.camel@mdickson-linux> <4C7D0B9A.3030904@t-data.com> <4C7D1AE8.1090301@metaverseink.com> <4C7D21F6.6020105@metaverseink.com> <4C7D4264.6080008@metaverseink.com> Date: Tue, 31 Aug 2010 11:28:37 -0700 Message-ID: From: Joshua Bell To: diva@metaverseink.com, "vwrap@ietf.org" Content-Type: multipart/alternative; boundary=0016367fb15ddfe536048f22bf29 Subject: Re: [vwrap] [Opensim-dev] Global identifiers X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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, 31 Aug 2010 18:28:13 -0000 --0016367fb15ddfe536048f22bf29 Content-Type: text/plain; charset=UTF-8 (Dropping opensim-dev from the distribution list - cross-posting between moderated lists is not ideal, and the conversation tends to be quite hard to follow. My apologies if this makes it worse.) Thanks for dropping in, Diva! This discussion is completely within the bounds of the VWRAP charter, so it's perfectly welcome on the vwrap@ietf.org list, if it's being done with an eye towards encouraging independent implementations. Don't feel that you're intruding at all - quite the opposite! This would be a great place to hash out details of security/trust models and protocols for data transport between virtual world instances, with the benefit of input from other list contributors who have experience in related areas. That's what this working group is chartered with, after all. As an example, over on the opensim-dev list branch of this thread, I noticed some conversation about the global identifiers that implied parsing URLs to extract data, rather than treating them as opaque references to resources. That's generally considered a big "no-no" and runs contrary to the collected wisdom of the IETF for several reasons (that I'm sure folks will be glad to enumerate), and there are alternate patterns that should be followed. Hopefully, input on that level would be appreciated - if so, please do take advantage of this forum. On Tue, Aug 31, 2010 at 10:56 AM, wrote: > One last thing, possibly of interest to the folks in VWRAP: > > Another thing that happened to OpenSim as it reached 0.7 was the > reconceptualization of the software itself. As a consequence of this > reconceptualization, interoperability architectures such as the Hypergrid > are built as optional components that don't affect the core of the > walled-garden code. > > As such, for those who don't like the Hypergrid for whatever reason, you > can experiment with your own ideas of interoperability without having to tip > toe around it. I suggest you understand HG1.5 first, as not to reimplement > it again. Then, if what you want to do is really different, and not just a > layer of *policy* above HG1.5 (policy specifications will be supported > soon), follow the same philosophy of modularizing things properly, as that > will give your architecture a chance for people to use as plugin. If you run > into a missing hook, just let me know. > > Bottom line wrt interop, two major things happened: 1) the hypergrid 1.5, a > system-to-system (S2S) architecture with the trust/security model explained > below; and 2) the clean up of the framework, allowing anyone to experiment > with interop. > > diva@metaverseink.com wrote: > >> One more thing, a bit less important than the others, as the others >> pertain to grid-level content, and this one pertains to user-level content: >> >> - WRT to the user agent itself (i.e. name, appearance, etc.), the user's >> user agent service (a grid-level service) is the party responsible for >> creating user agents that are launched at foreign grids. As such, that >> component is the authority that defines what agent data to send. If the user >> agent service of one grid so wishes, all of its users' agents can be >> anonymized and stripped off their clothes before going out. >> >> - HG 1.5 has another, symmetric, grid-level component called the >> Gatekeeper which has the role of deciding what comes in to its grid. So if >> the Gatekeeper so wishes, it can anonymize all foreign user agents and strip >> them off their clothes before allowing them in. >> >> In other words, the user agent service and the gatekeeper service are the >> yin and yang of the Hypergrid. >> >> diva@metaverseink.com wrote: >> >>> [unrelated to the narrow issue at hand, but since people want to know, >>> here goes] >>> >>> HG 1.5 has a trust/security model. The base case is one where grids are >>> peers, and the traveling of one user agent from his home grid to another >>> establishes the *base trust* in the following manner: >>> >>> - Everything that the agent references from his home grid is made >>> available to the foreign grid where the user is. In other words, the user is >>> the driver of trust. >>> >>> - Everything else that is not referenced by the visiting agent is out of >>> reach. "Out of reach" is a soft security model, i.e. the resources are >>> available on the internet, but you need to know their identifiers in order >>> to get them. Their identifiers behave as capabilities. This is the part that >>> still needs work, as Melanie thinks 'soft' is not enough. >>> >>> This trust model is the base upon which trust policies can be defined. In >>> other words, we now have the basis to add additional grid-level >>> specifications that overwrite the user's actions. >>> >>> Melanie wrote: >>> >>>> Hi, >>>> >>>> HG 1.5 doesn't address these concerns. Also, please remember that >>>> assets need to be freely available to all, else they can't be >>>> displayed. The observer gets a copy, too. >>>> >>>> Animations, textures, sounds, etc. need to be given to all observers. >>>> >>>> Melanie >>>> >>>> Mike Dickson wrote: >>>> >>>>> Right. I think some of the use cases related to how content is shared >>>>> have been glossed over. In a completely open model which is what has >>>>> been discussed this is all pretty straightforward. But if I'm running >>>>> an asset service (as part of a grid or separately) I might want to >>>>> provide access controls as part of that service. The same with user >>>>> services. I may have a trust relationship with one agent service and >>>>> allow content to be transferred to agents that service represents. But >>>>> for another agent service for which no such relationship exists I'd >>>>> like >>>>> to deny access to content. And even in the transfer case does the new >>>>> user get a new copy or a reference. That concept isn't supported now >>>>> but >>>>> in a distributed grid its an important distinction. I might wish to >>>>> know >>>>> that copies of objects rezzed in a simulator always come from a >>>>> specific >>>>> asset service. >>>>> >>>>> In short I think how the security model works is way more important >>>>> than >>>>> a caching optimization being applied to a URI/URL. Its important to >>>>> understand what levels of trust between services are supported and >>>>> under >>>>> what conditions an access is supported. As an Agent Service I may >>>>> consider even the "Names" of my users to be confidential and only to be >>>>> revealed to services for which a trust relationship exists. >>>>> >>>>> Mike >>>>> >>>>> On Tue, 2010-08-31 at 13:23 +0000, mysticaldemina@xrgrid.com wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> As a content creator this concerns me. I believe if I license my >>>>>> content to >>>>>> an avatar, and then they go to another grid that any content pulled >>>>>> should >>>>>> be from the grid that I have the content loaded into. I think I >>>>>> should be >>>>>> in control of my content. I also think I should be able to block >>>>>> grids that >>>>>> my content is being accessed from. If you don't always maintain the >>>>>> original content location there will be no control. If I give someone >>>>>> a >>>>>> copy of my content, then that is something else, they are now the >>>>>> owner of >>>>>> it and are free to do as they please with it, at least within any >>>>>> license I >>>>>> give them. But that is a legal stuff not a technically programmed >>>>>> one. At >>>>>> least I don't expect all situations to be programmed. >>>>>> >>>>>> Also when asset services start happening this will become more of an >>>>>> issue. >>>>>> I will have XRMarketplace.com live soon and plan to start selling >>>>>> content >>>>>> and provide that content as an asset server. How will I maintain any >>>>>> kind >>>>>> of control over the use of my content if people don't have to pull >>>>>> copies >>>>>> from me? >>>>>> >>>>>> I also think, and haven't seen in the new hypergrid, if someone goes >>>>>> to a >>>>>> new grid I may not allow any of my content to go there unless that >>>>>> avatars >>>>>> gets an authorization from me which should be attached to his proxy >>>>>> profile >>>>>> for access into my grid/asset server. >>>>>> >>>>>> The other thing to think about is how updates or corrections are >>>>>> propagated. >>>>>> SL has a terrible system of only supporting copies so any updates or >>>>>> copies >>>>>> have to be sent to everyone. Seems content replacement needs to be >>>>>> supported and if content is all over the place this will get even >>>>>> crazier. >>>>>> Also to support dynamic content there needs to be a ways to refresh or >>>>>> update content. I suggest there needs to be an expiration date on the >>>>>> content just like how images and HTML pages on the web work so that >>>>>> cached >>>>>> content will know to pull a new copy. And if the expiration date is >>>>>> 0, at >>>>>> the time it was pulled, it will always get refreshed. >>>>>> >>>>>> This is maybe should have its own discussion thread but seems to be >>>>>> part of >>>>>> how this is all going to work. >>>>>> >>>>>> >>>>>> M. >>>>>> >>>>>> -----Original Message----- >>>>>> From: opensim-dev-bounces@lists.berlios.de >>>>>> [mailto:opensim-dev-bounces@lists.berlios.de] On Behalf Of Ai Austin >>>>>> Sent: Tuesday, August 31, 2010 4:17 AM >>>>>> To: opensim-dev@lists.berlios.de >>>>>> Subject: Re: [Opensim-dev] Global identifiers >>>>>> >>>>>> myticaldemina makes a lot of good points... one thing that could be >>>>>> problematic though relates to this comment... >>>>>> >>>>>> From: >>>>>>> ...I would suggest any >>>>>>> >>>>>>> proxies would give the external system and identifier and not chain >>>>>>> proxy >>>>>>> >>>>>> to >>>>>> >>>>>>> proxy unless there is a reason to do it, and the assets should be >>>>>>> copied >>>>>>> >>>>>> >from the original source. >>>>>> >>>>>> >>>>>> I agree with the first half... no chains, just hand over the external >>>>>> system "authority" and its given identifier pair for the identity involved. >>>>>> >>>>>> But I don't agree at all with the idea that you then have to get the >>>>>> asset from that original authority. The permissions could have changed, >>>>>> corruptions could have occurred or much more likely the authority simply >>>>>> will no longer be there. The asset "as is" (with its textures, scripted >>>>>> content and what not) should be provided to the destination location/grid if >>>>>> the object permissions allow it, with proper transfer of the permissions to >>>>>> next owner exactly as if an avatar to avatar transfer or rez in world took >>>>>> place on the local grid, without trying to reload the asset from an original >>>>>> source. >>>>>> >>>>>> . >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Opensim-dev mailing list >>>>>> Opensim-dev@lists.berlios.de >>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>>>> >>>>>> _______________________________________________ >>>>>> Opensim-dev mailing list >>>>>> Opensim-dev@lists.berlios.de >>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> Opensim-dev@lists.berlios.de >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>>> >>>>> >>>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev@lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --0016367fb15ddfe536048f22bf29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(Dropping opensim-dev from the distribution list - cross-posting betwe= en moderated lists is not ideal, and the conversation tends to be quite har= d to follow. My apologies if this makes it worse.)

Than= ks for dropping in, Diva!=C2=A0

This discussion is completely within the bounds of the VWRAP= charter, so it's perfectly welcome on the vwrap@ietf.org list, if it's being done with an eye towards e= ncouraging=C2=A0independent=C2=A0implementations.=C2=A0Don't feel that = you're intruding at all - quite the opposite!

This would be a great place to hash out details of secu= rity/trust models and protocols for data transport between virtual world in= stances, with the benefit of input from other list contributors who have ex= perience in related areas. That's what this working group is chartered = with, after all.

As an example, over on the opensim-dev list branch of t= his thread, I noticed some conversation about the global identifiers that i= mplied parsing URLs to extract data, rather than treating them as opaque re= ferences to resources. That's generally considered a big "no-no&qu= ot; and runs contrary to the collected wisdom of the IETF for several reaso= ns (that I'm sure folks will be glad to enumerate), and there are alter= nate patterns that should be followed. Hopefully, input on that level would= be appreciated - if so, please do take advantage of this forum.

On Tue, Aug 31, 2010 at 10:56 AM, <diva@metaversein= k.com> wrote:
One last thing, possibly of interest to the folks in VWRAP:

Another thing that happened to OpenSim as it reached 0.7 was the reconceptu= alization of the software itself. As a consequence of this reconceptualizat= ion, interoperability architectures such as the Hypergrid are built as opti= onal components that don't affect the core of the walled-garden code.
As such, for those who don't like the Hypergrid for whatever reason, yo= u can experiment with your own ideas of interoperability without having to = tip toe around it. I suggest you understand HG1.5 first, as not to reimplem= ent it again. Then, if what you want to do is really different, and not jus= t a layer of *policy* above HG1.5 (policy specifications will be supported = soon), follow the same philosophy of modularizing things properly, as that = will give your architecture a chance for people to use as plugin. If you ru= n into a missing hook, just let me know.

Bottom line wrt interop, two major things happened: 1) the hypergrid 1.5, a= system-to-system (S2S) architecture with the trust/security model explaine= d below; and 2) the clean up of the framework, allowing anyone to experimen= t with interop.

diva@metaversein= k.com wrote:
One more thing, a bit less important than the others, as the others pertain= to grid-level content, and this one pertains to user-level content:

- WRT to the user agent itself (i.e. name, appearance, etc.), the user'= s user agent service (a grid-level service) is the party responsible for cr= eating user agents that are launched at foreign grids. As such, that compon= ent is the authority that defines what agent data to send. If the user agen= t service of one grid so wishes, all of its users' agents can be anonym= ized and stripped off their clothes before going out.

- HG 1.5 has another, symmetric, grid-level component called the Gatekeeper= which has the role of deciding what comes in to its grid. So if the Gateke= eper so wishes, it can anonymize all foreign user agents and strip them off= their clothes before allowing them in.

In other words, the user agent service and the gatekeeper service are the y= in and yang of the Hypergrid.

diva@metaversein= k.com wrote:
[unrelated to the narrow issue at hand, but since people want to know, here= goes]

HG 1.5 has a trust/security model. The base case is one where grids are pee= rs, and the traveling of one user agent from his home grid to another estab= lishes the *base trust* in the following manner:

- Everything that the agent references from his home grid is made available= to the foreign grid where the user is. In other words, the user is the dri= ver of trust.

- Everything else that is not referenced by the visiting agent is out of re= ach. "Out of reach" is a soft security model, i.e. the resources = are available on the internet, but you need to know their identifiers in or= der to get them. Their identifiers behave as capabilities. This is the part= that still needs work, as Melanie thinks 'soft' is not enough.

This trust model is the base upon which trust policies can be defined. In o= ther words, we now have the basis to add additional grid-level specificatio= ns that overwrite the user's actions.

Melanie wrote:
Hi,

HG 1.5 doesn't address these concerns. Also, please remember that
assets need to be freely available to all, else they can't be
displayed. The observer gets a copy, too.

Animations, textures, sounds, etc. need to be given to all observers.

Melanie

Mike Dickson wrote:
Right. I think some of the use cases related to how content is shared
have been glossed over. In a completely open model which is what has
been discussed this is all pretty straightforward. =C2=A0But if I'm run= ning
an asset service (as part of a grid or separately) I might want to
provide access controls as part of that service. The same with user
services. =C2=A0I may have a trust relationship with one agent service and<= br> allow content to be transferred to agents that service represents. But
for another agent service for which no such relationship exists I'd lik= e
to deny access to content. And even in the transfer case does the new
user get a new copy or a reference. That concept isn't supported now bu= t
in a distributed grid its an important distinction. I might wish to know that copies of objects rezzed in a simulator always come from a specific asset service.

In short I think how the security model works is way more important than a caching optimization being applied to a URI/URL. =C2=A0Its important to understand what levels of trust between services are supported and under what conditions an access is supported. =C2=A0As an Agent Service I may
consider even the "Names" of my users to be confidential and only= to be
revealed to services for which a trust relationship exists.

Mike

On Tue, 2010-08-31 at 13:23 +0000, mysticaldemina@xrgrid.com wrote:
Hi,

As a content creator this concerns me. =C2=A0I believe if I license my cont= ent to
an avatar, and then they go to another grid that any content pulled should<= br> be from the grid that I have the content loaded into. =C2=A0I think I shoul= d be
in control of my content. =C2=A0I also think I should be able to block grid= s that
my content is being accessed from. =C2=A0If you don't always maintain t= he
original content location there will be no control. =C2=A0If I give someone= a
copy of my content, then that is something else, they are now the owner of<= br> it and are free to do as they please with it, at least within any license I=
give them. =C2=A0But that is a legal stuff not a technically programmed one= . =C2=A0At
least I don't expect all situations to be programmed.

Also when asset services start happening this will become more of an issue.=
I will have XRMarketplace.com live soon and plan to start selling content and provide that content as an asset server. =C2=A0How will I maintain any = kind
of control over the use of my content if people don't have to pull copi= es
from me?

I also think, and haven't seen in the new hypergrid, if someone goes to= a
new grid I may not allow any of my content to go there unless that avatars<= br> gets an authorization from me which should be attached to his proxy profile=
for access into my grid/asset server.

The other thing to think about is how updates or corrections are propagated= .
SL has a terrible system of only supporting copies so any updates or copies=
have to be sent to everyone. =C2=A0Seems content replacement needs to be supported and if content is all over the place this will get even crazier.<= br> Also to support dynamic content there needs to be a ways to refresh or
update content. =C2=A0I suggest there needs to be an expiration date on the=
content just like how images and HTML pages on the web work so that cached<= br> content will know to pull a new copy. =C2=A0And if the expiration date is 0= , at
the time it was pulled, it will always get refreshed.

This is maybe should have its own discussion thread but seems to be part of=
how this is all going to work.


M.

-----Original Message-----
From: opensim-dev-bounces@lists.berlios.de
[mailto:opensim-dev-bounces@lists.berlios.de] On Behalf Of Ai Austin
Sent: Tuesday, August 31, 2010 4:17 AM
To: opens= im-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Global identifiers

myticaldemina makes a lot of good points... one thing that could be problem= atic though relates to this comment...

From: <my= sticaldemina@xrgrid.com>
...I would suggest any

proxies would give the external system and identifier and not chain proxy
to
proxy unless there is a reason to do it, and the assets should be copied
>from the original source.


I agree with the first half... no chains, just hand over the external syste= m "authority" and its given identifier pair for the identity invo= lved.

But I don't agree at all with the idea that you then have to get the as= set from that original authority. =C2=A0The permissions could have changed,= corruptions could have occurred or much more likely the authority simply w= ill no longer be there. =C2=A0The asset "as is" (with its texture= s, scripted content and what not) should be provided to the destination loc= ation/grid if the object permissions allow it, with proper transfer of the = permissions to next owner exactly as if an avatar to avatar transfer or rez= in world took place on the local grid, without trying to reload the asset = from an original source.

.


_______________________________________________
Opensim-dev mailing list
Opensim-d= ev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
Opensim-d= ev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
Opensim-d= ev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
Opensim-d= ev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
Opensim-d= ev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
Opensim-d= ev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

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

--0016367fb15ddfe536048f22bf29-- From lopes@ics.uci.edu Tue Aug 31 12:50:13 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726033A6A76 for ; Tue, 31 Aug 2010 12:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZXLvRz0BT7L for ; Tue, 31 Aug 2010 12:50:10 -0700 (PDT) Received: from david-tennant-v0.ics.uci.edu (david-tennant-v0.ics.uci.edu [128.195.1.174]) by core3.amsl.com (Postfix) with ESMTP id B95A93A6A8C for ; Tue, 31 Aug 2010 12:50:09 -0700 (PDT) Received: from tagus.ics.uci.edu (barbara-wright.ics.uci.edu [128.195.1.137]) by david-tennant-v0.ics.uci.edu (8.13.8/8.13.8) with ESMTP id o7VJoWkp016402 for ; Tue, 31 Aug 2010 12:50:32 -0700 Message-Id: <1F8EA561-D5EE-4673-978A-A2A5814684CD@ics.uci.edu> From: Cristina Videira Lopes To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-122-34354473 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 31 Aug 2010 12:50:32 -0700 X-Mailer: Apple Mail (2.936) X-ICS-MailScanner-Information: Please send mail to helpdesk@ics.uci.edu or more information X-ICS-MailScanner-ID: o7VJoWkp016402 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.362, required 5, autolearn=disabled, ALL_TRUSTED -1.44, HTML_MESSAGE 0.00, TW_VW 0.08) X-ICS-MailScanner-From: lopes@ics.uci.edu Subject: [vwrap] Hello world X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 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, 31 Aug 2010 19:51:34 -0000 --Apple-Mail-122-34354473 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Thanks, Josh! I'm signing in to this ML with my other identity, Crista =20= Lopes @ UCI. So don't be confused, I'm the same person behind = diva@metaversink.com=20 , and 'diva' is my pseudonym for all things open source. Here's my =20 introductory message. I'm a core developer of OpenSimulator, and the main architect of the =20 Hypergrid -- but by no means the only one. As you may have heard, =20 OpenSim reached its 0.7 version a couple of months ago; it was a hard, =20= painful labour with foundation work taking priority over feature work. =20= But it's here, and it uber-rocks! I can't stress enough the social impacts of the rewrite of the =20 framework. What we had before was a straight jacket for innovation, =20 and would have led to horrible clashes of the titans (read forks), as =20= people have very different ideas about what to do with virtual worlds. One of those contention points was interoperability between virtual =20 worlds. All that is now free of contention! The OpenSim framework =20 doesn't impose anything at all, and these virtual worlds can load any =20= network connectors and security checks that people plug into them. Now that the code is out of the way, the only agreements are those =20 that groups of people *voluntarily* decide to agree upon. With the =20 comfort of knowing that, if agreements are not reached, we don't need =20= to fork the core code that does simulation, we just need to provide =20 different plugins for people to use. (Not that I'm advocating =20 disagreement, but it's always good to have a solid Plan B) Having that as stepping stone, we continued to work on the Hypergrid =20 architecture, which is now in its 1.5 version, and has a decent trust/=20= security model -- as opposed to 1.0 which had a deficient trust/=20 security model. I'll be happy to explain how it works, as I'm working =20= on a paper that does that. I know some of you here in this group felt insulted that I didn't join =20= VWRAP when it was created. I stated my reasons at the time, which =20 boiled down to three points: (1) lack of time -- it was either working =20= on code or working on standards, but not both; (2) my impression that =20= the effort of defining standards for VWs was premature, because there =20= were no concrete solutions for interoperability, not even HG1.0 much =20 less OGP, and people would better invest their time in implementation =20= efforts; and (3) my impression that Linden Lab was using this group as =20= a marketing tool. Things have changed (except for (1) lack of time... :-). So here I am. Best, Crista ----------------- =95 From: Joshua Bell =95 To: diva at metaverseink.com, "vwrap at ietf.org" =95 Date: Tue, 31 Aug 2010 11:28:37 -0700 (Dropping opensim-dev from the distribution list - cross-posting =20 between moderated lists is not ideal, and the conversation tends to be =20= quite hard to follow. My apologies if this makes it worse.) Thanks for dropping in, Diva! This discussion is completely within the bounds of the VWRAP charter, =20= so it's perfectly welcome on the vwrap at ietf.org list, if it's being =20= done with an eye towards encouraging independent implementations. =20 Don't feel that you're intruding at all - quite the opposite! This would be a great place to hash out details of security/trust =20 models and protocols for data transport between virtual world =20 instances, with the benefit of input from other list contributors who =20= have experience in related areas. That's what this working group is =20 chartered with, after all. As an example, over on the opensim-dev list branch of this thread, I =20 noticed some conversation about the global identifiers that implied =20 parsing URLs to extract data, rather than treating them as opaque =20 references to resources. That's generally considered a big "no-no" and =20= runs contrary to the collected wisdom of the IETF for several reasons =20= (that I'm sure folks will be glad to enumerate), and there are =20 alternate patterns that should be followed. Hopefully, input on that =20 level would be appreciated - if so, please do take advantage of this =20 forum. --Apple-Mail-122-34354473 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
Thanks, Josh! I'm signing = in to this ML with my other identity, Crista Lopes @ UCI. So don't be = confused, I'm the same person behind diva@metaversink.com, and = 'diva' is my pseudonym for all things open source. Here's my = introductory message.

I'm a core developer of = OpenSimulator, and the main architect of the Hypergrid -- but by no = means the only one. As you may have heard, OpenSim reached its 0.7 = version a couple of months ago; it was a hard, painful labour with = foundation work taking priority over feature work. But it's here, and it = uber-rocks!

I can't stress enough the social = impacts of the rewrite of the framework. What we had before was a = straight jacket for innovation, and would have led to horrible clashes = of the titans (read forks), as people have very different ideas about = what to do with virtual worlds.

One of those = contention points was interoperability between virtual worlds. All that = is now free of contention! The OpenSim framework doesn't impose anything = at all, and these virtual worlds can load any network connectors and = security checks that people plug into = them. 

Now that the code is out of the = way, the only agreements are those that groups of people *voluntarily* = decide to agree upon. With the comfort of knowing that, if agreements = are not reached, we don't need to fork the core code that does = simulation, we just need to provide different plugins for people to use. = (Not that I'm advocating disagreement, but it's always good to have a = solid Plan B)

Having that as stepping stone, we = continued to work on the Hypergrid architecture, which is now in its 1.5 = version, and has a decent trust/security model -- as opposed to 1.0 = which had a deficient trust/security model. I'll be happy to explain how = it works, as I'm working on a paper that does = that.

I know some of you here in this group = felt insulted that I didn't join VWRAP when it was created. I stated my = reasons at the time, which boiled down to three points: (1) lack of time = -- it was either working on code or working on standards, but not both; = (2) my impression that the effort of defining standards for VWs was = premature, because there were no concrete solutions for = interoperability, not even HG1.0 much less OGP, and people would better = invest their time in implementation efforts; and (3) my impression that = Linden Lab was using this group as a marketing = tool.

Things have changed (except for (1) lack = of time... :-). So here I = am.

Best,
Crista

-----------------
=95 From: Joshua Bell <josh at = lindenlab.com>
=95 To: diva at metaverseink.com, = "vwrap at ietf.org" <vwrap at ietf.org>
=95 Date: Tue, = 31 Aug 2010 11:28:37 -0700

(Dropping = opensim-dev from the distribution list - cross-posting=20 between moderated lists is not ideal, and the conversation tends to be=20= quite hard to follow. My apologies if this makes it = worse.)

Thanks for dropping in, Diva! 

This discussion is completely within the bounds of the = VWRAP charter, so it's perfectly welcome on the vwrap at ietf.org list, if it's being done with an eye towards=20 encouraging independent implementations. Don't feel that = you're=20 intruding at all - quite the opposite!

This would be a great place to hash out details of=20= security/trust models and protocols for data transport between virtual=20= world instances, with the benefit of input from other list contributors=20= who have experience in related areas. That's what this working group is=20= chartered with, after all.

As an example, over on the opensim-dev = list branch of this thread, I noticed some conversation about the global identifiers that implied=20 parsing URLs to extract data, rather than treating them as opaque=20 references to resources. That's generally considered a big "no-no" and=20= runs contrary to the collected wisdom of the IETF for several reasons=20 (that I'm sure folks will be glad to enumerate), and there are alternate patterns that should be followed. Hopefully, input on that level would=20= be appreciated - if so, please do take advantage of this forum.

= --Apple-Mail-122-34354473--