From carlo@alinoe.com Fri Apr 1 06:43:32 2011 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 B66283A67FC for ; Fri, 1 Apr 2011 06:43:32 -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=[AWL=0.000, 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 791SfcGAKFMK for ; Fri, 1 Apr 2011 06:43:32 -0700 (PDT) Received: from fep16.mx.upcmail.net (fep16.mx.upcmail.net [62.179.121.36]) by core3.amsl.com (Postfix) with ESMTP id B6F533A67FA for ; Fri, 1 Apr 2011 06:43:31 -0700 (PDT) Received: from edge02.upcmail.net ([192.168.13.237]) by viefep16-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110401134510.TNVC9043.viefep16-int.chello.at@edge02.upcmail.net> for ; Fri, 1 Apr 2011 15:45:10 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge02.upcmail.net with edge id SDl91g00c0FlQed02DlAhM; Fri, 01 Apr 2011 15:45:10 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q5eez-00059Y-2W for vwrap@ietf.org; Fri, 01 Apr 2011 15:45:09 +0200 Date: Fri, 1 Apr 2011 15:45:09 +0200 From: Carlo Wood To: vwrap@ietf.org Message-ID: <20110401154509.5ce33fe0@hikaru.localdomain> In-Reply-To: <4D931434.2030206@boroon.dasgupta.ch> References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=vUpxTctd+kpWCBtSXXIkt5ll4Z8E5Qu9nLREXC/hfIo= c=1 sm=0 a=GIqV-yxGZKkA:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=BjFOTwK7AAAA:8 a=fg5VQgl67aBte82kfrkA:9 a=CjuIK1q_8ugA:10 a=bW3kdApBr58A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 01 Apr 2011 13:43:32 -0000 On Wed, 30 Mar 2011 13:29:56 +0200 Boroondas Gupte wrote: I meant it to be "sufficient". If both statements are satisfied then it would be completely weird and suspicious if anyone would go against the proposal. If not both statements are satisfied, or when it's not clear, then that does not mean that X shouldn't be part of the protocol, but then more discussion is necessary. -- Carlo Wood From carlo@alinoe.com Fri Apr 1 06:56:27 2011 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 7DA423A681C for ; Fri, 1 Apr 2011 06:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, 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 s88yG5uag5Ps for ; Fri, 1 Apr 2011 06:56:26 -0700 (PDT) Received: from fep11.mx.upcmail.net (fep11.mx.upcmail.net [62.179.121.31]) by core3.amsl.com (Postfix) with ESMTP id EA8613A67FA for ; Fri, 1 Apr 2011 06:56:25 -0700 (PDT) Received: from edge02.upcmail.net ([192.168.13.237]) by viefep11-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110401135805.DAPQ17007.viefep11-int.chello.at@edge02.upcmail.net> for ; Fri, 1 Apr 2011 15:58:05 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge02.upcmail.net with edge id SDy31g02G0FlQed02Dy4mq; Fri, 01 Apr 2011 15:58:04 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q5erT-0005Gr-Ds for vwrap@ietf.org; Fri, 01 Apr 2011 15:58:03 +0200 Date: Fri, 1 Apr 2011 15:58:03 +0200 From: Carlo Wood To: vwrap@ietf.org Message-ID: <20110401155803.427b2727@hikaru.localdomain> In-Reply-To: References: <20110330011458.GB8908@alinoe.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=vUpxTctd+kpWCBtSXXIkt5ll4Z8E5Qu9nLREXC/hfIo= c=1 sm=0 a=SNAFxGGoWQUA:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=mK_AVkanAAAA:8 a=klfZn6QLZ_uFIorRAXYA:9 a=51XBOe0O6TobSm34TxkA:7 a=CjuIK1q_8ugA:10 a=9xyTavCNlvEA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 01 Apr 2011 13:56:27 -0000 On Wed, 30 Mar 2011 10:01:33 +0100 Morgaine wrote: > Carlo, your suggested paragraph for consensus is a good one, but is > too easy to evade . It makes it trivial for a detractor to argue > that "substantial extra demands are being made [by B] on an > implementation that only implements the functionality of A", because > every B will impose extra demands on A." That exception contains the > recipe for neutralizing all progress. True... it might be too vague and senseless discussion might take place about what is substantial... Therefore I hope that by far most, if not all, people involved TRUELY think, like me, that in principle the protocol should support everything that is even remotely possibly necessary for some use case. Especially when it adds no complexity for those implementers who aren't interested in the extra functionality. For example, someone could propose to add 'X' that would allow something that 'Grid Y' doesn't want on THEIR grid. However, all that is required for them is to add a single parameter to some protocol message, ie - the parameter FALSE, to signal they don't want it. Then based on that it should be impossible to try and bar support for X from the protocol itself: Y would be "forced" to add that 'FALSE' in order to support X passively. > Instead of providing such an easy opportunity for veto by people who > only want A, place the onus on the people requiring B, which is much > more forward looking. I suggest something like this: > > - Whenever a change X in the protocol is proposed (which might be > an addition, a change of existing protocol or even deletion: any > change, making the protocol (VWRAP) go from A --> B), then that > change is accepted as part of VWRAP provided that: > > 1. Protocol B can do everything that A could do. > 2. Good use-case justification for B is provided. > 3. Implementation requirements of B are listed. Although I do not protest against the reformulation, I have to note that it's as easy to go against point 2: people can always argue that it's not a "good use-case"; and it isn't in their eyes when they are really opposed to the whole idea. Therefore I think it's better to say something like: if two or three people think it's a good use case. After all, the whole idea is that those who don't think that it is, will have to ability to not support it on their grid, but should not have the ability to bar it from the protocol. > This would make it clear that features are incremental (A+B must > always be a superset of A), offer an initial level of technical > detail about how functionality B can be achieved, and most > importantly, make everyone aware of the impact that B has on A. It > will also ensure that an implementation that provides A but not B is > by choice a subset implementation. I don't see it like that. A 'subset' seems to suggest incompatiblity. For example, if one world allows it's visitors to use assets from any source, including their own harddisk, while another world doesn't want to allow that for various (non-technical) reasons, then the protocol had to support it nevertheless. The latter world would just reply differently to certain protocol messages, but still be within the protocol and AWARE of the possiblity that allowing it is possible. They'd only refuse it. I don't really see that as supporting a subset of the protocol, if you understand what I mean. Carlo Wood From carlo@alinoe.com Fri Apr 1 07:12:00 2011 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 BC2DC3A684F for ; Fri, 1 Apr 2011 07:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 L9J8-0GA5GGg for ; Fri, 1 Apr 2011 07:11:56 -0700 (PDT) Received: from fep15.mx.upcmail.net (fep15.mx.upcmail.net [62.179.121.35]) by core3.amsl.com (Postfix) with ESMTP id 369773A6835 for ; Fri, 1 Apr 2011 07:11:55 -0700 (PDT) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep15-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110401141334.CZBD1633.viefep15-int.chello.at@edge01.upcmail.net> for ; Fri, 1 Apr 2011 16:13:34 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upcmail.net with edge id SEDY1g01n0FlQed01EDZSU; Fri, 01 Apr 2011 16:13:34 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q5f6S-0005OH-Eg for vwrap@ietf.org; Fri, 01 Apr 2011 16:13:32 +0200 Date: Fri, 1 Apr 2011 16:13:32 +0200 From: Carlo Wood To: vwrap@ietf.org Message-ID: <20110401161332.37ca0f9e@hikaru.localdomain> In-Reply-To: <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=HQ3F56nxkum+cgCiDL7AXQpbvw7DWrWCBJRnYYnM0Zc= c=1 sm=0 a=GIqV-yxGZKkA:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=cH6R9-kdAAAA:8 a=BjFOTwK7AAAA:8 a=Uv2ZS0_JHLw8c0ostA4A:9 a=CjuIK1q_8ugA:10 a=bt0zGP92IBIA:10 a=bW3kdApBr58A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 01 Apr 2011 14:12:02 -0000 On Wed, 30 Mar 2011 14:27:27 +0000 "Dickson, Mike (ISS Software)" wrote: > We don't need to make a process that forces agreement under a set of > terms. That's not how the IETF works. We need consensus and > documents. Nobody forces you to anything. I'm asking if there is consensus about this point. Frankly, I'm disappointed that you disagree already - at THIS level of abstraction. Perhaps it's caused by a false sense of fear that you would be forced to accept things into the protocol: you clearly want control. You want to decide on a case by case basis if you like it or not. But hell, that is NOT possible at this abstraction level. Please rethink carefully what the proposal means: do you REALLY want to reject the Ideal of an open protocol that doesn't deny support for use-cases that YOU don't want? > As a contributor I'll choose to agree or disagree based > on the topic. And in some cases I'm not sure I'd choose flexibility > over stability, etc. I don't see the 'etc' here. And IF the minimal support that an implementer would have to add who does NOT needed X would lead to instability then surely you wouldn't be able to speak of "No substantial extra demands are being made"! If implementation is so difficult, even for implementers NOT needing it, that it causes the danger of instability then you have EVER possibility to go against it, even if now you agree with the Principle of trying to be flexible. > It seems to me we've sorted drifted to a point we're there are 2 > camps and a proposal was made for how to deal with it. There are > those that want to work on service level interop. And others want to > define the whole concept of virtual world interop. IMO we need to > either agree that seperation exists and arrange the docs so it > describes the 2 work streams or agree that we can't agree and > disband. The service level interop. is a subset of the other and > given our track record I prefer to walk rather than run. I am not really sure how this applies to making the choice if you want to be flexible, or - put differently - want to cripple the protocol to make certain applications of it impossible. > And I don't buy the "evil corporate interests" argument. ... unless this is the case. And you just want to win a battle before it started. > Ideally if we do this right there *should* be some participation > from business interests that are looking at the space. A flexible protocol would be superset of what those businesses need (see point 1: Protocol B can do everything that A could do). So, if they would be interested when the protocol can only do A, please explain why they won't be interested anymore when it can do B? > Mike (speaking as me and not for HP) -- Carlo Wood From carlo@alinoe.com Fri Apr 1 07:17:52 2011 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 DB9F73A681A for ; Fri, 1 Apr 2011 07:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 BA5mXhwVmpi5 for ; Fri, 1 Apr 2011 07:17:52 -0700 (PDT) Received: from fep13.mx.upcmail.net (fep13.mx.upcmail.net [62.179.121.33]) by core3.amsl.com (Postfix) with ESMTP id E4D523A67FA for ; Fri, 1 Apr 2011 07:17:51 -0700 (PDT) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep13-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110401141931.VTPU1429.viefep13-int.chello.at@edge03.upcmail.net> for ; Fri, 1 Apr 2011 16:19:31 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge03.upcmail.net with edge id SEKV1g01u0FlQed03EKW1m; Fri, 01 Apr 2011 16:19:31 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q5fCD-0005RX-GN for vwrap@ietf.org; Fri, 01 Apr 2011 16:19:29 +0200 Date: Fri, 1 Apr 2011 16:19:29 +0200 From: Carlo Wood To: vwrap@ietf.org Message-ID: <20110401161929.1e3763f8@hikaru.localdomain> In-Reply-To: <1301499645.12359.10.camel@mdickson-hplinux> References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <1301499645.12359.10.camel@mdickson-hplinux> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=HQ3F56nxkum+cgCiDL7AXQpbvw7DWrWCBJRnYYnM0Zc= c=1 sm=0 a=SNAFxGGoWQUA:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=cH6R9-kdAAAA:8 a=BjFOTwK7AAAA:8 a=e11pYT2ks33SI-3qgYYA:9 a=CjuIK1q_8ugA:10 a=bt0zGP92IBIA:10 a=bW3kdApBr58A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 01 Apr 2011 14:17:52 -0000 On Wed, 30 Mar 2011 11:40:45 -0400 Mike Dickson wrote: > Yes, I get that. I have lots of standards experience, even serving on > the board of one organization in the past. I honestly find the whole > us vs. them rhetoric tiring. A healthy community will include both > individual and corporate interests. And its to be expected that > they'll all argue from their respective POV. That's healthy. > > Mike Then please explain to me again why you want to make it impossible for some party to use VWRAP for their specific use case, and apparently, are only interested to create a protocol that supports your use case (and those things that you are not going to oppose to when they are proposed, for the sake of creating a standard at all). What is the problem to make it possible to use VWRAP by an as wide as possible group of people? -- Carlo Wood From carlo@alinoe.com Fri Apr 1 07:25:39 2011 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 44A313A6864 for ; Fri, 1 Apr 2011 07:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 tu3-kzkoEUtt for ; Fri, 1 Apr 2011 07:25:38 -0700 (PDT) Received: from fep11.mx.upcmail.net (fep11.mx.upcmail.net [62.179.121.31]) by core3.amsl.com (Postfix) with ESMTP id C4E063A6845 for ; Fri, 1 Apr 2011 07:25:37 -0700 (PDT) Received: from edge05.upcmail.net ([192.168.13.212]) by viefep11-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110401142717.EXMH17007.viefep11-int.chello.at@edge05.upcmail.net> for ; Fri, 1 Apr 2011 16:27:17 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upcmail.net with edge id SETF1g02j0FlQed05ETGqV; Fri, 01 Apr 2011 16:27:17 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q5fJj-0005V9-M6 for vwrap@ietf.org; Fri, 01 Apr 2011 16:27:15 +0200 Date: Fri, 1 Apr 2011 16:27:15 +0200 From: Carlo Wood To: vwrap@ietf.org Message-ID: <20110401162715.4fd05aa5@hikaru.localdomain> In-Reply-To: <1301502034.12359.19.camel@mdickson-hplinux> References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <1301499645.12359.10.camel@mdickson-hplinux> <4D93620C.3000505@gmail.com> <1301502034.12359.19.camel@mdickson-hplinux> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=kRmApA04uPli/d8B8u1M0swu98hronvs6VvAqI8uQP0= c=1 sm=0 a=SNAFxGGoWQUA:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=cH6R9-kdAAAA:8 a=BjFOTwK7AAAA:8 a=ufDrww6TrNQOCB74D2EA:9 a=CjuIK1q_8ugA:10 a=bt0zGP92IBIA:10 a=bW3kdApBr58A:10 a=Kfufhcu0ff01f_SH:21 a=w0rG9CKMNLKLGuAQ:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 01 Apr 2011 14:25:39 -0000 On Wed, 30 Mar 2011 12:20:34 -0400 Mike Dickson wrote: > Yes, and I'm saying I'm not going to agree that flexibility is *the* > most important guiding principle over other factors like > compatibility. That was the original assertion (that we should agree > that flexibility is most important). You really misunderstood the intention (so maybe there is still hope). The statement: protocol B can do everything that protocol A can do completely eliminates this extra flexibility override ANYTHING. You seem to fear that "flexibility" is going to be "more important" than something else and "push something else aside". But that is not the case: the whole point is to not do what makes no sense (read that again). And in my eyes, it makes no sense to not add support to the protocol for X when that has not a single disadvantage. Then when it has a tiny little disadvantage; like you need to spend 5 minutes to think about it and it will add a chapter to the documents that you'll have to skip when reading it, or even you need to write 10 extra code lines to deal with procotol commands that you won't implement... then why want to deny all that to those who DO need it? That still makes no sense. I'm not trying to force anything specifically upon you. Not at all. I'm trying to reason something that is just pure logic imho. I had not expected that anyone would have had ALREADY a problem with the very first, almost trivial logical proposal for consensus :( -- Carlo Wood From sllists@boroon.dasgupta.ch Fri Apr 1 07:26:15 2011 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 55ABB3A6870 for ; Fri, 1 Apr 2011 07:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTrEXmx6RzOH for ; Fri, 1 Apr 2011 07:26:14 -0700 (PDT) Received: from datendelphin.net (india288.server4you.de [85.25.150.202]) by core3.amsl.com (Postfix) with ESMTP id B18573A686E for ; Fri, 1 Apr 2011 07:26:14 -0700 (PDT) Received: from [172.30.132.88] (guest-docking-nat-1-087.ethz.ch [82.130.71.87]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by datendelphin.net (Postfix) with ESMTPSA id 3BC652E047 for ; Fri, 1 Apr 2011 16:30:44 +0200 (CEST) Message-ID: <4D95E0E9.9000701@boroon.dasgupta.ch> Date: Fri, 01 Apr 2011 16:27:53 +0200 From: Boroondas Gupte User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110313 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: vwrap@ietf.org References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <20110401154509.5ce33fe0@hikaru.localdomain> In-Reply-To: <20110401154509.5ce33fe0@hikaru.localdomain> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 01 Apr 2011 14:26:15 -0000 On 04/01/2011 03:45 PM, Carlo Wood wrote: > I meant it to be "sufficient". > If both statements are satisfied then it would be > completely weird and suspicious if anyone would go > against the proposal. > > If not both statements are satisfied, or when > it's not clear, then that does not mean that X > shouldn't be part of the protocol, but then more > discussion is necessary I probably had some misconception of what this is about. You are talking about what can go into the protocol at all? Or how different (released, not just proposed) versions of the protocol might differ? In my first answer, I assumed the latter. If it's the former, I think I can agree even to the "sufficient" notion. Cheers, Boroondas From carlo@alinoe.com Fri Apr 1 07:34:45 2011 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 CED763A6850 for ; Fri, 1 Apr 2011 07:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 5Jx4GbbPXDaT for ; Fri, 1 Apr 2011 07:34:45 -0700 (PDT) Received: from fep17.mx.upcmail.net (fep17.mx.upcmail.net [62.179.121.37]) by core3.amsl.com (Postfix) with ESMTP id 946383A6835 for ; Fri, 1 Apr 2011 07:34:44 -0700 (PDT) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep17-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110401143623.DNWF11401.viefep17-int.chello.at@edge01.upcmail.net> for ; Fri, 1 Apr 2011 16:36:23 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upcmail.net with edge id SEcN1g00Z0FlQed01EcPAC; Fri, 01 Apr 2011 16:36:23 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q5fSX-0005ZD-Tq for vwrap@ietf.org; Fri, 01 Apr 2011 16:36:21 +0200 Date: Fri, 1 Apr 2011 16:36:21 +0200 From: Carlo Wood To: vwrap@ietf.org Message-ID: <20110401163621.770f7b7f@hikaru.localdomain> In-Reply-To: References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <1301499645.12359.10.camel@mdickson-hplinux> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=HQ3F56nxkum+cgCiDL7AXQpbvw7DWrWCBJRnYYnM0Zc= c=1 sm=0 a=SNAFxGGoWQUA:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=mK_AVkanAAAA:8 a=BjFOTwK7AAAA:8 a=tWLXOiYdhP8Fa-jICtYA:9 a=CjuIK1q_8ugA:10 a=9xyTavCNlvEA:10 a=bW3kdApBr58A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 01 Apr 2011 14:34:46 -0000 On Wed, 30 Mar 2011 18:13:28 +0100 Morgaine wrote: > To put it bluntly, VW *business* thinks it is best served by denying > interop between worlds, because denying interop holds users captive > and prevents them from easily leaving with their virtual possessions > to better worlds. (A myopic business model, I agree, but we have many > current examples of it.) > > In contrast, interop between worlds serves *individuals* and *user > communities* wonderfully in numerous ways: While this is probably all true. PLEASE EVERYONE - adding some SUPPORT to the protocol does NOT mean it has to be USED. If the VWRAP protocol supports *all* interop at any level, then the large business can STILL deny their users to level and take their assets with them. The protocol will NEVER demand you do something that you don't want. What we speak about here is that the standard - VWRAP - will or will not allow "others" to *use* VWRAP for THEIR purposes. So, I'm sorry - but if anyone is against THAT.. and even has the slightest hesitation to agree that VWRAP should support all interests out there (ie, the business model above, as well as the more user oriented one) then I have a good case to believe in the "evil corporate" theory. -- Carlo Wood From dzonatas@gmail.com Fri Apr 1 07:46:03 2011 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 C73FD3A687B for ; Fri, 1 Apr 2011 07:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 MMMz4pR9YPrI for ; Fri, 1 Apr 2011 07:46:02 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 783703A686E for ; Fri, 1 Apr 2011 07:46:02 -0700 (PDT) Received: by gyf3 with SMTP id 3so1624306gyf.31 for ; Fri, 01 Apr 2011 07:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KDkcqpF3eIP+vTjs58eM80Y/2CCMTenelqclABHcAII=; b=QELsU0C9iHFRqJPWJbiHZTrQq15PPAL7NQQLpXFsJ6333nM9q77U70Z8w86Vd16RQ9 +uUUwd0MXm9HBgZcZqSJ/ZvAlTZRr3OIDuJn1W0PGOjrU0/zJ3ee++dq2YdbpjrXJREg JrmCb+CqhOsjMw1ja2Pw3LVpKzXBFTWHAqIEM= 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=NYRqoiOq2DzMy77mVn99W+R4Ph0qn8M1KpzqMKacRAKPWkhKUMEuL3YBP8DtKEB3nq WYRAzYix/QgBQumSmhNQDHt3Uu6P5KVvRaqDFb79KJYq9MQxVW1mXiR/5Hwk02ESxqG3 vbNjwhpbdgEIn1J9QLwxr4Hb7GmZS23+1dgBM= Received: by 10.43.45.7 with SMTP id ui7mr4964511icb.262.1301669262301; Fri, 01 Apr 2011 07:47:42 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id wo15sm1356542icb.4.2011.04.01.07.47.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 07:47:39 -0700 (PDT) Message-ID: <4D95E5B6.90103@gmail.com> Date: Fri, 01 Apr 2011 07:48:22 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: <4D93E82C.7060503@gmail.com> <4D949BFB.1010804@gmail.com> <1301591963.12359.53.camel@mdickson-hplinux> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Conditioners and refineries 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, 01 Apr 2011 14:46:03 -0000 Much of the discussion is actually implemented, already (somehow). What "you" want, however, seems to be to have some LL-employee/OpenSim-dev to rewrite, reauthorize, reinvent, and bloat the monolithic client or add redundant capabilities on the simulators as some means to state what is official in VWRAP. None of that needs to happen, and please don't give the appearance that "we" need to beg any of them for implementation (especially, to tally some vote). Remember that the user-end/front-end/graphics-client is the one doing the real work. The simulator still exists as a router due to legacy reasons, so there is really no need to rely on LL sims or Opensim to implement any of this. (I'm sure backwards compatible is ideal.) The only exception is "domains". No need to leverage the weight of storage over implementation. The ideal word is "cohesion" of various implementations... not rewrite. Any rewrite or customization of implementations in any company is that company's business, not ours. Your assumption of what is in our "grasp" is in error because you assumed it in only part of LL or such reverse-engineered simulator, and there is no need for this sympathy here unless you're tried to win points with them somehow. Win points here... not there... Morgaine wrote: > That is incorrect. IETF drafts are not promoted to Internet standards unless they have implementations --- again, the Mission Statement is worth reading. "*Rough consensus and running code*" is a cardinal principle highlighted in BCP 95. Since we do not have the power to test our ideas within Second Life, but only within open source frameworks like Opensim, SL compatibility is beyond our reach until such a time as Linden Lab provides the required test implementation. In the absence of that, only Opensim and/or realXtend compatibility is within our grasp because we can add the "running code" there ourselves. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Fri Apr 1 07:52:27 2011 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 03D6F3A687B for ; Fri, 1 Apr 2011 07:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 tkb2w4BGKA2O for ; Fri, 1 Apr 2011 07:52:25 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id BE04A3A6869 for ; Fri, 1 Apr 2011 07:52:24 -0700 (PDT) Received: by iye19 with SMTP id 19so4175427iye.31 for ; Fri, 01 Apr 2011 07:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Zr1AG7TusPIg+ZQs9xcnapZNdr4/HFDA8+/t+A2qMn0=; b=W2wQVgBaPeB2+zpYY2b4ClFfRhUd2+I8HCLwmAE8jcKgVR8HT5Ajc/mJ5oiBxJDFGm EfFvDD3GnPxmIcerRIgEHZqpBtTmSkCzWGUqy9f3jS1UoD1eyoVwZ+cFv8ROHQrtstm5 uEh2aVJv0rTU32TKm8rOknBo9T2ruDNROuDps= 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=LZ3crUmEqL1FHu+cf7omDP+qi9dHjknXs2jcUHT5uqIB6JI0pIKR75Q/DsSnY4GuuH TSakUhUZZehheV81mHLrXJesclLk5Y4HQY2yG8bt3ZlbIel155nZWvH4BG9X60Kbj8L/ AGZcDmpAzkkcCxRPzQfSlOqJOWEGZQwZc59Io= Received: by 10.231.16.134 with SMTP id o6mr4121411iba.108.1301669644960; Fri, 01 Apr 2011 07:54:04 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id i20sm1510160iby.65.2011.04.01.07.54.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 07:54:03 -0700 (PDT) Message-ID: <4D95E734.4040002@gmail.com> Date: Fri, 01 Apr 2011 07:54:44 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: "dyerbrookme@juno.com" References: <20110331.161050.4499.0@webmail03.vgs.untd.com> In-Reply-To: <20110331.161050.4499.0@webmail03.vgs.untd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 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, 01 Apr 2011 14:52:27 -0000 dyerbrookme@juno.com wrote: > > Nobody but those who need to steal them has a felt need to share the > assets of Second Life. These are made by hard-working people who have > copyrighted these assets. *Get your furry paws off them*. > > Prokofy Neva The simulators (currently) share assets between those units and the use-end (monolithic client). How you consider that transfer any different between "steal" and "not-steal" mode is quite phantom to any actual code. Please do your homework, and be sure to understand that the current code actually transfers to much private data and asset information. Your copybot concern could have an easy solution just by the non-transfer of the asset dates. If you have any knowledge of double-entry accounting, you would agree as any banker would. That's also room to optimize the protocol to transfer less data, which could mean faster transfer rates. Anyways... -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Fri Apr 1 07:57:33 2011 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 5220E3A687B for ; Fri, 1 Apr 2011 07:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.542 X-Spam-Level: X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 6QnWp6WrxPko for ; Fri, 1 Apr 2011 07:57:32 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4EE663A6878 for ; Fri, 1 Apr 2011 07:57:32 -0700 (PDT) Received: by iwn39 with SMTP id 39so4180686iwn.31 for ; Fri, 01 Apr 2011 07:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=geIFh/YxAd9uLvEvIiyWBQ3ZNRkUutURCHkaAGLjJP4=; b=Wvdz0wBiqrv1nEbLGf79Wm8qo/8hPMTFhwfDWNE1ny3ipnqABR6OVIw2xO67qhLiZ7 6qEABtHgBM5Ik/GDJXrzAJZ9CCLWqszY1w4bOTe+BrQmF+e06pYlP0P97DMzTbiadDnm ksSGYPqbS0+VEwkVVM0AWpf0SYCgqxpAH4jBg= 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=Y4qx1LIDLX0YTYI0kVl4zKV1tHvQrJnwZj6zIwvpYHh2W2pmAijNJtG9KJKl1YyoCz IJyCUqZZwoFVCH2Of79+CI6m2oVo7FLMM3NQjJq02ThdrvJCGtZgpy0IPvAY0gUC3J1L hFlhB5DlhzQgAA4dl80Arvfu+rMlSR9UeiQ4g= Received: by 10.42.147.3 with SMTP id l3mr5483367icv.353.1301669952474; Fri, 01 Apr 2011 07:59:12 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id c1sm1512991ibe.49.2011.04.01.07.59.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 07:59:11 -0700 (PDT) Message-ID: <4D95E86A.106@gmail.com> Date: Fri, 01 Apr 2011 07:59:54 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Carlo Wood References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <1301499645.12359.10.camel@mdickson-hplinux> <4D93620C.3000505@gmail.com> <1301502034.12359.19.camel@mdickson-hplinux> <20110401162715.4fd05aa5@hikaru.localdomain> In-Reply-To: <20110401162715.4fd05aa5@hikaru.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 01 Apr 2011 14:57:33 -0000 Carlo Wood wrote: > And in my eyes, it makes no sense to not add support to the protocol > for X when that has not a single disadvantage. > > The use-case of optional parameters as given previously on this list is easy to add. I'm sure those that want the flexibility for proprietary reason will want the optional context allowance, not the actual content specified. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Fri Apr 1 07:59:37 2011 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 79AFE3A687F for ; Fri, 1 Apr 2011 07:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.873 X-Spam-Level: X-Spam-Status: No, score=-2.873 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGdlyYCSEPow for ; Fri, 1 Apr 2011 07:59:35 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id CB6B43A6875 for ; Fri, 1 Apr 2011 07:59:32 -0700 (PDT) Received: by qwg5 with SMTP id 5so2582024qwg.31 for ; Fri, 01 Apr 2011 08:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=v3L8yEyRN80Tglc6dMSBcfS/mJS9eUsgTIolcCzenbU=; b=LsIfgCv1lxS7UDavGVStslFUaCau0lk6vwUqiUcSe2etXA/8a2U31rlcUIF40frpSs KdQsbqo0JREDgwl7Y1UwG2R5nyp/VAx931eg2ciKFv4F2uoEgkkOfTrW2Eged8wje1/4 UOeQJUJxCkIp36IlZ+FiMpe30Cn9wDob9/E/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nqZi/9U61hLeU66nn84hgAVY7NN/NVL1QP1Suly3W2h/0fZxv1IIot3RRXSaKp1ICS fLnhntsj3XeHgaDI6ptDEPO5CqHN7acxQUPpEt+Ac3UHnLS0wmTQ7gur+IZC9A2nSbAA gigY0VrG/KvDQF6l7PMWwo20sFug+F6y+5uQg= MIME-Version: 1.0 Received: by 10.224.201.74 with SMTP id ez10mr3550562qab.372.1301670072661; Fri, 01 Apr 2011 08:01:12 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Fri, 1 Apr 2011 08:01:12 -0700 (PDT) In-Reply-To: <20110401161332.37ca0f9e@hikaru.localdomain> References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> Date: Fri, 1 Apr 2011 16:01:12 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=20cf300faf754bb718049fdcae0d Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 01 Apr 2011 14:59:37 -0000 --20cf300faf754bb718049fdcae0d Content-Type: text/plain; charset=ISO-8859-1 I agree 100% with every point made by Carlo in this post. Please note that I have extended Carlo's 2-clause proposal from his earlier email, because in his original formulation, flexibility in the protocol is easily vetoed by backward-looking detractors or vested interests. My formulation is here -- http://www.ietf.org/mail-archive/web/vwrap/current/msg00637.html . I am sure it can be improved still further. My goal is that (i) new areas of flexibility should be justified by use cases and supported by engineering solutions, and (ii) not subject to veto by those who are not interested in those use cases. That's how you make technical progress. Morgaine. ===================== On Fri, Apr 1, 2011 at 3:13 PM, Carlo Wood wrote: > On Wed, 30 Mar 2011 14:27:27 +0000 > "Dickson, Mike (ISS Software)" wrote: > > > We don't need to make a process that forces agreement under a set of > > terms. That's not how the IETF works. We need consensus and > > documents. > > Nobody forces you to anything. I'm asking if there is consensus > about this point. Frankly, I'm disappointed that you disagree > already - at THIS level of abstraction. Perhaps it's caused by > a false sense of fear that you would be forced to accept things > into the protocol: you clearly want control. You want to decide > on a case by case basis if you like it or not. > > But hell, that is NOT possible at this abstraction level. > Please rethink carefully what the proposal means: do you REALLY > want to reject the Ideal of an open protocol that doesn't deny > support for use-cases that YOU don't want? > > > As a contributor I'll choose to agree or disagree based > > on the topic. And in some cases I'm not sure I'd choose flexibility > > over stability, etc. > > I don't see the 'etc' here. And IF the minimal support that > an implementer would have to add who does NOT needed X would > lead to instability then surely you wouldn't be able to speak > of "No substantial extra demands are being made"! > > If implementation is so difficult, even for implementers NOT > needing it, that it causes the danger of instability then you > have EVER possibility to go against it, even if now you agree > with the Principle of trying to be flexible. > > > It seems to me we've sorted drifted to a point we're there are 2 > > camps and a proposal was made for how to deal with it. There are > > those that want to work on service level interop. And others want to > > define the whole concept of virtual world interop. IMO we need to > > either agree that seperation exists and arrange the docs so it > > describes the 2 work streams or agree that we can't agree and > > disband. The service level interop. is a subset of the other and > > given our track record I prefer to walk rather than run. > > I am not really sure how this applies to making the choice if > you want to be flexible, or - put differently - want to cripple > the protocol to make certain applications of it impossible. > > > And I don't buy the "evil corporate interests" argument. > > ... unless this is the case. And you just want to win a battle > before it started. > > > Ideally if we do this right there *should* be some participation > > from business interests that are looking at the space. > > A flexible protocol would be superset of what those businesses > need (see point 1: Protocol B can do everything that A could do). > So, if they would be interested when the protocol can only do A, > please explain why they won't be interested anymore when it > can do B? > > > Mike (speaking as me and not for HP) > > -- > Carlo Wood > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --20cf300faf754bb718049fdcae0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree 100% with every point made by Carlo in this post.

Please not= e that I have extended Carlo's 2-clause proposal from his earlier email= , because in his original formulation, flexibility in the protocol is easil= y vetoed by backward-looking detractors or vested interests.

My formulation is here -- http://www.ietf.org/mail-archive/web/vwrap/= current/msg00637.html .=A0 I am sure it can be improved still further.<= br>
My goal is that (i) new areas of flexibility should be justified by use= cases and supported by engineering solutions, and (ii) not subject to veto= by those who are not interested in those use cases.=A0 That's how you = make technical progress.


Morgaine.




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

On Fri, Apr 1= , 2011 at 3:13 PM, Carlo Wood <carlo@alinoe.com> wrote:
On Wed, 30 Mar 2011 14:27:27 +0000
"Dickson, Mike (ISS Software)" <mike.dickson@hp.com> wrote:

> We don't need to make a process that forces agreement under a set = of
> terms. =A0That's not how the IETF works. =A0We need consensus and<= br> > documents.

Nobody forces you to anything. I'm asking if there is consensus about this point. Frankly, I'm disappointed that you disagree
already - at THIS level of abstraction. Perhaps it's caused by
a false sense of fear that you would be forced to accept things
into the protocol: you clearly want control. You want to decide
on a case by case basis if you like it or not.

But hell, that is NOT possible at this abstraction level.
Please rethink carefully what the proposal means: do you REALLY
want to reject the Ideal of an open protocol that doesn't deny
support for use-cases that YOU don't want?

> =A0As a contributor I'll choose to agree or disagree based
> on the topic. =A0And in some cases I'm not sure I'd choose fle= xibility
> over stability, etc.

I don't see the 'etc' here. And IF the minimal support th= at
an implementer would have to add who does NOT needed X would
lead to instability then surely you wouldn't be able to speak
of "No substantial extra demands are being made"!

If implementation is so difficult, even for implementers NOT
needing it, that it causes the danger of instability then you
have EVER possibility to go against it, even if now you agree
with the Principle of trying to be flexible.

> It seems to me we've sorted drifted to a point we're there are= 2
> camps and a proposal was made for how to deal with it. =A0There are > those that want to work on service level interop. =A0And others want t= o
> define the whole concept of virtual world interop. IMO we need to
> either agree that seperation exists and arrange the docs so it
> describes the 2 work streams or agree that we can't agree and
> disband. =A0The service level interop. is a subset of the other and > given our track record I prefer to walk rather than run.

I am not really sure how this applies to making the choice if
you want to be flexible, or - put differently - want to cripple
the protocol to make certain applications of it impossible.

> =A0And I don't buy the "evil corporate interests" argume= nt.

... unless this is the case. And you just want to win a battle
before it started.

> =A0Ideally if we do this right there *should* be some participation > from business interests that are looking at the space.

A flexible protocol would be superset of what those businesses
need (see point 1: Protocol B can do everything that A could do).
So, if they would be interested when the protocol can only do A,
please explain why they won't be interested anymore when it
can do B?

> Mike (speaking as me and not for HP)

--
Carlo Wood <carlo@alinoe.com>=
_______________________________________________

--20cf300faf754bb718049fdcae0d-- From dzonatas@gmail.com Fri Apr 1 08:09:37 2011 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 C72053A68A2 for ; Fri, 1 Apr 2011 08:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 5tjuqtcUaeOK for ; Fri, 1 Apr 2011 08:09:36 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id CED103A688C for ; Fri, 1 Apr 2011 08:09:36 -0700 (PDT) Received: by iye19 with SMTP id 19so4192183iye.31 for ; Fri, 01 Apr 2011 08:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kXMPeNVXQD8CEALCuArCqvRKH2tfaZFz60tg73KSk/A=; b=AprB+MGYxPRuMYhCCZ3ZR/kgBW3VsohpJiSdN4XPq73goI4Y/cZVkRLXoNE2EBv7pU ZIdZZQfHAr+/w4iIO9FzAC8Dggx1V+suB4uMgYhrWX7u7OvJtSUSECVsI9TpMjG8GhQF gt/uLfb3PJ0CH694/jRDUNAVVGxLSnYtRRM2w= 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=x01RAZz1gbAHe1MmSynWXserJtb4rmCxqyd4RiVlXr8ya31EN5leYBHc8lLJOvx+J6 1OrJhU+D3JBFCi7n8stL32BgCwoimXlcGWkywBO8/T5F8N3ySnTZyyfqN5lp76dodA7X Qu54/b/LHIA9qj9TQ4c3UHLKzmyWwS9ArKdFk= Received: by 10.42.161.74 with SMTP id s10mr5122962icx.28.1301670677120; Fri, 01 Apr 2011 08:11:17 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id mv26sm1518530ibb.45.2011.04.01.08.11.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 08:11:15 -0700 (PDT) Message-ID: <4D95EB3F.8090807@gmail.com> Date: Fri, 01 Apr 2011 08:11:59 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Dzonatas Sol References: <4D93E82C.7060503@gmail.com> <4D949BFB.1010804@gmail.com> <4D94B1EF.2030206@gmail.com> In-Reply-To: <4D94B1EF.2030206@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] "Trust Domains", conditioners and refineries 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, 01 Apr 2011 15:09:37 -0000 Of replies received and to forward this further, the ideal "trust domains" are established in file by X.509 (and more recent claims) or by login credentials/authentication. This flexibility of these two alone to establish such domain already defeats the purpose to use client/server terminology except at the transfer-level. Consider that LLIDL & REST is above the transfer-level (from source-level perspective), there is not much need to use client/server terminology (except if you want pedantic buzzwords). Please let me know if there is some other case. Dzonatas Sol wrote: > Added "trust domains" to the subject line to hopefully narrow this > thread before it goes into some random debate. > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Fri Apr 1 10:07:17 2011 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 E1B893A68C3 for ; Fri, 1 Apr 2011 10:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.876 X-Spam-Level: X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmPRwKTJe3UF for ; Fri, 1 Apr 2011 10:07:16 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 6E2213A6856 for ; Fri, 1 Apr 2011 10:07:16 -0700 (PDT) Received: by qyk7 with SMTP id 7so2464605qyk.10 for ; Fri, 01 Apr 2011 10:08:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=YoT23MGZodQjy3tt8VmhPOocVPgZ5roITmzzYjxm6vQ=; b=F86EsH0HpTvlP776nUK9yOJCbTaboDEUV//NSmiLlxER0TfoUKGAxESTiI9Spt+o70 WAphEYjyvMCLwdQPe3zlN5iW1DdoQ6k1dCDnpw9FgMa/bSY2zwVngB2OInBXqQXkxce+ AFOKTXfHWh9EF5XRti95mYQ/gqJaGQfo0uvD0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=QSzvH2qrR8VTtyqopAKGxZ1l6rbc+ocbXpYtIrivBvHSwszxouhP6WkB6zZZFSVVde V+AHmYaioCxogWUZULrOTymouK5IKKcBsWLPO0va+61C0geDqsC0cOuA6yP2TKqNR06Z riPMMauncRCenOZbxGQNx0pdJroM2reksXuYE= MIME-Version: 1.0 Received: by 10.229.37.130 with SMTP id x2mr3653878qcd.147.1301677735824; Fri, 01 Apr 2011 10:08:55 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Fri, 1 Apr 2011 10:08:55 -0700 (PDT) In-Reply-To: <4D95EB3F.8090807@gmail.com> References: <4D93E82C.7060503@gmail.com> <4D949BFB.1010804@gmail.com> <4D94B1EF.2030206@gmail.com> <4D95EB3F.8090807@gmail.com> Date: Fri, 1 Apr 2011 18:08:55 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016368340c00e500b049fde77e6 Subject: Re: [vwrap] "Trust Domains", conditioners and refineries 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, 01 Apr 2011 17:07:18 -0000 --0016368340c00e500b049fde77e6 Content-Type: text/plain; charset=ISO-8859-1 I hope you realize that "trust domains" don't actually exist outside of some people's passion for buzzwords. Having worked in defense security and looked beyond buzzwords into what really happens with information protection and leakage, the concept of technically-secured trust in an open client-server system lies somewhere between delusion and comedy. No, just no. Information is secure only when it is not released and not accessible. In our VW architecture, all visible content is sent to all participants in the simulation by architectural design, and its non-distribution beyond that set of participants is not assurable. Indeed, it is objectively impossible to assure, because there is no control over public outbound information channels in our architecture, and even less control over covert channels. That makes all talk about "trust domains" here an exercise in futility, some kind of reliance on "faith" and wishful thinking. The merits of comedy aside, I suggest that we stick to concepts that we can underpin with concrete technology and implement in protocols. Trust is not one of them and just wastes time, despite the cuteness of the term "trust domain". If you want to keep information secure, don't send it to somewhere that is insecure such as a remote client. That's the technical solution, stripped of wishful thinking. Whatever one may think of the defense industry, at least they analyze issues to avoid self-delusion. We may not have a defense budget here, but that's not a reason for promoting concepts that simply don't work. Morgaine. ====================== On Fri, Apr 1, 2011 at 4:11 PM, Dzonatas Sol wrote: > Of replies received and to forward this further, the ideal "trust domains" > are established in file by X.509 (and more recent claims) or by login > credentials/authentication. This flexibility of these two alone to establish > such domain already defeats the purpose to use client/server terminology > except at the transfer-level. Consider that LLIDL & REST is above the > transfer-level (from source-level perspective), there is not much need to > use client/server terminology (except if you want pedantic buzzwords). > > Please let me know if there is some other case. > > > Dzonatas Sol wrote: > >> Added "trust domains" to the subject line to hopefully narrow this thread >> before it goes into some random debate. >> >> >> > > -- > --- 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 > --0016368340c00e500b049fde77e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I hope you realize that "trust domains" don't actually exist = outside of some people's passion for buzzwords.

Having worked in= defense security and looked beyond buzzwords into what really happens with= information protection and leakage, the concept of technically-secured tru= st in an open client-server system lies somewhere between delusion and come= dy.=A0 No, just no.

Information is secure only when it is not released and not accessible.= =A0 In our VW architecture, all visible content is sent to all participants= in the simulation by architectural design, and its non-distribution beyond= that set of participants is not assurable.=A0 Indeed, it is objectively im= possible to assure, because there is no control over public outbound inform= ation channels in our architecture, and even less control over covert chann= els.

That makes all talk about "trust domains" here an exercise in= futility, some kind of reliance on "faith" and wishful thinking.=

The merits of comedy aside, I suggest that we stick to concepts tha= t we can underpin with concrete technology and implement in protocols.=A0 T= rust is not one of them and just wastes time, despite the cuteness of the t= erm "trust domain".

If you want to keep information secure, don't send it to somewhere = that is insecure such as a remote client.=A0 That's the technical solut= ion, stripped of wishful thinking.

Whatever one may think of the def= ense industry, at least they analyze issues to avoid self-delusion.=A0 We m= ay not have a defense budget here, but that's not a reason for promotin= g concepts that simply don't work.


Morgaine.




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

On Fri, Ap= r 1, 2011 at 4:11 PM, Dzonatas Sol <dzonatas@gmail.com> wro= te:
Of replies receiv= ed and to forward this further, the ideal "trust domains" are est= ablished in file by X.509 (and more recent claims) or by login credentials/= authentication. This flexibility of these two alone to establish such domai= n already defeats the purpose to use client/server terminology except at th= e transfer-level. Consider that LLIDL & REST is above the transfer-leve= l (from source-level perspective), there is not much need to use client/ser= ver terminology (except if you want pedantic buzzwords).

Please let me know if there is some other case.


Dzonatas Sol wrote:
Added "trust domains" to the subject line to hopefully narrow thi= s thread before it goes into some random debate.




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

--0016368340c00e500b049fde77e6-- From dyerbrookme@juno.com Fri Apr 1 10:17:38 2011 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 20B503A68C3 for ; Fri, 1 Apr 2011 10:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 ENt0pzLx2r9Q for ; Fri, 1 Apr 2011 10:17:34 -0700 (PDT) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 87AB43A679F for ; Fri, 1 Apr 2011 10:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juno.com; s=alpha; t=1301678353; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; l=0; h=From:Date:To:Cc:Subject:Message-Id:Content-Type; b=F7IVIneaAkhZ+ShWcM0M0dQDqfwkKOWlNuDJPCxF0ZnF/tQX2rFM7V9He10bCzx+D BKWaDqynOlRxdw2J5uLwKlzpaymV0dm2b8WfZXbF0NrjM/4I/8pMyhB9u41740pGko EYBLAWqsDZEBaWk2RjPXtfvTPJmjk8wDEUUQHedA= X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail15.vgs.untd.com [10.181.12.155]) by smtpout05.vgs.untd.com with SMTP id AABG3NCHLAS7VNR2 for (sender ); Fri, 1 Apr 2011 10:18:34 -0700 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucf6HyplTnjJho212khZL3nea6rhRUZ0L5w== Received: (from dyerbrookme@juno.com) by webmail15.vgs.untd.com (jqueuemail) id Q7TP7E6Q; Fri, 01 Apr 2011 10:17:42 PDT Received: from [173.52.3.243] by webmail15.vgs.untd.com with HTTP: Fri, 1 Apr 2011 17:17:31 GMT X-Originating-IP: [173.52.3.243] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Fri, 1 Apr 2011 17:17:31 GMT To: dzonatas@gmail.com X-Mailer: Webmail Version 6.1_P2 Message-Id: <20110401.131731.7176.0@webmail15.vgs.untd.com> Content-Type: multipart/alternative;boundary="--__JWM__J61ed.7e34S.7a5dM" X-UNTD-BodySize: 5310 X-ContentStamp: 1:1:1465349296 X-UNTD-Peer-Info: 10.181.12.155|webmail15.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: vwrap@ietf.org Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 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, 01 Apr 2011 17:17:38 -0000 ----__JWM__J61ed.7e34S.7a5dM Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 >The simulators (currently) share assets between those units and the = use-end (monolithic client). How you consider that transfer any = different between "steal" and "not-steal" mode is quite phantom to any = actual code. Please do your homework, and be sure to understand that the current code= = actually transfers to much private data and asset information. Your = copybot concern could have an easy solution just by the non-transfer of = = the asset dates. If you have any knowledge of double-entry accounting, = you would agree as any banker would. That's also room to optimize the = protocol to transfer less data, which could mean faster transfer rates. Anyways... I've done my homework. Just because of the exigencies of accessing a vir= tual world (or anything on the Internet) with your browser meansthat "if= you can see it you can copy it" doesn't mean that you have to facilitat= e, incite, abet, and serve as anaccessory and accomplice after the fact = to content theft. You don't have to. We've been over this a million time= s. Most creators in Second Life do not want a check off box that says "t= ransfer to other grids". There's a good reason for that: the open sim gr= ids are flush with stolen content. Hello! So there is no call for intero= perability except among this small cult group fussing with interoperabil= ity for ideological reasons. WHEN there is need for it by *CUSTOMER REQU= IREMENTS* THEN it can be done in ways that preserve permissions. As has = been said may times before, there is absolutely no reason on earth or in= cyberspace that the protocols can be set upto respect the exact same DR= M that SL currently has: mod/copy/transfer permissions to be checked on = or off. Only ideologicalreasons would prevent this on the specious groun= ds that "you can crack that" or "you can copy it anyway" or "obfuscation= doesn't work blah blah blah". You make it work through organic POLICY; y= ou make it work by making sure that software code reflects ORGANIC POLIC= Ythat is MANIFESTED as hard coded preventions of copying at least at the= casual level. That's all.You don't drive a complex interactivesystem am= ong grids by what happens in 17 percent of the cases, you go with the ot= her 83 percent you can achieve. Prokofy ____________________________________________________________ Groupon™ Official Site 1 ridiculously huge coupon a day. Get 50-90% off your city's best! http://thirdpartyoffers.juno.com/TGL3141/4d9608ead458b4ae704st05vuc ----__JWM__J61ed.7e34S.7a5dM Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/html; charset=ISO-8859-1
>The simulators (currently) share assets between those uni= ts and the
use-end (monolithic client). How you consider that transf= er any
different between "steal" and "not-steal" mode is quite phant= om to any
actual code.

Please do your homework, and be sure t= o understand that the current code
actually transfers to much privat= e data and asset information. Your
copybot concern could have an eas= y solution just by the non-transfer of
the asset dates. If you have = any knowledge of double-entry accounting,
you would agree as any ban= ker would. That's also room to optimize the
protocol to transfer les= s data, which could mean faster transfer rates.

Anyways...
I've done my homework.
 
Just because of the e= xigencies of accessing a virtual world (or anything on the Internet) wit= h your browser means
that "if you can see it you can copy it" = doesn't mean that you have to facilitate, incite, abet, and serve as an<= /div>
accessory and accomplice after the fact to content theft.
 
You don't have to.
 
We'= ve been over this a million times.
 
Most creat= ors in Second Life do not want a check off box that says "transfer to ot= her grids".
 
There's a good reason for that: t= he open sim grids are flush with stolen content. Hello!
 =
So there is no call for interoperability except among this sm= all cult group fussing with interoperability for ideological reasons.
 
WHEN there is need for it by *CUSTOMER REQUIREM= ENTS* THEN it can be done in ways that preserve permissions.
&= nbsp;
As has been said may times before, there is absolutely n= o reason on earth or in cyberspace that the protocols can be set up
to respect the exact same DRM that SL currently has: mod/copy/tran= sfer permissions to be checked on or off. Only ideological
rea= sons would prevent this on the specious grounds that "you can crack that= " or "you can copy it anyway" or "obfuscation
doesn't work bla= h blah blah".
 
You make it work through organi= c POLICY; you make it work by making sure that software code reflects OR= GANIC POLICY
that is MANIFESTED as hard coded preventions of c= opying at least at the casual level. That's all.You don't drive a comple= x interactive
system among grids by what happens in 17 percent= of the cases, you go with the other 83 percent you can achieve.
 
Prokofy


_____________________________= _______________________________
Groupon™ Official Site
1 ridiculously huge coupon a day. Get 50-90% off your = city's best!
Groupon.com ----__JWM__J61ed.7e34S.7a5dM-- From dzonatas@gmail.com Fri Apr 1 10:17:57 2011 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 1406C3A68C3 for ; Fri, 1 Apr 2011 10:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Vqtym0R0ZLpd for ; Fri, 1 Apr 2011 10:17:56 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E1C913A679F for ; Fri, 1 Apr 2011 10:17:55 -0700 (PDT) Received: by iwn39 with SMTP id 39so4320092iwn.31 for ; Fri, 01 Apr 2011 10:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=80K0jMTl/dGOeQRd6O/9StPwA4lmfKCGKBMX9DXh0NQ=; b=Yl8NpeU8csLU47iSOq7bVB3dB1K9mZCEyecp9OZIMxL07MVjjaSNNC0ik7v8DNe+zU LVhT7tSbOF3l9qfvxmJ9bYPC4PWvKpEdIgr1RX1oT9uefKqYfvjmfZCrJTCOO4R6TZF2 4tHzUSvUF7qXjFHPPXqbz0rxXg9wZEf2YoCSU= 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=opNyqmn8IG/H4BRLoFiF0v7yB+7IdOUwZBJqa52oHFqM9Dlr5vaUzex2+g4F9tbdPH cTSCNhYUyGvkGtpm0kmho+FuO6BPa/MoRe7jE/pMnYbRb28c37nzZNP9vZSlczXY+3cM 96Ds2smfrml7hE9CJ+Lvm/eDpveU+mFWeJ8mc= Received: by 10.42.136.138 with SMTP id u10mr1773587ict.104.1301678376207; Fri, 01 Apr 2011 10:19:36 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id uf10sm1423351icb.5.2011.04.01.10.19.33 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 10:19:35 -0700 (PDT) Message-ID: <4D960950.8090205@gmail.com> Date: Fri, 01 Apr 2011 10:20:16 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: <4D93E82C.7060503@gmail.com> <4D949BFB.1010804@gmail.com> <4D94B1EF.2030206@gmail.com> <4D95EB3F.8090807@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] "Trust Domains", conditioners and refineries 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, 01 Apr 2011 17:17:57 -0000 I guess your reply is purely April 1st themed, as there are surely protocols in use now on the Internet, yet you make it sound like nobody trusts the Internet... again Morgaine wrote: > I hope you realize that "trust domains" don't actually exist outside > of some people's passion for buzzwords. > > Having worked in defense security and looked beyond buzzwords into > what really happens with information protection and leakage, the > concept of technically-secured trust in an open client-server system > lies somewhere between delusion and comedy.� No, just no. > > Information is secure only when it is not released and not > accessible.� In our VW architecture, all visible content is sent to > all participants in the simulation by architectural design, and its > non-distribution beyond that set of participants is not assurable.� > Indeed, it is objectively impossible to assure, because there is no > control over public outbound information channels in our architecture, > and even less control over covert channels. > > That makes all talk about "trust domains" here an exercise in > futility, some kind of reliance on "faith" and wishful thinking. > > The merits of comedy aside, I suggest that we stick to concepts that > we can underpin with concrete technology and implement in protocols.� > Trust is not one of them and just wastes time, despite the cuteness of > the term "trust domain". > > If you want to keep information secure, don't send it to somewhere > that is insecure such as a remote client.� That's the technical > solution, stripped of wishful thinking. > > Whatever one may think of the defense industry, at least they analyze > issues to avoid self-delusion.� We may not have a defense budget here, > but that's not a reason for promoting concepts that simply don't work. > > > Morgaine. > > > > > ====================== > > On Fri, Apr 1, 2011 at 4:11 PM, Dzonatas Sol > wrote: > > Of replies received and to forward this further, the ideal "trust > domains" are established in file by X.509 (and more recent claims) > or by login credentials/authentication. This flexibility of these > two alone to establish such domain already defeats the purpose to > use client/server terminology except at the transfer-level. > Consider that LLIDL & REST is above the transfer-level (from > source-level perspective), there is not much need to use > client/server terminology (except if you want pedantic buzzwords). > > Please let me know if there is some other case. > > > Dzonatas Sol wrote: > > Added "trust domains" to the subject line to hopefully narrow > this thread before it goes into some random debate. > > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Fri Apr 1 10:27:34 2011 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 0E7D23A6907 for ; Fri, 1 Apr 2011 10:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 3dmlPVae993J for ; Fri, 1 Apr 2011 10:27:32 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id A259B3A6765 for ; Fri, 1 Apr 2011 10:27:32 -0700 (PDT) Received: by iwn39 with SMTP id 39so4329820iwn.31 for ; Fri, 01 Apr 2011 10:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GyKpto5Mivqm3AHe51tfQrU3+LFpZYaB9praz+zwSEk=; b=bANGZy5NiQWUlAQcGQjahplFKingRANA/TIV6WtItIcZrD4JDHarKfeOQM1VjGt9cv k+CGdnkaO5IZkU/bYSxK9DJQrc9VlP48lwgP71MDu6qvArO2Y+ZFc9sMOFt5VHwV5NhS 5fXiLd43sn4Ss6uLD4qgIEj9kq9oKYJvw5dUc= 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=iiYh+ZHHWdcFBAZT2AqVlHZJDxldl/8puL1lXUYw0waMYKBh14rREGrMSEjrAZBThY RqzIrA7X7vu+TqQzGpjlysB2mQa9po7wuVtWht6ZLA23gbgHQleE4NnUOQ1w0/Cv16f5 A/a/1N8g+Prbm0gFY60JSXlrwpEIgPzhdv5+g= Received: by 10.42.29.202 with SMTP id s10mr5430982icc.4.1301678952438; Fri, 01 Apr 2011 10:29:12 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id u9sm1582061ibe.53.2011.04.01.10.29.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 10:29:11 -0700 (PDT) Message-ID: <4D960B92.3020202@gmail.com> Date: Fri, 01 Apr 2011 10:29:54 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: "dyerbrookme@juno.com" References: <20110401.131731.7176.0@webmail15.vgs.untd.com> In-Reply-To: <20110401.131731.7176.0@webmail15.vgs.untd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 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, 01 Apr 2011 17:27:34 -0000 Re: "Most creators in Second Life do not want a check off box that says "transfer to other grids"." Then why would anybody want to send any e-mail from one location on the net to another. I think the only ill-concept here is the impersonation of turtles on turtules (or the virtualization of virtualization). It all begins somewhere, just as you have used to send your e-mail. What do you want to do instead, send it only to yourself? That is basically what it seems you suggested and argued against. As for the "crack" comments, you started to argue the very nature of digital vs analog and the abilities to copy (digital) or not-copy the other (analog). This is not the list to argue such nature and copyability. You'll find that same argument everywhere across the net. Even a walled garden (with guarded high-rises in SF) is no protection to stop either from being stolen.That point is moot. Can people copy your conscious? Probably not, and that is example of analog non-copy-ability. This is basic data network knowledge, so we aren't that dumb. dyerbrookme@juno.com wrote: > >The simulators (currently) share assets between those units and the > use-end (monolithic client). How you consider that transfer any > different between "steal" and "not-steal" mode is quite phantom to any > actual code. > > Please do your homework, and be sure to understand that the current code > actually transfers to much private data and asset information. Your > copybot concern could have an easy solution just by the non-transfer of > the asset dates. If you have any knowledge of double-entry accounting, > you would agree as any banker would. That's also room to optimize the > protocol to transfer less data, which could mean faster transfer rates. > > Anyways... > > I've done my homework. > > Just because of the exigencies of accessing a virtual world (or > anything on the Internet) with your browser means > that "if you can see it you can copy it" doesn't mean that you have to > facilitate, incite, abet, and serve as an > accessory and accomplice after the fact to content theft. > > You don't have to. > > We've been over this a million times. > > Most creators in Second Life do not want a check off box that says > "transfer to other grids". > > There's a good reason for that: the open sim grids are flush with > stolen content. Hello! > > So there is no call for interoperability except among this small cult > group fussing with interoperability for ideological reasons. > > WHEN there is need for it by *CUSTOMER REQUIREMENTS* THEN it can be > done in ways that preserve permissions. > > As has been said may times before, there is absolutely no reason on > earth or in cyberspace that the protocols can be set up > to respect the exact same DRM that SL currently has: mod/copy/transfer > permissions to be checked on or off. Only ideological > reasons would prevent this on the specious grounds that "you can crack > that" or "you can copy it anyway" or "obfuscation > doesn't work blah blah blah". > > You make it work through organic POLICY; you make it work by making > sure that software code reflects ORGANIC POLICY > that is MANIFESTED as hard coded preventions of copying at least at > the casual level. That's all.You don't drive a complex interactive > system among grids by what happens in 17 percent of the cases, you go > with the other 83 percent you can achieve. > > Prokofy > > > ____________________________________________________________ > *Groupon™ Official Site* > 1 ridiculously huge coupon a day. Get 50-90% off your city's best! > Groupon.com > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Fri Apr 1 11:37:25 2011 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 1E2A83A6917 for ; Fri, 1 Apr 2011 11:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.88 X-Spam-Level: X-Spam-Status: No, score=-2.88 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vlr5fIDBlI2E for ; Fri, 1 Apr 2011 11:37:22 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 9807C3A6916 for ; Fri, 1 Apr 2011 11:37:22 -0700 (PDT) Received: by qwg5 with SMTP id 5so2724356qwg.31 for ; Fri, 01 Apr 2011 11:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=qAWw7P4FvMBRKRqAvAezQuoy1w8HbKNg53QrIECHY/w=; b=US8s/bb+n0WxCEErQWg0QJxI2GyRAUxC5HK53//ZRHlPxsHzjYELquo98tzhR49hC5 ddbcweR1DJ1GJTnjbrIomMZU8DLuw7zcItyJfgjJ2NDLzL3RU4rPZa89BuXAmNOdOePu QVv1+F0aKTVpqYbm1BvJPJPMBRUJjCHSCGu/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=GPFdS2jAWxBPGd3BxzFTvUhzZs6C8KK29c0KVikds3nOily8yX2aj9Vx6BwHgc03Nd pUvwpXPrdOKym5whhGOqBBRCaaVE8oLYTOZnGlr8lvo72dxlnKSXNPW4zhTGmFabIN7+ OHAc3v3FIa0fENZiY2UQs0VlK0t95BGDIEnwo= MIME-Version: 1.0 Received: by 10.224.137.32 with SMTP id u32mr3907201qat.322.1301683142663; Fri, 01 Apr 2011 11:39:02 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Fri, 1 Apr 2011 11:39:02 -0700 (PDT) In-Reply-To: <4D960950.8090205@gmail.com> References: <4D93E82C.7060503@gmail.com> <4D949BFB.1010804@gmail.com> <4D94B1EF.2030206@gmail.com> <4D95EB3F.8090807@gmail.com> <4D960950.8090205@gmail.com> Date: Fri, 1 Apr 2011 19:39:02 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00151748db04541f58049fdfb911 Subject: Re: [vwrap] "Trust Domains", conditioners and refineries 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, 01 Apr 2011 18:37:25 -0000 --00151748db04541f58049fdfb911 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 1, 2011 at 6:20 PM, Dzonatas Sol wrote: > I guess your reply is purely April 1st themed, as there are surely > protocols in use now on the Internet, yet you make it sound like nobody > trusts the Internet... > A lot of people trust the Internet at face value. Our innocent, well-intentioned but technically uninformed families are among them. That is why organized crime has such an easy ride online. In this group we are better informed than that though, and (hopefully) we understand that trust of an unknown remote 3rd party means absolutely nothing because "trust" and "unknown remote" is a contradiction in terms, even if they possess a cryptographically signed certificate. An X.509 credential means nothing except that the endpoint is recognizable for the session. It says nothing about participant trust, it says nothing about information security, it does not protect against contrary intentions= , and most importantly, it provides no technical mechanism for achieving the goal of "domain protection" that some people here think it supports. Thinking that X.509 offers anything beyond network endpoint identification is a misunderstanding of the technology and of security. It is not a wall. It is just a lock on the wall, and everything beyond the lock is unsecured. And it gets even worse than that. I have had the misfortune of being assigned the duty of interfacing with a leading certificate provider over several years, and can attest that certificates are granted without any kin= d of strong care and assurance. The process is effectively non-scalable, because as the population of certificate holders increases, the controls become ever less strong, and the meaning of holding a certificate reduces t= o virtually nothing. It certainly affords no trust. Having faith in empty delusions is rather common in humanity, but we don't need to enshrine them in an IETF protocol. We already have enough concrete work with goals that are verifiable on our plate. Adding unverifiable delusions to the protocol does not gain us anything beyond a warm feeling stemming from incompetence about security. 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 On Fri, Apr 1, 2011 at 6:20 PM, Dzonatas Sol wrote: > I guess your reply is purely April 1st themed, as there are surely > protocols in use now on the Internet, yet you make it sound like nobody > trusts the Internet... again > > Morgaine wrote: > >> I hope you realize that "trust domains" don't actually exist outside of >> some people's passion for buzzwords. >> >> Having worked in defense security and looked beyond buzzwords into what >> really happens with information protection and leakage, the concept of >> technically-secured trust in an open client-server system lies somewhere >> between delusion and comedy.=EF=BF=BD No, just no. >> >> Information is secure only when it is not released and not accessible.= =EF=BF=BD In >> our VW architecture, all visible content is sent to all participants in = the >> simulation by architectural design, and its non-distribution beyond that= set >> of participants is not assurable.=EF=BF=BD Indeed, it is objectively imp= ossible to >> assure, because there is no control over public outbound information >> channels in our architecture, and even less control over covert channels= . >> >> That makes all talk about "trust domains" here an exercise in futility, >> some kind of reliance on "faith" and wishful thinking. >> >> The merits of comedy aside, I suggest that we stick to concepts that we >> can underpin with concrete technology and implement in protocols.=EF=BF= =BD Trust is >> not one of them and just wastes time, despite the cuteness of the term >> "trust domain". >> >> If you want to keep information secure, don't send it to somewhere that = is >> insecure such as a remote client.=EF=BF=BD That's the technical solution= , stripped >> of wishful thinking. >> >> Whatever one may think of the defense industry, at least they analyze >> issues to avoid self-delusion.=EF=BF=BD We may not have a defense budget= here, but >> that's not a reason for promoting concepts that simply don't work. >> >> >> Morgaine. >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> On Fri, Apr 1, 2011 at 4:11 PM, Dzonatas Sol > dzonatas@gmail.com>> wrote: >> >> Of replies received and to forward this further, the ideal "trust >> domains" are established in file by X.509 (and more recent claims) >> or by login credentials/authentication. This flexibility of these >> two alone to establish such domain already defeats the purpose to >> use client/server terminology except at the transfer-level. >> Consider that LLIDL & REST is above the transfer-level (from >> source-level perspective), there is not much need to use >> client/server terminology (except if you want pedantic buzzwords). >> >> Please let me know if there is some other case. >> >> >> Dzonatas Sol wrote: >> >> Added "trust domains" to the subject line to hopefully narrow >> this thread before it goes into some random debate. >> >> >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > --00151748db04541f58049fdfb911 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 1, 2011 at 6:20 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
=
I guess your reply is purely April 1st themed, as there are surely=20 protocols in use now on the Internet, yet you make it sound like nobody=20 trusts the Internet...

A lot of people trust the I= nternet at face value.=C2=A0 Our innocent, well-intentioned but technically= uninformed families are among them.=C2=A0 That is why organized crime has = such an easy ride online.

In this group we are better informed than that though, and (hopefully) = we understand that trust of an unknown remote 3rd party means absolutely no= thing because "trust" and "unknown remote" is a contrad= iction in terms, even if they possess a cryptographically signed certificat= e.

An X.509 credential means nothing except that the endpoint is recogniza= ble for the session.=C2=A0 It says nothing about participant trust, it says= nothing about information security, it does not protect against contrary i= ntentions, and most importantly, it provides no technical mechanism for ach= ieving the goal of "domain protection" that some people here thin= k it supports.=C2=A0 Thinking that X.509 offers anything beyond network end= point identification is a misunderstanding of the technology and of securit= y.=C2=A0 It is not a wall.=C2=A0 It is just a lock on the wall, and everyth= ing beyond the lock is unsecured.

And it gets even worse than that.=C2=A0 I have had the misfortune of be= ing assigned the duty of interfacing with a leading certificate provider ov= er several years, and can attest that certificates are granted without any = kind of strong care and assurance.=C2=A0 The process is effectively non-sca= lable, because as the population of certificate holders increases, the cont= rols become ever less strong, and the meaning of holding a certificate redu= ces to virtually nothing.=C2=A0 It certainly affords no trust.

Having faith in empty delusions is rather common in humanity, but we do= n't need to enshrine them in an IETF protocol.=C2=A0 We already have en= ough concrete work with goals that are verifiable on our plate.=C2=A0 Addin= g unverifiable delusions to the protocol does not gain us anything beyond a= warm feeling stemming from incompetence about security.


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


On Fri, Apr 1, 2011 at 6:20 PM, Dzonatas Sol = <dzonatas@gmail.com>= wrote:
I guess your repl= y is purely April 1st themed, as there are surely protocols in use now on t= he Internet, yet you make it sound like nobody trusts the Internet... again=

Morgaine wrote:
I hope you realize that "trust domains" don't actually exist = outside of some people's passion for buzzwords.

Having worked in defense security and looked beyond buzzwords into what rea= lly happens with information protection and leakage, the concept of technic= ally-secured trust in an open client-server system lies somewhere between d= elusion and comedy.=EF=BF=BD No, just no.

Information is secure only when it is not released and not accessible.=EF= =BF=BD In our VW architecture, all visible content is sent to all participa= nts in the simulation by architectural design, and its non-distribution bey= ond that set of participants is not assurable.=EF=BF=BD Indeed, it is objec= tively impossible to assure, because there is no control over public outbou= nd information channels in our architecture, and even less control over cov= ert channels.

That makes all talk about "trust domains" here an exercise in fut= ility, some kind of reliance on "faith" and wishful thinking.

The merits of comedy aside, I suggest that we stick to concepts that we can= underpin with concrete technology and implement in protocols.=EF=BF=BD Tru= st is not one of them and just wastes time, despite the cuteness of the ter= m "trust domain".

If you want to keep information secure, don't send it to somewhere that= is insecure such as a remote client.=EF=BF=BD That's the technical sol= ution, stripped of wishful thinking.

Whatever one may think of the defense industry, at least they analyze issue= s to avoid self-delusion.=EF=BF=BD We may not have a defense budget here, b= ut that's not a reason for promoting concepts that simply don't wor= k.


Morgaine.




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

On Fri, Apr 1, 2011 at 4:11 PM, Dzonatas Sol <dzonatas@gmail.com <mailto:dzonatas@gmail.com>>= wrote:

=C2=A0 =C2=A0Of replies received and to forward this further, the ideal &q= uot;trust
=C2=A0 =C2=A0domains" are established in file by X.509 (and more rece= nt claims)
=C2=A0 =C2=A0or by login credentials/authentication. This flexibility of t= hese
=C2=A0 =C2=A0two alone to establish such domain already defeats the purpos= e to
=C2=A0 =C2=A0use client/server terminology except at the transfer-level. =C2=A0 =C2=A0Consider that LLIDL & REST is above the transfer-level (f= rom
=C2=A0 =C2=A0source-level perspective), there is not much need to use
=C2=A0 =C2=A0client/server terminology (except if you want pedantic buzzwo= rds).

=C2=A0 =C2=A0Please let me know if there is some other case.


=C2=A0 =C2=A0Dzonatas Sol wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0Added "trust domains" to the subject = line to hopefully narrow
=C2=A0 =C2=A0 =C2=A0 =C2=A0this thread before it goes into some random deb= ate.




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

=C2=A0 =C2=A0_______________________________________________
=C2=A0 =C2=A0vwrap mailing list
=C2=A0 =C2=A0vwrap@iet= f.org <mailto:vw= rap@ietf.org>

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


------------------------------------------------------------------------

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


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


--00151748db04541f58049fdfb911-- From mike.dickson@hp.com Fri Apr 1 13:54:19 2011 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 361B228C0EB for ; Fri, 1 Apr 2011 13:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, 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 a34WZaMW0rs4 for ; Fri, 1 Apr 2011 13:54:18 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by core3.amsl.com (Postfix) with ESMTP id 707C128C0D6 for ; Fri, 1 Apr 2011 13:54:18 -0700 (PDT) X-Authority-Analysis: v=1.1 cv=2pE2Kh9Ye2ywHyyFZnC5ZQ1FvuPrdOtuPO5uN4ysVDU= c=1 sm=0 a=SNAFxGGoWQUA:10 a=IkcTkHD0fZMA:10 a=E1l+YgTSNfk5lq7wdBf7xA==:17 a=cH6R9-kdAAAA:8 a=vhuo4gWzlUaIGBAV9zwA:9 a=7sXO9EnkgJg84L9W-HgA:7 a=QEXdDO2ut3YA:10 a=bt0zGP92IBIA:10 a=E1l+YgTSNfk5lq7wdBf7xA==:117 X-Cloudmark-Score: 0 X-Originating-IP: 174.100.47.252 Received: from [174.100.47.252] ([174.100.47.252:46051] helo=[192.168.0.101]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 7B/62-05159-EDB369D4; Fri, 01 Apr 2011 20:55:58 +0000 From: Mike Dickson To: Carlo Wood In-Reply-To: <20110401162715.4fd05aa5@hikaru.localdomain> References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <1301499645.12359.10.camel@mdickson-hplinux> <4D93620C.3000505@gmail.com> <1301502034.12359.19.camel@mdickson-hplinux> <20110401162715.4fd05aa5@hikaru.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Fri, 01 Apr 2011 16:55:53 -0400 Message-ID: <1301691353.2746.11.camel@mdickson-hplinux> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 01 Apr 2011 20:54:19 -0000 On Fri, 2011-04-01 at 14:27 +0000, Carlo Wood wrote: > On Wed, 30 Mar 2011 12:20:34 -0400 > Mike Dickson wrote: > > > Yes, and I'm saying I'm not going to agree that flexibility is *the* > > most important guiding principle over other factors like > > compatibility. That was the original assertion (that we should agree > > that flexibility is most important). > > You really misunderstood the intention (so maybe there is still hope). > I think perhaps I did misunderstand. It's just that I don't feel that discussion at a purely semantic level makes sense in cases like this. For instance if you said you wanted to build flexibility into protocols used between service endpoint A and service endpoint B and proposed: - That stateful communications would negotiate capabilities from a set of required and optional capabilities. - That an implementer was free to NAK those optional capabilities they didn't wish to implement. - For stateless communication, that if a service is unable to fulfill a request they can fail it in a way that the caller understands the service isn't implemented. All of these statements being focused on flexibly evolving the set of protocols in order to maximize benefit to the implementers. That is a concrete example directly related to the work we're doing. And something I could agree to. But saying we value flexibility as a principle doesn't help me when it comes to protocol design. So in general I think we agree, yes. Assuming this example made sense. Mike From vaughn.deluca@gmail.com Fri Apr 1 15:15:52 2011 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 65CC328C105 for ; Fri, 1 Apr 2011 15:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.253 X-Spam-Level: X-Spam-Status: No, score=-3.253 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] 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 l9EPZF-vEIXS for ; Fri, 1 Apr 2011 15:15:51 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 875D728C0FA for ; Fri, 1 Apr 2011 15:15:51 -0700 (PDT) Received: by eye13 with SMTP id 13so1354427eye.31 for ; Fri, 01 Apr 2011 15:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=B6vJYG+e7lCx9855N4FjNC4GAj/Y0D5QrSoarxjEsew=; b=Ym4IqbqMg3cf99F7sQWHmqkEcMCOb9iaJVZtjRTHu+ZbZcbvbCl98loq2upgijUgV4 5G21yICOMmefkQBnMTAjItWcF5isq28Vc5Zg0Tlxzho/GArdobbY0VphwBWO6+FeweHX +2XSoFw9f+WB9606ruI1WJVd5TSrdAe6E+z0k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=syI8BdnxSIp6Tc5WTf7YmdU14EWJkl2IQ62NwcMCk8f9SSHl5UXqMrhqwPoPgpn2iX KxHGsIBEe3qrFusv8sv4eNnMP0pIwrfF6mNawW3Pti+o2VRfMCceyqSILaTQ6xcor/iI kprl75dHDKTUju+VQTYq+1hX6FMh3l9t3H9bU= MIME-Version: 1.0 Received: by 10.213.103.138 with SMTP id k10mr633835ebo.125.1301696251340; Fri, 01 Apr 2011 15:17:31 -0700 (PDT) Received: by 10.213.17.17 with HTTP; Fri, 1 Apr 2011 15:17:31 -0700 (PDT) Date: Sat, 2 Apr 2011 00:17:31 +0200 Message-ID: From: Vaughn Deluca To: "" Content-Type: text/plain; charset=ISO-8859-1 Subject: [vwrap] [wvrap] Simulation consistency 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, 01 Apr 2011 22:15:52 -0000 This is a question i discussed with Morgaine off-list a while ago (I intended to send it to the list but pushed the wrong button...) I think we need to address this problem, and decide how to deal with it. In Davids deployment draft, section 7.3.1.1 an overview is given van ways to deliver content to the region. One way is only passing a capability that allows access to (part of) the resource: 7.3.1.1. Content delivery models A range of possible represenations can be passed to a region for simulation. [...] The other end of the delivery spectrum involves passing only a URI or capability used to access the rendering information and a collision mesh,and related data for physical simulation. In such a model, the client is responsible for fetching the additional information needed to render the item's visual presence from a separate service. This fetch can be done *under the credentials of the end user* viewing the material [my emphasis--VD] , and divorces the simulation from the trust chain needed to manage content. Any automation is done on a separate host which the content creator or owner trusts, interacting with the object through remoted interfaces. I can see the need for such a setup, however, i feel we are unpleasantly close to a situation were the coherence of the simulation falls apart. In this deployment pattern the region advertises the presence of the asset, and *some* clients will be able to get it as expected, while -based on the arbitrary whims of the asset service- others might not. My hope would be that after the asset server provides the region with the capability to get the asset, it gives up control. That would mean that if the client finds the inventory server is unwilling to serve the content - in spire of the region saying it is present-, the client should be able to turn around ask the *region* for the asset, (and get is after all). If that is not the case, -and there are probably good reasons for the deployment pattern as described- shouldn't we *warn* clients that the region might be inconsistent, so the users behind the client can vote with their feet, (or take the risk)? --Vaughn From dzonatas@gmail.com Fri Apr 1 17:22:36 2011 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 0CBF83A69B6 for ; Fri, 1 Apr 2011 17:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 DDXY7NE0wmHf for ; Fri, 1 Apr 2011 17:22:34 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 765993A69AE for ; Fri, 1 Apr 2011 17:22:34 -0700 (PDT) Received: by iwn39 with SMTP id 39so4661301iwn.31 for ; Fri, 01 Apr 2011 17:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5V5Zg5+cUDl5cPrAM81p2J/jxVGdAamUQ9xM+9/XQ4o=; b=ErLf7mUrbY9qMgNqTQVXHfUInszdIx4u+AmwgTKrYVaDFRU8K5ItuIg/iyOhRSAF2Y PubjZcJ3U7qCwr7gmUNd+Q+oBEkthioNGkqp7zwCshSzQ/r5XU6lE4raLK8/ysVAvQqI NdNg/XfMWvrisijTyRdivD3Xw45DpxiDoIcjM= 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=LLpNmICR9jNYhRnAqUFLJphypCqbDiRBf3/LjpXkiNfqEnU+QHZsYkreiIMbqkActN brpCHpNJ40B+4hc0VHQBeoWB2JgG6a94ZlnKeYes7K9kf7nLrFlkry4J38sgjfPn4kvh MiSZ5cq3USXQa3yyUXYZIF6cnKfoz13k6nAsM= Received: by 10.43.57.202 with SMTP id wh10mr1491199icb.96.1301703854775; Fri, 01 Apr 2011 17:24:14 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id vr5sm1612484icb.12.2011.04.01.17.24.12 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 17:24:13 -0700 (PDT) Message-ID: <4D966CD9.3040204@gmail.com> Date: Fri, 01 Apr 2011 17:24:57 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: <4D93E82C.7060503@gmail.com> <4D949BFB.1010804@gmail.com> <4D94B1EF.2030206@gmail.com> <4D95EB3F.8090807@gmail.com> <4D960950.8090205@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] "Trust Domains", conditioners and refineries 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: Sat, 02 Apr 2011 00:22:36 -0000 That still is some debate over mechanisms that only serve as an example or use-case, not further topology of such network, capability, and content path. We could argue such straw men, yet I'm not in the mood. Anyways... can we stay on track of terminology and asset services. Thanks. Morgaine wrote: > On Fri, Apr 1, 2011 at 6:20 PM, Dzonatas Sol > wrote: > > I guess your reply is purely April 1st themed, as there are surely > protocols in use now on the Internet, yet you make it sound like > nobody trusts the Internet... > > > A lot of people trust the Internet at face value. Our innocent, > well-intentioned but technically uninformed families are among them. > That is why organized crime has such an easy ride online. > > In this group we are better informed than that though, and (hopefully) > we understand that trust of an unknown remote 3rd party means > absolutely nothing because "trust" and "unknown remote" is a > contradiction in terms, even if they possess a cryptographically > signed certificate. > > An X.509 credential means nothing except that the endpoint is > recognizable for the session. It says nothing about participant > trust, it says nothing about information security, it does not protect > against contrary intentions, and most importantly, it provides no > technical mechanism for achieving the goal of "domain protection" that > some people here think it supports. Thinking that X.509 offers > anything beyond network endpoint identification is a misunderstanding > of the technology and of security. It is not a wall. It is just a > lock on the wall, and everything beyond the lock is unsecured. > > And it gets even worse than that. I have had the misfortune of being > assigned the duty of interfacing with a leading certificate provider > over several years, and can attest that certificates are granted > without any kind of strong care and assurance. The process is > effectively non-scalable, because as the population of certificate > holders increases, the controls become ever less strong, and the > meaning of holding a certificate reduces to virtually nothing. It > certainly affords no trust. > > Having faith in empty delusions is rather common in humanity, but we > don't need to enshrine them in an IETF protocol. We already have > enough concrete work with goals that are verifiable on our plate. > Adding unverifiable delusions to the protocol does not gain us > anything beyond a warm feeling stemming from incompetence about security. > > > Morgaine. > > > > > > ========================= > > > On Fri, Apr 1, 2011 at 6:20 PM, Dzonatas Sol > wrote: > > I guess your reply is purely April 1st themed, as there are surely > protocols in use now on the Internet, yet you make it sound like > nobody trusts the Internet... again > > Morgaine wrote: > > I hope you realize that "trust domains" don't actually exist > outside of some people's passion for buzzwords. > > Having worked in defense security and looked beyond buzzwords > into what really happens with information protection and > leakage, the concept of technically-secured trust in an open > client-server system lies somewhere between delusion and > comedy.� No, just no. > > Information is secure only when it is not released and not > accessible.� In our VW architecture, all visible content is > sent to all participants in the simulation by architectural > design, and its non-distribution beyond that set of > participants is not assurable.� Indeed, it is objectively > impossible to assure, because there is no control over public > outbound information channels in our architecture, and even > less control over covert channels. > > That makes all talk about "trust domains" here an exercise in > futility, some kind of reliance on "faith" and wishful thinking. > > The merits of comedy aside, I suggest that we stick to > concepts that we can underpin with concrete technology and > implement in protocols.� Trust is not one of them and just > wastes time, despite the cuteness of the term "trust domain". > > If you want to keep information secure, don't send it to > somewhere that is insecure such as a remote client.� That's > the technical solution, stripped of wishful thinking. > > Whatever one may think of the defense industry, at least they > analyze issues to avoid self-delusion.� We may not have a > defense budget here, but that's not a reason for promoting > concepts that simply don't work. > > > Morgaine. > > > > > ====================== > > On Fri, Apr 1, 2011 at 4:11 PM, Dzonatas Sol > > >> wrote: > > Of replies received and to forward this further, the ideal > "trust > domains" are established in file by X.509 (and more recent > claims) > or by login credentials/authentication. This flexibility of > these > two alone to establish such domain already defeats the > purpose to > use client/server terminology except at the transfer-level. > Consider that LLIDL & REST is above the transfer-level (from > source-level perspective), there is not much need to use > client/server terminology (except if you want pedantic > buzzwords). > > Please let me know if there is some other case. > > > Dzonatas Sol wrote: > > Added "trust domains" to the subject line to hopefully > narrow > this thread before it goes into some random debate. > > > > > -- --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, > Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > > https://www.ietf.org/mailman/listinfo/vwrap > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Fri Apr 1 20:54:04 2011 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 02A5F28C12B for ; Fri, 1 Apr 2011 20:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 BJd7f6Wdq2i4 for ; Fri, 1 Apr 2011 20:54:02 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 248EC28C107 for ; Fri, 1 Apr 2011 20:54:02 -0700 (PDT) Received: by qyk7 with SMTP id 7so2698892qyk.10 for ; Fri, 01 Apr 2011 20:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Gj+TC7h0RrOHVd5MwDrsokS248yv5srUNkUsOQkHplo=; b=Ob6lVXgzQPcrrZoT1SyLDrDsf/pdx9gXudzlp7yPTcjFtcLKaPROQzjOBcuqwIO1f3 B5uIP2JGaio7ZDvj+izDWl6SmGvYTbFWyK7F70mmfbc7bxbgx/K897nL7vJyGA4OW+dS IW0XtUklcEy74nEUifYoiEQ5rIkxmq2bhEZN0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=T+gImwTxD0sTuxlsbDi6P8wwLhoGg40mNmJGMNR5xtcw4uJontgLRn7HlYjlM7WDkQ uCpBVpzw1vVYclg9j5Ps9arQ6aCxLTpl9qAVGO1VPFTaT7wTNurCzMJV4rsAxEzqZikg OYGZwcjxu09NMmXDXYBSKVe+qBDwOhXazFPyY= MIME-Version: 1.0 Received: by 10.229.124.145 with SMTP id u17mr4105832qcr.71.1301716540840; Fri, 01 Apr 2011 20:55:40 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Fri, 1 Apr 2011 20:55:40 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Apr 2011 04:55:40 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd25cae03db68049fe78051 Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 03:54:04 -0000 --000e0cd25cae03db68049fe78051 Content-Type: text/plain; charset=ISO-8859-1 Every design choice results in a trade-off, Vaughn, improving one thing at the expense of something else. If every time we offered a service we had to inform its users about the downsides of all the trade-offs we have made, they would have an awful lot to read. ;-) The specific trade-off that you are discussing is no different. A region that proxies all content has the "benefit" of acquiring control from the asset servers over the items in the region, so that it can ensure that everyone in the region not only obtains the items but obtains the *same*items as everyone else. That does indeed provide a greater guarantee of consistency than a deployment in which the region only passes asset URIs to clients who then fetch the items from asset services separately. As always though, it's a trade-off, since the proxied design has very poor scalability compared to the distributed one. If we're going to warn users of the potential for inconsistency in the distributed deployment as you suggest, are we also going to warn them of non-scalability in the proxied one? I really don't see much merit in the idea of warning about design choices. Many such choices are technical, and the issues are quite likely to be of little interest to non-technical users anyway. In any case, the better services are likely to provide such information in their online documentation, I would guess. You mentioned users "voting with their feet" or choosing to accept the risk of inconsistency. Well that will happen anyway, when services fail and users get annoyed. If some asset services refuse to send the requested items to some users, those services will get a bad reputation and people will choose different asset services instead. Likewise, if a world service proxies everything and so it can't handle a large number of assets or of people, users will get annoyed at the lag and will go elsewhere. This user evaluation and "voting with their feet" happens already with online services all over the Internet, and I am sure that this human process will continue to work when the services are asset and region services. Back in September 2010, I wrote this post which proposes that we use in VWRAP a form of asset addressing that provides massive scalability at the same time as a very high degree of resilience -- http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html . It is based on the concept of the URI containing a host part and a hash part, where the hash is generated (once, at the time of storage to the asset service) using a specified digest algorithm over the content of the asset being referenced. You may wish to note that if this design were used, the failure of an asset service to deliver a requested item would result in a failover request for the item to one or more backup services, using the same hash part but with a different host address. This can go some way towards overcoming the problem that you think might occur when assets are fetched by clients from asset services directly. Although it won't help when the missing item is available from only a single asset service, it will help in many other cases, and it will compensate for service failures and network outages automatically at the same time. PS. This design for hash-based asset addressing is already being tested by Mojito Sorbet in her experimental world and client. It would give VWRAP-based worlds an improved level of service availability, so I think it should be a core feature of our protocol. Morgaine. =========================== On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca wrote: > This is a question i discussed with Morgaine off-list a while ago (I > intended to send it to the list but pushed the wrong button...) I > think we need to address this problem, and decide how to deal with it. > > In Davids deployment draft, section 7.3.1.1 an overview is given van > ways to deliver content to the region. One way is only passing a > capability that allows access to (part of) the resource: > > 7.3.1.1. Content delivery models > A range of possible represenations can be passed to a region for > simulation. [...] The other end of the delivery spectrum involves > passing > only a URI or capability used to access the rendering > information and a > collision mesh,and related data for physical simulation. > In such a model, the client is responsible for fetching the > additional > information needed to render the item's visual presence from a > separate > service. This fetch can be done *under the credentials of the > end user* > viewing the material [my emphasis--VD] , and divorces the > simulation from > the trust chain needed to manage content. Any automation > is done on a > separate host which the content creator or owner trusts, > interacting with the > object through remoted interfaces. > > I can see the need for such a setup, however, i feel we are > unpleasantly close to a situation were the coherence of the simulation > falls apart. > In this deployment pattern the region advertises the presence of the > asset, and *some* clients will be able to get it as expected, while > -based on the arbitrary whims of the asset service- others might not. > > My hope would be that after the asset server provides the region with > the capability to get the asset, it gives up control. That would mean > that if the client finds the inventory server is unwilling to serve > the content - in spire of the region saying it is present-, the client > should be able to turn around ask the *region* for the asset, (and get > is after all). > > If that is not the case, -and there are probably good reasons for the > deployment pattern as described- shouldn't we *warn* clients that the > region might be inconsistent, so the users behind the client can vote > with their feet, (or take the risk)? > > --Vaughn > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --000e0cd25cae03db68049fe78051 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Every design choice results in a trade-off, Vaughn, improving one thing at = the expense of something else.=A0 If every time we offered a service we had= to inform its users about the downsides of all the trade-offs we have made= , they would have an awful lot to read. ;-)

The specific trade-off that you are discussing is no different.=A0 A re= gion that proxies all content has the "benefit" of acquiring cont= rol from the asset servers over the items in the region, so that it can ens= ure that everyone in the region not only obtains the items but obtains the = same items as everyone else.=A0 That does indeed provide a greater g= uarantee of consistency than a deployment in which the region only passes a= sset URIs to clients who then fetch the items from asset services separatel= y.=A0 As always though, it's a trade-off, since the proxied design has = very poor scalability compared to the distributed one.

If we're going to warn users of the potential for inconsistency in = the distributed deployment as you suggest, are we also going to warn them o= f non-scalability in the proxied one?=A0 I really don't see much merit = in the idea of warning about design choices.=A0 Many such choices are techn= ical, and the issues are quite likely to be of little interest to non-techn= ical users anyway.=A0 In any case, the better services are likely to provid= e such information in their online documentation, I would guess.

You mentioned users "voting with their feet" or choosing to a= ccept the risk of inconsistency.=A0 Well that will happen anyway, when serv= ices fail and users get annoyed.=A0 If some asset services refuse to send t= he requested items to some users, those services will get a bad reputation = and people will choose different asset services instead.=A0 Likewise, if a = world service proxies everything and so it can't handle a large number = of assets or of people, users will get annoyed at the lag and will go elsew= here.=A0 This user evaluation and "voting with their feet" happen= s already with online services all over the Internet, and I am sure that th= is human process will continue to work when the services are asset and regi= on services.

Back in September 2010, I wrote this post which proposes that we use in= VWRAP a form of asset addressing that provides massive scalability at the = same time as a very high degree of resilience -- http://www.ietf.org/mail= -archive/web/vwrap/current/msg00463.html .=A0 It is based on the concep= t of the URI containing a host part and a hash part, where the hash is gene= rated (once, at the time of storage to the asset service) using a specified= digest algorithm over the content of the asset being referenced.=A0 You ma= y wish to note that if this design were used, the failure of an asset servi= ce to deliver a requested item would result in a failover request for the i= tem to one or more backup services, using the same hash part but with a dif= ferent host address.

This can go some way towards overcoming the problem that you think migh= t occur when assets are fetched by clients from asset services directly.=A0= Although it won't help when the missing item is available from only a = single asset service, it will help in many other cases, and it will compens= ate for service failures and network outages automatically at the same time= .

PS. This design for hash-based asset addressing is already being tested= by Mojito Sorbet in her experimental world and client.=A0 It would give VW= RAP-based worlds an improved level of service availability, so I think it s= hould be a core feature of our protocol.


Morgaine.




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

On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca <<= a href=3D"mailto:vaughn.deluca@gmail.com">vaughn.deluca@gmail.com> wrote:
This is a questio= n i discussed with Morgaine off-list a while ago (I
intended to send it to the list but pushed the wrong button...) I
think we need to address this problem, and decide how to deal with it.

=A0In Davids deployment draft, section 7.3.1.1 an overview is given van
ways to deliver content to the region. One way is only passing a
capability that allows access to (part of) the resource:

=A0 =A0 =A0 =A0 =A0 7.3.1.1. =A0Content delivery models
=A0 =A0 =A0 =A0 =A0 A range of possible represenations can be passed to a = region for
=A0 =A0 =A0 =A0 =A0 simulation. [...] The other end of the delivery spectr= um involves passing
=A0 =A0 =A0 =A0 =A0 only a URI or capability used to access the rendering<= br> information and a
=A0 =A0 =A0 =A0 =A0 collision mesh,and related data for physical simulatio= n.
=A0 =A0 =A0 =A0 =A0 In such a model, the client is responsible for fetchin= g the additional
=A0 =A0 =A0 =A0 =A0 information needed to render the item's visual pre= sence from a separate
=A0 =A0 =A0 =A0 =A0 service. =A0This fetch can be done *under the credenti= als of the end user*
=A0 =A0 =A0 =A0 =A0 viewing the material [my emphasis--VD] , and divorces = the
simulation from
=A0 =A0 =A0 =A0 =A0 the trust chain needed to manage content. =A0Any autom= ation
is done on a
=A0 =A0 =A0 =A0 =A0 separate host which the content creator or owner trust= s,
interacting with the
=A0 =A0 =A0 =A0 =A0 object through remoted interfaces.

=A0I can see the need for such a setup, however, i feel we are
unpleasantly close to a situation were the coherence of the simulation
falls apart.
In this deployment pattern the region advertises the presence of the
asset, and *some* clients will be able to get it as expected, while
-based on the arbitrary whims of the asset service- others might not.

My hope would be that after the asset server provides the region with
the capability to get the asset, it gives up control. That would mean
that if the client finds the inventory server is unwilling to serve
the content - in spire of the region saying it is present-, the client
should be able to turn around ask the *region* for the asset, (and get
is after all).

=A0If that is not the case, -and there are probably good reasons for the deployment pattern as described- =A0shouldn't we *warn* clients that th= e
region might be inconsistent, so the users behind the client can vote
with their feet, (or take the risk)?

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

--000e0cd25cae03db68049fe78051-- From morgaine.dinova@googlemail.com Fri Apr 1 22:30:07 2011 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 371FC28C0FF for ; Fri, 1 Apr 2011 22:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 kCMHTsimeXd9 for ; Fri, 1 Apr 2011 22:29:50 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 361203A63EB for ; Fri, 1 Apr 2011 22:29:50 -0700 (PDT) Received: by qwg5 with SMTP id 5so2935245qwg.31 for ; Fri, 01 Apr 2011 22:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zh9C3R18u+4AVCqrQoFIoHdLxQTeUDvEzBQjf8aX68M=; b=HXY+rxge+xt8CsTgWKnLhxFwPJN6VicnlQ7fJ1bL3GTdEvRwE1le/FGR+SOP3ZiFa6 UJUWowvChGxdoFiTjZPBib5jz0fBxmioS0zVYxmaG6Y61LOojoWdVhducssVZQHfYtHg oPGoqoTW5WRWSmeDredziDd8ls/zQIcUi0w70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HxDlC0B/2dqlenBrigkp0oG1MbMSOzCQvKFONQ+NTqM0fNYatg/aqTp4weRDdx/ngz GqPH85Hr4o0IC/CaCh6/I+kCdIEjnBIptuvNCwSVC78tlv8Zvohi3Ns6bAZYxitrZPC6 9ooUAideoobnjwzy9odjlKcI7fRRtgBWaLRxQ= MIME-Version: 1.0 Received: by 10.229.37.130 with SMTP id x2mr4091163qcd.147.1301722290623; Fri, 01 Apr 2011 22:31:30 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Fri, 1 Apr 2011 22:31:30 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Apr 2011 06:31:30 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016368340c0ba97ba049fe8d631 Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 05:30:07 -0000 --0016368340c0ba97ba049fe8d631 Content-Type: text/plain; charset=ISO-8859-1 Further to my last post, it's worth noting that if you find that you suffer poor quality behavior from a particular asset service and it is breaking the consistency of your simulation, with hash-based item addressing you can also automatically use an alternative asset service *in preference* to the one specified in a given URI. Your client could be configured to attempt the item fetch at a known good quality asset service *first* (perhaps one that you paid to use because of its better service), automatically, and maybe even dynamically depending on the type of item. The scheme has a long list of benefits, and overcoming (to some extent) poor quality asset services is just one of them. Morgaine. =================== On Sat, Apr 2, 2011 at 4:55 AM, Morgaine wrote: > Every design choice results in a trade-off, Vaughn, improving one thing at > the expense of something else. If every time we offered a service we had to > inform its users about the downsides of all the trade-offs we have made, > they would have an awful lot to read. ;-) > > The specific trade-off that you are discussing is no different. A region > that proxies all content has the "benefit" of acquiring control from the > asset servers over the items in the region, so that it can ensure that > everyone in the region not only obtains the items but obtains the *same*items as everyone else. That does indeed provide a greater guarantee of > consistency than a deployment in which the region only passes asset URIs to > clients who then fetch the items from asset services separately. As always > though, it's a trade-off, since the proxied design has very poor scalability > compared to the distributed one. > > If we're going to warn users of the potential for inconsistency in the > distributed deployment as you suggest, are we also going to warn them of > non-scalability in the proxied one? I really don't see much merit in the > idea of warning about design choices. Many such choices are technical, and > the issues are quite likely to be of little interest to non-technical users > anyway. In any case, the better services are likely to provide such > information in their online documentation, I would guess. > > You mentioned users "voting with their feet" or choosing to accept the risk > of inconsistency. Well that will happen anyway, when services fail and > users get annoyed. If some asset services refuse to send the requested > items to some users, those services will get a bad reputation and people > will choose different asset services instead. Likewise, if a world service > proxies everything and so it can't handle a large number of assets or of > people, users will get annoyed at the lag and will go elsewhere. This user > evaluation and "voting with their feet" happens already with online services > all over the Internet, and I am sure that this human process will continue > to work when the services are asset and region services. > > Back in September 2010, I wrote this post which proposes that we use in > VWRAP a form of asset addressing that provides massive scalability at the > same time as a very high degree of resilience -- > http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html . It is > based on the concept of the URI containing a host part and a hash part, > where the hash is generated (once, at the time of storage to the asset > service) using a specified digest algorithm over the content of the asset > being referenced. You may wish to note that if this design were used, the > failure of an asset service to deliver a requested item would result in a > failover request for the item to one or more backup services, using the same > hash part but with a different host address. > > This can go some way towards overcoming the problem that you think might > occur when assets are fetched by clients from asset services directly. > Although it won't help when the missing item is available from only a single > asset service, it will help in many other cases, and it will compensate for > service failures and network outages automatically at the same time. > > PS. This design for hash-based asset addressing is already being tested by > Mojito Sorbet in her experimental world and client. It would give > VWRAP-based worlds an improved level of service availability, so I think it > should be a core feature of our protocol. > > > Morgaine. > > > > > =========================== > > > On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca wrote: > >> This is a question i discussed with Morgaine off-list a while ago (I >> intended to send it to the list but pushed the wrong button...) I >> think we need to address this problem, and decide how to deal with it. >> >> In Davids deployment draft, section 7.3.1.1 an overview is given van >> ways to deliver content to the region. One way is only passing a >> capability that allows access to (part of) the resource: >> >> 7.3.1.1. Content delivery models >> A range of possible represenations can be passed to a region for >> simulation. [...] The other end of the delivery spectrum >> involves passing >> only a URI or capability used to access the rendering >> information and a >> collision mesh,and related data for physical simulation. >> In such a model, the client is responsible for fetching the >> additional >> information needed to render the item's visual presence from a >> separate >> service. This fetch can be done *under the credentials of the >> end user* >> viewing the material [my emphasis--VD] , and divorces the >> simulation from >> the trust chain needed to manage content. Any automation >> is done on a >> separate host which the content creator or owner trusts, >> interacting with the >> object through remoted interfaces. >> >> I can see the need for such a setup, however, i feel we are >> unpleasantly close to a situation were the coherence of the simulation >> falls apart. >> In this deployment pattern the region advertises the presence of the >> asset, and *some* clients will be able to get it as expected, while >> -based on the arbitrary whims of the asset service- others might not. >> >> My hope would be that after the asset server provides the region with >> the capability to get the asset, it gives up control. That would mean >> that if the client finds the inventory server is unwilling to serve >> the content - in spire of the region saying it is present-, the client >> should be able to turn around ask the *region* for the asset, (and get >> is after all). >> >> If that is not the case, -and there are probably good reasons for the >> deployment pattern as described- shouldn't we *warn* clients that the >> region might be inconsistent, so the users behind the client can vote >> with their feet, (or take the risk)? >> >> --Vaughn >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> > > --0016368340c0ba97ba049fe8d631 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Further to my last post, it's worth noting that if you find that you su= ffer poor quality behavior from a particular asset service and it is breaki= ng the consistency of your simulation, with hash-based item addressing you = can also automatically use an alternative asset service in preference= to the one specified in a given URI.

Your client could be configured to attempt the item fetch at a known go= od quality asset service first (perhaps one that you paid to use bec= ause of its better service), automatically, and maybe even dynamically depe= nding on the type of item.

The scheme has a long list of benefits, and overcoming (to some extent)= poor quality asset services is just one of them.


Morgaine.
<= br>



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

On Sat, Apr 2, 2011 at 4:55 AM, Morgaine <morgaine.dinova@googlemail.com>= ; wrote:
http:/= /www.ietf.org/mail-archive/web/vwrap/current/msg00463.html .=A0 It is b= ased on the concept of the URI containing a host part and a hash part, wher= e the hash is generated (once, at the time of storage to the asset service)= using a specified digest algorithm over the content of the asset being ref= erenced.=A0 You may wish to note that if this design were used, the failure= of an asset service to deliver a requested item would result in a failover= request for the item to one or more backup services, using the same hash p= art but with a different host address.

This can go some way towards overcoming the problem that you think migh= t occur when assets are fetched by clients from asset services directly.=A0= Although it won't help when the missing item is available from only a = single asset service, it will help in many other cases, and it will compens= ate for service failures and network outages automatically at the same time= .

PS. This design for hash-based asset addressing is already being tested= by Mojito Sorbet in her experimental world and client.=A0 It would give VW= RAP-based worlds an improved level of service availability, so I think it s= hould be a core feature of our protocol.


Morgaine.




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


On Fri, Apr 1, 2011 at 11:17 = PM, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
This is a questio= n i discussed with Morgaine off-list a while ago (I
intended to send it to the list but pushed the wrong button...) I
think we need to address this problem, and decide how to deal with it.

=A0In Davids deployment draft, section 7.3.1.1 an overview is given van
ways to deliver content to the region. One way is only passing a
capability that allows access to (part of) the resource:

=A0 =A0 =A0 =A0 =A0 7.3.1.1. =A0Content delivery models
=A0 =A0 =A0 =A0 =A0 A range of possible represenations can be passed to a = region for
=A0 =A0 =A0 =A0 =A0 simulation. [...] The other end of the delivery spectr= um involves passing
=A0 =A0 =A0 =A0 =A0 only a URI or capability used to access the rendering<= br> information and a
=A0 =A0 =A0 =A0 =A0 collision mesh,and related data for physical simulatio= n.
=A0 =A0 =A0 =A0 =A0 In such a model, the client is responsible for fetchin= g the additional
=A0 =A0 =A0 =A0 =A0 information needed to render the item's visual pre= sence from a separate
=A0 =A0 =A0 =A0 =A0 service. =A0This fetch can be done *under the credenti= als of the end user*
=A0 =A0 =A0 =A0 =A0 viewing the material [my emphasis--VD] , and divorces = the
simulation from
=A0 =A0 =A0 =A0 =A0 the trust chain needed to manage content. =A0Any autom= ation
is done on a
=A0 =A0 =A0 =A0 =A0 separate host which the content creator or owner trust= s,
interacting with the
=A0 =A0 =A0 =A0 =A0 object through remoted interfaces.

=A0I can see the need for such a setup, however, i feel we are
unpleasantly close to a situation were the coherence of the simulation
falls apart.
In this deployment pattern the region advertises the presence of the
asset, and *some* clients will be able to get it as expected, while
-based on the arbitrary whims of the asset service- others might not.

My hope would be that after the asset server provides the region with
the capability to get the asset, it gives up control. That would mean
that if the client finds the inventory server is unwilling to serve
the content - in spire of the region saying it is present-, the client
should be able to turn around ask the *region* for the asset, (and get
is after all).

=A0If that is not the case, -and there are probably good reasons for the deployment pattern as described- =A0shouldn't we *warn* clients that th= e
region might be inconsistent, so the users behind the client can vote
with their feet, (or take the risk)?

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


--0016368340c0ba97ba049fe8d631-- From vaughn.deluca@gmail.com Sat Apr 2 03:24:32 2011 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 ED4453A67AE for ; Sat, 2 Apr 2011 03:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.084 X-Spam-Level: X-Spam-Status: No, score=-3.084 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 WqQUCrmZOBSZ for ; Sat, 2 Apr 2011 03:24:30 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id D80883A67AD for ; Sat, 2 Apr 2011 03:24:29 -0700 (PDT) Received: by eye13 with SMTP id 13so1457869eye.31 for ; Sat, 02 Apr 2011 03:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dxIs2y0j3CfzATrjqed4KCxwdS7qsGerj73g4wYRNow=; b=crOiSBUsdEdqJcuhmxlmuGyjDF/Y/jijjthK7gga6yO9I1gGzk/dyotkxc4nn17N/L sVBO6m7y89kofRxow1zpPUVC/IRtO6hfkJjMa/xnajKPegVdKU75aIM2ywq6PUvLS9hM xpQrJqQJMSZN8sYa/aq5nCn8mdkmpXbBoWJxY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=F0JwTBpIwcbIQeptczejBK53ec5poFVAA5Zh6+mFzw3JlWJNGzN8SWfj+cwuYr1ch+ QHDJctao9QA/TxbvckfW6Beq2hA5lOUHeZc1EYkda0PX4aM4mEpTR4hSHwVJwX4QPQd0 bWCobixOMjAgEAgfE5ezidixoWa7jvAMyiuGo= MIME-Version: 1.0 Received: by 10.213.25.79 with SMTP id y15mr2816333ebb.41.1301739968296; Sat, 02 Apr 2011 03:26:08 -0700 (PDT) Received: by 10.213.17.17 with HTTP; Sat, 2 Apr 2011 03:26:08 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Apr 2011 12:26:08 +0200 Message-ID: From: Vaughn Deluca To: Morgaine Content-Type: multipart/alternative; boundary=000e0ce0b726667779049fecf457 Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 10:24:33 -0000 --000e0ce0b726667779049fecf457 Content-Type: text/plain; charset=ISO-8859-1 Morgaine, Meadhbh, Thanks for the answers, but i see that i have not been clear enough. I think the protocol should demand certain things to prevent the deterioration of the simulation to an unacceptable level. We need to be more precise to prevent problems and i think we can. I was arguing from the perspecive of a region service without making that explicit. Note i was *not* advocating the region proxies everything, just that it lives up to its promises about object presence. Also note that i do *not* always have the option to pick another high quality asset service, since I normally do not own the assets. I will use Prokofy as an example just for the fun of it. He is highly worried about content theft, so (in the unlikely case he wants to start selling stuff outside of SL) he might use this deployment pattern. Assume he sells wonderful sexy dresses to two customers, that can only be fetched from his own asset service for rendering. Both customers go off to "Vaughns highly immersive world" were a party is given. My region receives some physics properties of the dresses for simulation and an address of Proks asset service for high-res details and textures. In this case the region does not even get the capability to fetch the assets, just a link to the asset service and its up to viewer to request the details and show credentials to get them. The two girls meet, both their viewers request the details of the other dress, and Proks asset service grants those requests. They girls admire their dresses and compliment each other with their good taste. Now when i arrive and my viewer request the dress details, Prok's asset service recognises me as the copyleftists that i am. It refuses to serve the asset details -and depending on my viewers behaviour i might get to view two girls in sexy underwear -or wearing even less- instead of party dresses. From a consistency point of view this is a highly undesirable situation, it breaks immersion, and depending on the circumstances might also be embarrassing to the people involved. The key question is if we want to allow this situation to arise within VWRAP compliant worlds. I would like to argue that the region *should* get the capability to fetch all details. In other words, Prokofy would have to give up some control over the asset in case he allows it to be used by my region. Note that this does not mean that the region *has* to proxy the asset, just that in case the asset service refuses to serve a client it does not like, the region can insist on delivery based on the capability it originally got. If that fails Proks asset service can not be called VWRAP compliant. If Prokofy does not want to relinquish that level of control, fine, it is his right not to, but in that case the dresses should not be allowed to get into my region in the first place. If people visit my region and find themselves naked in the eyes of some others *I* will get the blame. As Morgaine says, the technical details of my innocence will not convince the general public. So I want methods to prevent breaking my highly emergent world as much as possible. My proposal would be that the whatever the region gets MUST be guaranteed by protocol to be delivered to anybody within the region requesting it. If the asset service does not want to serve a cryptocomunist copyleftist, fine, but IF it has given the region a capability, it MUST serve the full asset to be VWRAP compliant. Its *my* choice as a region deployer to download the full asset to be able to guarantee region consistency if I want to. I will try to avoid that as much as possible, but if my customers complain, i will be forces to start doing this for certain asset services that i know show discriminatory behaviour against for instance copyleftist. Finally Morgaine, you keep hammering on the fact that proxying by the region does not scale. (I tend to disagree, but that is beside the point here). I do agree the asset should not be needlessly transfered, but i strongly feel we must insist in the protocol on transferring the *rights* to view the asset. If that leads to to the region not getting the asset at all, so be it, it can warn visitors that their assets will not be visible and even offer to serve simple replacements (1). This in turn will encourage the end users to avoid this type of asset service, and Prokofy will go out of business, as should be the case given the behaviour of the service. And if he pulls it off, thats fine with me also, as long as i do not have to suffer from it due to lack of rigour in the protocol specs. So, in summary, I very well see that there is no way to enforce consistent serving behaviour but it should at least be clear that it is non-standard and not conform the protocol. The way I am understanding you now, your argument seems to be just one step to far in the direction of anarchy. Or am i misreading you? --Vaughn (1) I just realise that the region might cheat and advertise its own asset brands claiming the competitions assets could not be rendered... Oh well, one might hope that if there is enough choice in worlds such regions will be forced out of business as well. On Sat, Apr 2, 2011 at 7:31 AM, Morgaine wrote: > Further to my last post, it's worth noting that if you find that you suffer > poor quality behavior from a particular asset service and it is breaking the > consistency of your simulation, with hash-based item addressing you can also > automatically use an alternative asset service *in preference* to the one > specified in a given URI. > > Your client could be configured to attempt the item fetch at a known good > quality asset service *first* (perhaps one that you paid to use because of > its better service), automatically, and maybe even dynamically depending on > the type of item. > > The scheme has a long list of benefits, and overcoming (to some extent) > poor quality asset services is just one of them. > > > Morgaine. > > > > > > =================== > > > On Sat, Apr 2, 2011 at 4:55 AM, Morgaine wrote: > >> Every design choice results in a trade-off, Vaughn, improving one thing at >> the expense of something else. If every time we offered a service we had to >> inform its users about the downsides of all the trade-offs we have made, >> they would have an awful lot to read. ;-) >> >> The specific trade-off that you are discussing is no different. A region >> that proxies all content has the "benefit" of acquiring control from the >> asset servers over the items in the region, so that it can ensure that >> everyone in the region not only obtains the items but obtains the *same*items as everyone else. That does indeed provide a greater guarantee of >> consistency than a deployment in which the region only passes asset URIs to >> clients who then fetch the items from asset services separately. As always >> though, it's a trade-off, since the proxied design has very poor scalability >> compared to the distributed one. >> >> If we're going to warn users of the potential for inconsistency in the >> distributed deployment as you suggest, are we also going to warn them of >> non-scalability in the proxied one? I really don't see much merit in the >> idea of warning about design choices. Many such choices are technical, and >> the issues are quite likely to be of little interest to non-technical users >> anyway. In any case, the better services are likely to provide such >> information in their online documentation, I would guess. >> >> You mentioned users "voting with their feet" or choosing to accept the >> risk of inconsistency. Well that will happen anyway, when services fail and >> users get annoyed. If some asset services refuse to send the requested >> items to some users, those services will get a bad reputation and people >> will choose different asset services instead. Likewise, if a world service >> proxies everything and so it can't handle a large number of assets or of >> people, users will get annoyed at the lag and will go elsewhere. This user >> evaluation and "voting with their feet" happens already with online services >> all over the Internet, and I am sure that this human process will continue >> to work when the services are asset and region services. >> >> Back in September 2010, I wrote this post which proposes that we use in >> VWRAP a form of asset addressing that provides massive scalability at the >> same time as a very high degree of resilience -- >> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html . It is >> based on the concept of the URI containing a host part and a hash part, >> where the hash is generated (once, at the time of storage to the asset >> service) using a specified digest algorithm over the content of the asset >> being referenced. You may wish to note that if this design were used, the >> failure of an asset service to deliver a requested item would result in a >> failover request for the item to one or more backup services, using the same >> hash part but with a different host address. >> >> This can go some way towards overcoming the problem that you think might >> occur when assets are fetched by clients from asset services directly. >> Although it won't help when the missing item is available from only a single >> asset service, it will help in many other cases, and it will compensate for >> service failures and network outages automatically at the same time. >> >> PS. This design for hash-based asset addressing is already being tested by >> Mojito Sorbet in her experimental world and client. It would give >> VWRAP-based worlds an improved level of service availability, so I think it >> should be a core feature of our protocol. >> >> >> Morgaine. >> >> >> >> >> =========================== >> >> >> On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca wrote: >> >>> This is a question i discussed with Morgaine off-list a while ago (I >>> intended to send it to the list but pushed the wrong button...) I >>> think we need to address this problem, and decide how to deal with it. >>> >>> In Davids deployment draft, section 7.3.1.1 an overview is given van >>> ways to deliver content to the region. One way is only passing a >>> capability that allows access to (part of) the resource: >>> >>> 7.3.1.1. Content delivery models >>> A range of possible represenations can be passed to a region >>> for >>> simulation. [...] The other end of the delivery spectrum >>> involves passing >>> only a URI or capability used to access the rendering >>> information and a >>> collision mesh,and related data for physical simulation. >>> In such a model, the client is responsible for fetching the >>> additional >>> information needed to render the item's visual presence from a >>> separate >>> service. This fetch can be done *under the credentials of the >>> end user* >>> viewing the material [my emphasis--VD] , and divorces the >>> simulation from >>> the trust chain needed to manage content. Any automation >>> is done on a >>> separate host which the content creator or owner trusts, >>> interacting with the >>> object through remoted interfaces. >>> >>> I can see the need for such a setup, however, i feel we are >>> unpleasantly close to a situation were the coherence of the simulation >>> falls apart. >>> In this deployment pattern the region advertises the presence of the >>> asset, and *some* clients will be able to get it as expected, while >>> -based on the arbitrary whims of the asset service- others might not. >>> >>> My hope would be that after the asset server provides the region with >>> the capability to get the asset, it gives up control. That would mean >>> that if the client finds the inventory server is unwilling to serve >>> the content - in spire of the region saying it is present-, the client >>> should be able to turn around ask the *region* for the asset, (and get >>> is after all). >>> >>> If that is not the case, -and there are probably good reasons for the >>> deployment pattern as described- shouldn't we *warn* clients that the >>> region might be inconsistent, so the users behind the client can vote >>> with their feet, (or take the risk)? >>> >>> --Vaughn >>> _______________________________________________ >>> vwrap mailing list >>> vwrap@ietf.org >>> https://www.ietf.org/mailman/listinfo/vwrap >>> >> >> > --000e0ce0b726667779049fecf457 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Morgaine, Meadhbh,

Thanks for the answers, bu= t i see that i have not been clear enough.
I think the protocol s= hould demand certain things to prevent the =A0deterioration of the simulati= on to an unacceptable level. We need to be more precise to prevent problems= and i think we can.

I was arguing from the perspecive of a region service w= ithout making that explicit. Note i was *not* advocating the region proxies= everything, just that it lives up to its promises about object presence. A= lso note that i do =A0*not* always have the option to pick another high qua= lity asset service, since I normally do not own the assets. I will use Prok= ofy as an example just for the fun of it. =A0He is highly worried about con= tent theft, so (in the unlikely case he wants to start selling stuff outsid= e of SL) he might use this deployment pattern. =A0Assume he sells wonderful= sexy dresses to two customers, that can only be fetched from his own asset= service for rendering. Both customers go off to "Vaughns highly immer= sive world" were a party is given. =A0My region receives some physics = properties of the dresses for simulation and an address of Proks asset serv= ice for high-res details and textures. In this case the region does not eve= n get the capability to fetch the assets, just a link to the asset service = and its up to viewer to request the details and show credentials to get the= m. The two girls meet, both their viewers request the details of the other = dress, and Proks asset service grants those requests. They girls admire the= ir dresses and compliment each other with their good taste. Now when i arri= ve and my viewer request the dress details, Prok's asset service recogn= ises me as the copyleftists that i am. It refuses to serve the asset detail= s -and depending on my viewers behaviour i might get to view two girls in s= exy underwear -or wearing even less- instead of party dresses. From a consi= stency point of view this is a highly undesirable situation, it breaks imme= rsion, and depending on the circumstances might also be embarrassing to the= people involved.=A0

The key question is if we want to allow this situation = to arise within VWRAP compliant worlds.
I would like to argue tha= t the region *should* get the capability to fetch all details. In other wor= ds, Prokofy would have to give up some control over the asset in case he al= lows it to be used by my region. Note that this does not mean that the regi= on *has* to proxy the asset, just that in case the asset service refuses to= serve a client it does not like, the region can insist on delivery =A0base= d on the capability it originally got. If that fails Proks asset service ca= n not be called VWRAP compliant. =A0

If Prokofy does not want to relinquish =A0that level of= control, fine, it is his right not to, but in that case the dresses should= not be allowed to get into my region in the first place. =A0If people visi= t my region and find themselves naked in the eyes of some others *I* will g= et the blame. =A0As Morgaine says, the technical details of my innocence wi= ll not convince the general public. So I want methods to prevent breaking m= y highly emergent world as much as possible.=A0
My proposal would be that the whatever the region gets MUST be guarant= eed by protocol to be delivered to =A0anybody within the region requesting = it. If the asset service does not want to serve a cryptocomunist copyleftis= t, fine, but IF it has given the region a capability, it MUST serve the ful= l asset to be VWRAP compliant. Its *my* choice as a region deployer to down= load the full asset to be able to guarantee region consistency if I want to= . I will try to avoid that as much as possible, but if my customers complai= n, i will be forces to start doing this for certain asset services that i k= now show discriminatory behaviour against for instance copyleftist.=A0

Finally Morgaine, you keep hammering on the fact that p= roxying by the region does not scale. (I tend to disagree, but that is besi= de the point here). I do agree the asset should not be needlessly transfere= d, but i strongly feel we must insist in the protocol on transferring the *= rights* to view the asset. If that leads to to the region not getting the a= sset at all, so be it, it can warn visitors that their assets will not be v= isible and even offer to serve simple replacements (1). This in turn will e= ncourage the end users to avoid this type of asset service, and Prokofy wil= l go out of business, as should be the case given the behaviour of the serv= ice. And if he pulls it off, thats fine with me also, as long as i do not h= ave to suffer from it due to lack of rigour in the protocol specs. =A0

So, in summary, I very well see that there is no way to= enforce consistent serving behaviour but it should at least be clear that = it is non-standard and not conform the protocol. The way I am understanding= you now, your argument seems to be just one step to far in the direction o= f anarchy.
Or am i misreading you?

--Vaughn

(1) I just realise that the region might cheat = and advertise its own asset brands claiming the competitions assets =A0coul= d not be rendered... Oh well, one might hope that if there is enough choice= in worlds such regions will be forced =A0out of business as well.=A0

On Sat, Apr 2, 2011 at 7:31 AM, Morgaine <morgai= ne.dinova@googlemail.com> wrote:
Further to my last post, it's worth noting that if you find that you su= ffer poor quality behavior from a particular asset service and it is breaki= ng the consistency of your simulation, with hash-based item addressing you = can also automatically use an alternative asset service in preference= to the one specified in a given URI.

Your client could be configured to attempt the item fetch at a known go= od quality asset service first (perhaps one that you paid to use bec= ause of its better service), automatically, and maybe even dynamically depe= nding on the type of item.

The scheme has a long list of benefits, and overcoming (to some extent)= poor quality asset services is just one of them.


Morgaine.





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


On Sat, Apr 2, 2011 at 4:55 AM, Morgaine <morgaine.dinova@goo= glemail.com> wrote:
Every design choice results in a trade-off, Vaughn, improving one thing at = the expense of something else.=A0 If every time we offered a service we had= to inform its users about the downsides of all the trade-offs we have made= , they would have an awful lot to read. ;-)

The specific trade-off that you are discussing is no different.=A0 A re= gion that proxies all content has the "benefit" of acquiring cont= rol from the asset servers over the items in the region, so that it can ens= ure that everyone in the region not only obtains the items but obtains the = same items as everyone else.=A0 That does indeed provide a greater g= uarantee of consistency than a deployment in which the region only passes a= sset URIs to clients who then fetch the items from asset services separatel= y.=A0 As always though, it's a trade-off, since the proxied design has = very poor scalability compared to the distributed one.

If we're going to warn users of the potential for inconsistency in = the distributed deployment as you suggest, are we also going to warn them o= f non-scalability in the proxied one?=A0 I really don't see much merit = in the idea of warning about design choices.=A0 Many such choices are techn= ical, and the issues are quite likely to be of little interest to non-techn= ical users anyway.=A0 In any case, the better services are likely to provid= e such information in their online documentation, I would guess.

You mentioned users "voting with their feet" or choosing to a= ccept the risk of inconsistency.=A0 Well that will happen anyway, when serv= ices fail and users get annoyed.=A0 If some asset services refuse to send t= he requested items to some users, those services will get a bad reputation = and people will choose different asset services instead.=A0 Likewise, if a = world service proxies everything and so it can't handle a large number = of assets or of people, users will get annoyed at the lag and will go elsew= here.=A0 This user evaluation and "voting with their feet" happen= s already with online services all over the Internet, and I am sure that th= is human process will continue to work when the services are asset and regi= on services.

Back in September 2010, I wrote this post which proposes that we use in= VWRAP a form of asset addressing that provides massive scalability at the = same time as a very high degree of resilience -- http:/= /www.ietf.org/mail-archive/web/vwrap/current/msg00463.html .=A0 It is b= ased on the concept of the URI containing a host part and a hash part, wher= e the hash is generated (once, at the time of storage to the asset service)= using a specified digest algorithm over the content of the asset being ref= erenced.=A0 You may wish to note that if this design were used, the failure= of an asset service to deliver a requested item would result in a failover= request for the item to one or more backup services, using the same hash p= art but with a different host address.

This can go some way towards overcoming the problem that you think migh= t occur when assets are fetched by clients from asset services directly.=A0= Although it won't help when the missing item is available from only a = single asset service, it will help in many other cases, and it will compens= ate for service failures and network outages automatically at the same time= .

PS. This design for hash-based asset addressing is already being tested= by Mojito Sorbet in her experimental world and client.=A0 It would give VW= RAP-based worlds an improved level of service availability, so I think it s= hould be a core feature of our protocol.


Morgaine.




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

On Fri, Apr 1, 2011 at 11:17 PM, Vaughn De= luca <vaughn.deluca@gmail.com> wrote:
This is a question i di= scussed with Morgaine off-list a while ago (I
intended to send it to the list but pushed the wrong button...) I
think we need to address this problem, and decide how to deal with it.

=A0In Davids deployment draft, section 7.3.1.1 an overview is given van
ways to deliver content to the region. One way is only passing a
capability that allows access to (part of) the resource:

=A0 =A0 =A0 =A0 =A0 7.3.1.1. =A0Content delivery models
=A0 =A0 =A0 =A0 =A0 A range of possible represenations can be passed to a = region for
=A0 =A0 =A0 =A0 =A0 simulation. [...] The other end of the delivery spectr= um involves passing
=A0 =A0 =A0 =A0 =A0 only a URI or capability used to access the rendering<= br> information and a
=A0 =A0 =A0 =A0 =A0 collision mesh,and related data for physical simulatio= n.
=A0 =A0 =A0 =A0 =A0 In such a model, the client is responsible for fetchin= g the additional
=A0 =A0 =A0 =A0 =A0 information needed to render the item's visual pre= sence from a separate
=A0 =A0 =A0 =A0 =A0 service. =A0This fetch can be done *under the credenti= als of the end user*
=A0 =A0 =A0 =A0 =A0 viewing the material [my emphasis--VD] , and divorces = the
simulation from
=A0 =A0 =A0 =A0 =A0 the trust chain needed to manage content. =A0Any autom= ation
is done on a
=A0 =A0 =A0 =A0 =A0 separate host which the content creator or owner trust= s,
interacting with the
=A0 =A0 =A0 =A0 =A0 object through remoted interfaces.

=A0I can see the need for such a setup, however, i feel we are
unpleasantly close to a situation were the coherence of the simulation
falls apart.
In this deployment pattern the region advertises the presence of the
asset, and *some* clients will be able to get it as expected, while
-based on the arbitrary whims of the asset service- others might not.

My hope would be that after the asset server provides the region with
the capability to get the asset, it gives up control. That would mean
that if the client finds the inventory server is unwilling to serve
the content - in spire of the region saying it is present-, the client
should be able to turn around ask the *region* for the asset, (and get
is after all).

=A0If that is not the case, -and there are probably good reasons for the deployment pattern as described- =A0shouldn't we *warn* clients that th= e
region might be inconsistent, so the users behind the client can vote
with their feet, (or take the risk)?

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



--000e0ce0b726667779049fecf457-- From morgaine.dinova@googlemail.com Sat Apr 2 05:56:35 2011 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 1F7A73A67EB for ; Sat, 2 Apr 2011 05:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 pBDfpkJjOcSY for ; Sat, 2 Apr 2011 05:56:31 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id B08AB3A67EA for ; Sat, 2 Apr 2011 05:56:30 -0700 (PDT) Received: by qwg5 with SMTP id 5so3050638qwg.31 for ; Sat, 02 Apr 2011 05:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UkjpN+PG4rJrpQAV4n7TiMB3+V+IkvSKi54EOvQ2Ar0=; b=e4AUEWjykiCC8LKaGAEjkOUNGFuU21JaSWYKGy6CvGOBQIjgZudLh6U7CMYIYhV835 vVNQ9Mx27slY09O6XRbPGmoNLlpjU0Rs/BZbiYNy5fC6QeqyGOkREXNQ3BCZMmh4GX7K 7M2maPWuO0LlzlYZEFrGui65RG91M7fBYszXo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xC/QfEVx+4gK3TR75msrMutBOA5Ypxd4RUpSYpxZ/NTCnYbbHXBx/9Cm6We51yrJ9M kBWOxYsYrPjjfaHCvSzBmJaBXlxAJ6AlJBeHpkpzC1XkZKs7ZDOnZlzp8vQBm5G6pgrQ 4X3IgcRgZR7aC0YC6XE482hCkyT9o8Krc8VLw= MIME-Version: 1.0 Received: by 10.229.37.130 with SMTP id x2mr4287842qcd.147.1301749091376; Sat, 02 Apr 2011 05:58:11 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sat, 2 Apr 2011 05:58:11 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Apr 2011 13:58:11 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016368340c02d9d40049fef1407 Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 12:56:35 -0000 --0016368340c02d9d40049fef1407 Content-Type: text/plain; charset=ISO-8859-1 Vaughn, I think you've described the situation perfectly, and no, I doubt that you have been misunderstood, at least not by me. (Admittedly we did discuss this issue in depth in emails previously, but I think you have presented it so clearly that I am sure that everyone understands the point you are making.) The problem however is that you are asking the impossible, namely that one party (the region provider) should have policy control over another (the asset service provider). As David has said on many different occasions and in various different ways, this attempt at policy export just won't work in practice, because each party is "sovereign" over its own service, so to speak. At best you can only recommend or hope for sensible behavior by all, and if there is a legal relationship between the parties then presumably the pressure of law can help as well. The big commercial players may well take a legal route, but certainly not the thousands (or millions) of participants in a flourishing metaverse of community VWs that is spread across the whole planet in countless jurisdictions. What they will have to rely on is either something that works by technical means, or else simply on *best effort* by all --- in other words, exactly the same means by which the quality of services on the Internet is "assured", using the word loosely. ;-) Technical means of assuring what you want are in your grasp --- you can proxy everything, as we said before, but only at a large cost to your scalability because your region will now have to transport enormously more data to clients. Still, that may be a tradeoff that you are willing to make if you are so keen on offering many 9's worth of simulation consistency and don't expect your region to scale much. That choice would be up to you, and it's a perfectly excellent choice to make because you have a requirement that needs to be met, but you cannot force that choice on everybody. I predict that many commercial providers will be more interested in scalability than in 100% consistency because there is money to be made from large numbers of visitors to your world, and so they might well be happy to tolerate the occasional hiccup in external asset services which scale so well. For non-commercial world operators though, the normal best-effort "guarantees" are likely to be entirely sufficient, particularly if we use hash-based addressing so that asset access has multiple failover paths. I do think that you have overstated the magnitude of the problem, however. Yes, it will be possible for things to break if asset service operators purposely reject some connections, but how widespread is this likely to be? Just think of the consequences of doing so. If I buy a dress and TP to a holiday world and I arrive minus dress, do you think I will buy more clothing that is served from that same asset service? Not very likely. Seller beware! I expect ranking sites that rank both community and commercial asset services to appear, showing service uptime and delivery speed and reliability metrics, just like there are ranking sites for ISPs today showing speed and availability. The Internet communities are very good at doing that sort of thing, and it applies pressure on service providers very nicely. "Vote with your feet" will have every chance of working well. This issue really highlights how important the concept of "deployment patterns" is in VWRAP. It's easy to see that requirements are going to vary widely between different providers, and we will have to ensure that deployments are available that cater for all the common scenarios, of which yours is clearly one. Morgaine. ==================== On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca wrote: > Morgaine, Meadhbh, > > Thanks for the answers, but i see that i have not been clear enough. > I think the protocol should demand certain things to prevent the > deterioration of the simulation to an unacceptable level. We need to be > more precise to prevent problems and i think we can. > > I was arguing from the perspecive of a region service without making that > explicit. Note i was *not* advocating the region proxies everything, just > that it lives up to its promises about object presence. Also note that i do > *not* always have the option to pick another high quality asset service, > since I normally do not own the assets. I will use Prokofy as an example > just for the fun of it. He is highly worried about content theft, so (in > the unlikely case he wants to start selling stuff outside of SL) he might > use this deployment pattern. Assume he sells wonderful sexy dresses to two > customers, that can only be fetched from his own asset service for > rendering. Both customers go off to "Vaughns highly immersive world" were a > party is given. My region receives some physics properties of the dresses > for simulation and an address of Proks asset service for high-res details > and textures. In this case the region does not even get the capability to > fetch the assets, just a link to the asset service and its up to viewer to > request the details and show credentials to get them. The two girls meet, > both their viewers request the details of the other dress, and Proks asset > service grants those requests. They girls admire their dresses and > compliment each other with their good taste. Now when i arrive and my viewer > request the dress details, Prok's asset service recognises me as the > copyleftists that i am. It refuses to serve the asset details -and depending > on my viewers behaviour i might get to view two girls in sexy underwear -or > wearing even less- instead of party dresses. From a consistency point of > view this is a highly undesirable situation, it breaks immersion, and > depending on the circumstances might also be embarrassing to the people > involved. > > The key question is if we want to allow this situation to arise within > VWRAP compliant worlds. > I would like to argue that the region *should* get the capability to fetch > all details. In other words, Prokofy would have to give up some control over > the asset in case he allows it to be used by my region. Note that this does > not mean that the region *has* to proxy the asset, just that in case the > asset service refuses to serve a client it does not like, the region can > insist on delivery based on the capability it originally got. If that fails > Proks asset service can not be called VWRAP compliant. > > If Prokofy does not want to relinquish that level of control, fine, it is > his right not to, but in that case the dresses should not be allowed to get > into my region in the first place. If people visit my region and find > themselves naked in the eyes of some others *I* will get the blame. As > Morgaine says, the technical details of my innocence will not convince the > general public. So I want methods to prevent breaking my highly emergent > world as much as possible. > My proposal would be that the whatever the region gets MUST be guaranteed > by protocol to be delivered to anybody within the region requesting it. If > the asset service does not want to serve a cryptocomunist copyleftist, fine, > but IF it has given the region a capability, it MUST serve the full asset to > be VWRAP compliant. Its *my* choice as a region deployer to download the > full asset to be able to guarantee region consistency if I want to. I will > try to avoid that as much as possible, but if my customers complain, i will > be forces to start doing this for certain asset services that i know show > discriminatory behaviour against for instance copyleftist. > > Finally Morgaine, you keep hammering on the fact that proxying by the > region does not scale. (I tend to disagree, but that is beside the point > here). I do agree the asset should not be needlessly transfered, but i > strongly feel we must insist in the protocol on transferring the *rights* to > view the asset. If that leads to to the region not getting the asset at all, > so be it, it can warn visitors that their assets will not be visible and > even offer to serve simple replacements (1). This in turn will encourage the > end users to avoid this type of asset service, and Prokofy will go out of > business, as should be the case given the behaviour of the service. And if > he pulls it off, thats fine with me also, as long as i do not have to suffer > from it due to lack of rigour in the protocol specs. > > So, in summary, I very well see that there is no way to enforce consistent > serving behaviour but it should at least be clear that it is non-standard > and not conform the protocol. The way I am understanding you now, your > argument seems to be just one step to far in the direction of anarchy. > Or am i misreading you? > > --Vaughn > > > (1) I just realise that the region might cheat and advertise its own asset > brands claiming the competitions assets could not be rendered... Oh well, > one might hope that if there is enough choice in worlds such regions will be > forced out of business as well. > > On Sat, Apr 2, 2011 at 7:31 AM, Morgaine wrote: > >> Further to my last post, it's worth noting that if you find that you >> suffer poor quality behavior from a particular asset service and it is >> breaking the consistency of your simulation, with hash-based item addressing >> you can also automatically use an alternative asset service *in >> preference* to the one specified in a given URI. >> >> Your client could be configured to attempt the item fetch at a known good >> quality asset service *first* (perhaps one that you paid to use because >> of its better service), automatically, and maybe even dynamically depending >> on the type of item. >> >> The scheme has a long list of benefits, and overcoming (to some extent) >> poor quality asset services is just one of them. >> >> >> Morgaine. >> >> >> >> >> >> =================== >> >> >> On Sat, Apr 2, 2011 at 4:55 AM, Morgaine wrote: >> >>> Every design choice results in a trade-off, Vaughn, improving one thing >>> at the expense of something else. If every time we offered a service we had >>> to inform its users about the downsides of all the trade-offs we have made, >>> they would have an awful lot to read. ;-) >>> >>> The specific trade-off that you are discussing is no different. A region >>> that proxies all content has the "benefit" of acquiring control from the >>> asset servers over the items in the region, so that it can ensure that >>> everyone in the region not only obtains the items but obtains the *same*items as everyone else. That does indeed provide a greater guarantee of >>> consistency than a deployment in which the region only passes asset URIs to >>> clients who then fetch the items from asset services separately. As always >>> though, it's a trade-off, since the proxied design has very poor scalability >>> compared to the distributed one. >>> >>> If we're going to warn users of the potential for inconsistency in the >>> distributed deployment as you suggest, are we also going to warn them of >>> non-scalability in the proxied one? I really don't see much merit in the >>> idea of warning about design choices. Many such choices are technical, and >>> the issues are quite likely to be of little interest to non-technical users >>> anyway. In any case, the better services are likely to provide such >>> information in their online documentation, I would guess. >>> >>> You mentioned users "voting with their feet" or choosing to accept the >>> risk of inconsistency. Well that will happen anyway, when services fail and >>> users get annoyed. If some asset services refuse to send the requested >>> items to some users, those services will get a bad reputation and people >>> will choose different asset services instead. Likewise, if a world service >>> proxies everything and so it can't handle a large number of assets or of >>> people, users will get annoyed at the lag and will go elsewhere. This user >>> evaluation and "voting with their feet" happens already with online services >>> all over the Internet, and I am sure that this human process will continue >>> to work when the services are asset and region services. >>> >>> Back in September 2010, I wrote this post which proposes that we use in >>> VWRAP a form of asset addressing that provides massive scalability at the >>> same time as a very high degree of resilience -- >>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html . It >>> is based on the concept of the URI containing a host part and a hash part, >>> where the hash is generated (once, at the time of storage to the asset >>> service) using a specified digest algorithm over the content of the asset >>> being referenced. You may wish to note that if this design were used, the >>> failure of an asset service to deliver a requested item would result in a >>> failover request for the item to one or more backup services, using the same >>> hash part but with a different host address. >>> >>> This can go some way towards overcoming the problem that you think might >>> occur when assets are fetched by clients from asset services directly. >>> Although it won't help when the missing item is available from only a single >>> asset service, it will help in many other cases, and it will compensate for >>> service failures and network outages automatically at the same time. >>> >>> PS. This design for hash-based asset addressing is already being tested >>> by Mojito Sorbet in her experimental world and client. It would give >>> VWRAP-based worlds an improved level of service availability, so I think it >>> should be a core feature of our protocol. >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> =========================== >>> >>> >>> On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca wrote: >>> >>>> This is a question i discussed with Morgaine off-list a while ago (I >>>> intended to send it to the list but pushed the wrong button...) I >>>> think we need to address this problem, and decide how to deal with it. >>>> >>>> In Davids deployment draft, section 7.3.1.1 an overview is given van >>>> ways to deliver content to the region. One way is only passing a >>>> capability that allows access to (part of) the resource: >>>> >>>> 7.3.1.1. Content delivery models >>>> A range of possible represenations can be passed to a region >>>> for >>>> simulation. [...] The other end of the delivery spectrum >>>> involves passing >>>> only a URI or capability used to access the rendering >>>> information and a >>>> collision mesh,and related data for physical simulation. >>>> In such a model, the client is responsible for fetching the >>>> additional >>>> information needed to render the item's visual presence from a >>>> separate >>>> service. This fetch can be done *under the credentials of the >>>> end user* >>>> viewing the material [my emphasis--VD] , and divorces the >>>> simulation from >>>> the trust chain needed to manage content. Any automation >>>> is done on a >>>> separate host which the content creator or owner trusts, >>>> interacting with the >>>> object through remoted interfaces. >>>> >>>> I can see the need for such a setup, however, i feel we are >>>> unpleasantly close to a situation were the coherence of the simulation >>>> falls apart. >>>> In this deployment pattern the region advertises the presence of the >>>> asset, and *some* clients will be able to get it as expected, while >>>> -based on the arbitrary whims of the asset service- others might not. >>>> >>>> My hope would be that after the asset server provides the region with >>>> the capability to get the asset, it gives up control. That would mean >>>> that if the client finds the inventory server is unwilling to serve >>>> the content - in spire of the region saying it is present-, the client >>>> should be able to turn around ask the *region* for the asset, (and get >>>> is after all). >>>> >>>> If that is not the case, -and there are probably good reasons for the >>>> deployment pattern as described- shouldn't we *warn* clients that the >>>> region might be inconsistent, so the users behind the client can vote >>>> with their feet, (or take the risk)? >>>> >>>> --Vaughn >>>> _______________________________________________ >>>> vwrap mailing list >>>> vwrap@ietf.org >>>> https://www.ietf.org/mailman/listinfo/vwrap >>>> >>> >>> >> > --0016368340c02d9d40049fef1407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Vaughn, I think you've described the situation perfectly, and no, I dou= bt that you have been misunderstood, at least not by me.=A0 (Admittedly we = did discuss this issue in depth in emails previously, but I think you have = presented it so clearly that I am sure that everyone understands the point = you are making.)

The problem however is that you are asking the impossible, namely that = one party (the region provider) should have policy control over another (th= e asset service provider).=A0 As David has said on many different occasions= and in various different ways, this attempt at policy export just won'= t work in practice, because each party is "sovereign" over its ow= n service, so to speak.=A0 At best you can only recommend or hope for sensi= ble behavior by all, and if there is a legal relationship between the parti= es then presumably the pressure of law can help as well.

The big commercial players may well take a legal route, but certainly n= ot the thousands (or millions) of participants in a flourishing metaverse o= f community VWs that is spread across the whole planet in countless jurisdi= ctions.=A0 What they will have to rely on is either something that works by= technical means, or else simply on best effort by all --- in other = words, exactly the same means by which the quality of services on the Inter= net is "assured", using the word loosely. ;-)

Technical means of assuring what you want are in your grasp --- you can= proxy everything, as we said before, but only at a large cost to your scal= ability because your region will now have to transport enormously more data= to clients.=A0 Still, that may be a tradeoff that you are willing to make = if you are so keen on offering many 9's worth of simulation consistency= and don't expect your region to scale much.

That choice would be up to you, and it's a perfectly excellent choi= ce to make because you have a requirement that needs to be met, but you can= not force that choice on everybody.=A0 I predict that many commercial provi= ders will be more interested in scalability than in 100% consistency becaus= e there is money to be made from large numbers of visitors to your world, a= nd so they might well be happy to tolerate the occasional hiccup in externa= l asset services which scale so well.=A0 For non-commercial world operators= though, the normal best-effort "guarantees" are likely to be ent= irely sufficient, particularly if we use hash-based addressing so that asse= t access has multiple failover paths.

I do think that you have overstated the magnitude of the problem, howev= er.=A0 Yes, it will be possible for things to break if asset service operat= ors purposely reject some connections, but how widespread is this likely to= be?=A0 Just think of the consequences of doing so.=A0 If I buy a dress and= TP to a holiday world and I arrive minus dress, do you think I will buy mo= re clothing that is served from that same asset service?=A0 Not very likely= .=A0 Seller beware!

I expect ranking sites that rank both community and commercial asset se= rvices to appear, showing service uptime and delivery speed and reliability= metrics, just like there are ranking sites for ISPs today showing speed an= d availability.=A0 The Internet communities are very good at doing that sor= t of thing, and it applies pressure on service providers very nicely.=A0 &q= uot;Vote with your feet" will have every chance of working well.

This issue really highlights how important the concept of "deploym= ent patterns" is in VWRAP.=A0 It's easy to see that requirements a= re going to vary widely between different providers, and we will have to en= sure that deployments are available that cater for all the common scenarios= , of which yours is clearly one.


Morgaine.






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


On Sat= , Apr 2, 2011 at 11:26 AM, Vaughn Deluca <vaughn.deluca@gmail.com> wrote= :
Morgaine, Me= adhbh,

Thanks for the answers, but i see that i ha= ve not been clear enough.
I think the protocol should demand certain things to prevent the =A0de= terioration of the simulation to an unacceptable level. We need to be more = precise to prevent problems and i think we can.

I was arguing from the perspecive of a region service w= ithout making that explicit. Note i was *not* advocating the region proxies= everything, just that it lives up to its promises about object presence. A= lso note that i do =A0*not* always have the option to pick another high qua= lity asset service, since I normally do not own the assets. I will use Prok= ofy as an example just for the fun of it. =A0He is highly worried about con= tent theft, so (in the unlikely case he wants to start selling stuff outsid= e of SL) he might use this deployment pattern. =A0Assume he sells wonderful= sexy dresses to two customers, that can only be fetched from his own asset= service for rendering. Both customers go off to "Vaughns highly immer= sive world" were a party is given. =A0My region receives some physics = properties of the dresses for simulation and an address of Proks asset serv= ice for high-res details and textures. In this case the region does not eve= n get the capability to fetch the assets, just a link to the asset service = and its up to viewer to request the details and show credentials to get the= m. The two girls meet, both their viewers request the details of the other = dress, and Proks asset service grants those requests. They girls admire the= ir dresses and compliment each other with their good taste. Now when i arri= ve and my viewer request the dress details, Prok's asset service recogn= ises me as the copyleftists that i am. It refuses to serve the asset detail= s -and depending on my viewers behaviour i might get to view two girls in s= exy underwear -or wearing even less- instead of party dresses. From a consi= stency point of view this is a highly undesirable situation, it breaks imme= rsion, and depending on the circumstances might also be embarrassing to the= people involved.=A0

The key question is if we want to allow this situation = to arise within VWRAP compliant worlds.
I would like to argue tha= t the region *should* get the capability to fetch all details. In other wor= ds, Prokofy would have to give up some control over the asset in case he al= lows it to be used by my region. Note that this does not mean that the regi= on *has* to proxy the asset, just that in case the asset service refuses to= serve a client it does not like, the region can insist on delivery =A0base= d on the capability it originally got. If that fails Proks asset service ca= n not be called VWRAP compliant. =A0

If Prokofy does not want to relinquish =A0that level of= control, fine, it is his right not to, but in that case the dresses should= not be allowed to get into my region in the first place. =A0If people visi= t my region and find themselves naked in the eyes of some others *I* will g= et the blame. =A0As Morgaine says, the technical details of my innocence wi= ll not convince the general public. So I want methods to prevent breaking m= y highly emergent world as much as possible.=A0
My proposal would be that the whatever the region gets MUST be guarant= eed by protocol to be delivered to =A0anybody within the region requesting = it. If the asset service does not want to serve a cryptocomunist copyleftis= t, fine, but IF it has given the region a capability, it MUST serve the ful= l asset to be VWRAP compliant. Its *my* choice as a region deployer to down= load the full asset to be able to guarantee region consistency if I want to= . I will try to avoid that as much as possible, but if my customers complai= n, i will be forces to start doing this for certain asset services that i k= now show discriminatory behaviour against for instance copyleftist.=A0

Finally Morgaine, you keep hammering on the fact that p= roxying by the region does not scale. (I tend to disagree, but that is besi= de the point here). I do agree the asset should not be needlessly transfere= d, but i strongly feel we must insist in the protocol on transferring the *= rights* to view the asset. If that leads to to the region not getting the a= sset at all, so be it, it can warn visitors that their assets will not be v= isible and even offer to serve simple replacements (1). This in turn will e= ncourage the end users to avoid this type of asset service, and Prokofy wil= l go out of business, as should be the case given the behaviour of the serv= ice. And if he pulls it off, thats fine with me also, as long as i do not h= ave to suffer from it due to lack of rigour in the protocol specs. =A0

So, in summary, I very well see that there is no way to= enforce consistent serving behaviour but it should at least be clear that = it is non-standard and not conform the protocol. The way I am understanding= you now, your argument seems to be just one step to far in the direction o= f anarchy.
Or am i misreading you?

--Vaughn

(1) I just realise that the region might cheat = and advertise its own asset brands claiming the competitions assets =A0coul= d not be rendered... Oh well, one might hope that if there is enough choice= in worlds such regions will be forced =A0out of business as well.=A0

On Sat, Apr 2, 2011 at 7:31 AM, Morgaine <morgaine.dinova@googlemail.com> wrote:
Further to my last post, it's worth noting that if you find that you su= ffer poor quality behavior from a particular asset service and it is breaki= ng the consistency of your simulation, with hash-based item addressing you = can also automatically use an alternative asset service in preference= to the one specified in a given URI.

Your client could be configured to attempt the item fetch at a known go= od quality asset service first (perhaps one that you paid to use bec= ause of its better service), automatically, and maybe even dynamically depe= nding on the type of item.

The scheme has a long list of benefits, and overcoming (to some extent)= poor quality asset services is just one of them.


Morgaine.





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


On Sat, Apr 2, 2011 at 4:55 AM, Morgaine <morgaine.dinova@goo= glemail.com> wrote:
Every design choice results in a trade-off, Vaughn, improving one thing at = the expense of something else.=A0 If every time we offered a service we had= to inform its users about the downsides of all the trade-offs we have made= , they would have an awful lot to read. ;-)

The specific trade-off that you are discussing is no different.=A0 A re= gion that proxies all content has the "benefit" of acquiring cont= rol from the asset servers over the items in the region, so that it can ens= ure that everyone in the region not only obtains the items but obtains the = same items as everyone else.=A0 That does indeed provide a greater g= uarantee of consistency than a deployment in which the region only passes a= sset URIs to clients who then fetch the items from asset services separatel= y.=A0 As always though, it's a trade-off, since the proxied design has = very poor scalability compared to the distributed one.

If we're going to warn users of the potential for inconsistency in = the distributed deployment as you suggest, are we also going to warn them o= f non-scalability in the proxied one?=A0 I really don't see much merit = in the idea of warning about design choices.=A0 Many such choices are techn= ical, and the issues are quite likely to be of little interest to non-techn= ical users anyway.=A0 In any case, the better services are likely to provid= e such information in their online documentation, I would guess.

You mentioned users "voting with their feet" or choosing to a= ccept the risk of inconsistency.=A0 Well that will happen anyway, when serv= ices fail and users get annoyed.=A0 If some asset services refuse to send t= he requested items to some users, those services will get a bad reputation = and people will choose different asset services instead.=A0 Likewise, if a = world service proxies everything and so it can't handle a large number = of assets or of people, users will get annoyed at the lag and will go elsew= here.=A0 This user evaluation and "voting with their feet" happen= s already with online services all over the Internet, and I am sure that th= is human process will continue to work when the services are asset and regi= on services.

Back in September 2010, I wrote this post which proposes that we use in= VWRAP a form of asset addressing that provides massive scalability at the = same time as a very high degree of resilience -- http:/= /www.ietf.org/mail-archive/web/vwrap/current/msg00463.html .=A0 It is b= ased on the concept of the URI containing a host part and a hash part, wher= e the hash is generated (once, at the time of storage to the asset service)= using a specified digest algorithm over the content of the asset being ref= erenced.=A0 You may wish to note that if this design were used, the failure= of an asset service to deliver a requested item would result in a failover= request for the item to one or more backup services, using the same hash p= art but with a different host address.

This can go some way towards overcoming the problem that you think migh= t occur when assets are fetched by clients from asset services directly.=A0= Although it won't help when the missing item is available from only a = single asset service, it will help in many other cases, and it will compens= ate for service failures and network outages automatically at the same time= .

PS. This design for hash-based asset addressing is already being tested= by Mojito Sorbet in her experimental world and client.=A0 It would give VW= RAP-based worlds an improved level of service availability, so I think it s= hould be a core feature of our protocol.


Morgaine.




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

On Fri, Apr 1, 2011 at 11:17 PM, Vaughn De= luca <vaughn.deluca@gmail.com> wrote:
This is a questio= n i discussed with Morgaine off-list a while ago (I
intended to send it to the list but pushed the wrong button...) I
think we need to address this problem, and decide how to deal with it.

=A0In Davids deployment draft, section 7.3.1.1 an overview is given van
ways to deliver content to the region. One way is only passing a
capability that allows access to (part of) the resource:

=A0 =A0 =A0 =A0 =A0 7.3.1.1. =A0Content delivery models
=A0 =A0 =A0 =A0 =A0 A range of possible represenations can be passed to a = region for
=A0 =A0 =A0 =A0 =A0 simulation. [...] The other end of the delivery spectr= um involves passing
=A0 =A0 =A0 =A0 =A0 only a URI or capability used to access the rendering<= br> information and a
=A0 =A0 =A0 =A0 =A0 collision mesh,and related data for physical simulatio= n.
=A0 =A0 =A0 =A0 =A0 In such a model, the client is responsible for fetchin= g the additional
=A0 =A0 =A0 =A0 =A0 information needed to render the item's visual pre= sence from a separate
=A0 =A0 =A0 =A0 =A0 service. =A0This fetch can be done *under the credenti= als of the end user*
=A0 =A0 =A0 =A0 =A0 viewing the material [my emphasis--VD] , and divorces = the
simulation from
=A0 =A0 =A0 =A0 =A0 the trust chain needed to manage content. =A0Any autom= ation
is done on a
=A0 =A0 =A0 =A0 =A0 separate host which the content creator or owner trust= s,
interacting with the
=A0 =A0 =A0 =A0 =A0 object through remoted interfaces.

=A0I can see the need for such a setup, however, i feel we are
unpleasantly close to a situation were the coherence of the simulation
falls apart.
In this deployment pattern the region advertises the presence of the
asset, and *some* clients will be able to get it as expected, while
-based on the arbitrary whims of the asset service- others might not.

My hope would be that after the asset server provides the region with
the capability to get the asset, it gives up control. That would mean
that if the client finds the inventory server is unwilling to serve
the content - in spire of the region saying it is present-, the client
should be able to turn around ask the *region* for the asset, (and get
is after all).

=A0If that is not the case, -and there are probably good reasons for the deployment pattern as described- =A0shouldn't we *warn* clients that th= e
region might be inconsistent, so the users behind the client can vote
with their feet, (or take the risk)?

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




--0016368340c02d9d40049fef1407-- From dyerbrookme@juno.com Sat Apr 2 07:12:53 2011 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 AC7EF3A681B for ; Sat, 2 Apr 2011 07:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 qKPabLEVIAEJ for ; Sat, 2 Apr 2011 07:12:46 -0700 (PDT) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 1BE3C3A6814 for ; Sat, 2 Apr 2011 07:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juno.com; s=alpha; t=1301753662; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; l=0; h=From:Date:To:Cc:Subject:Message-Id:Content-Type; b=CbjSpmVNhQZ28HGEUpczDlhr13nFQ+MNNqD8jdTT4Y3+eDpyYIcNRjAJ078gJNy54 PCaNmOBuy+mwPVFbSFxMsgnF+GhraEMFpio02jgGecow7zHU/S8QHHUAS8b+tA46lZ b4616Cqq+SSBBjsnEmcXBjBXzjCfQSWwuTjZF3rs= X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail09.vgs.untd.com [10.181.12.149]) by smtpout04.vgs.untd.com with SMTP id AABG3QM2XACFFGJS for (sender ); Sat, 2 Apr 2011 07:13:41 -0700 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucf6HyplTnjJho1oyE26oVKTQ/s5/FqZUFw== Received: (from dyerbrookme@juno.com) by webmail09.vgs.untd.com (jqueuemail) id Q7VX2FB2; Sat, 02 Apr 2011 07:13:15 PDT Received: from [173.52.3.243] by webmail09.vgs.untd.com with HTTP: Sat, 2 Apr 2011 14:12:59 GMT X-Originating-IP: [173.52.3.243] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sat, 2 Apr 2011 14:12:59 GMT To: vaughn.deluca@gmail.com X-Mailer: Webmail Version 6.1_P2 Message-Id: <20110402.101259.14412.0@webmail09.vgs.untd.com> Content-Type: multipart/alternative;boundary="--__JWM__J0658.40e2S.53daM" X-UNTD-BodySize: 12145 X-ContentStamp: 1:1:3269397054 X-UNTD-Peer-Info: 10.181.12.149|webmail09.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 14:12:53 -0000 ----__JWM__J0658.40e2S.53daM Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 Vaughn, A key reason the Metaverse construction cannot be left to coder= s and other technologists like yourself alone is this kind of coervice = hypothesis, crowbarring a metaphor in service of a pre-existing agenda.= First of all, I don't make content of any significant amount as an ama= teur, such as to be concerned only about "my dresses" and "little dress= maker genocide" as copyleftist cynics call it. But I express this conce= rn on behalf of my rentals customers who do make content and who are wo= rried -- and rightly so -- about theft, and most of all, I express this= as a *matter of principle*. Second, the notion that girls travelling t= o a party at "Vaugh's Immersive Fabulousness" from "Prokofy's Palm Cafe= At the End of the Mind" need not fear nakedness of Vaughn simply besti= rs himself, *in good faith* (always in short supply with metaversal eng= ineers), to automatically supply a generic dress or Ruth appearance and= outfit in the event that the server can't fetch the assets for any rea= son. So that's specious entirely. Third, if you think customers and the= ir wants and inciting their hatred of platform providers who can't rend= er their dresses in all their pretty glory are the way to hijack the me= taverse for the copyleftist/open source cult agenda, think again. Dress= shoppers can become fiercely loyal patrons of the copyright of their f= avourite designers. Fiercely.And they will mount the consumer boycott a= nd press campaign to match their ferocity. Fourth, If you have a world= in which copying the dresses off avatars is a function of the browser = you let connect to your world, like the copybotting Thugs Lyfe, merely = with a mouseclick or two, then you deserve to be ostracized. And in fac= t, you and all providers can have a policy about not letting such TPV v= iewers connect, as LL does -- and without any pretense that it can cont= rol every manifestation. BTW, the Red Zone statistics of 9 million scan= s with only 78,000 rogue viewers captured lets us know that this proble= m is exaggerated -- and usually by engineers who claim there is no tech= nical solution. Fifth, and most relevant, the metaverse does not have t= o be built entirely on automatic machines that only perform rote routin= es, which are, indeed, only the mechanistic concretization of human wil= l and "nothing special". It can be also constructed of polices and agre= ements rooted in organic minds and organic institutions. And that's ok.= And that would mean a basic charter, that could be as historical and e= pic as the Magna Charter or as mundane as the Bottle Bill of Rights han= ging on the wall of your supermarket. And that charter would spell out = that platforms that do not respect copyright *by including the engineer= ed DRM on creations* and *by including a TPV policy* do not get the han= dshake, do not get the hookup. And that's it. It's not so hard, truly. = These treaties can be forged at real-life in-person conventions, just l= ike other technical agreements are, including IEEE standards, and they = can be forged ultimately in a "scaling" fashion by having templates tha= t a server seeking to make a connection with have or not have, not wit= hstanding Morgaine's wild and hysterical notions that "nothing" can be = trusted on the Internet and trust regimes are all a scam. It's not abou= t Prokofy relinquishing control for the sake of his customers' eye cand= y. It's about two platforms shaking hands on an established pre-existin= g agreement that becomes the metaversal standard -- and a standard crea= ted not by a cabal of a few engineers in an obscure IEEF working group,= but open conventions. And please don't pretend this can't scale. There= 's about 17 and a half virtual worlds out there at most that really hav= e any viability and people on them with stuff that works for the user. = So they can make a confederation of standards that does respect the *te= chnical implementation* of copyright and intellectual property rights *= simply because they can*. It's a matter of political will, and its abse= nce now is one of blatant collectivist ideology at work. If you yoursel= f opt to break your fabulous immersive world by not putting default dre= sses on people in decency, and more to the point, not abiding by a simp= le protocol to include DRM as a default with the "export to other grids= " box and c/m/t boxes checked, and "TPV policy compliant" then you're t= he problem, not Prokofy's fear of crypto communists hiding under the s= ervers. You seem to be like all followers of the California Business Mo= del (let all uploads first, sell ads, then DMCA takedowns later) -- and= you seem to be willing to wait for your customers complain. That's not= necessary if you're an ethical provider -- you can make the agreements= first. Forcing the issue by deploying the age-old "analog hole" argume= nt and whining that you "must" serve up the view of an asset your custo= mers "expect" to see or already "can" see doesn't let you off the hook.= There is no reason to be literalist about it. You can weld c/m/t into = operability from the get-go. You can refuse to allow viewers that copyb= ot. Your resistance to this is purely ideological. And BTW, if you pers= ist in calling people who rightfully and legitimately raise copyright c= oncerns and rightly and legitimately point out the copyleftist ideologi= cal bias as "paranoid" and "conspiracy theorists" and "fearful of cryp= tocommunists" and "McCarthyites" than you're going to go on being calle= d the Leninists that you in fact are. Prokofy = ____________________________________________________________ Groupon™ Official Site 1 ridiculously huge coupon a day. Get 50-90% off your city's best! http://thirdpartyoffers.juno.com/TGL3141/4d972f1545e6f4f6811st04vuc ----__JWM__J0658.40e2S.53daM Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/html; charset=ISO-8859-1
Vaughn,
 
A key reason the Metaverse= construction cannot be left to coders and other technologists like you= rself alone is this kind of coervice hypothesis, crowbarring a metaphor= in service of a pre-existing agenda.
 
First = of all, I don't make content of any significant amount as an amateur, s= uch as to be concerned only about "my dresses" and "little dressmaker g= enocide" as copyleftist cynics call it. But I express this concern on b= ehalf of my rentals customers who do make content and who are worried -= - and rightly so -- about theft, and most of all, I express this as a *= matter of principle*.
 
Second, the notion tha= t girls travelling to a party at "Vaugh's Immersive Fabulousness" from = "Prokofy's Palm Cafe At the End of the Mind" need not fear nakedness of= Vaughn simply bestirs himself, *in good faith* (always in short supply= with metaversal engineers), to automatically supply a generic dress or= Ruth appearance and outfit in the event that the server can't fetch th= e assets for any reason. So that's specious entirely.
 <= /div>
Third, if you think customers and their wants and inciting th= eir hatred of platform providers who can't render their dresses in all = their pretty glory are the way to hijack the metaverse for the copyleft= ist/open source cult agenda, think again. Dress shoppers can become fie= rcely loyal patrons of the copyright of their favourite designers. Fier= cely.And they will mount the consumer boycott and press campaign to mat= ch their ferocity.
 
Fourth, If you have a wor= ld in which copying the dresses off avatars is a function of the browse= r you let connect to your world, like the copybotting Thugs Lyfe, merel= y with a mouseclick or two, then you deserve to be ostracized. And in f= act, you and all providers can have a policy about not letting such TPV= viewers connect, as LL does -- and without any pretense that it can co= ntrol every manifestation. BTW, the Red Zone statistics of 9 million sc= ans with only 78,000 rogue viewers captured lets us know that this prob= lem is exaggerated -- and usually by engineers who claim there is no te= chnical solution.
 
Fifth, and most relevant, t= he metaverse does not have to be built entirely on automatic machines t= hat only perform rote routines, which are, indeed, only the mechanistic= concretization of human will and "nothing special".
 
It can be also constructed of polices and agreements rooted in= organic minds and organic institutions. And that's ok. And that would = mean a basic charter, that could be as historical and epic as the Magna= Charter or as mundane as the Bottle Bill of Rights hanging on the wall= of your supermarket. And that charter would spell out that platforms t= hat do not respect copyright *by including the engineered DRM on creati= ons* and *by including a TPV policy* do not get the handshake, do not g= et the hookup. And that's it. It's not so hard, truly.
 =
These treaties can be forged at real-life in-person conventi= ons, just like other technical agreements are, including IEEE standards= , and they can be forged ultimately in a "scaling" fashion by having te= mplates that a server seeking to make a connection with have or not hav= e, not withstanding Morgaine's wild and hysterical notions that "nothin= g" can be trusted on the Internet and trust regimes are all a scam.
 
It's not about Prokofy relinquishing control fo= r the sake of his customers' eye candy. It's about two platforms shakin= g hands on an established pre-existing agreement that becomes the metav= ersal standard -- and a standard created not by a cabal of a few engine= ers in an obscure IEEF working group, but open conventions.
&= nbsp;
And please don't pretend this can't scale. There's abou= t 17 and a half virtual worlds out there at most that really have any v= iability and people on them with stuff that works for the user. So they= can make a confederation of standards that does respect the *technical= implementation* of copyright and intellectual property rights *simply = because they can*. It's a matter of political will, and its absence now= is one of blatant collectivist ideology at work.
 
If you yourself opt to break your fabulous immersive world by not= putting default dresses on people in decency, and more to the point, n= ot abiding by a simple protocol to include DRM as a default with the "e= xport to other grids" box and c/m/t boxes checked, and "TPV policy comp= liant" then you're the problem, not Prokofy's fear of crypto communists= hiding under the servers.
 
You seem to be li= ke all followers of the California Business Model (let all uploads firs= t, sell ads, then DMCA takedowns later) -- and you seem to be willing t= o wait for your customers complain.
 
That's n= ot necessary if you're an ethical provider -- you can make the agreemen= ts first. Forcing the issue by deploying the age-old "analog hole" argu= ment and whining that you "must" serve up the view of an asset your cus= tomers "expect" to see or already "can" see doesn't let you off the hoo= k. There is no reason to be literalist about it. You can weld c/m/t int= o operability from the get-go. You can refuse to allow viewers that cop= ybot. Your resistance to this is purely ideological.
 
And BTW, if you persist in calling people who rightfully and l= egitimately raise copyright concerns and rightly and legitimately point= out the copyleftist ideological bias as "paranoid" and "conspiracy the= orists" and "fearful of cryptocommunists" and "McCarthyites" than you'r= e going to go on being called the Leninists that you in fact are.
=
 
Prokofy
 
 


_____________________________= _______________________________
Groupon™ Official Site
1 ridiculously huge coupon a day. Get 50-90% off your = city's best!
Groupon.com ----__JWM__J0658.40e2S.53daM-- From dyerbrookme@juno.com Sat Apr 2 07:25:35 2011 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 270103A682A for ; Sat, 2 Apr 2011 07:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 j3yBqHU4-LO5 for ; Sat, 2 Apr 2011 07:25:33 -0700 (PDT) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id E10FE3A682B for ; Sat, 2 Apr 2011 07:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juno.com; s=alpha; t=1301754432; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; l=0; h=From:Date:To:Cc:Subject:Message-Id:Content-Type; b=ombvQx/3EU4C+CyOvXrS9skXMO4pcmZOfOk55dOPoyTzD62ZRQu4OfnD9ULeTTqL+ FfNTdPj9VjgoP7AJpPcpOvINF4gSPxJ3UrrtqvgTv/bFdGZQ5EzrguFyQvIV9auaxz FpkFYDCHVV1Wx5KkWItxtWB40UjAy+y03ddlLX0I= X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail09.vgs.untd.com [10.181.12.149]) by smtpout03.vgs.untd.com with SMTP id AABG3QNTRAQHX3GA for (sender ); Sat, 2 Apr 2011 07:26:55 -0700 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucf6HyplTnjJhW/umrhGUoHA+0oS/40xfXA== Received: (from dyerbrookme@juno.com) by webmail09.vgs.untd.com (jqueuemail) id Q7VYRYCV; Sat, 02 Apr 2011 07:26:07 PDT Received: from [173.52.3.243] by webmail09.vgs.untd.com with HTTP: Sat, 2 Apr 2011 14:25:38 GMT X-Originating-IP: [173.52.3.243] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sat, 2 Apr 2011 14:25:38 GMT To: morgaine.dinova@googlemail.com X-Mailer: Webmail Version 6.1_P2 Message-Id: <20110402.102538.14412.1@webmail09.vgs.untd.com> Content-Type: multipart/alternative;boundary="--__JWM__J7b66.0912S.7347M" X-UNTD-BodySize: 6996 X-ContentStamp: 1:1:3194961392 X-UNTD-Peer-Info: 10.181.12.149|webmail09.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 14:25:35 -0000 ----__JWM__J7b66.0912S.7347M Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 >The problem however is that you are asking the impossible, namely that = one party (the region provider) should have policy control over another= (the asset service provider). As David has said on many different oc= casions and in various different ways, this attempt at policy export ju= st won't work in practice, because each party is "sovereign" over its o= wn service, so to speak. At best you can only recommend or hope for se= nsible behavior by all, and if there is a legal relationship between th= e parties then presumably the pressure of law can help as well. Just bec= ause David Levine (if that's who is referenced) has said something is tr= ue a million times doesn't make it true. He may have a very well-informe= d opinion, but he knows as well as anyone that when early pioneers have = achieved things in the Metaverse, like Linden Lab creating a version of = Second Life to go behind the firewall, it was done by concluding an orga= nic bilateral agreement with a company, IBM, not by fiddling with techni= cal set-ups. When talks on interoperability began in San Jose in 2008 at= the Virtual Worlds expo, it was in a closed meeting by invitation only = to have an organic meeting about organic politics, not because some gagg= le of geeks created some mechanical protocol for a cyberspace bridge. Of= course one party can have policy control over another *when both are bo= und by a higher law*. These sorts of basic notion of the rule of law and= the rule of international law are always missing from this discussion d= ominated by the coarse and tribal rule of code, which is merely the brut= al manifestation of human will (and is therefore a weapon). In fact, the= larger commercial providers and those earliest in the space like Linden= Lab will get together and make the necessary "treaties" and eventually = all these "millions" of little moms and pops (there are actually only 17= and a half) will be forced out of business if they refuse to respect co= pyright. And that will be a good thing, because copyleftism is coercive,= and not about freedom for the economy or the creator or the consumer. V= irtual worlds are not "the Internet" even if they are reached by "the In= ternet". They have features of real-time interactivity and user-generate= d content and human relationships that do no pertain on the static, read= , non-interactive text and image page of the previous Internet iteration= s. Therefore the "rules" that the pioneers of web 1.0 and even 2.0 keep = yammering about do not *have* to obtain; indeed, their coerceive collect= ivization has been a hobble to commerce and destructive of livlihoods. F= acebook, Twitter, Quora, these all illustrate how the concept of "open" = -- in the closed notion it has existed in the open source cult -- is not= useful and not necessary -- even if technically some open source code i= s used in these enterprises. A person whose dress is not served will hav= e every reason to stay on their home world. And stay home they will, unt= il the other grid shapes up and abides by the right protocols to ensure = that their favourite dressmaker's dress can be served and seen but not c= opybotted. Prokofy = ____________________________________________________________ Groupon.com Official Site 1 huge daily deal on the best stuff to do in your city. Try it today! http://thirdpartyoffers.juno.com/TGL3141/4d97322fc28c04eac5cst03vuc ----__JWM__J7b66.0912S.7347M Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/html; charset=ISO-8859-1
>The problem however is that you are asking the impossible= , namely that one party (the region provider) should have policy contro= l over another (the asset service provider).  As David has said on= many different occasions and in various different ways, this attempt a= t policy export just won't work in practice, because each party is "sov= ereign" over its own service, so to speak.  At best you can only r= ecommend or hope for sensible behavior by all, and if there is a legal = relationship between the parties then presumably the pressure of law ca= n help as well.
 
Just because David Levine (if= that's who is referenced) has said something is true a million times do= esn't make it true. He may have a very well-informed opinion, but he kno= ws as well as anyone that when early pioneers have achieved things in th= e Metaverse, like Linden Lab creating a version of Second Life to go beh= ind the firewall, it was done by concluding an organic bilateral agreeme= nt with a company, IBM, not by fiddling with technical set-ups. When tal= ks on interoperability began in San Jose in 2008 at the Virtual Worlds e= xpo, it was in a closed meeting by invitation only to have an organic me= eting about organic politics, not because some gaggle of geeks created s= ome mechanical protocol for a cyberspace bridge.
 
<= div>Of course one party can have policy control over another *when both = are bound by a higher law*. These sorts of basic notion of the rule of l= aw and the rule of international law are always missing from this discus= sion dominated by the coarse and tribal rule of code, which is merely th= e brutal manifestation of human will (and is therefore a weapon).
<= div> 
In fact, the larger commercial providers and those = earliest in the space like Linden Lab will get together and make the nec= essary "treaties" and eventually all these "millions" of little moms and= pops (there are actually only 17 and a half) will be forced out of busi= ness if they refuse to respect copyright. And that will be a good thing,= because copyleftism is coercive, and not about freedom for the economy = or the creator or the consumer.
 
Virtual world= s are not "the Internet" even if they are reached by "the Internet". The= y have features of real-time interactivity and user-generated content an= d human relationships that do no pertain on the static, read, non-intera= ctive text and image page of the previous Internet iterations. Therefore= the "rules" that the pioneers of web 1.0 and even 2.0 keep yammering ab= out do not *have* to obtain; indeed, their coerceive collectivization ha= s been a hobble to commerce and destructive of livlihoods.
&nb= sp;
Facebook, Twitter, Quora, these all illustrate how the con= cept of "open" -- in the closed notion it has existed in the open source= cult -- is not useful and not necessary -- even if technically some ope= n source code is used in these enterprises.
 
A= person whose dress is not served will have every reason to stay on thei= r home world. And stay home they will, until the other grid shapes up an= d abides by the right protocols to ensure that their favourite dressmake= r's dress can be served and seen but not copybotted.
 
Prokofy
 
 


_____________________________= _______________________________
Groupon.com Official Site
1 huge daily deal on the best stuff to do in your city. = Try it today!
Gr= oupon.com ----__JWM__J7b66.0912S.7347M-- From djshag@hotmail.com Sat Apr 2 08:01:39 2011 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 DE53F3A683A for ; Sat, 2 Apr 2011 08:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6YP4Hfif4IK for ; Sat, 2 Apr 2011 08:01:38 -0700 (PDT) Received: from blu0-omc2-s10.blu0.hotmail.com (blu0-omc2-s10.blu0.hotmail.com [65.55.111.85]) by core3.amsl.com (Postfix) with ESMTP id C5C383A6837 for ; Sat, 2 Apr 2011 08:01:37 -0700 (PDT) Received: from BLU159-DS8 ([65.55.111.73]) by blu0-omc2-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 2 Apr 2011 08:03:18 -0700 X-Originating-IP: [184.163.193.51] X-Originating-Email: [djshag@hotmail.com] Message-ID: From: "Patnad Babii" To: , References: <20110402.101259.14412.0@webmail09.vgs.untd.com> In-Reply-To: <20110402.101259.14412.0@webmail09.vgs.untd.com> Date: Sat, 2 Apr 2011 11:03:17 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01CBF125.91F0C330" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3508.1109 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3508.1109 X-OriginalArrivalTime: 02 Apr 2011 15:03:18.0708 (UTC) FILETIME=[19BE8740:01CBF147] Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 15:01:40 -0000 Ce message est compos et au format MIME. ------=_NextPart_000_0042_01CBF125.91F0C330 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Let me put it simple, Linden Lab is not forced to use this protocol at = ALL and I'm pretty sure as they are a pretty big company with brains, = they are not going to allow something that=E2=80=99s going to reduce = security or allow more thief to their grid anytime soon. This protocol is intended mostly for other Open virtual worlds. If at a = point Linden Labs find it an interest in the protocol they might = implement it. Linden Labs is not working anymore on grid interop for = some time now, so please stop being afraid by the big bad wolf, cause it = is not here you are going to find it.=20 From: dyerbrookme@juno.com=20 Sent: Saturday, April 02, 2011 10:12 AM To: vaughn.deluca@gmail.com=20 Cc: vwrap@ietf.org=20 Subject: Re: [vwrap] [wvrap] Simulation consistency Vaughn, A key reason the Metaverse construction cannot be left to coders and = other technologists like yourself alone is this kind of coervice = hypothesis, crowbarring a metaphor in service of a pre-existing agenda. First of all, I don't make content of any significant amount as an = amateur, such as to be concerned only about "my dresses" and "little = dressmaker genocide" as copyleftist cynics call it. But I express this = concern on behalf of my rentals customers who do make content and who = are worried -- and rightly so -- about theft, and most of all, I express = this as a *matter of principle*. Second, the notion that girls travelling to a party at "Vaugh's = Immersive Fabulousness" from "Prokofy's Palm Cafe At the End of the = Mind" need not fear nakedness of Vaughn simply bestirs himself, *in good = faith* (always in short supply with metaversal engineers), to = automatically supply a generic dress or Ruth appearance and outfit in = the event that the server can't fetch the assets for any reason. So = that's specious entirely. Third, if you think customers and their wants and inciting their hatred = of platform providers who can't render their dresses in all their pretty = glory are the way to hijack the metaverse for the copyleftist/open = source cult agenda, think again. Dress shoppers can become fiercely = loyal patrons of the copyright of their favourite designers. = Fiercely.And they will mount the consumer boycott and press campaign to = match their ferocity. Fourth, If you have a world in which copying the dresses off avatars is = a function of the browser you let connect to your world, like the = copybotting Thugs Lyfe, merely with a mouseclick or two, then you = deserve to be ostracized. And in fact, you and all providers can have a = policy about not letting such TPV viewers connect, as LL does -- and = without any pretense that it can control every manifestation. BTW, the = Red Zone statistics of 9 million scans with only 78,000 rogue viewers = captured lets us know that this problem is exaggerated -- and usually by = engineers who claim there is no technical solution. Fifth, and most relevant, the metaverse does not have to be built = entirely on automatic machines that only perform rote routines, which = are, indeed, only the mechanistic concretization of human will and = "nothing special". It can be also constructed of polices and agreements rooted in organic = minds and organic institutions. And that's ok. And that would mean a = basic charter, that could be as historical and epic as the Magna Charter = or as mundane as the Bottle Bill of Rights hanging on the wall of your = supermarket. And that charter would spell out that platforms that do not = respect copyright *by including the engineered DRM on creations* and *by = including a TPV policy* do not get the handshake, do not get the hookup. = And that's it. It's not so hard, truly. These treaties can be forged at real-life in-person conventions, just = like other technical agreements are, including IEEE standards, and they = can be forged ultimately in a "scaling" fashion by having templates that = a server seeking to make a connection with have or not have, not = withstanding Morgaine's wild and hysterical notions that "nothing" can = be trusted on the Internet and trust regimes are all a scam. It's not about Prokofy relinquishing control for the sake of his = customers' eye candy. It's about two platforms shaking hands on an = established pre-existing agreement that becomes the metaversal standard = -- and a standard created not by a cabal of a few engineers in an = obscure IEEF working group, but open conventions. And please don't pretend this can't scale. There's about 17 and a half = virtual worlds out there at most that really have any viability and = people on them with stuff that works for the user. So they can make a = confederation of standards that does respect the *technical = implementation* of copyright and intellectual property rights *simply = because they can*. It's a matter of political will, and its absence now = is one of blatant collectivist ideology at work. If you yourself opt to break your fabulous immersive world by not = putting default dresses on people in decency, and more to the point, not = abiding by a simple protocol to include DRM as a default with the = "export to other grids" box and c/m/t boxes checked, and "TPV policy = compliant" then you're the problem, not Prokofy's fear of crypto = communists hiding under the servers. You seem to be like all followers of the California Business Model (let = all uploads first, sell ads, then DMCA takedowns later) -- and you seem = to be willing to wait for your customers complain. That's not necessary if you're an ethical provider -- you can make the = agreements first. Forcing the issue by deploying the age-old "analog = hole" argument and whining that you "must" serve up the view of an asset = your customers "expect" to see or already "can" see doesn't let you off = the hook. There is no reason to be literalist about it. You can weld = c/m/t into operability from the get-go. You can refuse to allow viewers = that copybot. Your resistance to this is purely ideological. And BTW, if you persist in calling people who rightfully and = legitimately raise copyright concerns and rightly and legitimately point = out the copyleftist ideological bias as "paranoid" and "conspiracy = theorists" and "fearful of cryptocommunists" and "McCarthyites" than = you're going to go on being called the Leninists that you in fact are. Prokofy ____________________________________________________________ Groupon=E2=84=A2 Official Site 1 ridiculously huge coupon a day. Get 50-90% off your city's best! Groupon.com=20 -------------------------------------------------------------------------= ------- _______________________________________________ vwrap mailing list vwrap@ietf.org https://www.ietf.org/mailman/listinfo/vwrap ------=_NextPart_000_0042_01CBF125.91F0C330 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Let me put it simple, Linden Lab is not forced to use this protocol = at ALL=20 and I'm pretty sure as they are a pretty big company with brains, they = are not=20 going to allow something that=E2=80=99s going to reduce security or = allow more thief to=20 their grid anytime soon.
 
This protocol is intended mostly for other Open virtual = worlds.  If at=20 a point Linden Labs find it an interest in the protocol they might = implement it.=20 Linden Labs is not working anymore on grid interop for some time now, so = please=20 stop being afraid by the big bad wolf, cause it is not here you are = going to=20 find it.
 
 
Sent: Saturday, April 02, 2011 10:12 AM
Subject: Re: [vwrap] [wvrap] Simulation=20 consistency
 
Vaughn,
 
A key reason the Metaverse construction cannot be left to coders = and other=20 technologists like yourself alone is this kind of coervice hypothesis,=20 crowbarring a metaphor in service of a pre-existing agenda.
 
First of all, I don't make content of any significant amount as an = amateur,=20 such as to be concerned only about "my dresses" and "little dressmaker = genocide"=20 as copyleftist cynics call it. But I express this concern on behalf of = my=20 rentals customers who do make content and who are worried -- and rightly = so --=20 about theft, and most of all, I express this as a *matter of = principle*.
 
Second, the notion that girls travelling to a party at "Vaugh's = Immersive=20 Fabulousness" from "Prokofy's Palm Cafe At the End of the Mind" need not = fear=20 nakedness of Vaughn simply bestirs himself, *in good faith* (always in = short=20 supply with metaversal engineers), to automatically supply a generic = dress or=20 Ruth appearance and outfit in the event that the server can't fetch the = assets=20 for any reason. So that's specious entirely.
 
Third, if you think customers and their wants and inciting their = hatred of=20 platform providers who can't render their dresses in all their pretty = glory are=20 the way to hijack the metaverse for the copyleftist/open source cult = agenda,=20 think again. Dress shoppers can become fiercely loyal patrons of the = copyright=20 of their favourite designers. Fiercely.And they will mount the consumer = boycott=20 and press campaign to match their ferocity.
 
Fourth, If you have a world in which copying the dresses off = avatars is a=20 function of the browser you let connect to your world, like the = copybotting=20 Thugs Lyfe, merely with a mouseclick or two, then you deserve to be = ostracized.=20 And in fact, you and all providers can have a policy about not letting = such TPV=20 viewers connect, as LL does -- and without any pretense that it can = control=20 every manifestation. BTW, the Red Zone statistics of 9 million scans = with only=20 78,000 rogue viewers captured lets us know that this problem is = exaggerated --=20 and usually by engineers who claim there is no technical solution.
 
Fifth, and most relevant, the metaverse does not have to be built = entirely=20 on automatic machines that only perform rote routines, which are, = indeed, only=20 the mechanistic concretization of human will and "nothing = special".
 
It can be also constructed of polices and agreements rooted in = organic=20 minds and organic institutions. And that's ok. And that would mean a = basic=20 charter, that could be as historical and epic as the Magna Charter or as = mundane=20 as the Bottle Bill of Rights hanging on the wall of your supermarket. = And that=20 charter would spell out that platforms that do not respect copyright *by = including the engineered DRM on creations* and *by including a TPV = policy* do=20 not get the handshake, do not get the hookup. And that's it. It's not so = hard,=20 truly.
 
These treaties can be forged at real-life in-person conventions, = just like=20 other technical agreements are, including IEEE standards, and they can = be forged=20 ultimately in a "scaling" fashion by having templates that a server = seeking to=20 make a connection with have or not have, not withstanding Morgaine's = wild and=20 hysterical notions that "nothing" can be trusted on the Internet and = trust=20 regimes are all a scam.
 
It's not about Prokofy relinquishing control for the sake of his = customers'=20 eye candy. It's about two platforms shaking hands on an established = pre-existing=20 agreement that becomes the metaversal standard -- and a standard created = not by=20 a cabal of a few engineers in an obscure IEEF working group, but open=20 conventions.
 
And please don't pretend this can't scale. There's about 17 and a = half=20 virtual worlds out there at most that really have any viability and = people on=20 them with stuff that works for the user. So they can make a = confederation of=20 standards that does respect the *technical implementation* of copyright = and=20 intellectual property rights *simply because they can*. It's a matter of = political will, and its absence now is one of blatant collectivist = ideology at=20 work.
 
If you yourself opt to break your fabulous immersive world by not = putting=20 default dresses on people in decency, and more to the point, not abiding = by a=20 simple protocol to include DRM as a default with the "export to other = grids" box=20 and c/m/t boxes checked, and "TPV policy compliant" then you're the = problem, not=20 Prokofy's fear of crypto communists hiding under the servers.
 
You seem to be like all followers of the California Business Model = (let all=20 uploads first, sell ads, then DMCA takedowns later) -- and you seem to = be=20 willing to wait for your customers complain.
 
That's not necessary if you're an ethical provider -- you can make = the=20 agreements first. Forcing the issue by deploying the age-old "analog = hole"=20 argument and whining that you "must" serve up the view of an asset your=20 customers "expect" to see or already "can" see doesn't let you off the = hook.=20 There is no reason to be literalist about it. You can weld c/m/t into=20 operability from the get-go. You can refuse to allow viewers that = copybot. Your=20 resistance to this is purely ideological.
 
And BTW, if you persist in calling people who rightfully and = legitimately=20 raise copyright concerns and rightly and legitimately point out the = copyleftist=20 ideological bias as "paranoid" and "conspiracy theorists" and "fearful = of=20 cryptocommunists" and "McCarthyites" than you're going to go on being = called the=20 Leninists that you in fact are.
 
Prokofy
 
 


____________________________________________________________
Groupon=E2=84=A2 Official=20 Site
1 ridiculously huge = coupon a day.=20 Get 50-90% off your city's best!
Groupon.com=20

_______________________________________________
vwrap mailing=20 list
vwrap@ietf.org
https://www.ietf.org/mailman/listinfo/vwrap
=
------=_NextPart_000_0042_01CBF125.91F0C330-- From morgaine.dinova@googlemail.com Sat Apr 2 08:08:12 2011 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 A697C3A683C for ; Sat, 2 Apr 2011 08:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 WwGVvuLh-hIN for ; Sat, 2 Apr 2011 08:08:10 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 94F173A6837 for ; Sat, 2 Apr 2011 08:08:09 -0700 (PDT) Received: by qwg5 with SMTP id 5so3093590qwg.31 for ; Sat, 02 Apr 2011 08:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cjmSbKO1+TqFuYXu6+ywPlxg17+JXsnm1VrDD33Vc4o=; b=ONcQA4tejXW5lp/orAqVo6QJGA3AE0hW4eKvfR82XWnJ17Z2+CWarErQtTBOZHRJOz 5gWiQ/0uI2GwTkDw66Yhh6+WjrTfL/LkUGoi4HemNsIToUMys6P+nGn2QpTShBEf4SeJ i5zC8VSUjKgZ52S5GBqOG7O9y/rr1j+56xHKA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iJdwe76bWBo+v4jFgSHWnQUAV/e+B9c0W5gncwOCh1RzmEEoqJkYOtN6ccCs3C0zWh uChT0E0+YxI0pDOd9eReVUNJXO+cbPlwhutI9O4jus54Zdb4rQd6Obuc8Nc34rx0jy9C fpitSMjvWOcJnkRhq3UQfDuEJQKxdYSfhbE/k= MIME-Version: 1.0 Received: by 10.229.105.82 with SMTP id s18mr12286qco.109.1301756989966; Sat, 02 Apr 2011 08:09:49 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sat, 2 Apr 2011 08:09:49 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Apr 2011 16:09:49 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=002354470e60f888f0049ff0eac4 Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 15:08:12 -0000 --002354470e60f888f0049ff0eac4 Content-Type: text/plain; charset=ISO-8859-1 Vaughn, I left your final (and very important) point for the end of my response, and then I fired off my email without addressing it ... Sorry. :P On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca wrote: > So I want methods to prevent breaking my highly emergent world as much as > possible. > Yes indeed!!! You have a perfectly reasonable requirement for the service that you want to operate, and you need some means of meeting it. I agree with that wholeheartedly. I only begin to disagree when you hint that your requirement must be imposed on everyone, whether they want it or not. That I cannot support, and I expect that you did not mean it that way anyway. After all, some of my requirements are probably not of interest to you either, and you would not wish me to impose them on you. It cuts both ways. So, how can we enable you to offer a service with many 9's of simulation consistency, without imposing that requirement on those who prefer a different trade-off? You hinted at the solution yourself, so I'll merely elaborate on it. You wrote: I would like to argue that the region *should* get the capability to fetch > all details. [...] Note that this does not mean that the region *has* to > proxy the asset, just that in case the asset service refuses to serve a > client it does not like, the region can insist on delivery based on the > capability it originally got. > Perfect. All you need then is an optional query in the protocol that allows a region to ask each asset service referenced by assets carried by newly arriving avatars the following question: QUERY: "*Do I have your permission to fetch from your asset service the assets normally reserved for client fetches, and to distribute these assets to clients directly in the (unexpected) event that I want to?*" That easily maps to an optional capability request of course. If the asset service answers "No" to you, then you can deny the incoming avatar entry to your region, returning a status that indicates RESPONSE: "*Asset service X referenced by asset Y does not meet the re-distribution requirement requested for entry to region Z*". Your requirement is then satisfied (I believe) without imposing that requirement on a region operator who does not need it because they desire a different trade-off. Those who don't have your requirement simply won't request the capability. For example, it would be pointless to even ask an asset service founded entirely around Creative Commons assets that question, since all CC content is perpetually and non-revocably redistributable by anyone and to anyone. By not issuing the query we can save ourselves the round-trip time and allow faster entry to the region. Would something like that get the nod from you? PS. You need to note that when an asset service answers "Yes" to your query, this does not mean that it will necessarily honor its promise when you actually attempt to fetch items. David's very important point about independent parties not having control over each other applies here. You can at most hope that it will behave well, and perhaps test the promise by fetching something. However, if you truly want as many 9's of consistency as is obtainable then you will have to fetch all the assets yourself prior to allowing entry to the avatar, and that would be a dreadful overhead. Most people will probably settle for "*best effort*" approaches, which are quite likely to succeed. Morgaine. ===================== On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca wrote: > Morgaine, Meadhbh, > > Thanks for the answers, but i see that i have not been clear enough. > I think the protocol should demand certain things to prevent the > deterioration of the simulation to an unacceptable level. We need to be > more precise to prevent problems and i think we can. > > I was arguing from the perspecive of a region service without making that > explicit. Note i was *not* advocating the region proxies everything, just > that it lives up to its promises about object presence. Also note that i do > *not* always have the option to pick another high quality asset service, > since I normally do not own the assets. I will use Prokofy as an example > just for the fun of it. He is highly worried about content theft, so (in > the unlikely case he wants to start selling stuff outside of SL) he might > use this deployment pattern. Assume he sells wonderful sexy dresses to two > customers, that can only be fetched from his own asset service for > rendering. Both customers go off to "Vaughns highly immersive world" were a > party is given. My region receives some physics properties of the dresses > for simulation and an address of Proks asset service for high-res details > and textures. In this case the region does not even get the capability to > fetch the assets, just a link to the asset service and its up to viewer to > request the details and show credentials to get them. The two girls meet, > both their viewers request the details of the other dress, and Proks asset > service grants those requests. They girls admire their dresses and > compliment each other with their good taste. Now when i arrive and my viewer > request the dress details, Prok's asset service recognises me as the > copyleftists that i am. It refuses to serve the asset details -and depending > on my viewers behaviour i might get to view two girls in sexy underwear -or > wearing even less- instead of party dresses. From a consistency point of > view this is a highly undesirable situation, it breaks immersion, and > depending on the circumstances might also be embarrassing to the people > involved. > > The key question is if we want to allow this situation to arise within > VWRAP compliant worlds. > I would like to argue that the region *should* get the capability to fetch > all details. In other words, Prokofy would have to give up some control over > the asset in case he allows it to be used by my region. Note that this does > not mean that the region *has* to proxy the asset, just that in case the > asset service refuses to serve a client it does not like, the region can > insist on delivery based on the capability it originally got. If that fails > Proks asset service can not be called VWRAP compliant. > > If Prokofy does not want to relinquish that level of control, fine, it is > his right not to, but in that case the dresses should not be allowed to get > into my region in the first place. If people visit my region and find > themselves naked in the eyes of some others *I* will get the blame. As > Morgaine says, the technical details of my innocence will not convince the > general public. So I want methods to prevent breaking my highly emergent > world as much as possible. > My proposal would be that the whatever the region gets MUST be guaranteed > by protocol to be delivered to anybody within the region requesting it. If > the asset service does not want to serve a cryptocomunist copyleftist, fine, > but IF it has given the region a capability, it MUST serve the full asset to > be VWRAP compliant. Its *my* choice as a region deployer to download the > full asset to be able to guarantee region consistency if I want to. I will > try to avoid that as much as possible, but if my customers complain, i will > be forces to start doing this for certain asset services that i know show > discriminatory behaviour against for instance copyleftist. > > Finally Morgaine, you keep hammering on the fact that proxying by the > region does not scale. (I tend to disagree, but that is beside the point > here). I do agree the asset should not be needlessly transfered, but i > strongly feel we must insist in the protocol on transferring the *rights* to > view the asset. If that leads to to the region not getting the asset at all, > so be it, it can warn visitors that their assets will not be visible and > even offer to serve simple replacements (1). This in turn will encourage the > end users to avoid this type of asset service, and Prokofy will go out of > business, as should be the case given the behaviour of the service. And if > he pulls it off, thats fine with me also, as long as i do not have to suffer > from it due to lack of rigour in the protocol specs. > > So, in summary, I very well see that there is no way to enforce consistent > serving behaviour but it should at least be clear that it is non-standard > and not conform the protocol. The way I am understanding you now, your > argument seems to be just one step to far in the direction of anarchy. > Or am i misreading you? > > --Vaughn > > > (1) I just realise that the region might cheat and advertise its own asset > brands claiming the competitions assets could not be rendered... Oh well, > one might hope that if there is enough choice in worlds such regions will be > forced out of business as well. > > On Sat, Apr 2, 2011 at 7:31 AM, Morgaine wrote: > >> Further to my last post, it's worth noting that if you find that you >> suffer poor quality behavior from a particular asset service and it is >> breaking the consistency of your simulation, with hash-based item addressing >> you can also automatically use an alternative asset service *in >> preference* to the one specified in a given URI. >> >> Your client could be configured to attempt the item fetch at a known good >> quality asset service *first* (perhaps one that you paid to use because >> of its better service), automatically, and maybe even dynamically depending >> on the type of item. >> >> The scheme has a long list of benefits, and overcoming (to some extent) >> poor quality asset services is just one of them. >> >> >> Morgaine. >> >> >> >> >> >> =================== >> >> >> On Sat, Apr 2, 2011 at 4:55 AM, Morgaine wrote: >> >>> Every design choice results in a trade-off, Vaughn, improving one thing >>> at the expense of something else. If every time we offered a service we had >>> to inform its users about the downsides of all the trade-offs we have made, >>> they would have an awful lot to read. ;-) >>> >>> The specific trade-off that you are discussing is no different. A region >>> that proxies all content has the "benefit" of acquiring control from the >>> asset servers over the items in the region, so that it can ensure that >>> everyone in the region not only obtains the items but obtains the *same*items as everyone else. That does indeed provide a greater guarantee of >>> consistency than a deployment in which the region only passes asset URIs to >>> clients who then fetch the items from asset services separately. As always >>> though, it's a trade-off, since the proxied design has very poor scalability >>> compared to the distributed one. >>> >>> If we're going to warn users of the potential for inconsistency in the >>> distributed deployment as you suggest, are we also going to warn them of >>> non-scalability in the proxied one? I really don't see much merit in the >>> idea of warning about design choices. Many such choices are technical, and >>> the issues are quite likely to be of little interest to non-technical users >>> anyway. In any case, the better services are likely to provide such >>> information in their online documentation, I would guess. >>> >>> You mentioned users "voting with their feet" or choosing to accept the >>> risk of inconsistency. Well that will happen anyway, when services fail and >>> users get annoyed. If some asset services refuse to send the requested >>> items to some users, those services will get a bad reputation and people >>> will choose different asset services instead. Likewise, if a world service >>> proxies everything and so it can't handle a large number of assets or of >>> people, users will get annoyed at the lag and will go elsewhere. This user >>> evaluation and "voting with their feet" happens already with online services >>> all over the Internet, and I am sure that this human process will continue >>> to work when the services are asset and region services. >>> >>> Back in September 2010, I wrote this post which proposes that we use in >>> VWRAP a form of asset addressing that provides massive scalability at the >>> same time as a very high degree of resilience -- >>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html . It >>> is based on the concept of the URI containing a host part and a hash part, >>> where the hash is generated (once, at the time of storage to the asset >>> service) using a specified digest algorithm over the content of the asset >>> being referenced. You may wish to note that if this design were used, the >>> failure of an asset service to deliver a requested item would result in a >>> failover request for the item to one or more backup services, using the same >>> hash part but with a different host address. >>> >>> This can go some way towards overcoming the problem that you think might >>> occur when assets are fetched by clients from asset services directly. >>> Although it won't help when the missing item is available from only a single >>> asset service, it will help in many other cases, and it will compensate for >>> service failures and network outages automatically at the same time. >>> >>> PS. This design for hash-based asset addressing is already being tested >>> by Mojito Sorbet in her experimental world and client. It would give >>> VWRAP-based worlds an improved level of service availability, so I think it >>> should be a core feature of our protocol. >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> =========================== >>> >>> >>> On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca wrote: >>> >>>> This is a question i discussed with Morgaine off-list a while ago (I >>>> intended to send it to the list but pushed the wrong button...) I >>>> think we need to address this problem, and decide how to deal with it. >>>> >>>> In Davids deployment draft, section 7.3.1.1 an overview is given van >>>> ways to deliver content to the region. One way is only passing a >>>> capability that allows access to (part of) the resource: >>>> >>>> 7.3.1.1. Content delivery models >>>> A range of possible represenations can be passed to a region >>>> for >>>> simulation. [...] The other end of the delivery spectrum >>>> involves passing >>>> only a URI or capability used to access the rendering >>>> information and a >>>> collision mesh,and related data for physical simulation. >>>> In such a model, the client is responsible for fetching the >>>> additional >>>> information needed to render the item's visual presence from a >>>> separate >>>> service. This fetch can be done *under the credentials of the >>>> end user* >>>> viewing the material [my emphasis--VD] , and divorces the >>>> simulation from >>>> the trust chain needed to manage content. Any automation >>>> is done on a >>>> separate host which the content creator or owner trusts, >>>> interacting with the >>>> object through remoted interfaces. >>>> >>>> I can see the need for such a setup, however, i feel we are >>>> unpleasantly close to a situation were the coherence of the simulation >>>> falls apart. >>>> In this deployment pattern the region advertises the presence of the >>>> asset, and *some* clients will be able to get it as expected, while >>>> -based on the arbitrary whims of the asset service- others might not. >>>> >>>> My hope would be that after the asset server provides the region with >>>> the capability to get the asset, it gives up control. That would mean >>>> that if the client finds the inventory server is unwilling to serve >>>> the content - in spire of the region saying it is present-, the client >>>> should be able to turn around ask the *region* for the asset, (and get >>>> is after all). >>>> >>>> If that is not the case, -and there are probably good reasons for the >>>> deployment pattern as described- shouldn't we *warn* clients that the >>>> region might be inconsistent, so the users behind the client can vote >>>> with their feet, (or take the risk)? >>>> >>>> --Vaughn >>>> _______________________________________________ >>>> vwrap mailing list >>>> vwrap@ietf.org >>>> https://www.ietf.org/mailman/listinfo/vwrap >>>> >>> >>> >> > --002354470e60f888f0049ff0eac4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Vaughn, I left your final (and very important) point for the end of my resp= onse, and then I fired off my email without addressing it ...=A0 Sorry. :P<= br>
On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca <= ;vaughn.deluca@gmail.com>= wrote:
=A0So I want= methods=20 to prevent breaking my highly emergent world as much as possible.


Yes indeed!!!

You have a perfectly reasonable = requirement for the service that you want to operate, and you need some mea= ns of meeting it.=A0 I agree with that wholeheartedly.=A0 I only begin to d= isagree when you hint that your requirement must be imposed on everyone, wh= ether they want it or not.=A0 That I cannot support, and I expect that you = did not mean it that way anyway.=A0 After all, some of my requirements are = probably not of interest to you either, and you would not wish me to impose= them on you.=A0 It cuts both ways.

So, how can we enable you to offer a service with many 9's of simul= ation consistency, without imposing that requirement on those who prefer a = different trade-off?=A0 You hinted at the solution yourself, so I'll me= rely elaborate on it.=A0 You wrote:



= I would like to argue that the region *should* get the capability to=20 fetch all details. [...]=A0=20 Note that this does not mean that the region *has* to proxy the asset,=20 just that in case the asset service refuses to serve a client it does=20 not like, the region can insist on delivery =A0based on the capability it= =20 originally got.



Perfect.=A0 All you need then= is an optional query in the protocol that allows a region to ask each asse= t service referenced by assets carried by newly arriving avatars the follow= ing question:

QUERY: "Do I have your permis= sion to fetch from your asset service the assets normally reserved for clie= nt fetches, and to distribute these assets to clients directly in the (unex= pected) event that I want to?"


That easily maps to an optional capability request of course.= =A0 If the asset service answers "No" to you, then you can deny t= he incoming avatar entry to your region, returning a status that indicates<= br>
RESPONSE: "Asset service X re= ferenced by asset Y does not meet the re-distribution requirement requested= for entry to region Z".


Your requirement is then= satisfied (I believe) without imposing that requirement on a region operat= or who does not need it because they desire a different trade-off.=A0 Those= who don't have your requirement simply won't request the capabilit= y.

For example, it would be pointless to even ask an asset service founded= entirely around Creative Commons assets that question, since all CC conten= t is perpetually and non-revocably redistributable by anyone and to anyone.= =A0 By not issuing the query we can save ourselves the round-trip time and = allow faster entry to the region.

Would something like that get the nod from you?


PS. You need= to note that when an asset service answers "Yes" to your query, = this does not mean that it will necessarily honor its promise when you actu= ally attempt to fetch items.=A0 David's very important point about inde= pendent parties not having control over each other applies here.=A0 You can= at most hope that it will behave well, and perhaps test the promise by fet= ching something.=A0 However, if you truly want as many 9's of consisten= cy as is obtainable then you will have to fetch all the assets yourself pri= or to allowing entry to the avatar, and that would be a dreadful overhead.= =A0 Most people will probably settle for "best effort" app= roaches, which are quite likely to succeed.


Morgaine.





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

On Sat, Ap= r 2, 2011 at 11:26 AM, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
Morgaine, Me= adhbh,

Thanks for the answers, but i see that i ha= ve not been clear enough.
I think the protocol should demand certain things to prevent the =A0de= terioration of the simulation to an unacceptable level. We need to be more = precise to prevent problems and i think we can.

I was arguing from the perspecive of a region service w= ithout making that explicit. Note i was *not* advocating the region proxies= everything, just that it lives up to its promises about object presence. A= lso note that i do =A0*not* always have the option to pick another high qua= lity asset service, since I normally do not own the assets. I will use Prok= ofy as an example just for the fun of it. =A0He is highly worried about con= tent theft, so (in the unlikely case he wants to start selling stuff outsid= e of SL) he might use this deployment pattern. =A0Assume he sells wonderful= sexy dresses to two customers, that can only be fetched from his own asset= service for rendering. Both customers go off to "Vaughns highly immer= sive world" were a party is given. =A0My region receives some physics = properties of the dresses for simulation and an address of Proks asset serv= ice for high-res details and textures. In this case the region does not eve= n get the capability to fetch the assets, just a link to the asset service = and its up to viewer to request the details and show credentials to get the= m. The two girls meet, both their viewers request the details of the other = dress, and Proks asset service grants those requests. They girls admire the= ir dresses and compliment each other with their good taste. Now when i arri= ve and my viewer request the dress details, Prok's asset service recogn= ises me as the copyleftists that i am. It refuses to serve the asset detail= s -and depending on my viewers behaviour i might get to view two girls in s= exy underwear -or wearing even less- instead of party dresses. From a consi= stency point of view this is a highly undesirable situation, it breaks imme= rsion, and depending on the circumstances might also be embarrassing to the= people involved.=A0

The key question is if we want to allow this situation = to arise within VWRAP compliant worlds.
I would like to argue tha= t the region *should* get the capability to fetch all details. In other wor= ds, Prokofy would have to give up some control over the asset in case he al= lows it to be used by my region. Note that this does not mean that the regi= on *has* to proxy the asset, just that in case the asset service refuses to= serve a client it does not like, the region can insist on delivery =A0base= d on the capability it originally got. If that fails Proks asset service ca= n not be called VWRAP compliant. =A0

If Prokofy does not want to relinquish =A0that level of= control, fine, it is his right not to, but in that case the dresses should= not be allowed to get into my region in the first place. =A0If people visi= t my region and find themselves naked in the eyes of some others *I* will g= et the blame. =A0As Morgaine says, the technical details of my innocence wi= ll not convince the general public. So I want methods to prevent breaking m= y highly emergent world as much as possible.=A0
My proposal would be that the whatever the region gets MUST be guarant= eed by protocol to be delivered to =A0anybody within the region requesting = it. If the asset service does not want to serve a cryptocomunist copyleftis= t, fine, but IF it has given the region a capability, it MUST serve the ful= l asset to be VWRAP compliant. Its *my* choice as a region deployer to down= load the full asset to be able to guarantee region consistency if I want to= . I will try to avoid that as much as possible, but if my customers complai= n, i will be forces to start doing this for certain asset services that i k= now show discriminatory behaviour against for instance copyleftist.=A0

Finally Morgaine, you keep hammering on the fact that p= roxying by the region does not scale. (I tend to disagree, but that is besi= de the point here). I do agree the asset should not be needlessly transfere= d, but i strongly feel we must insist in the protocol on transferring the *= rights* to view the asset. If that leads to to the region not getting the a= sset at all, so be it, it can warn visitors that their assets will not be v= isible and even offer to serve simple replacements (1). This in turn will e= ncourage the end users to avoid this type of asset service, and Prokofy wil= l go out of business, as should be the case given the behaviour of the serv= ice. And if he pulls it off, thats fine with me also, as long as i do not h= ave to suffer from it due to lack of rigour in the protocol specs. =A0

So, in summary, I very well see that there is no way to= enforce consistent serving behaviour but it should at least be clear that = it is non-standard and not conform the protocol. The way I am understanding= you now, your argument seems to be just one step to far in the direction o= f anarchy.
Or am i misreading you?

--Vaughn

(1) I just realise that the region might cheat = and advertise its own asset brands claiming the competitions assets =A0coul= d not be rendered... Oh well, one might hope that if there is enough choice= in worlds such regions will be forced =A0out of business as well.=A0

On Sat, Apr 2, 2011 at 7:31 AM, Morgaine <morgaine.dinova@googlemail.com> wrote:
Further to my last post, it's worth noting that if you find that you su= ffer poor quality behavior from a particular asset service and it is breaki= ng the consistency of your simulation, with hash-based item addressing you = can also automatically use an alternative asset service in preference= to the one specified in a given URI.

Your client could be configured to attempt the item fetch at a known go= od quality asset service first (perhaps one that you paid to use bec= ause of its better service), automatically, and maybe even dynamically depe= nding on the type of item.

The scheme has a long list of benefits, and overcoming (to some extent)= poor quality asset services is just one of them.


Morgaine.





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


On Sat, Apr 2, 2011 at 4:55 AM, Morgaine <morgaine.dinova@goo= glemail.com> wrote:
Every design choice results in a trade-off, Vaughn, improving one thing at = the expense of something else.=A0 If every time we offered a service we had= to inform its users about the downsides of all the trade-offs we have made= , they would have an awful lot to read. ;-)

The specific trade-off that you are discussing is no different.=A0 A re= gion that proxies all content has the "benefit" of acquiring cont= rol from the asset servers over the items in the region, so that it can ens= ure that everyone in the region not only obtains the items but obtains the = same items as everyone else.=A0 That does indeed provide a greater g= uarantee of consistency than a deployment in which the region only passes a= sset URIs to clients who then fetch the items from asset services separatel= y.=A0 As always though, it's a trade-off, since the proxied design has = very poor scalability compared to the distributed one.

If we're going to warn users of the potential for inconsistency in = the distributed deployment as you suggest, are we also going to warn them o= f non-scalability in the proxied one?=A0 I really don't see much merit = in the idea of warning about design choices.=A0 Many such choices are techn= ical, and the issues are quite likely to be of little interest to non-techn= ical users anyway.=A0 In any case, the better services are likely to provid= e such information in their online documentation, I would guess.

You mentioned users "voting with their feet" or choosing to a= ccept the risk of inconsistency.=A0 Well that will happen anyway, when serv= ices fail and users get annoyed.=A0 If some asset services refuse to send t= he requested items to some users, those services will get a bad reputation = and people will choose different asset services instead.=A0 Likewise, if a = world service proxies everything and so it can't handle a large number = of assets or of people, users will get annoyed at the lag and will go elsew= here.=A0 This user evaluation and "voting with their feet" happen= s already with online services all over the Internet, and I am sure that th= is human process will continue to work when the services are asset and regi= on services.

Back in September 2010, I wrote this post which proposes that we use in= VWRAP a form of asset addressing that provides massive scalability at the = same time as a very high degree of resilience -- http:/= /www.ietf.org/mail-archive/web/vwrap/current/msg00463.html .=A0 It is b= ased on the concept of the URI containing a host part and a hash part, wher= e the hash is generated (once, at the time of storage to the asset service)= using a specified digest algorithm over the content of the asset being ref= erenced.=A0 You may wish to note that if this design were used, the failure= of an asset service to deliver a requested item would result in a failover= request for the item to one or more backup services, using the same hash p= art but with a different host address.

This can go some way towards overcoming the problem that you think migh= t occur when assets are fetched by clients from asset services directly.=A0= Although it won't help when the missing item is available from only a = single asset service, it will help in many other cases, and it will compens= ate for service failures and network outages automatically at the same time= .

PS. This design for hash-based asset addressing is already being tested= by Mojito Sorbet in her experimental world and client.=A0 It would give VW= RAP-based worlds an improved level of service availability, so I think it s= hould be a core feature of our protocol.


Morgaine.




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

On Fri, Apr 1, 2011 at 11:17 PM, Vaughn De= luca <vaughn.deluca@gmail.com> wrote:
This is a questio= n i discussed with Morgaine off-list a while ago (I
intended to send it to the list but pushed the wrong button...) I
think we need to address this problem, and decide how to deal with it.

=A0In Davids deployment draft, section 7.3.1.1 an overview is given van
ways to deliver content to the region. One way is only passing a
capability that allows access to (part of) the resource:

=A0 =A0 =A0 =A0 =A0 7.3.1.1. =A0Content delivery models
=A0 =A0 =A0 =A0 =A0 A range of possible represenations can be passed to a = region for
=A0 =A0 =A0 =A0 =A0 simulation. [...] The other end of the delivery spectr= um involves passing
=A0 =A0 =A0 =A0 =A0 only a URI or capability used to access the rendering<= br> information and a
=A0 =A0 =A0 =A0 =A0 collision mesh,and related data for physical simulatio= n.
=A0 =A0 =A0 =A0 =A0 In such a model, the client is responsible for fetchin= g the additional
=A0 =A0 =A0 =A0 =A0 information needed to render the item's visual pre= sence from a separate
=A0 =A0 =A0 =A0 =A0 service. =A0This fetch can be done *under the credenti= als of the end user*
=A0 =A0 =A0 =A0 =A0 viewing the material [my emphasis--VD] , and divorces = the
simulation from
=A0 =A0 =A0 =A0 =A0 the trust chain needed to manage content. =A0Any autom= ation
is done on a
=A0 =A0 =A0 =A0 =A0 separate host which the content creator or owner trust= s,
interacting with the
=A0 =A0 =A0 =A0 =A0 object through remoted interfaces.

=A0I can see the need for such a setup, however, i feel we are
unpleasantly close to a situation were the coherence of the simulation
falls apart.
In this deployment pattern the region advertises the presence of the
asset, and *some* clients will be able to get it as expected, while
-based on the arbitrary whims of the asset service- others might not.

My hope would be that after the asset server provides the region with
the capability to get the asset, it gives up control. That would mean
that if the client finds the inventory server is unwilling to serve
the content - in spire of the region saying it is present-, the client
should be able to turn around ask the *region* for the asset, (and get
is after all).

=A0If that is not the case, -and there are probably good reasons for the deployment pattern as described- =A0shouldn't we *warn* clients that th= e
region might be inconsistent, so the users behind the client can vote
with their feet, (or take the risk)?

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




--002354470e60f888f0049ff0eac4-- From carlo@alinoe.com Sat Apr 2 08:17:47 2011 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 7353B3A6837 for ; Sat, 2 Apr 2011 08:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 RHKzzCyEpLiP for ; Sat, 2 Apr 2011 08:17:46 -0700 (PDT) Received: from fep14.mx.upcmail.net (fep14.mx.upcmail.net [62.179.121.34]) by core3.amsl.com (Postfix) with ESMTP id 2DDA13A681D for ; Sat, 2 Apr 2011 08:17:45 -0700 (PDT) Received: from edge05.upcmail.net ([192.168.13.212]) by viefep14-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110402151925.SARH1458.viefep14-int.chello.at@edge05.upcmail.net> for ; Sat, 2 Apr 2011 17:19:25 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upcmail.net with edge id SfKQ1g00N0FlQed05fKRWn; Sat, 02 Apr 2011 17:19:25 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q62bj-00032O-W7 for vwrap@ietf.org; Sat, 02 Apr 2011 17:19:24 +0200 Date: Sat, 2 Apr 2011 17:19:23 +0200 From: Carlo Wood To: vwrap@ietf.org Message-ID: <20110402171923.13176462@hikaru.localdomain> In-Reply-To: <20110402.101259.14412.0@webmail09.vgs.untd.com> References: <20110402.101259.14412.0@webmail09.vgs.untd.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=CqMFsqQC4gx7bBgpmnW/wKYuJF/a5pXPeCAfngFtYkU= c=1 sm=0 a=CxkBH-eyvKEA:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=NoAKp6exAAAA:8 a=BjFOTwK7AAAA:8 a=t1TwdTNkX5-CMBQloOMA:9 a=bTkC8fk6nwbvebxC_3MA:7 a=CjuIK1q_8ugA:10 a=B0cvAcWxpcAA:10 a=bW3kdApBr58A:10 a=CVyfxXMwha7X1bQE:21 a=ICZwLq1sKXtftP7D:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 15:17:47 -0000 On Sat, 2 Apr 2011 14:12:59 GMT "dyerbrookme@juno.com" wrote: > BTW, the Red Zone statistics of 9 million scans with only 78,000 > rogue viewers captured lets us know that this problem is exaggerated > -- and usually by engineers who claim there is no technical solution. Just for the record, from a hacker/engineer: there is no technical solution. It is possible to copy everything (and without being detected by a "Red Zone" which can only detect rogue viewers that were released to the public and explicitly make a point of being detectable in the first place (call that bragging: no fun in releasing a "k3wl" viewer if others (or even the coder himself) can't see that it is being used.) So, there is a psychological advantage for the detectors, but not really a technical one. Lets concentrate on textures for the moment to explain this. In order to see an object, or clothing, with the appropriate textures, those textures have to be downloadable for the viewer. There is nothing you can do about that short of running the whole viewer server-side and providing a video. But even in that case it would technically be possible to rip the textures: they are still visible (ie, you could make a screenshot of the surface of a wall). I don't consider the video-broadcast to even be remotely interesting, certainly not from the viewpoint of VWRAP so lets forget that for the moment and just accept that it is possible for anyone to store whatever they SEE to their harddisk. Secondly, if the first creator could upload this texture then so can the ripper. And don't tell me software exists that can detect if an uploaded texture "looks like" one of the already existing billion textures that were uploaded before. If the texture is converted twice, ie from jpeg2000 to jpg to tga and then uploaded, then you'd need a human to look at the original and the newly uploaded texture at the same time to judge that it is MAYBE a copy - which then can only be proved in court if the original creator can prove that his original textures are 100% his own and not, for example, downloaded from the internet somewhere (because in that case the other uploader could have used the same source). A real problem, currently in SL, is imho the complete lack of support for FREE things. The amount of restriction (for people with honest viewers) is tremendous: if you're not an expert or do not pay attention for a second, then your creation is not truely free anymore. Everything defaults to very copyleft unfriendly settings. I'm trying to get my friends, who are very willing in that regard, to only create full permission stuff, but it's simply near impossible to keep something full permission and often we're stuck with something nobody else can change or edit because the creator forgot to set the bit of the contents of an object after changing the group etc blah blah... For example, last a good friend of me wanted my help with making a large amount of changes on his sim: hunderds of objects had to be adjusted... He was willing to: 1) Add me to any group necessary. 2) Give me his build rights 3) Transfer any object to me (temporary ownership transfer) 4) Make any adjustments to the objects and the objects contents needed to allow me to access what I needed to access. etc etc The end result: He had to do it all by himself. It was impossible to give me enough access to help him (for those who don't believe that, one of things involved changing the "anyone can move" bit of an object in the contents of objects: it is not possible to take anything out of the contents (ie copy it to your inventory) when it's no transfer, and therefore you can't edit it, even though it's modify and you get all the rights that the owner can give you). Sorry, but that is unacceptable; and it CLEARLY shows that something is missing from the protocol. Now the above example doesn't show that a free object is not supported, it only make clear that non-free objects can be very annoying even in situations where the owner has all the rights to do what he wants to do. There are many other such examples. Hence, it shows that it is very annoying that an object is non-free by default at so many levels that you need an IQ of over 140 to create one and those permissions erode quickly to non-free. Even the so called "freebies" are non-free by the way: they are almost always no transfer. Hell, even the default shape that you can when you create a new account is no transfer, what kind of insanity is that?! I think you might find a lot of people, like myself, a lot more willing to help out with thinking of ways on how to protect property in virtual worlds when first it is assured that those who want to create things that are FREE are equally supported as the commercial guys out there. -- Carlo Wood From dzonatas@gmail.com Sat Apr 2 08:33:46 2011 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 D73593A683F for ; Sat, 2 Apr 2011 08:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 abVrjeyHvgEu for ; Sat, 2 Apr 2011 08:33:45 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C1EDB3A683B for ; Sat, 2 Apr 2011 08:33:45 -0700 (PDT) Received: by iwn39 with SMTP id 39so5091149iwn.31 for ; Sat, 02 Apr 2011 08:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sx82Y7rZb8QLNvy+cEUvmkIdtWOFb/HKDHzMJh3vPNg=; b=UjM1MQ2paAfm5Uq8nETYWSABVEFGgMDW5xvptknED7kTc+1z2PFJu4FG58KCvjC+O8 zIvQsjFDmhAUcNer3xgBAN23klSuxJfgTR+A98Y0HZv/kqfldYVkdBlkslUSLQGqNwRu tYHk/+4g4lQ7gCKWgR2xacdgG0dysLMjPQCXY= 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=WbcT/auRuyJpN32uWWeeKeEBiIdRtzZZLWmoSuhVtyBx+Tc5Ef/fvAQzhqfZHtRR5N KyfP6L8fR4XOqRNibTkLtLxD/4mEqmiQFYKToMBlcy0JnuBSBQOgIiDaBm8SCSADkWCe P6ERGb1+SxJb/AEHYaymUiLBa/QGixvaIBm5Y= Received: by 10.43.55.137 with SMTP id vy9mr7319458icb.174.1301758526616; Sat, 02 Apr 2011 08:35:26 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id hc41sm2274158ibb.47.2011.04.02.08.35.25 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Apr 2011 08:35:25 -0700 (PDT) Message-ID: <4D97426B.8010302@gmail.com> Date: Sat, 02 Apr 2011 08:36:11 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 15:33:47 -0000 Your hash/digest method is similar to basic REST and what I already implemented. Icesphere already has implementations and methods and even furthers them with burst modes so where there is no worry to have a URI for each asset. The URI can specify a list of assets or single asset (content varies as such), which can be returned immediately or when each is ready for transfer, individually. Uses LLIDL with proposed changes: Everything is documented here: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Inventory (Last edited that doc in August 2010 & Icesphere's implementation has been used for awhile since then) Morgaine wrote: > Back in September 2010, I wrote this post which proposes that we use > in VWRAP a form of asset addressing that provides massive scalability > at the same time as a very high degree of resilience -- > http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html .� It > is based on the concept of the URI containing a host part and a hash > part, where the hash is generated (once, at the time of storage to the > asset service) using a specified digest algorithm over the content of > the asset being referenced.� You may wish to note that if this design > were used, the failure of an asset service to deliver a requested item > would result in a failover request for the item to one or more backup > services, using the same hash part but with a different host address. > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Sat Apr 2 09:01:09 2011 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 DD5C028C122 for ; Sat, 2 Apr 2011 09:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 bHcUYs2YgLV8 for ; Sat, 2 Apr 2011 09:01:08 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 217C928C0E7 for ; Sat, 2 Apr 2011 09:01:08 -0700 (PDT) Received: by iwn39 with SMTP id 39so5108869iwn.31 for ; Sat, 02 Apr 2011 09:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AZdWfbxVXkCv8zwLl4lyS2rlVmVFXQmEv4p9CNYgLds=; b=qtowBHeIToe6oOjFGrV2gWOfrdYiLKTUEx+3M7vqGIGqmliTyXVRalJU8l5sp3cgMU ztEW3V7xvG1OtzIFeDwRfcpziugtlUh7TMkcign9PLoaaFqIV+h1+QEJdBL3jsQmK1PD Z6BnE8npZPa/vIDHNQ8yugDoGqvk9pzxy+VWs= 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=PUJIQ2pq7qG68T3itU4KngHpmTKvSUr8dWcpa4NY9ZRRzt9EESRh+ZMsppojKy8LOR 1wmAkXpowYrAWbOX/DmyJzQ1GWSFMLgy9WWAo1TaAK5GWvZLEgi1MtFGZEyAk9pdvAXJ /gcuBRXcTa0V3Ijv1ZXEZ5z/TKF7+Q2jXk/WI= Received: by 10.42.239.6 with SMTP id ku6mr6633895icb.189.1301760164683; Sat, 02 Apr 2011 09:02:44 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id gy41sm2290069ibb.22.2011.04.02.09.02.42 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Apr 2011 09:02:43 -0700 (PDT) Message-ID: <4D9748D0.3000808@gmail.com> Date: Sat, 02 Apr 2011 09:03:28 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Dzonatas Sol References: <4D93E82C.7060503@gmail.com> <4D949BFB.1010804@gmail.com> <4D94B1EF.2030206@gmail.com> <4D95EB3F.8090807@gmail.com> <4D960950.8090205@gmail.com> <4D966CD9.3040204@gmail.com> In-Reply-To: <4D966CD9.3040204@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] "Trust Domains", conditioners and refineries 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: Sat, 02 Apr 2011 16:01:10 -0000 I almost forgot I did provide a way for "trust" to be actual trust and not some exploitable digital copy or exploitable encryption. The ability takes advantage of ray-casters/ray-tracers to view analog based virtual worlds, yet I purposely haven't gone in much detail other than to note flow and support here: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Interface At this time, LL has made no comment or proposed fix for few very exploitable client/server implementations other than "trust" in firewalls. I'll avoid details and assume a few others on the list are aware. That's where I last left off... so not much has change (in icesphere and here) since then. (Oh yeah, I posted exemplified advanced 12D simulation with quantum computers at tiny and macro scale, which went over people's heads... "spoke too soon"). Dzonatas Sol wrote: > That still is some debate over mechanisms that only serve as an > example or use-case, not further topology of such network, capability, > and content path. > > We could argue such straw men, yet I'm not in the mood. Anyways... can > we stay on track of terminology and asset services. Thanks. > > Morgaine wrote: >> On Fri, Apr 1, 2011 at 6:20 PM, Dzonatas Sol > > wrote: >> >> I guess your reply is purely April 1st themed, as there are surely >> protocols in use now on the Internet, yet you make it sound like >> nobody trusts the Internet... >> >> >> A lot of people trust the Internet at face value. Our innocent, >> well-intentioned but technically uninformed families are among them. >> That is why organized crime has such an easy ride online. >> >> In this group we are better informed than that though, and >> (hopefully) we understand that trust of an unknown remote 3rd party >> means absolutely nothing because "trust" and "unknown remote" is a >> contradiction in terms, even if they possess a cryptographically >> signed certificate. >> >> An X.509 credential means nothing except that the endpoint is >> recognizable for the session. It says nothing about participant >> trust, it says nothing about information security, it does not >> protect against contrary intentions, and most importantly, it >> provides no technical mechanism for achieving the goal of "domain >> protection" that some people here think it supports. Thinking that >> X.509 offers anything beyond network endpoint identification is a >> misunderstanding of the technology and of security. It is not a >> wall. It is just a lock on the wall, and everything beyond the lock >> is unsecured. >> >> And it gets even worse than that. I have had the misfortune of being >> assigned the duty of interfacing with a leading certificate provider >> over several years, and can attest that certificates are granted >> without any kind of strong care and assurance. The process is >> effectively non-scalable, because as the population of certificate >> holders increases, the controls become ever less strong, and the >> meaning of holding a certificate reduces to virtually nothing. It >> certainly affords no trust. >> >> Having faith in empty delusions is rather common in humanity, but we >> don't need to enshrine them in an IETF protocol. We already have >> enough concrete work with goals that are verifiable on our plate. >> Adding unverifiable delusions to the protocol does not gain us >> anything beyond a warm feeling stemming from incompetence about >> security. >> >> >> Morgaine. >> >> >> >> >> >> ========================= >> >> >> On Fri, Apr 1, 2011 at 6:20 PM, Dzonatas Sol > > wrote: >> >> I guess your reply is purely April 1st themed, as there are surely >> protocols in use now on the Internet, yet you make it sound like >> nobody trusts the Internet... again >> >> Morgaine wrote: >> >> I hope you realize that "trust domains" don't actually exist >> outside of some people's passion for buzzwords. >> >> Having worked in defense security and looked beyond buzzwords >> into what really happens with information protection and >> leakage, the concept of technically-secured trust in an open >> client-server system lies somewhere between delusion and >> comedy.� No, just no. >> >> Information is secure only when it is not released and not >> accessible.� In our VW architecture, all visible content is >> sent to all participants in the simulation by architectural >> design, and its non-distribution beyond that set of >> participants is not assurable.� Indeed, it is objectively >> impossible to assure, because there is no control over public >> outbound information channels in our architecture, and even >> less control over covert channels. >> >> That makes all talk about "trust domains" here an exercise in >> futility, some kind of reliance on "faith" and wishful thinking. >> >> The merits of comedy aside, I suggest that we stick to >> concepts that we can underpin with concrete technology and >> implement in protocols.� Trust is not one of them and just >> wastes time, despite the cuteness of the term "trust domain". >> >> If you want to keep information secure, don't send it to >> somewhere that is insecure such as a remote client.� That's >> the technical solution, stripped of wishful thinking. >> >> Whatever one may think of the defense industry, at least they >> analyze issues to avoid self-delusion.� We may not have a >> defense budget here, but that's not a reason for promoting >> concepts that simply don't work. >> >> >> Morgaine. >> >> >> >> >> ====================== >> >> On Fri, Apr 1, 2011 at 4:11 PM, Dzonatas Sol >> >> >> wrote: >> >> Of replies received and to forward this further, the ideal >> "trust >> domains" are established in file by X.509 (and more recent >> claims) >> or by login credentials/authentication. This flexibility of >> these >> two alone to establish such domain already defeats the >> purpose to >> use client/server terminology except at the transfer-level. >> Consider that LLIDL & REST is above the transfer-level (from >> source-level perspective), there is not much need to use >> client/server terminology (except if you want pedantic >> buzzwords). >> >> Please let me know if there is some other case. >> >> >> Dzonatas Sol wrote: >> >> Added "trust domains" to the subject line to hopefully >> narrow >> this thread before it goes into some random debate. >> >> >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, >> Consultant >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> > >> >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From ohmeadhbh@gmail.com Sat Apr 2 09:51:15 2011 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 0E8AC3A6859 for ; Sat, 2 Apr 2011 09:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCxTrLdxQDib for ; Sat, 2 Apr 2011 09:51:13 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 6B3723A6857 for ; Sat, 2 Apr 2011 09:51:13 -0700 (PDT) Received: by iye19 with SMTP id 19so5325401iye.31 for ; Sat, 02 Apr 2011 09:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=KhT2OUP9uW8qnzYxDafoOnAXmDLILSF54Iq5OAPAtas=; b=j/2eUnMtvhWMU27WYVd9+Qnjy0lyZTKmDIrabi5kqphPd3Qqyv44E81FnEwbek2q3/ KMjN+lmitp5/elG+DyB/p1QxSOTj3eAef4Rpp4vXZUu/yre4xC/W6jU/VlBlzZX3NkTt 6KxdjOcObIjGNE6n9qUWG7CmY0FNUjyBRO7FA= 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=iSE4pEAdgpNrISmoOafyQ+KTGrnQlsfhRES+QHvz1Gi7AyVujc/h/lp4BOKh4xP0Ra PfG/C18KKIaACzQXHR1zUFaSZBpx7anfjxeBCQcGJZsyM8JUt+EYdg4fb+easIBcM7KU M9fzK2qVZIROQ4TsYetvVfj+iFnk+0uvqbTNw= Received: by 10.42.158.200 with SMTP id i8mr5341960icx.339.1301763174305; Sat, 02 Apr 2011 09:52:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.225.199 with HTTP; Sat, 2 Apr 2011 09:52:34 -0700 (PDT) In-Reply-To: References: <20110402.101259.14412.0@webmail09.vgs.untd.com> From: Meadhbh Hamrick Date: Sat, 2 Apr 2011 09:52:34 -0700 Message-ID: To: Patnad Babii Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 16:51:15 -0000 the likelihood that linden will use any output from this group at this point is about nil. if they were, they would likely actually pay someone to participate. but... i don't speak for linden anymore, so take that last statement with a grain of salt. -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Sat, Apr 2, 2011 at 8:03 AM, Patnad Babii wrote: > Let me put it simple, Linden Lab is not forced to use this protocol at AL= L > and I'm pretty sure as they are a pretty big company with brains, they ar= e > not going to allow something that=92s going to reduce security or allow m= ore > thief to their grid anytime soon. > > This protocol is intended mostly for other Open virtual worlds.=A0 If at = a > point Linden Labs find it an interest in the protocol they might implemen= t > it. Linden Labs is not working anymore on grid interop for some time now,= so > please stop being afraid by the big bad wolf, cause it is not here you ar= e > going to find it. > > > From: dyerbrookme@juno.com > Sent: Saturday, April 02, 2011 10:12 AM > To: vaughn.deluca@gmail.com > Cc: vwrap@ietf.org > Subject: Re: [vwrap] [wvrap] Simulation consistency > > Vaughn, > > A key reason the Metaverse construction cannot be left to coders and othe= r > technologists like yourself alone is this kind of coervice hypothesis, > crowbarring a metaphor in service of a pre-existing agenda. > > First of all, I don't make content of any significant amount as an amateu= r, > such as to be concerned only about "my dresses" and "little dressmaker > genocide" as copyleftist cynics call it. But I express this concern on > behalf of my rentals customers who do make content and who are worried -- > and rightly so -- about theft, and most of all, I express this as a *matt= er > of principle*. > > Second, the notion that girls travelling to a party at "Vaugh's Immersive > Fabulousness" from "Prokofy's Palm Cafe At the End of the Mind" need not > fear nakedness of Vaughn simply bestirs himself, *in good faith* (always = in > short supply with metaversal engineers), to automatically supply a generi= c > dress or Ruth appearance and outfit in the event that the server can't fe= tch > the assets for any reason. So that's specious entirely. > > Third, if you think customers and their wants and inciting their hatred o= f > platform providers who can't render their dresses in all their pretty glo= ry > are the way to hijack the metaverse for the copyleftist/open source cult > agenda, think again. Dress shoppers can become fiercely loyal patrons of = the > copyright of their favourite designers. Fiercely.And they will mount the > consumer boycott and press campaign to match their ferocity. > > Fourth, If you have a world in which copying the dresses off avatars is a > function of the browser you let connect to your world, like the copybotti= ng > Thugs Lyfe, merely with a mouseclick or two, then you deserve to be > ostracized. And in fact, you and all providers can have a policy about no= t > letting such TPV viewers connect, as LL does -- and without any pretense > that it can control every manifestation. BTW, the Red Zone statistics of = 9 > million scans with only 78,000 rogue viewers captured lets us know that t= his > problem is exaggerated -- and usually by engineers who claim there is no > technical solution. > > Fifth, and most relevant, the metaverse does not have to be built entirel= y > on automatic machines that only perform rote routines, which are, indeed, > only the mechanistic concretization of human will and "nothing special". > > It can be also constructed of polices and agreements rooted in organic mi= nds > and organic institutions. And that's ok. And that would mean a basic > charter, that could be as historical and epic as the Magna Charter or as > mundane as the Bottle Bill of Rights hanging on the wall of your > supermarket. And that charter would spell out that platforms that do not > respect copyright *by including the engineered DRM on creations* and *by > including a TPV policy* do not get the handshake, do not get the hookup. = And > that's it. It's not so hard, truly. > > These treaties can be forged at real-life in-person conventions, just lik= e > other technical agreements are, including IEEE standards, and they can be > forged ultimately in a "scaling" fashion by having templates that a serve= r > seeking to make a connection with have or not have, not withstanding > Morgaine's wild and hysterical notions that "nothing" can be trusted on t= he > Internet and trust regimes are all a scam. > > It's not about Prokofy relinquishing control for the sake of his customer= s' > eye candy. It's about two platforms shaking hands on an established > pre-existing agreement that becomes the metaversal standard -- and a > standard created not by a cabal of a few engineers in an obscure IEEF > working group, but open conventions. > > And please don't pretend this can't scale. There's about 17 and a half > virtual worlds out there at most that really have any viability and peopl= e > on them with stuff that works for the user. So they can make a confederat= ion > of standards that does respect the *technical implementation* of copyrigh= t > and intellectual property rights *simply because they can*. It's a matter= of > political will, and its absence now is one of blatant collectivist ideolo= gy > at work. > > If you yourself opt to break your fabulous immersive world by not putting > default dresses on people in decency, and more to the point, not abiding = by > a simple protocol to include DRM as a default with the "export to other > grids" box and c/m/t boxes checked, and "TPV policy compliant" then you'r= e > the problem, not Prokofy's fear of crypto communists hiding under the > servers. > > You seem to be like all followers of the California Business Model (let a= ll > uploads first, sell ads, then DMCA takedowns later) -- and you seem to be > willing to wait for your customers complain. > > That's not necessary if you're an ethical provider -- you can make the > agreements first. Forcing the issue by deploying the age-old "analog hole= " > argument and whining that you "must" serve up the view of an asset your > customers "expect" to see or already "can" see doesn't let you off the ho= ok. > There is no reason to be literalist about it. You can weld c/m/t into > operability from the get-go. You can refuse to allow viewers that copybot= . > Your resistance to this is purely ideological. > > And BTW, if you persist in calling people who rightfully and legitimately > raise copyright concerns and rightly and legitimately point out the > copyleftist ideological bias as "paranoid" and "conspiracy theorists" and > "fearful of cryptocommunists" and "McCarthyites" than you're going to go = on > being called the Leninists that you in fact are. > > Prokofy > > > > ____________________________________________________________ > Groupon=99 Official Site > 1 ridiculously huge coupon a day. Get 50-90% off your city's best! > Groupon.com > > ________________________________ > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > From ohmeadhbh@gmail.com Sat Apr 2 10:00:26 2011 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 F034A3A6866 for ; Sat, 2 Apr 2011 10:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 1oVvA6Dtm4dB for ; Sat, 2 Apr 2011 10:00:24 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 169013A6864 for ; Sat, 2 Apr 2011 10:00:22 -0700 (PDT) Received: by iye19 with SMTP id 19so5331234iye.31 for ; Sat, 02 Apr 2011 10:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=w96bUo9FBnSJygNoJckd+Gxo3Qc405zWTy1GIk07PJI=; b=AaIT3hNlI9WDKqqMFNhhHR5Dd5kDRN+A0f1Cy7BxK4IA+EyoJD2LeVNBrnUu7ensmO /WHL4+u1fgRq17qrYWzRN+TtWg3idK98LWGU2mQGIpnMVMVqTdmKtYQ+hiTUFdBw5tnV ybKpBBOnbPDV5AF1VEBusb9ex09qeq4ohiw2w= 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=SsM0UdkaDZlQ5Aotfyt90piMFFRWp9oEgXG+QA7U7f/i1YnE4Fav4Y+b/l1qBz0OGw IWPNnPlsEIfJMSRK6LnPPvwueJYatggvlnNpZE5xG7mxfSVxHPDY+FnyVTpCgja4B2tn 5C4Alw+ESF7KhK/yUT1tY6h/d1XwuzzJpSHlI= Received: by 10.43.57.78 with SMTP id wf14mr1800213icb.138.1301763723153; Sat, 02 Apr 2011 10:02:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.225.199 with HTTP; Sat, 2 Apr 2011 10:01:43 -0700 (PDT) In-Reply-To: <20110402171923.13176462@hikaru.localdomain> References: <20110402.101259.14412.0@webmail09.vgs.untd.com> <20110402171923.13176462@hikaru.localdomain> From: Meadhbh Hamrick Date: Sat, 2 Apr 2011 10:01:43 -0700 Message-ID: To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 17:00:26 -0000 yes. there is something missing in the protocol. it's trust. you don't put "trust" in a protocol, you put "security" in a protocol. at the end of the day, the people using this protocol will need to decide whom they trust. this is why there was a security model and the ability of the protocol to "securely carry trust." the idea is that the protocol would carry cryptographically unforgeable attestations of an endpoint's identity. this identity would then be evaluated by protocol participants to see if it is "trusted." there's no place in the protocol that says "you must trust a specific entity," but rather a mechanism deployers can use to carry the identity of people wishing to be trusted. at the end of the day, an asset service should only barf up assets to trusted simulation services. simulators SHOULD only allow people on the grid they trust (for some definition of the word "trust.") if you're a company like Linden that needs to respond to DMCA takedown requests, you're likely to require the client trust knob turned up a bit. if you're an enterprise, you're going to want that trust knob turned all the way up. if you're the pirate bay, you're going to intentionally want that trust knob turned all the way down. as protocol developers, it's our duty to create a protocol that meets everyone's use cases. so... i mean... feel free to try to define a protocol that mandates the use of DRM or blesses a particular trust point, but the likelihood of it being widely supported is.. approximately nil. my recommendation has always been... "define mechanism, not policy." -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Sat, Apr 2, 2011 at 8:19 AM, Carlo Wood wrote: > On Sat, 2 Apr 2011 14:12:59 GMT > "dyerbrookme@juno.com" wrote: > >> BTW, the Red Zone statistics of 9 million =A0scans with only 78,000 >> rogue viewers captured lets us know that this =A0problem is exaggerated >> -- and usually by engineers who claim there is no =A0technical solution. > > Just for the record, from a hacker/engineer: there is no technical > solution. It is possible to copy everything (and without being detected > by a "Red Zone" which can only detect rogue viewers that were released > to the public and explicitly make a point of being detectable > in the first place (call that bragging: no fun in releasing a "k3wl" > viewer if others (or even the coder himself) can't see that it is being > used.) So, there is a psychological advantage for the detectors, but > not really a technical one. > > Lets concentrate on textures for the moment to explain this. > > In order to see an object, or clothing, with the appropriate textures, > those textures have to be downloadable for the viewer. There is nothing > you can do about that short of running the whole viewer server-side > and providing a video. But even in that case it would technically be > possible to rip the textures: they are still visible (ie, you could > make a screenshot of the surface of a wall). I don't consider the > video-broadcast to even be remotely interesting, certainly not from the > viewpoint of VWRAP so lets forget that for the moment and just accept > that it is possible for anyone to store whatever they SEE to their harddi= sk. > > Secondly, if the first creator could upload this texture then so can > the ripper. And don't tell me software exists that can detect if > an uploaded texture "looks like" one of the already existing billion > textures that were uploaded before. If the texture is converted twice, > ie from jpeg2000 to jpg to tga and then uploaded, then you'd need a > human to look at the original and the newly uploaded texture at the > same time to judge that it is MAYBE a copy - which then can only be > proved in court if the original creator can prove that his original > textures are 100% his own and not, for example, downloaded from the > internet somewhere (because in that case the other uploader could > have used the same source). > > A real problem, currently in SL, is imho the complete lack of > support for FREE things. The amount of restriction (for people with > honest viewers) is tremendous: if you're not an expert or do not pay > attention for a second, then your creation is not truely free anymore. > Everything defaults to very copyleft unfriendly settings. I'm trying to > get my friends, who are very willing in that regard, to only create > full permission stuff, but it's simply near impossible to keep > something full permission and often we're stuck with something nobody > else can change or edit because the creator forgot to set the bit of > the contents of an object after changing the group etc blah blah... > > For example, last a good friend of me wanted my help with making a > large amount of changes on his sim: hunderds of objects had to be > adjusted... He was willing to: > 1) Add me to any group necessary. > 2) Give me his build rights > 3) Transfer any object to me (temporary ownership transfer) > 4) Make any adjustments to the objects and the objects contents > =A0 needed to allow me to access what I needed to access. > etc etc > > The end result: He had to do it all by himself. It was impossible to > give me enough access to help him (for those who don't believe that, > one of things involved changing the "anyone can move" bit of an > object in the contents of objects: it is not possible to take anything > out of the contents (ie copy it to your inventory) when it's no > transfer, and therefore you can't edit it, even though it's modify > and you get all the rights that the owner can give you). > > Sorry, but that is unacceptable; and it CLEARLY shows that something is > missing from the protocol. > > Now the above example doesn't show that a free object is not supported, > it only make clear that non-free objects can be very annoying even in > situations where the owner has all the rights to do what he wants to > do. There are many other such examples. Hence, it shows that it is very > annoying that an object is non-free by default at so many levels that > you need an IQ of over 140 to create one and those permissions erode > quickly to non-free. Even the so called "freebies" are non-free by the > way: they are almost always no transfer. Hell, even the default shape > that you can when you create a new account is no transfer, what kind of > insanity is that?! > > I think you might find a lot of people, like myself, a lot more willing > to help out with thinking of ways on how to protect property in virtual > worlds when first it is assured that those who want to create things > that are FREE are equally supported as the commercial guys out there. > > -- > Carlo Wood > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From carlo@alinoe.com Sat Apr 2 10:07:17 2011 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 5DA5B3A686E for ; Sat, 2 Apr 2011 10:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 rEKFkiGADtQ2 for ; Sat, 2 Apr 2011 10:07:16 -0700 (PDT) Received: from fep18.mx.upcmail.net (fep18.mx.upcmail.net [62.179.121.38]) by core3.amsl.com (Postfix) with ESMTP id 3BB613A686C for ; Sat, 2 Apr 2011 10:07:16 -0700 (PDT) Received: from edge05.upcmail.net ([192.168.13.212]) by viefep18-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110402170856.VPCZ1353.viefep18-int.chello.at@edge05.upcmail.net> for ; Sat, 2 Apr 2011 19:08:56 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upcmail.net with edge id Sh8u1g00w0FlQed05h8vrz; Sat, 02 Apr 2011 19:08:56 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q64Jh-0004CO-Vt for vwrap@ietf.org; Sat, 02 Apr 2011 19:08:54 +0200 Date: Sat, 2 Apr 2011 19:08:53 +0200 From: Carlo Wood To: vwrap@ietf.org Message-ID: <20110402190853.7c525764@hikaru.localdomain> In-Reply-To: References: X-Mailer: Claws Mail 3.7.8 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=tMVj8KYobzzX0EiRnC7vY2isLrCxFvdg4RrHWPZXwJ0= c=1 sm=0 a=CxkBH-eyvKEA:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=mK_AVkanAAAA:8 a=BjFOTwK7AAAA:8 a=mqISKdNJmrkE4mHaEg4A:9 a=8_7yNeBXZWXb_h9ul9MA:7 a=CjuIK1q_8ugA:10 a=9xyTavCNlvEA:10 a=bW3kdApBr58A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 17:07:17 -0000 On Sat, 2 Apr 2011 16:09:49 +0100 Morgaine wrote: > That easily maps to an optional capability request of course. If the > asset service answers "No" to you, then you can deny the incoming > avatar entry to your region, returning a status that indicates > > RESPONSE: "*Asset service X referenced by asset Y does not meet the > re-distribution requirement requested for entry to region Z*". At which point, as a user, I'd like to have the option to detach / take off (replace) whatever I'm using from asset service X, rather than to completely be banned from entering the region. If the result is that I look aweful, then the only requirement I have is that I see the same thing as others, after I can I make the decision to either avoid using asset server Y for future purchases, or to avoid entering this region. -- Carlo Wood From dyerbrookme@juno.com Sat Apr 2 10:14:43 2011 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 1E8DC3A6864 for ; Sat, 2 Apr 2011 10:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, UNPARSEABLE_RELAY=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 EXVbFJhVpXpp for ; Sat, 2 Apr 2011 10:14:40 -0700 (PDT) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 7465C3A685B for ; Sat, 2 Apr 2011 10:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juno.com; s=alpha; t=1301764578; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; l=0; h=From:Date:To:Cc:Subject:Message-Id:Content-Type; b=jjEIFbqaiOxgqBEi9qBCMOBo1Z/+yQjSHCZxbz3qUfUx9XFn0lsn9al2mxlSxmfXO lcuhhB/r2zw4jYmERai8JnHF/0v15GSVqbazyzHVoolHJdVFs+BoOQfNpjaQ2+en4Y xp6j4EAfxVbamWyYTQHqciF4wzizahp8dpGhviKg= X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail16.vgs.untd.com [10.181.12.156]) by smtpout06.vgs.untd.com with SMTP id AABG3QYPNARYRP92 for (sender ); Sat, 2 Apr 2011 10:15:24 -0700 (PDT) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucf6HyplTnjJhRvmipsNYrhrxXasQglA6uQ== Received: (from dyerbrookme@juno.com) by webmail16.vgs.untd.com (jqueuemail) id Q7WAD8YB; Sat, 02 Apr 2011 10:14:28 PDT Received: from [173.52.3.243] by webmail16.vgs.untd.com with HTTP: Sat, 2 Apr 2011 17:14:18 GMT X-Originating-IP: [173.52.3.243] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sat, 2 Apr 2011 17:14:18 GMT To: carlo@alinoe.com X-Mailer: Webmail Version 6.1_P2 Message-Id: <20110402.131418.12136.0@webmail16.vgs.untd.com> Content-Type: multipart/alternative;boundary="--__JWM__J3def.1614S.7255M" X-UNTD-BodySize: 26380 X-ContentStamp: 1:1:2234950662 X-MAIL-INFO: 238df1a9f12d4950fd2450b1b43180e909d590903de495e55964e9f0f06d8dc9b0e58dade121e4a9615d2db0f0d0d049f09451a4d4d0fdf4f4c18001b9a1 X-UNTD-Peer-Info: 10.181.12.156|webmail16.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 17:14:43 -0000 ----__JWM__J3def.1614S.7255M Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 Carlo, Why, after 7 years (or more like 15 years) of discussions about t= he Metaverse do you feel the need to come and state the obvious about th= e analog hole once again?And the obvious about the inability to stop rog= ue viewers once again because they can all spoof things? We get all that= -- and got a million times ago when you smugly explained it the first m= illion times. The reality is, companies use a variety of techniques to b= attle these problems, some engineered in code, some in organic policy. I= ndeed they use DRM and paywalls despite everything that you think or tha= t Apple has done. And that's ok. We all get that there is no 100 percent= solution. But if you cease to think in the rigid binary manner of 0/1, = if you have 67 percent of a solution, that's still pretty good. If youco= mbine that with 6 other methods, some engineered, some managed by people= , you have a pretty good system. You don't admit or counsel defeat or as= sume a knowier-than-thou defeatist position about the problem of copying= on the Internet just because there's copyablity. As Jaron Lanier has explained a number of times, "It's this way because = we made it this way." The ideology was baked in; it can be baked out *sh= rugs*. Why you would have to rehearse, in numbing, boring detail for the= millionth time in this discussion, the way textures operate -- facts we= who are not technologistsbut who use SL already got the first million t= imes you discussed it -- can only be explained by a belief that if you s= ay something enough times it will "make it true" -- as a policy, and not= just as code. The reality is, most people don't copy. The reality is, m= ost people find c/m/t works pretty good. In fact, so good that the entir= e economy thrives on it. The reality is, the Lindens do catch rogue view= ers. The reality is, most people have absolutely no need to liberate the= ir own or other's content. It's a completely contrived claim that they d= o, just because you as the copyleftist sect have this "need". And again = THE PROBLEM IS EXAGGERATED and indeed those latest statistics in fact le= t us know that. 9 million scans of X thousands of avatars, and only 78,0= 00 found with rogue viewers. And DER we get it that the real rogues are = not going to show up as "known rogues". So what? *There aren't that many= of them either*. Psychological advantage *matters*. = "And don't tell me software exists that can detect if an uploaded texture "looks like" one of the already existing billion textures that were uploaded before. If the texture is converted twice, ie from jpeg2000 to jpg to tga and then uploaded, then you'd need a human to look at the original and the newly uploaded texture at the same time to judge that it is MAYBE a copy - which then can only be proved in court if the original creator can prove that his original textures are 100% his own and not, for example, downloaded from the internet somewhere (because in that case the other uploader could have used the same source). Well, maybe it does, and maybe it doesn't. I= n fact, YOU would not be a source on this because you and your confreres= here already have one perspective, and that's the copyleftist one.You'r= e already predisposed to see every nail of attempt to find mechanical me= ans, even if not perfect, with the hammer of your default copyleftism. S= o you're not the person to consult about this.You and the others here ar= e not trustworthy; you are not good stewards of the public trust. You ha= ve no credibility. The idea that there is "the complete lack of support = for FREE things" in Second Life is outrageously laughable. It's the sort= of thing only the most extreme, lunatic Stillmanite could say. Every st= ore has freebies. There are zillions of divas who have loss leaders. The= re are thousands of people who like helping the masses with free crap. T= here is a concerned, aggressive, obsessive sect of opensource freaks in = SL who constantly release things for free, especially if they can ruin s= omeone else's proprietary business that they don't think they should hav= e -- for example, CrystalShar Foo's infamous Freeview TV, cumbersome and= unworkable but free, and designed to undermine the proprietary TV scrip= ts (ultimately an unsuccessful gambit, but one which still continues to = wreck havoc). So there's no shortage of "free" and "free on all perms" -= - to claim the opposite is to defy what we can all see before our eyes o= n every sim. There is no customer demand for rezzing prims defaulting to= the collectivist mode of all perms. That's a minority, sectarian opinio= n of some copyleftists and they've aggressively mounted a JIRA demanding= the first step toward this (with an aim to undermine the default), and i= t's no accident, comrade, that I am banned from the JIRA for precisely o= bjecting that exact stealth campaign, barely camouflaged becausethe orig= inators' petition and comments on tech publications are all available to= see on the Internet to determine their real agenda. NO ONE is complaini= ng that prims rez to default to no-transfer. THAT'S OK. It prevents peop= le especially when new from giving away their creations accidently. It t= akes one click to change them to the share-bear freebie mode if needed. = No one has ever been deterred in their zeal to make everything "free for= the masses" -- communism abounds in SL. It's a completely false use cas= e to claim that there are all these people who are fussing that they can= 't manage builds or objects because of permissions problems. There aren'= t. Instead, there are way more people complaining that there is too much= unpunished copybotting and too much aggressiveness freebie flooding fro= m a small concerted clique with an agenda. It's just you don't hear from= these far greater masses of people because they aren't technologists. B= ut even without computer science degrees, people become very savvy about= running JIRA proposals and getting votes, and the votes show it: people= do not need the copyleftist regime in SL; they need the copyright regim= e in SL. That's all there is to it. Pretending this isn't the case is do= ne for ideological reasons and not science. The use case of "my friend n= eeds to me to change all the objects on my sim" is an isolated one and o= ne that is remedied with build perms most of the time. I've commissioned= numerous builds and worked with builders and other residents constantly= . Nobody has ever been deterred from collaboration or assistance with ma= nagement by the permissions system. Businesses make group avatars that m= ultiple use or they make company avatars just for that build to use. If = a creator "forgot" to set some root prim some way, you can contact them = and work it out. Most prefab creators put houses on copy/mod but not tra= nsfer precisely so you can easily change their buildings, in fact. Those= that put their item on no-copy/transfer will send you another copy or s= ell you a box with 6 back ups -- but the overwhelming majority put their= items on copy/mod. These fake claims of "entire sims" with "builds I ca= n't move or transfer" are artificial exoticisms used to make copyleftist= arguments -- I've gone and examined a few of them and found things like= Siggy Romulus' beach house, which was issued 7 years ago on all perms, = and which ends up in somebody's inventory without all the perms, but *wh= ich can be gotten again easily on all perms* -- that is, gosh, if you ca= n't live without an ugly brown newbie building and can't make one yourse= lf (and even I can do that). I discovered the two educators bellowing th= e loudest about not being able to copy content to open sim when they mov= ed due to price hikes last fall were people with a couple of free or ver= y cheap prefabs on their sims -- to hear them talk, they had the 65,000 = proprietary works of Scope Cleaver and had paid tens of thousands of dol= lars and were now wailing. Had that actually been the case, of course, t= hey could contact Scope and pay him for a transfer. To invoke fake use c= ases of builders long gone from the grid doesn't cut it -- most things i= n SL can be be built quickly anew, and the same textures purchased. Usin= g common sense and logic you sustain the economy; making up fake use cas= es and cranking up the tech or demanding changes to policy to match thos= e fake use cases, you undermine the economy. With builders I work with, = I'm able to copy their items because I have their build perms. So I coul= d put something again if it disappears in a sim rolling restart, somethi= ng that happens about once every few months. If I copy some large block = of concrete and put it out inworld, I can't then keep pulling on and cop= ying that block, I have to take it again from inventory. Same with commi= ssioned works I resell. I have to carefully rez each copy out of my inve= ntory and reset the perms to make sure I don't sell them all perm. I hav= e to do this with several items a few times a month. And it's worth it t= o preserve the intellectual property rights of those creators, and my in= vestment in commissioning content. I'm not a RL store owner who has to u= npack a crate and dust off the peanuts and manually put them on real she= lves, I'm a virtual store owner who...clicks a few times. Big deal. I am= NOT INTERESTED in CHANGES TO SERVER-SIDE CODE that remove the Berne inh= erency:http://secondthoughts.typepad.com/second_thoughts/2011/02/the-ber= ne-inherency-and-the-interop-flop-reply-to-meadh.html None of the "hards= hips" you describe are real. They all have workarounds. And they all hav= e solutions in the long run that will keep value *when this technologica= l exercise is in other hands*. There is nothing "missing" from the proto= col because a friend who has created something who somehow now needs you= to fiddle with his prims can't turn over every aspect of them to you. I= f he loves you that much, he can give you his log on and you can log on = as him. There is no "annoyance" that an object is "non free". That's ass= igning anthropomorphic features to a piece of code rendering as a block.= Catherine Pfeffer, flogging the all-perms JIRA, does exactly the same g= ambit, accusing the server of "enslaving" objects. Nonsense. The server,= the system, the protocols preserve value by keeping the maximum of choi= ces OPEN as a default. We value that. You don't. Go on open sim and play= in your Leninist sandboxes and stop trying to build a bridge between tw= o systems merely designed to flush the content out for free. We're not i= nterested; indeed we will vigorously oppose it. Freebies that are non-tr= ansfer are designed that way because freebies are usually tethered to a = purpose: serving as a loss-leader to drive people back to the store wher= e they were issued so that people might buy things as well as take the l= oss-leaders. And that's ok, that's normal, and that's what most people w= ant. You're ALREADY free to create content and set all the perms to supp= ort the collectivist ideals you wish to support. There is CHOICE. When o= pen source copyleftism is imposed on defaults, then THERE IS NO CHOICE. = As for this notion: "I think you might find a lot of people, like myself= , a lot more willing to help out with thinking of ways on how to protect= property in virtual worlds when first it is assured that those who want to create things tha= t are FREE are equally supported as the commercial guys out there. You're already FREE because there is already CHOICE and you are banging = on an open door -- with only the aim to close it and impose the coercive= copyleftist agenda with is NOT FREE for those who want to keep the inte= gration of copyright and commerce, a laudable aim. Once again, I want to= remind everyone what VWRAP and metaversestandards.org and other similar= exercises are about: ideological control by copyleftism, not technology= . And ideological control that is only able to keep itself in power by s= ilencing people on the JIRA, kicking people off lists like this, silenci= ng them on the opensource Linden list, etc. etc. Just as the real-life c= oercion of Soviet communism failed, so will this technocommunist version= of it fail precisely because of this coercion -- coercion in controllin= g speech criticizing of its hijacking of the agenda, coercion in opposit= ion to exposure of false use cases, and coercion in demanding technical = exigencies to suit copyleftism. Leave Second Life alone. Prokofy Neva ____________________________________________________________ Groupon.com Official Site 1 huge daily deal on the best stuff to do in your city. Try it today! http://thirdpartyoffers.juno.com/TGL3141/4d9759acc6cfc3f539st06vuc ----__JWM__J3def.1614S.7255M Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/html; charset=ISO-8859-1
Carlo,
 
Why, after 7 years (or more= like 15 years) of discussions about the Metaverse do you feel the need = to come and state the obvious about the analog hole once again?
And the obvious about the inability to stop rogue viewers once again b= ecause they can all spoof things?
 
We get all = that -- and got a million times ago when you smugly explained it the fir= st million times.
 
The reality is, companies u= se a variety of techniques to battle these problems, some engineered in = code, some in organic policy. Indeed they use DRM and paywalls despite e= verything that you think or that Apple has done. And that's ok. We all g= et that there is no 100 percent solution. But if you cease to think in t= he rigid binary manner of 0/1, if you have 67 percent of a solution, tha= t's still pretty good. If you
combine that with 6 other method= s, some engineered, some managed by people, you have a pretty good syste= m.
 
You don't admit or counsel defeat or assum= e a knowier-than-thou defeatist position about the problem of copying on= the Internet just because there's copyablity.

As Jaron La= nier has explained a number of times, "It's this way because we made it = this way." The ideology was baked in; it can be baked out *shrugs*.
 
Why you would have to rehearse, in numbing, borin= g detail for the millionth time in this discussion, the way textures ope= rate -- facts we who are not technologists
but who use SL alre= ady got the first million times you discussed it -- can only be explaine= d by a belief that if you say something enough times it will "make it tr= ue" -- as a policy, and not just as code.
 
The= reality is, most people don't copy. The reality is, most people find c/= m/t works pretty good. In fact, so good that the entire economy thrives = on it. The reality is, the Lindens do catch rogue viewers. The reality i= s, most people have absolutely no need to liberate their own or other's = content. It's a completely contrived claim that they do, just because yo= u as the copyleftist sect have this "need".
 
A= nd again THE PROBLEM IS EXAGGERATED and indeed those latest statistics i= n fact let us know that. 9 million scans of X thousands of avatars, and = only 78,000 found with rogue viewers.
 
And DER= we get it that the real rogues are not going to show up as "known rogue= s". So what? *There aren't that many of them either*. Psychological adva= ntage *matters*.
 

"And don't tell me softw= are exists that can detect if
an uploaded texture "looks like" one of= the already existing billion
textures that were uploaded before. If = the texture is converted twice,
ie from jpeg2000 to jpg to tga and th= en uploaded, then you'd need a
human to look at the original and the = newly uploaded texture at the
same time to judge that it is MAYBE a c= opy - which then can only be
proved in court if the original creator = can prove that his original
textures are 100% his own and not, for ex= ample, downloaded from the
internet somewhere (because in that case t= he other uploader could
have used the same source).
 <= /div>
Well, maybe it does, and maybe it doesn't. In fact, YOU would = not be a source on this because you and your confreres here already have= one perspective, and that's the copyleftist one.
You're alrea= dy predisposed to see every nail of attempt to find mechanical means, ev= en if not perfect, with the hammer of your default copyleftism. So you'r= e not the person to consult about this.
You and the others her= e are not trustworthy; you are not good stewards of the public trust. Yo= u have no credibility.
 
The idea that there is= "the complete lack of support for FREE things" in Second Life is outrag= eously laughable. It's the sort of thing only the most extreme, lunatic = Stillmanite could say.
 
Every store has freebi= es. There are zillions of divas who have loss leaders. There are thousan= ds of people who like helping the masses with free crap. There is a conc= erned, aggressive, obsessive sect of opensource freaks in SL who constan= tly release things for free, especially if they can ruin someone else's = proprietary business that they don't think they should have -- for examp= le, CrystalShar Foo's infamous Freeview TV, cumbersome and unworkable bu= t free, and designed to undermine the proprietary TV scripts (ultimately= an unsuccessful gambit, but one which still continues to wreck havoc). = So there's no shortage of "free" and "free on all perms" -- to claim the= opposite is to defy what we can all see before our eyes on every sim.
 
There is no customer demand for rezzing prims = defaulting to the collectivist mode of all perms. That's a minority, sec= tarian opinion of some copyleftists and they've aggressively mounted a J= IRA demanding
the first step toward this (with an aim to under= mine the default), and it's no accident, comrade, that I am banned from = the JIRA for precisely objecting that exact stealth campaign, barely cam= ouflaged because
the originators' petition and comments on tec= h publications are all available to see on the Internet to determine the= ir real agenda.
 
NO ONE is complaining that pr= ims rez to default to no-transfer. THAT'S OK. It prevents people especia= lly when new from giving away their creations accidently. It takes one c= lick to change them to the share-bear freebie mode if needed. No one has= ever been deterred in their zeal to make everything "free for the masse= s" -- communism abounds in SL.
 
It's a complet= ely false use case to claim that there are all these people who are fuss= ing that they can't manage builds or objects because of permissions prob= lems. There aren't. Instead, there are way more people complaining that = there is too much unpunished copybotting and too much aggressiveness fre= ebie flooding from a small concerted clique with an agenda. It's just yo= u don't hear from these far greater masses of people because they aren't= technologists. But even without computer science degrees, people become= very savvy about running JIRA proposals and getting votes, and the vote= s show it: people do not need the copyleftist regime in SL; they need th= e copyright regime in SL. That's all there is to it. Pretending this isn= 't the case is done for ideological reasons and not science.
&= nbsp;
The use case of "my friend needs to me to change all the= objects on my sim" is an isolated one and one that is remedied with bui= ld perms most of the time. I've commissioned numerous builds and worked = with builders and other residents constantly. Nobody has ever been deter= red from collaboration or assistance with management by the permissions = system. Businesses make group avatars that multiple use or they make com= pany avatars just for that build to use.
 
If a= creator "forgot" to set some root prim some way, you can contact them a= nd work it out. Most prefab creators put houses on copy/mod but not tran= sfer precisely so you can easily change their buildings, in fact. Those = that put their item on no-copy/transfer will send you another copy or se= ll you a box with 6 back ups -- but the overwhelming majority put their = items on copy/mod. These fake claims of "entire sims" with "builds I can= 't move or transfer" are artificial exoticisms used to make copyleftist = arguments -- I've gone and examined a few of them and found things like = Siggy Romulus' beach house, which was issued 7 years ago on all perms, a= nd which ends up in somebody's inventory without all the perms, but *whi= ch can be gotten again easily on all perms* -- that is, gosh, if you can= 't live without an ugly brown newbie building and can't make one yoursel= f (and even I can do that). I discovered the two educators bellowing the= loudest about not being able to copy content to open sim when they move= d due to price hikes last fall were people with a couple of free or very= cheap prefabs on their sims -- to hear them talk, they had the 65,000 p= roprietary works of Scope Cleaver and had paid tens of thousands of doll= ars and were now wailing. Had that actually been the case, of course, th= ey could contact Scope and pay him for a transfer. To invoke fake use ca= ses of builders long gone from the grid doesn't cut it -- most things in= SL can be be built quickly anew, and the same textures purchased. Using= common sense and logic you sustain the economy; making up fake use case= s and cranking up the tech or demanding changes to policy to match those= fake use cases, you undermine the economy.
 
W= ith builders I work with, I'm able to copy their items because I have th= eir build perms. So I could put something again if it disappears in a si= m rolling restart, something that happens about once every few months. I= f I copy some large block of concrete and put it out inworld, I can't th= en keep pulling on and copying that block, I have to take it again from = inventory. Same with commissioned works I resell. I have to carefully re= z each copy out of my inventory and reset the perms to make sure I don't= sell them all perm. I have to do this with several items a few times a = month. And it's worth it to preserve the intellectual property rights of= those creators, and my investment in commissioning content. I'm not a R= L store owner who has to unpack a crate and dust off the peanuts and man= ually put them on real shelves, I'm a virtual store owner who...clicks a= few times. Big deal. I am NOT INTERESTED in CHANGES TO SERVER-SIDE CODE= that remove the Berne inherency:
http://secondthoughts.typepa= d.com/second_thoughts/2011/02/the-berne-inherency-and-the-interop-flop-r= eply-to-meadh.html
 
None of the "hardships" yo= u describe are real. They all have workarounds. And they all have soluti= ons in the long run that will keep value *when this technological exerci= se is in other hands*.
 
There is nothing "miss= ing" from the protocol because a friend who has created something who so= mehow now needs you to fiddle with his prims can't turn over every aspec= t of them to you. If he loves you that much, he can give you his log on = and you can log on as him.
 
There is no "annoy= ance" that an object is "non free". That's assigning anthropomorphic fea= tures to a piece of code rendering as a block. Catherine Pfeffer, floggi= ng the all-perms JIRA, does exactly the same gambit, accusing the server= of "enslaving" objects.
 
Nonsense. The server= , the system, the protocols preserve value by keeping the maximum of cho= ices OPEN as a default. We value that. You don't. Go on open sim and pla= y in your Leninist sandboxes and stop trying to build a bridge between t= wo systems merely designed to flush the content out for free. We're not = interested; indeed we will vigorously oppose it.
 
<= div>Freebies that are non-transfer are designed that way because freebie= s are usually tethered to a purpose: serving as a loss-leader to drive p= eople back to the store where they were issued so that people might buy = things as well as take the loss-leaders. And that's ok, that's normal, a= nd that's what most people want.
 
You're ALREA= DY free to create content and set all the perms to support the collectiv= ist ideals you wish to support. There is CHOICE. When open source copyle= ftism is imposed on defaults, then THERE IS NO CHOICE.
 <= /div>
As for this notion: "I think you might find a lot of people, l= ike myself, a lot more willing to help out with thinking of ways on how = to protect property in virtual
worlds when first it is assured that t= hose who want to create things that are FREE are equally supported as th= e commercial guys out there.

You're already FREE because there is= already CHOICE and you are banging on an open door -- with only the aim= to close it and impose the coercive copyleftist agenda with is NOT FREE= for those who want to keep the integration of copyright and commerce, a= laudable aim. Once again, I want to remind everyone what VWRAP and meta= versestandards.org and other similar exercises are about: ideological co= ntrol by copyleftism, not technology. And ideological control that is on= ly able to keep itself in power by silencing people on the JIRA, kicking= people off lists like this, silencing them on the opensource Linden lis= t, etc. etc. Just as the real-life coercion of Soviet communism failed, = so will this technocommunist version of it fail precisely because of thi= s coercion -- coercion in controlling speech criticizing of its hijackin= g of the agenda, coercion in opposition to exposure of false use cases, = and coercion in demanding technical exigencies to suit copyleftism.
 
Leave Second Life alone.
 
Prokofy Neva


_____________________________= _______________________________
Groupon.com Official Site
1 huge daily deal on the best stuff to do in your city. T= ry it today!
Grou= pon.com ----__JWM__J3def.1614S.7255M-- From carlo@alinoe.com Sat Apr 2 10:47:19 2011 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 0005E28C122 for ; Sat, 2 Apr 2011 10:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, 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 lOyQaJiaz9LW for ; Sat, 2 Apr 2011 10:47:17 -0700 (PDT) Received: from fep12.mx.upcmail.net (fep12.mx.upcmail.net [62.179.121.32]) by core3.amsl.com (Postfix) with ESMTP id E5DEA3A686A for ; Sat, 2 Apr 2011 10:47:15 -0700 (PDT) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep12-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110402174855.FTWQ18728.viefep12-int.chello.at@edge04.upcmail.net> for ; Sat, 2 Apr 2011 19:48:55 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upcmail.net with edge id Shou1g0070FlQed04hov2M; Sat, 02 Apr 2011 19:48:55 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q64wP-0004WR-NT for vwrap@ietf.org; Sat, 02 Apr 2011 19:48:53 +0200 Date: Sat, 2 Apr 2011 19:48:53 +0200 From: Carlo Wood To: vwrap@ietf.org Message-ID: <20110402194853.20da8238@hikaru.localdomain> In-Reply-To: References: <20110402.101259.14412.0@webmail09.vgs.untd.com> <20110402171923.13176462@hikaru.localdomain> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Cloudmark-Analysis: v=1.1 cv=tMVj8KYobzzX0EiRnC7vY2isLrCxFvdg4RrHWPZXwJ0= c=1 sm=0 a=lF6S9qf5Q1oA:10 a=IkcTkHD0fZMA:10 a=pGLkceISAAAA:8 a=AYLji6ZvAAAA:8 a=BjFOTwK7AAAA:8 a=NoAKp6exAAAA:8 a=48vgC7mUAAAA:8 a=Atv1WHuS4AGoYdfVbqoA:9 a=DcJN9O2lR_aPraIDuYUA:7 a=QEXdDO2ut3YA:10 a=MSl-tDqOz04A:10 a=bW3kdApBr58A:10 a=B0cvAcWxpcAA:10 a=lZB815dzVvQA:10 a=jXQfTU4057PZLB3_:21 a=NCIqN71ChGOy6vFO:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [vwrap] Simulation consistency 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: Sat, 02 Apr 2011 17:47:19 -0000 On Sat, 2 Apr 2011 10:01:43 -0700 Meadhbh Hamrick wrote: This is not exactly what I was refering too :p What I meant is that it should be possible to tag a creation as "GPL-ed" or "Common Creations" etc, and that the result is that that thing stays that way. That it is not possible to accidently break such free licenses by making it 'no mod' because someone forgot to check a box. Although this seems to be a client-side issue, and thus something internally to grid (and thus not related to VWRAP), it DOES mean that such information has to be supported at all levels: the fact that something IS explicitely allowed to be copied etc, has to be stored in asset servers and be transported to others who obtain a copy if it. If everyone is willing to work as hard on guaranteeing support for such free product as on the use case for proprietary products, then I'm willing to think hard of ways to support the latter. > yes. there is something missing in the protocol. it's trust. you don't > put "trust" in a protocol, you put "security" in a protocol. at the > end of the day, the people using this protocol will need to decide > whom they trust. this is why there was a security model and the > ability of the protocol to "securely carry trust." >=20 > the idea is that the protocol would carry cryptographically > unforgeable attestations of an endpoint's identity. this identity > would then be evaluated by protocol participants to see if it is > "trusted." >=20 > there's no place in the protocol that says "you must trust a specific > entity," but rather a mechanism deployers can use to carry the > identity of people wishing to be trusted. >=20 > at the end of the day, an asset service should only barf up assets to > trusted simulation services. simulators SHOULD only allow people on > the grid they trust (for some definition of the word "trust.") >=20 > if you're a company like Linden that needs to respond to DMCA takedown > requests, you're likely to require the client trust knob turned up a > bit. if you're an enterprise, you're going to want that trust knob > turned all the way up. if you're the pirate bay, you're going to > intentionally want that trust knob turned all the way down. >=20 > as protocol developers, it's our duty to create a protocol that meets > everyone's use cases. so... i mean... feel free to try to define a > protocol that mandates the use of DRM or blesses a particular trust > point, but the likelihood of it being widely supported is.. > approximately nil. >=20 > my recommendation has always been... "define mechanism, not policy." >=20 > -cheers > -meadhbh > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >=20 >=20 >=20 > On Sat, Apr 2, 2011 at 8:19 AM, Carlo Wood wrote: > > On Sat, 2 Apr 2011 14:12:59 GMT > > "dyerbrookme@juno.com" wrote: > > > >> BTW, the Red Zone statistics of 9 million =C2=A0scans with only 78,000 > >> rogue viewers captured lets us know that this =C2=A0problem is > >> exaggerated -- and usually by engineers who claim there is no > >> =C2=A0technical solution. > > > > Just for the record, from a hacker/engineer: there is no technical > > solution. It is possible to copy everything (and without being > > detected by a "Red Zone" which can only detect rogue viewers that > > were released to the public and explicitly make a point of being > > detectable in the first place (call that bragging: no fun in > > releasing a "k3wl" viewer if others (or even the coder himself) > > can't see that it is being used.) So, there is a psychological > > advantage for the detectors, but not really a technical one. > > > > Lets concentrate on textures for the moment to explain this. > > > > In order to see an object, or clothing, with the appropriate > > textures, those textures have to be downloadable for the viewer. > > There is nothing you can do about that short of running the whole > > viewer server-side and providing a video. But even in that case it > > would technically be possible to rip the textures: they are still > > visible (ie, you could make a screenshot of the surface of a wall). > > I don't consider the video-broadcast to even be remotely > > interesting, certainly not from the viewpoint of VWRAP so lets > > forget that for the moment and just accept that it is possible for > > anyone to store whatever they SEE to their harddisk. > > > > Secondly, if the first creator could upload this texture then so can > > the ripper. And don't tell me software exists that can detect if > > an uploaded texture "looks like" one of the already existing billion > > textures that were uploaded before. If the texture is converted > > twice, ie from jpeg2000 to jpg to tga and then uploaded, then you'd > > need a human to look at the original and the newly uploaded texture > > at the same time to judge that it is MAYBE a copy - which then can > > only be proved in court if the original creator can prove that his > > original textures are 100% his own and not, for example, downloaded > > from the internet somewhere (because in that case the other > > uploader could have used the same source). > > > > A real problem, currently in SL, is imho the complete lack of > > support for FREE things. The amount of restriction (for people with > > honest viewers) is tremendous: if you're not an expert or do not pay > > attention for a second, then your creation is not truely free > > anymore. Everything defaults to very copyleft unfriendly settings. > > I'm trying to get my friends, who are very willing in that regard, > > to only create full permission stuff, but it's simply near > > impossible to keep something full permission and often we're stuck > > with something nobody else can change or edit because the creator > > forgot to set the bit of the contents of an object after changing > > the group etc blah blah... > > > > For example, last a good friend of me wanted my help with making a > > large amount of changes on his sim: hunderds of objects had to be > > adjusted... He was willing to: > > 1) Add me to any group necessary. > > 2) Give me his build rights > > 3) Transfer any object to me (temporary ownership transfer) > > 4) Make any adjustments to the objects and the objects contents > > =C2=A0 needed to allow me to access what I needed to access. > > etc etc > > > > The end result: He had to do it all by himself. It was impossible to > > give me enough access to help him (for those who don't believe that, > > one of things involved changing the "anyone can move" bit of an > > object in the contents of objects: it is not possible to take > > anything out of the contents (ie copy it to your inventory) when > > it's no transfer, and therefore you can't edit it, even though it's > > modify and you get all the rights that the owner can give you). > > > > Sorry, but that is unacceptable; and it CLEARLY shows that > > something is missing from the protocol. > > > > Now the above example doesn't show that a free object is not > > supported, it only make clear that non-free objects can be very > > annoying even in situations where the owner has all the rights to > > do what he wants to do. There are many other such examples. Hence, > > it shows that it is very annoying that an object is non-free by > > default at so many levels that you need an IQ of over 140 to create > > one and those permissions erode quickly to non-free. Even the so > > called "freebies" are non-free by the way: they are almost always > > no transfer. Hell, even the default shape that you can when you > > create a new account is no transfer, what kind of insanity is that?! > > > > I think you might find a lot of people, like myself, a lot more > > willing to help out with thinking of ways on how to protect > > property in virtual worlds when first it is assured that those who > > want to create things that are FREE are equally supported as the > > commercial guys out there. > > > > -- > > Carlo Wood > > _______________________________________________ > > vwrap mailing list > > vwrap@ietf.org > > https://www.ietf.org/mailman/listinfo/vwrap > > --=20 Carlo Wood From djshag@hotmail.com Sat Apr 2 10:47:53 2011 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 C55CC28C122 for ; Sat, 2 Apr 2011 10:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dy86-LI-61Pu for ; Sat, 2 Apr 2011 10:47:51 -0700 (PDT) Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com [65.55.111.112]) by core3.amsl.com (Postfix) with ESMTP id B0DB03A686A for ; Sat, 2 Apr 2011 10:47:50 -0700 (PDT) Received: from BLU159-DS20 ([65.55.111.73]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 2 Apr 2011 10:49:31 -0700 X-Originating-IP: [184.163.193.51] X-Originating-Email: [djshag@hotmail.com] Message-ID: From: "Patnad Babii" To: , References: <20110402.131418.12136.0@webmail16.vgs.untd.com> In-Reply-To: <20110402.131418.12136.0@webmail16.vgs.untd.com> Date: Sat, 2 Apr 2011 13:49:30 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01CBF13C.CA5486A0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3508.1109 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3508.1109 X-OriginalArrivalTime: 02 Apr 2011 17:49:31.0942 (UTC) FILETIME=[52414460:01CBF15E] Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 17:47:53 -0000 Ce message est compos et au format MIME. ------=_NextPart_000_007C_01CBF13C.CA5486A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Look i have no idea why you make personal attack in this IETF working = group list, but you should stop it, if you don=E2=80=99t have anything = constructive to say in here, please go rant in some other places, i`m = sure there's plenty of places where you can just go about it. Why = don=E2=80=99t you just blog about it and don=E2=80=99t use the list. = I=E2=80=99m not trying to tell you that you can=E2=80=99t express = yourself here, but flaming others really doesn=E2=80=99t have a place in = a list like this. Please stop it, every time your posting in here turn = out in a flaming war and we really don=E2=80=99t need this. Thank you From: dyerbrookme@juno.com=20 Sent: Saturday, April 02, 2011 1:14 PM To: carlo@alinoe.com=20 Cc: vwrap@ietf.org=20 Subject: Re: [vwrap] [wvrap] Simulation consistency Carlo, Why, after 7 years (or more like 15 years) of discussions about the = Metaverse do you feel the need to come and state the obvious about the = analog hole once again? And the obvious about the inability to stop rogue viewers once again = because they can all spoof things? We get all that -- and got a million times ago when you smugly explained = it the first million times. The reality is, companies use a variety of techniques to battle these = problems, some engineered in code, some in organic policy. Indeed they = use DRM and paywalls despite everything that you think or that Apple has = done. And that's ok. We all get that there is no 100 percent solution. = But if you cease to think in the rigid binary manner of 0/1, if you have = 67 percent of a solution, that's still pretty good. If you combine that with 6 other methods, some engineered, some managed by = people, you have a pretty good system. You don't admit or counsel defeat or assume a knowier-than-thou = defeatist position about the problem of copying on the Internet just = because there's copyablity. As Jaron Lanier has explained a number of times, "It's this way because = we made it this way." The ideology was baked in; it can be baked out = *shrugs*. Why you would have to rehearse, in numbing, boring detail for the = millionth time in this discussion, the way textures operate -- facts we = who are not technologists but who use SL already got the first million times you discussed it -- = can only be explained by a belief that if you say something enough times = it will "make it true" -- as a policy, and not just as code. The reality is, most people don't copy. The reality is, most people find = c/m/t works pretty good. In fact, so good that the entire economy = thrives on it. The reality is, the Lindens do catch rogue viewers. The = reality is, most people have absolutely no need to liberate their own or = other's content. It's a completely contrived claim that they do, just = because you as the copyleftist sect have this "need". And again THE PROBLEM IS EXAGGERATED and indeed those latest statistics = in fact let us know that. 9 million scans of X thousands of avatars, and = only 78,000 found with rogue viewers. And DER we get it that the real rogues are not going to show up as = "known rogues". So what? *There aren't that many of them either*. = Psychological advantage *matters*. "And don't tell me software exists that can detect if an uploaded texture "looks like" one of the already existing billion textures that were uploaded before. If the texture is converted twice, ie from jpeg2000 to jpg to tga and then uploaded, then you'd need a human to look at the original and the newly uploaded texture at the same time to judge that it is MAYBE a copy - which then can only be proved in court if the original creator can prove that his original textures are 100% his own and not, for example, downloaded from the internet somewhere (because in that case the other uploader could have used the same source). Well, maybe it does, and maybe it doesn't. In fact, YOU would not be a = source on this because you and your confreres here already have one = perspective, and that's the copyleftist one. You're already predisposed to see every nail of attempt to find = mechanical means, even if not perfect, with the hammer of your default = copyleftism. So you're not the person to consult about this. You and the others here are not trustworthy; you are not good stewards = of the public trust. You have no credibility. The idea that there is "the complete lack of support for FREE things" in = Second Life is outrageously laughable. It's the sort of thing only the = most extreme, lunatic Stillmanite could say. Every store has freebies. There are zillions of divas who have loss = leaders. There are thousands of people who like helping the masses with = free crap. There is a concerned, aggressive, obsessive sect of = opensource freaks in SL who constantly release things for free, = especially if they can ruin someone else's proprietary business that = they don't think they should have -- for example, CrystalShar Foo's = infamous Freeview TV, cumbersome and unworkable but free, and designed = to undermine the proprietary TV scripts (ultimately an unsuccessful = gambit, but one which still continues to wreck havoc). So there's no = shortage of "free" and "free on all perms" -- to claim the opposite is = to defy what we can all see before our eyes on every sim. There is no customer demand for rezzing prims defaulting to the = collectivist mode of all perms. That's a minority, sectarian opinion of = some copyleftists and they've aggressively mounted a JIRA demanding the first step toward this (with an aim to undermine the default), and = it's no accident, comrade, that I am banned from the JIRA for precisely = objecting that exact stealth campaign, barely camouflaged because the originators' petition and comments on tech publications are all = available to see on the Internet to determine their real agenda. NO ONE is complaining that prims rez to default to no-transfer. THAT'S = OK. It prevents people especially when new from giving away their = creations accidently. It takes one click to change them to the = share-bear freebie mode if needed. No one has ever been deterred in = their zeal to make everything "free for the masses" -- communism abounds = in SL. It's a completely false use case to claim that there are all these = people who are fussing that they can't manage builds or objects because = of permissions problems. There aren't. Instead, there are way more = people complaining that there is too much unpunished copybotting and too = much aggressiveness freebie flooding from a small concerted clique with = an agenda. It's just you don't hear from these far greater masses of = people because they aren't technologists. But even without computer = science degrees, people become very savvy about running JIRA proposals = and getting votes, and the votes show it: people do not need the = copyleftist regime in SL; they need the copyright regime in SL. That's = all there is to it. Pretending this isn't the case is done for = ideological reasons and not science. The use case of "my friend needs to me to change all the objects on my = sim" is an isolated one and one that is remedied with build perms most = of the time. I've commissioned numerous builds and worked with builders = and other residents constantly. Nobody has ever been deterred from = collaboration or assistance with management by the permissions system. = Businesses make group avatars that multiple use or they make company = avatars just for that build to use. If a creator "forgot" to set some root prim some way, you can contact = them and work it out. Most prefab creators put houses on copy/mod but = not transfer precisely so you can easily change their buildings, in = fact. Those that put their item on no-copy/transfer will send you = another copy or sell you a box with 6 back ups -- but the overwhelming = majority put their items on copy/mod. These fake claims of "entire sims" = with "builds I can't move or transfer" are artificial exoticisms used to = make copyleftist arguments -- I've gone and examined a few of them and = found things like Siggy Romulus' beach house, which was issued 7 years = ago on all perms, and which ends up in somebody's inventory without all = the perms, but *which can be gotten again easily on all perms* -- that = is, gosh, if you can't live without an ugly brown newbie building and = can't make one yourself (and even I can do that). I discovered the two = educators bellowing the loudest about not being able to copy content to = open sim when they moved due to price hikes last fall were people with a = couple of free or very cheap prefabs on their sims -- to hear them talk, = they had the 65,000 proprietary works of Scope Cleaver and had paid tens = of thousands of dollars and were now wailing. Had that actually been the = case, of course, they could contact Scope and pay him for a transfer. To = invoke fake use cases of builders long gone from the grid doesn't cut it = -- most things in SL can be be built quickly anew, and the same textures = purchased. Using common sense and logic you sustain the economy; making = up fake use cases and cranking up the tech or demanding changes to = policy to match those fake use cases, you undermine the economy. With builders I work with, I'm able to copy their items because I have = their build perms. So I could put something again if it disappears in a = sim rolling restart, something that happens about once every few months. = If I copy some large block of concrete and put it out inworld, I can't = then keep pulling on and copying that block, I have to take it again = from inventory. Same with commissioned works I resell. I have to = carefully rez each copy out of my inventory and reset the perms to make = sure I don't sell them all perm. I have to do this with several items a = few times a month. And it's worth it to preserve the intellectual = property rights of those creators, and my investment in commissioning = content. I'm not a RL store owner who has to unpack a crate and dust off = the peanuts and manually put them on real shelves, I'm a virtual store = owner who...clicks a few times. Big deal. I am NOT INTERESTED in CHANGES = TO SERVER-SIDE CODE that remove the Berne inherency: http://secondthoughts.typepad.com/second_thoughts/2011/02/the-berne-inher= ency-and-the-interop-flop-reply-to-meadh.html None of the "hardships" you describe are real. They all have = workarounds. And they all have solutions in the long run that will keep = value *when this technological exercise is in other hands*. There is nothing "missing" from the protocol because a friend who has = created something who somehow now needs you to fiddle with his prims = can't turn over every aspect of them to you. If he loves you that much, = he can give you his log on and you can log on as him. There is no "annoyance" that an object is "non free". That's assigning = anthropomorphic features to a piece of code rendering as a block. = Catherine Pfeffer, flogging the all-perms JIRA, does exactly the same = gambit, accusing the server of "enslaving" objects. Nonsense. The server, the system, the protocols preserve value by = keeping the maximum of choices OPEN as a default. We value that. You = don't. Go on open sim and play in your Leninist sandboxes and stop = trying to build a bridge between two systems merely designed to flush = the content out for free. We're not interested; indeed we will = vigorously oppose it. Freebies that are non-transfer are designed that way because freebies = are usually tethered to a purpose: serving as a loss-leader to drive = people back to the store where they were issued so that people might buy = things as well as take the loss-leaders. And that's ok, that's normal, = and that's what most people want. You're ALREADY free to create content and set all the perms to support = the collectivist ideals you wish to support. There is CHOICE. When open = source copyleftism is imposed on defaults, then THERE IS NO CHOICE. As for this notion: "I think you might find a lot of people, like = myself, a lot more willing to help out with thinking of ways on how to = protect property in virtual worlds when first it is assured that those who want to create things = that are FREE are equally supported as the commercial guys out there. You're already FREE because there is already CHOICE and you are banging = on an open door -- with only the aim to close it and impose the coercive = copyleftist agenda with is NOT FREE for those who want to keep the = integration of copyright and commerce, a laudable aim. Once again, I = want to remind everyone what VWRAP and metaversestandards.org and other = similar exercises are about: ideological control by copyleftism, not = technology. And ideological control that is only able to keep itself in = power by silencing people on the JIRA, kicking people off lists like = this, silencing them on the opensource Linden list, etc. etc. Just as = the real-life coercion of Soviet communism failed, so will this = technocommunist version of it fail precisely because of this coercion -- = coercion in controlling speech criticizing of its hijacking of the = agenda, coercion in opposition to exposure of false use cases, and = coercion in demanding technical exigencies to suit copyleftism. Leave Second Life alone. Prokofy Neva ____________________________________________________________ Groupon.com Official Site 1 huge daily deal on the best stuff to do in your city. Try it today! Groupon.com=20 -------------------------------------------------------------------------= ------- _______________________________________________ vwrap mailing list vwrap@ietf.org https://www.ietf.org/mailman/listinfo/vwrap ------=_NextPart_000_007C_01CBF13C.CA5486A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Look i have no idea why you make personal attack in this IETF = working group=20 list, but you should stop it, if you don=E2=80=99t have anything = constructive to say in=20 here, please go rant in some other places, i`m sure there's plenty of = places=20 where you can just go about it. Why don=E2=80=99t you just blog about it = and don=E2=80=99t use=20 the list. I=E2=80=99m not trying to tell you that you can=E2=80=99t = express yourself here, but=20 flaming others really doesn=E2=80=99t have a place in a list like this. = Please stop it,=20 every time your posting in here turn out in a flaming war and we really = don=E2=80=99t=20 need this.
 
Thank you
 
Sent: Saturday, April 02, 2011 1:14 PM
Subject: Re: [vwrap] [wvrap] Simulation=20 consistency
 
Carlo,
 
Why, after 7 years (or more like 15 years) of discussions about the = Metaverse do you feel the need to come and state the obvious about the = analog=20 hole once again?
And the obvious about the inability to stop rogue viewers once = again=20 because they can all spoof things?
 
We get all that -- and got a million times ago when you smugly = explained it=20 the first million times.
 
The reality is, companies use a variety of techniques to battle = these=20 problems, some engineered in code, some in organic policy. Indeed they = use DRM=20 and paywalls despite everything that you think or that Apple has done. = And=20 that's ok. We all get that there is no 100 percent solution. But if you = cease to=20 think in the rigid binary manner of 0/1, if you have 67 percent of a = solution,=20 that's still pretty good. If you
combine that with 6 other methods, some engineered, some managed by = people,=20 you have a pretty good system.
 
You don't admit or counsel defeat or assume a knowier-than-thou = defeatist=20 position about the problem of copying on the Internet just because = there's=20 copyablity.

As Jaron Lanier has explained a number of times, "It's this way = because=20 we made it this way." The ideology was baked in; it can be baked out=20 *shrugs*.
 
Why you would have to rehearse, in numbing, boring detail for the = millionth=20 time in this discussion, the way textures operate -- facts we who are = not=20 technologists
but who use SL already got the first million times you discussed it = -- can=20 only be explained by a belief that if you say something enough times it = will=20 "make it true" -- as a policy, and not just as code.
 
The reality is, most people don't copy. The reality is, most people = find=20 c/m/t works pretty good. In fact, so good that the entire economy = thrives on it.=20 The reality is, the Lindens do catch rogue viewers. The reality is, most = people=20 have absolutely no need to liberate their own or other's content. It's a = completely contrived claim that they do, just because you as the = copyleftist=20 sect have this "need".
 
And again THE PROBLEM IS EXAGGERATED and indeed those latest = statistics in=20 fact let us know that. 9 million scans of X thousands of avatars, and = only=20 78,000 found with rogue viewers.
 
And DER we get it that the real rogues are not going to show up as = "known=20 rogues". So what? *There aren't that many of them either*. Psychological = advantage *matters*.
 

"And don't tell me software exists that can detect if
an = uploaded=20 texture "looks like" one of the already existing billion
textures = that were=20 uploaded before. If the texture is converted twice,
ie from jpeg2000 = to jpg=20 to tga and then uploaded, then you'd need a
human to look at the = original and=20 the newly uploaded texture at the
same time to judge that it is MAYBE = a copy=20 - which then can only be
proved in court if the original creator can = prove=20 that his original
textures are 100% his own and not, for example, = downloaded=20 from the
internet somewhere (because in that case the other uploader=20 could
have used the same source).
 
Well, maybe it does, and maybe it doesn't. In fact, YOU would not = be a=20 source on this because you and your confreres here already have one = perspective,=20 and that's the copyleftist one.
You're already predisposed to see every nail of attempt to find = mechanical=20 means, even if not perfect, with the hammer of your default copyleftism. = So=20 you're not the person to consult about this.
You and the others here are not trustworthy; you are not good = stewards of=20 the public trust. You have no credibility.
 
The idea that there is "the complete lack of support for FREE = things" in=20 Second Life is outrageously laughable. It's the sort of thing only the = most=20 extreme, lunatic Stillmanite could say.
 
Every store has freebies. There are zillions of divas who have loss = leaders. There are thousands of people who like helping the masses with = free=20 crap. There is a concerned, aggressive, obsessive sect of opensource = freaks in=20 SL who constantly release things for free, especially if they can ruin = someone=20 else's proprietary business that they don't think they should have -- = for=20 example, CrystalShar Foo's infamous Freeview TV, cumbersome and = unworkable but=20 free, and designed to undermine the proprietary TV scripts (ultimately = an=20 unsuccessful gambit, but one which still continues to wreck havoc). So = there's=20 no shortage of "free" and "free on all perms" -- to claim the opposite = is to=20 defy what we can all see before our eyes on every sim.
 
There is no customer demand for rezzing prims defaulting to the=20 collectivist mode of all perms. That's a minority, sectarian opinion of = some=20 copyleftists and they've aggressively mounted a JIRA demanding
the first step toward this (with an aim to undermine the default), = and it's=20 no accident, comrade, that I am banned from the JIRA for precisely = objecting=20 that exact stealth campaign, barely camouflaged because
the originators' petition and comments on tech publications are all = available to see on the Internet to determine their real agenda.
 
NO ONE is complaining that prims rez to default to no-transfer. = THAT'S OK.=20 It prevents people especially when new from giving away their creations=20 accidently. It takes one click to change them to the share-bear freebie = mode if=20 needed. No one has ever been deterred in their zeal to make everything = "free for=20 the masses" -- communism abounds in SL.
 
It's a completely false use case to claim that there are all these = people=20 who are fussing that they can't manage builds or objects because of = permissions=20 problems. There aren't. Instead, there are way more people complaining = that=20 there is too much unpunished copybotting and too much aggressiveness = freebie=20 flooding from a small concerted clique with an agenda. It's just you = don't hear=20 from these far greater masses of people because they aren't = technologists. But=20 even without computer science degrees, people become very savvy about = running=20 JIRA proposals and getting votes, and the votes show it: people do not = need the=20 copyleftist regime in SL; they need the copyright regime in SL. That's = all there=20 is to it. Pretending this isn't the case is done for ideological reasons = and not=20 science.
 
The use case of "my friend needs to me to change all the objects on = my sim"=20 is an isolated one and one that is remedied with build perms most of the = time.=20 I've commissioned numerous builds and worked with builders and other = residents=20 constantly. Nobody has ever been deterred from collaboration or = assistance with=20 management by the permissions system. Businesses make group avatars that = multiple use or they make company avatars just for that build to = use.
 
If a creator "forgot" to set some root prim some way, you can = contact them=20 and work it out. Most prefab creators put houses on copy/mod but not = transfer=20 precisely so you can easily change their buildings, in fact. Those that = put=20 their item on no-copy/transfer will send you another copy or sell you a = box with=20 6 back ups -- but the overwhelming majority put their items on copy/mod. = These=20 fake claims of "entire sims" with "builds I can't move or transfer" are=20 artificial exoticisms used to make copyleftist arguments -- I've gone = and=20 examined a few of them and found things like Siggy Romulus' beach house, = which=20 was issued 7 years ago on all perms, and which ends up in somebody's = inventory=20 without all the perms, but *which can be gotten again easily on all = perms* --=20 that is, gosh, if you can't live without an ugly brown newbie building = and can't=20 make one yourself (and even I can do that). I discovered the two = educators=20 bellowing the loudest about not being able to copy content to open sim = when they=20 moved due to price hikes last fall were people with a couple of free or = very=20 cheap prefabs on their sims -- to hear them talk, they had the 65,000=20 proprietary works of Scope Cleaver and had paid tens of thousands of = dollars and=20 were now wailing. Had that actually been the case, of course, they could = contact=20 Scope and pay him for a transfer. To invoke fake use cases of builders = long gone=20 from the grid doesn't cut it -- most things in SL can be be built = quickly anew,=20 and the same textures purchased. Using common sense and logic you = sustain the=20 economy; making up fake use cases and cranking up the tech or demanding = changes=20 to policy to match those fake use cases, you undermine the = economy.
 
With builders I work with, I'm able to copy their items because I = have=20 their build perms. So I could put something again if it disappears in a = sim=20 rolling restart, something that happens about once every few months. If = I copy=20 some large block of concrete and put it out inworld, I can't then keep = pulling=20 on and copying that block, I have to take it again from inventory. Same = with=20 commissioned works I resell. I have to carefully rez each copy out of my = inventory and reset the perms to make sure I don't sell them all perm. I = have to=20 do this with several items a few times a month. And it's worth it to = preserve=20 the intellectual property rights of those creators, and my investment in = commissioning content. I'm not a RL store owner who has to unpack a = crate and=20 dust off the peanuts and manually put them on real shelves, I'm a = virtual store=20 owner who...clicks a few times. Big deal. I am NOT INTERESTED in CHANGES = TO=20 SERVER-SIDE CODE that remove the Berne inherency:
http://secondthoughts.typepad.com/second_thoughts/2011/02/the-berne-= inherency-and-the-interop-flop-reply-to-meadh.html
 
None of the "hardships" you describe are real. They all have = workarounds.=20 And they all have solutions in the long run that will keep value *when = this=20 technological exercise is in other hands*.
 
There is nothing "missing" from the protocol because a friend who = has=20 created something who somehow now needs you to fiddle with his prims = can't turn=20 over every aspect of them to you. If he loves you that much, he can give = you his=20 log on and you can log on as him.
 
There is no "annoyance" that an object is "non free". That's = assigning=20 anthropomorphic features to a piece of code rendering as a block. = Catherine=20 Pfeffer, flogging the all-perms JIRA, does exactly the same gambit, = accusing the=20 server of "enslaving" objects.
 
Nonsense. The server, the system, the protocols preserve value by = keeping=20 the maximum of choices OPEN as a default. We value that. You don't. Go = on open=20 sim and play in your Leninist sandboxes and stop trying to build a = bridge=20 between two systems merely designed to flush the content out for free. = We're not=20 interested; indeed we will vigorously oppose it.
 
Freebies that are non-transfer are designed that way because = freebies are=20 usually tethered to a purpose: serving as a loss-leader to drive people = back to=20 the store where they were issued so that people might buy things as well = as take=20 the loss-leaders. And that's ok, that's normal, and that's what most = people=20 want.
 
You're ALREADY free to create content and set all the perms to = support the=20 collectivist ideals you wish to support. There is CHOICE. When open = source=20 copyleftism is imposed on defaults, then THERE IS NO CHOICE.
 
As for this notion: "I think you might find a lot of people, like = myself, a=20 lot more willing to help out with thinking of ways on how to protect = property in=20 virtual
worlds when first it is assured that those who want to create = things=20 that are FREE are equally supported as the commercial guys out=20 there.

You're already FREE because there is already CHOICE and = you are=20 banging on an open door -- with only the aim to close it and impose the = coercive=20 copyleftist agenda with is NOT FREE for those who want to keep the = integration=20 of copyright and commerce, a laudable aim. Once again, I want to remind = everyone=20 what VWRAP and metaversestandards.org and other similar exercises are = about:=20 ideological control by copyleftism, not technology. And ideological = control that=20 is only able to keep itself in power by silencing people on the JIRA, = kicking=20 people off lists like this, silencing them on the opensource Linden = list, etc.=20 etc. Just as the real-life coercion of Soviet communism failed, so will = this=20 technocommunist version of it fail precisely because of this coercion -- = coercion in controlling speech criticizing of its hijacking of the = agenda,=20 coercion in opposition to exposure of false use cases, and coercion in = demanding=20 technical exigencies to suit copyleftism.
 
Leave Second Life alone.
 
Prokofy Neva


____________________________________________________________
Groupon.com=20 Official Site
1 huge daily = deal on the=20 best stuff to do in your city. Try it today!
Groupon.com=20

_______________________________________________
vwrap mailing=20 list
vwrap@ietf.org
https://www.ietf.org/mailman/listinfo/vwrap
=
------=_NextPart_000_007C_01CBF13C.CA5486A0-- From izzyalanis@gmail.com Sat Apr 2 11:04:08 2011 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 1F7C728C136 for ; Sat, 2 Apr 2011 11:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.103 X-Spam-Level: X-Spam-Status: No, score=-3.103 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 84XJ39afP5AW for ; Sat, 2 Apr 2011 11:04:06 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 41F7B28C103 for ; Sat, 2 Apr 2011 11:04:05 -0700 (PDT) Received: by fxm15 with SMTP id 15so3648496fxm.31 for ; Sat, 02 Apr 2011 11:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vEnqCAocmQ1jFGPzlx+RxyT67lHL0fNncDnC39jm6Sw=; b=uGMmGMA7AVEvnQGCa8kuOEIUmhd/zXjT7dIaIIppslZcJz9nLdqw4V2EfZM5VPLy6/ AJmGMxcd7eye1bmGdIjO58rFnNVL76yD9KoSxjf9WOOPLA6ecHOFnD1icmqaYgvCK6bW s3GTRJOlwTfG91BZI5GsR/vRKx2VHS/tlhgOs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RTQm/15UaYjElDmzuh379MaC+FVD+vJcknDhwWcNzsBoE11ERdTLrqo5PbvT/APyKh MO9P3BEAk7IpiiRWqN8hjT6i9uylcExd64iWHr9LppThodQxrS8HmtGnOADJr61JUZ3E 2z+LAXXCILNfCH7TWGlecdnW5NQkUbwTwGzmY= MIME-Version: 1.0 Received: by 10.223.86.2 with SMTP id q2mr1517769fal.120.1301767546757; Sat, 02 Apr 2011 11:05:46 -0700 (PDT) Received: by 10.223.81.66 with HTTP; Sat, 2 Apr 2011 11:05:46 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Apr 2011 14:05:46 -0400 Message-ID: From: Izzy Alanis To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 18:04:08 -0000 > As always though, it's a trade-off, since the proxied design has very poo= r scalability compared to the distributed one. I don't agree with that... If a user enters a highly populated region, every other client is going to (could and should be trying to) hit the asset server(s) for the assets that the user is wearing (assuming they're not cached locally). Every asset server has to be scaled up to the point that it can handle that load from all over... If I'm hosting a region that supports 10s of thousands of simultaneous users (thinking of the future), I already have to scale to meet that demand. If the region is proxying the assets, then, yes the region has to be scaled to meet that asset demand too, but it already has to be scaled to meet other demands of being a region server... and why is scaling those asset proxy services hard? It's going to cost $, but is not technically challenging. So, if I want to host a region like that... sure it will cost me, but the simulation will be consistent and users will be able to participate equally, regardless of the capabilities of their individual asset services. On Fri, Apr 1, 2011 at 11:55 PM, Morgaine wrote: > Every design choice results in a trade-off, Vaughn, improving one thing a= t > the expense of something else.=A0 If every time we offered a service we h= ad to > inform its users about the downsides of all the trade-offs we have made, > they would have an awful lot to read. ;-) > > The specific trade-off that you are discussing is no different.=A0 A regi= on > that proxies all content has the "benefit" of acquiring control from the > asset servers over the items in the region, so that it can ensure that > everyone in the region not only obtains the items but obtains the same it= ems > as everyone else.=A0 That does indeed provide a greater guarantee of > consistency than a deployment in which the region only passes asset URIs = to > clients who then fetch the items from asset services separately.=A0 As al= ways > though, it's a trade-off, since the proxied design has very poor scalabil= ity > compared to the distributed one. > > If we're going to warn users of the potential for inconsistency in the > distributed deployment as you suggest, are we also going to warn them of > non-scalability in the proxied one?=A0 I really don't see much merit in t= he > idea of warning about design choices.=A0 Many such choices are technical,= and > the issues are quite likely to be of little interest to non-technical use= rs > anyway.=A0 In any case, the better services are likely to provide such > information in their online documentation, I would guess. > > You mentioned users "voting with their feet" or choosing to accept the ri= sk > of inconsistency.=A0 Well that will happen anyway, when services fail and > users get annoyed.=A0 If some asset services refuse to send the requested > items to some users, those services will get a bad reputation and people > will choose different asset services instead.=A0 Likewise, if a world ser= vice > proxies everything and so it can't handle a large number of assets or of > people, users will get annoyed at the lag and will go elsewhere.=A0 This = user > evaluation and "voting with their feet" happens already with online servi= ces > all over the Internet, and I am sure that this human process will continu= e > to work when the services are asset and region services. > > Back in September 2010, I wrote this post which proposes that we use in > VWRAP a form of asset addressing that provides massive scalability at the > same time as a very high degree of resilience -- > http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html .=A0 It = is > based on the concept of the URI containing a host part and a hash part, > where the hash is generated (once, at the time of storage to the asset > service) using a specified digest algorithm over the content of the asset > being referenced.=A0 You may wish to note that if this design were used, = the > failure of an asset service to deliver a requested item would result in a > failover request for the item to one or more backup services, using the s= ame > hash part but with a different host address. > > This can go some way towards overcoming the problem that you think might > occur when assets are fetched by clients from asset services directly. > Although it won't help when the missing item is available from only a sin= gle > asset service, it will help in many other cases, and it will compensate f= or > service failures and network outages automatically at the same time. > > PS. This design for hash-based asset addressing is already being tested b= y > Mojito Sorbet in her experimental world and client.=A0 It would give > VWRAP-based worlds an improved level of service availability, so I think = it > should be a core feature of our protocol. > > > Morgaine. > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca > wrote: >> >> This is a question i discussed with Morgaine off-list a while ago (I >> intended to send it to the list but pushed the wrong button...) I >> think we need to address this problem, and decide how to deal with it. >> >> =A0In Davids deployment draft, section 7.3.1.1 an overview is given van >> ways to deliver content to the region. One way is only passing a >> capability that allows access to (part of) the resource: >> >> =A0 =A0 =A0 =A0 =A0 7.3.1.1. =A0Content delivery models >> =A0 =A0 =A0 =A0 =A0 A range of possible represenations can be passed to = a region for >> =A0 =A0 =A0 =A0 =A0 simulation. [...] The other end of the delivery spec= trum >> involves passing >> =A0 =A0 =A0 =A0 =A0 only a URI or capability used to access the renderin= g >> information and a >> =A0 =A0 =A0 =A0 =A0 collision mesh,and related data for physical simulat= ion. >> =A0 =A0 =A0 =A0 =A0 In such a model, the client is responsible for fetch= ing the >> additional >> =A0 =A0 =A0 =A0 =A0 information needed to render the item's visual prese= nce from a >> separate >> =A0 =A0 =A0 =A0 =A0 service. =A0This fetch can be done *under the creden= tials of the >> end user* >> =A0 =A0 =A0 =A0 =A0 viewing the material [my emphasis--VD] , and divorce= s the >> simulation from >> =A0 =A0 =A0 =A0 =A0 the trust chain needed to manage content. =A0Any aut= omation >> is done on a >> =A0 =A0 =A0 =A0 =A0 separate host which the content creator or owner tru= sts, >> interacting with the >> =A0 =A0 =A0 =A0 =A0 object through remoted interfaces. >> >> =A0I can see the need for such a setup, however, i feel we are >> unpleasantly close to a situation were the coherence of the simulation >> falls apart. >> In this deployment pattern the region advertises the presence of the >> asset, and *some* clients will be able to get it as expected, while >> -based on the arbitrary whims of the asset service- others might not. >> >> My hope would be that after the asset server provides the region with >> the capability to get the asset, it gives up control. That would mean >> that if the client finds the inventory server is unwilling to serve >> the content - in spire of the region saying it is present-, the client >> should be able to turn around ask the *region* for the asset, (and get >> is after all). >> >> =A0If that is not the case, -and there are probably good reasons for the >> deployment pattern as described- =A0shouldn't we *warn* clients that the >> region might be inconsistent, so the users behind the client can vote >> with their feet, (or take the risk)? >> >> --Vaughn >> _______________________________________________ >> 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 dzonatas@gmail.com Sat Apr 2 11:26:28 2011 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 4D7B93A687D for ; Sat, 2 Apr 2011 11:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 eRL5RtQ2d-PW for ; Sat, 2 Apr 2011 11:26:27 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 24CE53A6873 for ; Sat, 2 Apr 2011 11:26:27 -0700 (PDT) Received: by iye19 with SMTP id 19so5385640iye.31 for ; Sat, 02 Apr 2011 11:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4qmXkUuYgG0unOqGr1UG9IJo5wYbtLTI67qMgm5q4pc=; b=aE4C6Cu95KCpCv3VyhLLd7yjzlMQQ+SCK+ed7RkYt2PWcuFzS791uzuzCcmxvPvsaN 2KJ6bSVrrZb0pkBUYw7l3kQBL51rPNqT1neYlsF+FYQ1dV5su/Hw0TGe3lNgnWwhQWIR ubCXnnmfJsCDnGyE5hVLknVAPMB4+ivl+bstk= 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=vsQp1XBGNlX9kyiekzIIwnmNgygU6jWrbSFXneDiXJcmxUn93GvBkACaLQ9a/Yv7HL oOga3k0kDnzw1bMwuVleMUzzUc7aaKxmCKGGTOsskbDQx1c9gB7iSO6Dd3nZ8gLung7E GWfBNdNKsvZxW3sIDoOOtkNDeF6mJHRBySJAY= Received: by 10.42.153.2 with SMTP id k2mr4050491icw.333.1301768888262; Sat, 02 Apr 2011 11:28:08 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id wu1sm2164361icb.22.2011.04.02.11.28.04 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Apr 2011 11:28:04 -0700 (PDT) Message-ID: <4D976AE2.50302@gmail.com> Date: Sat, 02 Apr 2011 11:28:50 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: vwrap@ietf.org References: <20110402.101259.14412.0@webmail09.vgs.untd.com> <20110402171923.13176462@hikaru.localdomain> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Meadhbh Hamrick Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 18:26:28 -0000 Meadhbh Hamrick wrote: > yes. there is something missing in the protocol. it's trust. you don't > put "trust" in a protocol, you put "security" in a protocol. at the > end of the day, the people using this protocol will need to decide > whom they trust. this is why there was a security model and the > ability of the protocol to "securely carry trust." > Well said! +1 > the idea is that the protocol would carry cryptographically > unforgeable attestations of an endpoint's identity. this identity > would then be evaluated by protocol participants to see if it is > "trusted." > Exactly! Perhaps some assume content is always digital-deliverables for evaluation rather than only digital-context and the need to evaluate analog-content (separately). I know the issue is that I can write that easy and yet the overall task is complex, especially when one tries to wrap their head around the concept of analog-content evaluation over digital networks. Maybe kinetics (as now popularized by Microsoft) can help people comprehend these steps without the need to know the bounds of math, omegas, within the limits, and beyond, as we can more easily assume with ray-tracer knowledge. I mention this because know such knowledge would help ease the hearts of those in concern of asset security, yet I don't always have easier ways to explain things as Meadhbh did above. Imagine the only way to establish some sign-on is a specific diet and motion in front of the MS-Kinetic cam. That is analog data. If you think of single captures of the images then that is the digital renders of analog samples. The point is analog can only be sampled. The question of "trust" becomes how many samples does it take before some other participant acknowledges. (Or...,) How many milliseconds go by before you even recognize someone and trust your own cognition? Something to keep in mind while this list assumed digital-security (and exploitation) was the only argument possible. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Sat Apr 2 11:30:13 2011 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 D67CC3A687C for ; Sat, 2 Apr 2011 11:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.843 X-Spam-Level: X-Spam-Status: No, score=-2.843 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ww8nViuJPwiT for ; Sat, 2 Apr 2011 11:30:12 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 309EF3A6873 for ; Sat, 2 Apr 2011 11:30:12 -0700 (PDT) Received: by qwg5 with SMTP id 5so3152273qwg.31 for ; Sat, 02 Apr 2011 11:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Do6/8TgAO//3V9qrX7f18G3vXsv3JnZ1n3XXkcdq4Rs=; b=Perx5HCpQa1+GmP9y84TBQyOELLPcbnNdfCnMkUosPtI6JuDXQ2vY1vzqYhm5rSD5j uKSoZ/oegGNeE/gX+7IMk37IsOw+D0xou4jPbkFWwjd/fxB0/qoxn/jXUhq7ucdbbyNv I5rLpaaGUvP6Fnktp3ifYU/75XPTaF4ZlBxnE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=YBHHbHjEdpSanpYxvxpKAVQURs/KsXKOROIPJa7bw2TX/DOdExFimb9jhLDt6AIZzq cjDaW0LEc4EzfZapxTg8HG0VWeGsBrYqBMabYU1HJuwsAg0ifDMR5PLlgZ5caedZEOKf b3a6QiatGW8XPHM3/uLRIGQT2cVobHq+igSPU= MIME-Version: 1.0 Received: by 10.229.78.22 with SMTP id i22mr1957807qck.33.1301769112934; Sat, 02 Apr 2011 11:31:52 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sat, 2 Apr 2011 11:31:52 -0700 (PDT) In-Reply-To: <4D97426B.8010302@gmail.com> References: <4D97426B.8010302@gmail.com> Date: Sat, 2 Apr 2011 19:31:52 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00235429d8f48e5953049ff3bdd2 Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 18:30:14 -0000 --00235429d8f48e5953049ff3bdd2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hash-based addressing is very different to UUID-based addressing as used in SNOW-375, so I expect there is some misunderstanding of how hash digests ar= e applied in this scheme, The universal address of the item is the hash digest over the data of the item using a specified digest algorithm, and is not a UUID. It is invarian= t regardless of who computes it, although it would normally be computed only once by the asset service at the time that the item is being stored in the service. All asset services everywhere will use the same digest as an address for this item, because the digest algorithm is specified. Data that is addressed and indexed in this way can of course be used in a REST architecture with appropriate design, but because hash digests are not UUIDs, there is quite a different semantic to it. A UUID cannot be used as a shared cache index in a multi-world architecture, because identical content in N different worlds will have different UUIDs associated with it in each world. In contrast, identical content in N different worlds will have an identical hash in every world, and therefore only a single storage entry is needed in a multi-world cache. The effect of this is dramatic. Every time that an Object ARchive is loade= d to populate a new region, this can generate another several hundred thousan= d (and soon, millions) of new assets which in a UUID-addressed scheme will typically just grow the asset storage without bound. In a hash-addressed scheme, that OAR can be loaded a million times and the asset data storage doesn't increase by 1 byte, neither in the asset server, the region, nor in client caches. Only metadata storage need grow for repeated assets in asse= t services, but it's not even needed in client-side caches, so the benefits are huge. A nice mental image that really brings this home is that of grass patches and trees and other common environmental objects reused in countless worlds across the metaverse, yet requiring no downloads at all as you tour around the worlds because visiting just one world has populated your persistent cache with those common items already. This can represents storage savings of thousands or even millions to 1, and corresponding time savings too because the remote fetches from asset services are avoided entirely. The impact of this scheme on user experienc= e can be expected to be outstanding even in today's humble beginnings, and much more so as the metaverse blooms. It's the scheme with the best performance and scalability of any we have examined so far. UUID-based asset storage does not have these excellent properties, nor the other advantages that I have described previously. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Sat, Apr 2, 2011 at 4:36 PM, Dzonatas Sol wrote: > Your hash/digest method is similar to basic REST and what I already > implemented. Icesphere already has implementations and methods and even > furthers them with burst modes so where there is no worry to have a URI f= or > each asset. The URI can specify a list of assets or single asset (content > varies as such), which can be returned immediately or when each is ready = for > transfer, individually. Uses LLIDL with proposed changes: > > Everything is documented here: > http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Inve= ntory > (Last edited that doc in August 2010 & Icesphere's implementation has bee= n > used for awhile since then) > > > > Morgaine wrote: > >> Back in September 2010, I wrote this post which proposes that we use in >> VWRAP a form of asset addressing that provides massive scalability at th= e >> same time as a very high degree of resilience -- >> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html .=EF=BF= =BD It is >> based on the concept of the URI containing a host part and a hash part, >> where the hash is generated (once, at the time of storage to the asset >> service) using a specified digest algorithm over the content of the asse= t >> being referenced.=EF=BF=BD You may wish to note that if this design were= used, the >> failure of an asset service to deliver a requested item would result in = a >> failover request for the item to one or more backup services, using the = same >> hash part but with a different host address. >> >> > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > --00235429d8f48e5953049ff3bdd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hash-based addressing is very different to UUID-based addressing as used in= SNOW-375, so I expect there is some misunderstanding of how hash digests a= re applied in this scheme,

The universal address of the item is the = hash digest over the data of the item using a specified digest algorithm, a= nd is not a UUID.=C2=A0 It is invariant regardless of who computes it, alth= ough it would normally be computed only once by the asset service at the ti= me that the item is being stored in the service.=C2=A0 All asset services e= verywhere will use the same digest as an address for this item, because the= digest algorithm is specified.

Data that is addressed and indexed in this way can of course be used in= a REST architecture with appropriate design, but because hash digests are = not UUIDs, there is quite a different semantic to it.=C2=A0 A UUID cannot b= e used as a shared cache index in a multi-world architecture, because ident= ical content in N different worlds will have different UUIDs associated wit= h it in each world.=C2=A0 In contrast, identical content in N different wor= lds will have an identical hash in every world, and therefore only a single= storage entry is needed in a multi-world cache.

The effect of this is dramatic.=C2=A0 Every time that an Object ARchive= is loaded to populate a new region, this can generate another several hund= red thousand (and soon, millions) of new assets which in a UUID-addressed s= cheme will typically just grow the asset storage without bound.=C2=A0 In a = hash-addressed scheme, that OAR can be loaded a million times and the asset= data storage doesn't increase by 1 byte, neither in the asset server, = the region, nor in client caches.=C2=A0 Only metadata storage need grow for= repeated assets in asset services, but it's not even needed in client-= side caches, so the benefits are huge.

A nice mental image that really brings this home is that of grass patch= es and trees and other common environmental objects reused in countless wor= lds across the metaverse, yet requiring no downloads at all as you tour aro= und the worlds because visiting just one world has populated your persisten= t cache with those common items already.

This can represents storage savings of thousands or even millions to 1,= and corresponding time savings too because the remote fetches from asset s= ervices are avoided entirely.=C2=A0 The impact of this scheme on user exper= ience can be expected to be outstanding even in today's humble beginnin= gs, and much more so as the metaverse blooms.=C2=A0 It's the scheme wit= h the best performance and scalability of any we have examined so far.

UUID-based asset storage does not have these excellent properties, nor = the other advantages that I have described previously.


Morgaine.=





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

On Sat, Apr 2, 2011 at 4:36 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
=
Your hash/digest method is similar to basic REST and what I already impleme= nted. Icesphere already has implementations and methods and even furthers t= hem with burst modes so where there is no worry to have a URI for each asse= t. The URI can specify a list of assets or single asset (content varies as = such), which can be returned immediately or when each is ready for transfer= , individually. Uses LLIDL with proposed changes:

Everything is documented here: http://wik= i.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Inventory (Last edited that doc in August 2010 & Icesphere's implementation h= as been used for awhile since then)



Morgaine wrote:
Back in September 2010, I wrote this post which proposes that we use in VWR= AP a form of asset addressing that provides massive scalability at the same= time as a very high degree of resilience -- http://www= .ietf.org/mail-archive/web/vwrap/current/msg00463.html .=EF=BF=BD It is= based on the concept of the URI containing a host part and a hash part, wh= ere the hash is generated (once, at the time of storage to the asset servic= e) using a specified digest algorithm over the content of the asset being r= eferenced.=EF=BF=BD You may wish to note that if this design were used, the= failure of an asset service to deliver a requested item would result in a = failover request for the item to one or more backup services, using the sam= e hash part but with a different host address.



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


--00235429d8f48e5953049ff3bdd2-- From dzonatas@gmail.com Sat Apr 2 11:39:43 2011 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 154AA3A687F for ; Sat, 2 Apr 2011 11:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 hkFTkWClBJJJ for ; Sat, 2 Apr 2011 11:39:41 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 591DA3A6452 for ; Sat, 2 Apr 2011 11:39:41 -0700 (PDT) Received: by iye19 with SMTP id 19so5393850iye.31 for ; Sat, 02 Apr 2011 11:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2JUg4J+BIJeA3hsBUZBltSS0XOrnGTC7RGeyct2oqf4=; b=KzT3jS5DsTJWAPrSAK+0cJVRSx9xrDhi48Kj88h8NJ6uFySMhtLL4X8Z6K0GDXxobL Tg3BhnMJuCZdo7HLSZwPW2Zur8dDlXMgjBGQmLqgvzyeaETF+m0YFLSeNl4eSNCZdsw9 0M48wWphA8oELRZ4+U6cf2NG2pcuC8UR0UCdw= 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=XCPDEP/4tZU1gMmy7k6s+TEFnYieVrIy58oGbql6BOqM2TcgMBSH4ec7Mj4RtdMWRD blHYtPL8LSpegN+YpXleTPTs0OniprNPgU9jiUvGGJUIiIQpiKOZQYW6cKDjjKZAndWb 7712lr4AJPUZPsVkg6HEbwJGCD6h3NHFSK5uQ= Received: by 10.43.56.211 with SMTP id wd19mr3202602icb.91.1301769682344; Sat, 02 Apr 2011 11:41:22 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id wo15sm2170966icb.4.2011.04.02.11.41.20 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Apr 2011 11:41:21 -0700 (PDT) Message-ID: <4D976DFE.6090601@gmail.com> Date: Sat, 02 Apr 2011 11:42:06 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Carlo Wood References: <20110402.101259.14412.0@webmail09.vgs.untd.com> <20110402171923.13176462@hikaru.localdomain> <20110402194853.20da8238@hikaru.localdomain> In-Reply-To: <20110402194853.20da8238@hikaru.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Simulation consistency 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: Sat, 02 Apr 2011 18:39:43 -0000 Not everything has to be copied. Wrap your mind around the ability for one simulator A to act as the client to another simulator B. In such case, the assets are not copied if they are only ray-traced. The ray-traced rendition can then allow user C to connect to sim A and see some appearance of assets froms sim B, yet not the exact copies. Now, consider many asset servers to be the original analog-version of assets that are being simulated individually, and simulators will need to connect to these asset simulators in order to get some sampled view of the original. The sample view is the only allowable copy, and the original is never transfered. Detail of the sample view may vary. Consider some jewelry has some very unique, highly detailed, intricate work, the sampled version will never come close to the original, especially given limits on number of samples and resolution. One would have to trade the original manually in order to transfer it. Convex/concave samples outside of ray-tracers are not always easy. It's doesn't always begin with a prim for these concepts. Again, the idea is individual (and original) asset simulators instead of region simulator that (own and) simulate everything about requested assets. Related concepts: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/HttpCastRayLLSD http://icyspherical.blogspot.com/2010/07/optimizing-simulations-with-basic.html Carlo Wood wrote: > On Sat, 2 Apr 2011 10:01:43 -0700 > Meadhbh Hamrick wrote: > > This is not exactly what I was refering too :p > What I meant is that it should be possible to tag > a creation as "GPL-ed" or "Common Creations" etc, > and that the result is that that thing stays that > way. That it is not possible to accidently break > such free licenses by making it 'no mod' because > someone forgot to check a box. > > Although this seems to be a client-side issue, > and thus something internally to grid (and thus > not related to VWRAP), it DOES mean that such > information has to be supported at all levels: > the fact that something IS explicitely allowed > to be copied etc, has to be stored in asset > servers and be transported to others who obtain > a copy if it. > > If everyone is willing to work as hard on guaranteeing > support for such free product as on the use case > for proprietary products, then I'm willing to think > hard of ways to support the latter. > > >> yes. there is something missing in the protocol. it's trust. you don't >> put "trust" in a protocol, you put "security" in a protocol. at the >> end of the day, the people using this protocol will need to decide >> whom they trust. this is why there was a security model and the >> ability of the protocol to "securely carry trust." >> >> the idea is that the protocol would carry cryptographically >> unforgeable attestations of an endpoint's identity. this identity >> would then be evaluated by protocol participants to see if it is >> "trusted." >> >> there's no place in the protocol that says "you must trust a specific >> entity," but rather a mechanism deployers can use to carry the >> identity of people wishing to be trusted. >> >> at the end of the day, an asset service should only barf up assets to >> trusted simulation services. simulators SHOULD only allow people on >> the grid they trust (for some definition of the word "trust.") >> >> if you're a company like Linden that needs to respond to DMCA takedown >> requests, you're likely to require the client trust knob turned up a >> bit. if you're an enterprise, you're going to want that trust knob >> turned all the way up. if you're the pirate bay, you're going to >> intentionally want that trust knob turned all the way down. >> >> as protocol developers, it's our duty to create a protocol that meets >> everyone's use cases. so... i mean... feel free to try to define a >> protocol that mandates the use of DRM or blesses a particular trust >> point, but the likelihood of it being widely supported is.. >> approximately nil. >> >> my recommendation has always been... "define mechanism, not policy." >> >> -cheers >> -meadhbh >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> On Sat, Apr 2, 2011 at 8:19 AM, Carlo Wood wrote: >> >>> On Sat, 2 Apr 2011 14:12:59 GMT >>> "dyerbrookme@juno.com" wrote: >>> >>> >>>> BTW, the Red Zone statistics of 9 million scans with only 78,000 >>>> rogue viewers captured lets us know that this problem is >>>> exaggerated -- and usually by engineers who claim there is no >>>> technical solution. >>>> >>> Just for the record, from a hacker/engineer: there is no technical >>> solution. It is possible to copy everything (and without being >>> detected by a "Red Zone" which can only detect rogue viewers that >>> were released to the public and explicitly make a point of being >>> detectable in the first place (call that bragging: no fun in >>> releasing a "k3wl" viewer if others (or even the coder himself) >>> can't see that it is being used.) So, there is a psychological >>> advantage for the detectors, but not really a technical one. >>> >>> Lets concentrate on textures for the moment to explain this. >>> >>> In order to see an object, or clothing, with the appropriate >>> textures, those textures have to be downloadable for the viewer. >>> There is nothing you can do about that short of running the whole >>> viewer server-side and providing a video. But even in that case it >>> would technically be possible to rip the textures: they are still >>> visible (ie, you could make a screenshot of the surface of a wall). >>> I don't consider the video-broadcast to even be remotely >>> interesting, certainly not from the viewpoint of VWRAP so lets >>> forget that for the moment and just accept that it is possible for >>> anyone to store whatever they SEE to their harddisk. >>> >>> Secondly, if the first creator could upload this texture then so can >>> the ripper. And don't tell me software exists that can detect if >>> an uploaded texture "looks like" one of the already existing billion >>> textures that were uploaded before. If the texture is converted >>> twice, ie from jpeg2000 to jpg to tga and then uploaded, then you'd >>> need a human to look at the original and the newly uploaded texture >>> at the same time to judge that it is MAYBE a copy - which then can >>> only be proved in court if the original creator can prove that his >>> original textures are 100% his own and not, for example, downloaded >>> from the internet somewhere (because in that case the other >>> uploader could have used the same source). >>> >>> A real problem, currently in SL, is imho the complete lack of >>> support for FREE things. The amount of restriction (for people with >>> honest viewers) is tremendous: if you're not an expert or do not pay >>> attention for a second, then your creation is not truely free >>> anymore. Everything defaults to very copyleft unfriendly settings. >>> I'm trying to get my friends, who are very willing in that regard, >>> to only create full permission stuff, but it's simply near >>> impossible to keep something full permission and often we're stuck >>> with something nobody else can change or edit because the creator >>> forgot to set the bit of the contents of an object after changing >>> the group etc blah blah... >>> >>> For example, last a good friend of me wanted my help with making a >>> large amount of changes on his sim: hunderds of objects had to be >>> adjusted... He was willing to: >>> 1) Add me to any group necessary. >>> 2) Give me his build rights >>> 3) Transfer any object to me (temporary ownership transfer) >>> 4) Make any adjustments to the objects and the objects contents >>> needed to allow me to access what I needed to access. >>> etc etc >>> >>> The end result: He had to do it all by himself. It was impossible to >>> give me enough access to help him (for those who don't believe that, >>> one of things involved changing the "anyone can move" bit of an >>> object in the contents of objects: it is not possible to take >>> anything out of the contents (ie copy it to your inventory) when >>> it's no transfer, and therefore you can't edit it, even though it's >>> modify and you get all the rights that the owner can give you). >>> >>> Sorry, but that is unacceptable; and it CLEARLY shows that >>> something is missing from the protocol. >>> >>> Now the above example doesn't show that a free object is not >>> supported, it only make clear that non-free objects can be very >>> annoying even in situations where the owner has all the rights to >>> do what he wants to do. There are many other such examples. Hence, >>> it shows that it is very annoying that an object is non-free by >>> default at so many levels that you need an IQ of over 140 to create >>> one and those permissions erode quickly to non-free. Even the so >>> called "freebies" are non-free by the way: they are almost always >>> no transfer. Hell, even the default shape that you can when you >>> create a new account is no transfer, what kind of insanity is that?! >>> >>> I think you might find a lot of people, like myself, a lot more >>> willing to help out with thinking of ways on how to protect >>> property in virtual worlds when first it is assured that those who >>> want to create things that are FREE are equally supported as the >>> commercial guys out there. >>> >>> -- >>> Carlo Wood >>> _______________________________________________ >>> vwrap mailing list >>> vwrap@ietf.org >>> https://www.ietf.org/mailman/listinfo/vwrap >>> >>> > > > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Sat Apr 2 11:58:18 2011 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 75CC83A67E4 for ; Sat, 2 Apr 2011 11:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 YvQ4cw7mH07I for ; Sat, 2 Apr 2011 11:58:16 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 728343A6452 for ; Sat, 2 Apr 2011 11:58:16 -0700 (PDT) Received: by iwn39 with SMTP id 39so5219049iwn.31 for ; Sat, 02 Apr 2011 11:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6W/Lmtmfu9RWXkqajs0xmiC0eDxO4g2vuRvFxnBqMmY=; b=ZdHO0KQlOl03HRcG0FlzD0Gu1u1yodPMCrKteDWn4dC4BCPXyd0GRlBwRVmv6zMPF2 tpMQLwD2gOY+JJZQyXisygpS2ZvapFzMN725zOxnLf1i9V+4imhg9U0VxvZtn9wZN/+h d23eSVZRnG+AxhiU5GeZHg78VNIA+kFfmUbUY= 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=kD3SftFKSPiHGwPLKFXtC37EUwVdoG4pj85vCDGSqackSKcMcAZeo5wk2eJWxJ9KLP C+0nXwTXK2QT24xDreiQLl/9U9fcSYnN7sX+rRN1du+x7innZa89V1+bnlE8j1UWfyp7 TIQBuJfG02JsYID8dyt90PTwje/STe/qKIKSA= Received: by 10.42.146.70 with SMTP id i6mr6907401icv.361.1301770797319; Sat, 02 Apr 2011 11:59:57 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id mv26sm2382323ibb.28.2011.04.02.11.59.55 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Apr 2011 11:59:56 -0700 (PDT) Message-ID: <4D977259.2090307@gmail.com> Date: Sat, 02 Apr 2011 12:00:41 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: <4D97426B.8010302@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 18:58:18 -0000 Again, you assumed too much and narrowed it down too some straw-man argument of UUID only. There are many ways to cache. SNOW-375 has the functionality for hash-based, if you want to further the public/private implementation of URIs. The functionality for private-URI being based on public URIs (as documented) is just cache and redirect, not much different from hash-based as you describe. I just haven't implemented login option create a digest for private URIs (as noted in the documentation section about "feature freeze"). Purposely waited... (and I'm in multi-point/multi-client/full-duplex/anti-exploit mindset )... ...and waited... Despite my reasons to wait and do other things, open virtual worlds vs legacy... I'll lean more towards organic and analog based types then identical assets, especially if virtual worlds include real world peripherals. Morgaine wrote: > Hash-based addressing is very different to UUID-based addressing as > used in SNOW-375, so I expect there is some misunderstanding of how > hash digests are applied in this scheme, > > The universal address of the item is the hash digest over the data of > the item using a specified digest algorithm, and is not a UUID. It is > invariant regardless of who computes it, although it would normally be > computed only once by the asset service at the time that the item is > being stored in the service. All asset services everywhere will use > the same digest as an address for this item, because the digest > algorithm is specified. > > Data that is addressed and indexed in this way can of course be used > in a REST architecture with appropriate design, but because hash > digests are not UUIDs, there is quite a different semantic to it. A > UUID cannot be used as a shared cache index in a multi-world > architecture, because identical content in N different worlds will > have different UUIDs associated with it in each world. In contrast, > identical content in N different worlds will have an identical hash in > every world, and therefore only a single storage entry is needed in a > multi-world cache. > > The effect of this is dramatic. Every time that an Object ARchive is > loaded to populate a new region, this can generate another several > hundred thousand (and soon, millions) of new assets which in a > UUID-addressed scheme will typically just grow the asset storage > without bound. In a hash-addressed scheme, that OAR can be loaded a > million times and the asset data storage doesn't increase by 1 byte, > neither in the asset server, the region, nor in client caches. Only > metadata storage need grow for repeated assets in asset services, but > it's not even needed in client-side caches, so the benefits are huge. > > A nice mental image that really brings this home is that of grass > patches and trees and other common environmental objects reused in > countless worlds across the metaverse, yet requiring no downloads at > all as you tour around the worlds because visiting just one world has > populated your persistent cache with those common items already. > > This can represents storage savings of thousands or even millions to > 1, and corresponding time savings too because the remote fetches from > asset services are avoided entirely. The impact of this scheme on > user experience can be expected to be outstanding even in today's > humble beginnings, and much more so as the metaverse blooms. It's the > scheme with the best performance and scalability of any we have > examined so far. > > UUID-based asset storage does not have these excellent properties, nor > the other advantages that I have described previously. > > > Morgaine. > > > > > > ===================== > > On Sat, Apr 2, 2011 at 4:36 PM, Dzonatas Sol > wrote: > > Your hash/digest method is similar to basic REST and what I > already implemented. Icesphere already has implementations and > methods and even furthers them with burst modes so where there is > no worry to have a URI for each asset. The URI can specify a list > of assets or single asset (content varies as such), which can be > returned immediately or when each is ready for transfer, > individually. Uses LLIDL with proposed changes: > > Everything is documented here: > http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Inventory > (Last edited that doc in August 2010 & Icesphere's implementation > has been used for awhile since then) > > > > Morgaine wrote: > > Back in September 2010, I wrote this post which proposes that > we use in VWRAP a form of asset addressing that provides > massive scalability at the same time as a very high degree of > resilience -- > http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html > .� It is based on the concept of the URI containing a host > part and a hash part, where the hash is generated (once, at > the time of storage to the asset service) using a specified > digest algorithm over the content of the asset being > referenced.� You may wish to note that if this design were > used, the failure of an asset service to deliver a requested > item would result in a failover request for the item to one or > more backup services, using the same hash part but with a > different host address. > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Sat Apr 2 12:14:18 2011 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 DC9E03A63D2 for ; Sat, 2 Apr 2011 12:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4eN3uTgG--P for ; Sat, 2 Apr 2011 12:14:17 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id BC9E53A63EC for ; Sat, 2 Apr 2011 12:14:16 -0700 (PDT) Received: by qwg5 with SMTP id 5so3164064qwg.31 for ; Sat, 02 Apr 2011 12:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=irp+AeFGo5bZ7V87d+W16mNV3nMxD9CHawCP0ThzwuQ=; b=vXforbXye54uoutmE7kuHu7Y7e7R1QUUO52DzNiRyDReeh7ePdVuixD7IIeiQhLCiX gpUSZL1r/Gv3eOqGxaj/TtAlWRcNXe/n47eTcjzCaVq8gh7ALehJVGX3pe6ko93kMKsa n2vvA/R3b6qwqrhBgSw0xifIg2T8leWkNpIn4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=PETr/QnFl3T0lLUxYRPxEFDvS34hgNDOWapkgQ0phqfzeQ8dxHlDCNAdWXcmZBTesu vW6dlP5NXytByLjo0/FoEQq4VhXv4mKV1tX5fX7+ZkLvEgHjzxBLWDAN8KZFPO82e+B3 jKebQJ5DASqNiqD+zXhnXT/ymnFvOr5kYTf8A= MIME-Version: 1.0 Received: by 10.229.124.145 with SMTP id u17mr4568440qcr.71.1301771757503; Sat, 02 Apr 2011 12:15:57 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sat, 2 Apr 2011 12:15:57 -0700 (PDT) In-Reply-To: <4D977259.2090307@gmail.com> References: <4D97426B.8010302@gmail.com> <4D977259.2090307@gmail.com> Date: Sat, 2 Apr 2011 20:15:57 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd25cae2f4500049ff45b2b Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 19:14:19 -0000 --000e0cd25cae2f4500049ff45b2b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have no doubt that you *could* adapt SNOW-375 to hash-based addressing, but that is not what SNOW-375 currently describes, so the point is moot. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Sat, Apr 2, 2011 at 8:00 PM, Dzonatas Sol wrote: > Again, you assumed too much and narrowed it down too some straw-man > argument of UUID only. There are many ways to cache. > > SNOW-375 has the functionality for hash-based, if you want to further the > public/private implementation of URIs. The functionality for private-URI > being based on public URIs (as documented) is just cache and redirect, no= t > much different from hash-based as you describe. I just haven't implemente= d > login option create a digest for private URIs (as noted in the documentat= ion > section about "feature freeze"). Purposely waited... (and I'm in > multi-point/multi-client/full-duplex/anti-exploit mindset )... > > ...and waited... > > Despite my reasons to wait and do other things, open virtual worlds vs > legacy... > > I'll lean more towards organic and analog based types then identical > assets, especially if virtual worlds include real world peripherals. > > > Morgaine wrote: > >> Hash-based addressing is very different to UUID-based addressing as used >> in SNOW-375, so I expect there is some misunderstanding of how hash dige= sts >> are applied in this scheme, >> >> The universal address of the item is the hash digest over the data of th= e >> item using a specified digest algorithm, and is not a UUID. It is invar= iant >> regardless of who computes it, although it would normally be computed on= ly >> once by the asset service at the time that the item is being stored in t= he >> service. All asset services everywhere will use the same digest as an >> address for this item, because the digest algorithm is specified. >> >> Data that is addressed and indexed in this way can of course be used in = a >> REST architecture with appropriate design, but because hash digests are = not >> UUIDs, there is quite a different semantic to it. A UUID cannot be used= as >> a shared cache index in a multi-world architecture, because identical >> content in N different worlds will have different UUIDs associated with = it >> in each world. In contrast, identical content in N different worlds wil= l >> have an identical hash in every world, and therefore only a single stora= ge >> entry is needed in a multi-world cache. >> >> The effect of this is dramatic. Every time that an Object ARchive is >> loaded to populate a new region, this can generate another several hundr= ed >> thousand (and soon, millions) of new assets which in a UUID-addressed sc= heme >> will typically just grow the asset storage without bound. In a >> hash-addressed scheme, that OAR can be loaded a million times and the as= set >> data storage doesn't increase by 1 byte, neither in the asset server, th= e >> region, nor in client caches. Only metadata storage need grow for repea= ted >> assets in asset services, but it's not even needed in client-side caches= , so >> the benefits are huge. >> >> A nice mental image that really brings this home is that of grass patche= s >> and trees and other common environmental objects reused in countless wor= lds >> across the metaverse, yet requiring no downloads at all as you tour arou= nd >> the worlds because visiting just one world has populated your persistent >> cache with those common items already. >> >> This can represents storage savings of thousands or even millions to 1, >> and corresponding time savings too because the remote fetches from asset >> services are avoided entirely. The impact of this scheme on user experi= ence >> can be expected to be outstanding even in today's humble beginnings, and >> much more so as the metaverse blooms. It's the scheme with the best >> performance and scalability of any we have examined so far. >> >> UUID-based asset storage does not have these excellent properties, nor t= he >> other advantages that I have described previously. >> >> >> Morgaine. >> >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> On Sat, Apr 2, 2011 at 4:36 PM, Dzonatas Sol > dzonatas@gmail.com>> wrote: >> >> Your hash/digest method is similar to basic REST and what I >> already implemented. Icesphere already has implementations and >> methods and even furthers them with burst modes so where there is >> no worry to have a URI for each asset. The URI can specify a list >> of assets or single asset (content varies as such), which can be >> returned immediately or when each is ready for transfer, >> individually. Uses LLIDL with proposed changes: >> >> Everything is documented here: >> >> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Inv= entory >> (Last edited that doc in August 2010 & Icesphere's implementation >> has been used for awhile since then) >> >> >> >> Morgaine wrote: >> >> Back in September 2010, I wrote this post which proposes that >> we use in VWRAP a form of asset addressing that provides >> massive scalability at the same time as a very high degree of >> resilience -- >> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >> .=EF=BF=BD It is based on the concept of the URI containing a hos= t >> part and a hash part, where the hash is generated (once, at >> the time of storage to the asset service) using a specified >> digest algorithm over the content of the asset being >> referenced.=EF=BF=BD You may wish to note that if this design wer= e >> used, the failure of an asset service to deliver a requested >> item would result in a failover request for the item to one or >> more backup services, using the same hash part but with a >> different host address. >> >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > --000e0cd25cae2f4500049ff45b2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have no doubt that you could adapt SNOW-375 to hash-based a= ddressing, but that is not what SNOW-375 currently describes, so the point = is moot.


Morgaine.




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

On Sat, Apr 2, 2011 at 8:00 PM, Dzonatas Sol= <dzonatas@gmail= .com> wrote:
Again, you assumed too much and narrowed it down too some straw-man argumen= t of UUID only. There are many ways to cache.

SNOW-375 has the functionality for hash-based, if you want to further the p= ublic/private implementation of URIs. The functionality for private-URI bei= ng based on public URIs (as documented) is just cache and redirect, not muc= h different from hash-based as you describe. I just haven't implemented= login option create a digest for private URIs (as noted in the documentati= on section about "feature freeze"). Purposely waited... =C2=A0 (a= nd I'm in multi-point/multi-client/full-duplex/anti-exploit mindset )..= .

...and waited...

Despite my reasons to wait and do other things, open virtual worlds vs lega= cy...

I'll lean more towards organic and analog based types then identical as= sets, especially if virtual worlds include real world peripherals.


Morgaine wrote:
Hash-based addressing is very different to UUID-based addressing as used in= SNOW-375, so I expect there is some misunderstanding of how hash digests a= re applied in this scheme,

The universal address of the item is the hash digest over the data of the i= tem using a specified digest algorithm, and is not a UUID. =C2=A0It is inva= riant regardless of who computes it, although it would normally be computed= only once by the asset service at the time that the item is being stored i= n the service. =C2=A0All asset services everywhere will use the same digest= as an address for this item, because the digest algorithm is specified.
Data that is addressed and indexed in this way can of course be used in a R= EST architecture with appropriate design, but because hash digests are not = UUIDs, there is quite a different semantic to it. =C2=A0A UUID cannot be us= ed as a shared cache index in a multi-world architecture, because identical= content in N different worlds will have different UUIDs associated with it= in each world. =C2=A0In contrast, identical content in N different worlds = will have an identical hash in every world, and therefore only a single sto= rage entry is needed in a multi-world cache.

The effect of this is dramatic. =C2=A0Every time that an Object ARchive is = loaded to populate a new region, this can generate another several hundred = thousand (and soon, millions) of new assets which in a UUID-addressed schem= e will typically just grow the asset storage without bound. =C2=A0In a hash= -addressed scheme, that OAR can be loaded a million times and the asset dat= a storage doesn't increase by 1 byte, neither in the asset server, the = region, nor in client caches. =C2=A0Only metadata storage need grow for rep= eated assets in asset services, but it's not even needed in client-side= caches, so the benefits are huge.

A nice mental image that really brings this home is that of grass patches a= nd trees and other common environmental objects reused in countless worlds = across the metaverse, yet requiring no downloads at all as you tour around = the worlds because visiting just one world has populated your persistent ca= che with those common items already.

This can represents storage savings of thousands or even millions to 1, and= corresponding time savings too because the remote fetches from asset servi= ces are avoided entirely. =C2=A0The impact of this scheme on user experienc= e can be expected to be outstanding even in today's humble beginnings, = and much more so as the metaverse blooms. =C2=A0It's the scheme with th= e best performance and scalability of any we have examined so far.

UUID-based asset storage does not have these excellent properties, nor the = other advantages that I have described previously.


Morgaine.





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

On Sat, Apr 2, 2011 at 4:36 PM, Dzonatas Sol <dzonatas@gmail.com <mailto:dzonatas@gmail.com>>= wrote:

=C2=A0 =C2=A0Your hash/digest method is similar to basic REST and what I =C2=A0 =C2=A0already implemented. Icesphere already has implementations an= d
=C2=A0 =C2=A0methods and even furthers them with burst modes so where ther= e is
=C2=A0 =C2=A0no worry to have a URI for each asset. The URI can specify a = list
=C2=A0 =C2=A0of assets or single asset (content varies as such), which can= be
=C2=A0 =C2=A0returned immediately or when each is ready for transfer,
=C2=A0 =C2=A0individually. Uses LLIDL with proposed changes:

=C2=A0 =C2=A0Everything is documented here:
=C2=A0 =C2=A0http://wiki.secondlife.com/= wiki/User:Dzonatas_Sol/SNOW-375_Resources/Inventory
=C2=A0 =C2=A0(Last edited that doc in August 2010 & Icesphere's im= plementation
=C2=A0 =C2=A0has been used for awhile since then)



=C2=A0 =C2=A0Morgaine wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0Back in September 2010, I wrote this post which= proposes that
=C2=A0 =C2=A0 =C2=A0 =C2=A0we use in VWRAP a form of asset addressing that= provides
=C2=A0 =C2=A0 =C2=A0 =C2=A0massive scalability at the same time as a very = high degree of
=C2=A0 =C2=A0 =C2=A0 =C2=A0resilience --
=C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/mail-ar= chive/web/vwrap/current/msg00463.html
=C2=A0 =C2=A0 =C2=A0 =C2=A0.=EF=BF=BD It is based on the concept of the UR= I containing a host
=C2=A0 =C2=A0 =C2=A0 =C2=A0part and a hash part, where the hash is generat= ed (once, at
=C2=A0 =C2=A0 =C2=A0 =C2=A0the time of storage to the asset service) using= a specified
=C2=A0 =C2=A0 =C2=A0 =C2=A0digest algorithm over the content of the asset = being
=C2=A0 =C2=A0 =C2=A0 =C2=A0referenced.=EF=BF=BD You may wish to note that = if this design were
=C2=A0 =C2=A0 =C2=A0 =C2=A0used, the failure of an asset service to delive= r a requested
=C2=A0 =C2=A0 =C2=A0 =C2=A0item would result in a failover request for the= item to one or
=C2=A0 =C2=A0 =C2=A0 =C2=A0more backup services, using the same hash part = but with a
=C2=A0 =C2=A0 =C2=A0 =C2=A0different host address.



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


------------------------------------------------------------------------

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


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


--000e0cd25cae2f4500049ff45b2b-- From dzonatas@gmail.com Sat Apr 2 12:36:22 2011 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 655103A6840 for ; Sat, 2 Apr 2011 12:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 7GOTb8enTOKg for ; Sat, 2 Apr 2011 12:36:20 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id C2E943A687B for ; Sat, 2 Apr 2011 12:36:20 -0700 (PDT) Received: by iye19 with SMTP id 19so5428278iye.31 for ; Sat, 02 Apr 2011 12:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5DZoQFfxIeRddXwjrzmhw1xJntG/AXZL668HvQlc2sA=; b=kgs1YAKo8BS8JQ+HtOWYucnGhhy4Yb9VbZ/86eqGSb45nPtRa5dScBsJyBr5Na25Fh jJTrlFEWyJUP98zp8Dc+OacMKO+P52tGmTkF5BRGETW8dvlrcX0hRN9Ee+uNV8Orvqm0 qOh11DA69R+i6rb7lZLBBHH9zTa+v/ATWOyV4= 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=A9h82so4fFXZmbYAHvIOTfv/XX8nFpvjCPdaVXgJcPs8YAq7CPHNXczlgylWXDfWzi khxyFDJvvMSKC9EcmauFSENF8mTzcdg3v3jyswNxnGoCMNc98beasG46HYBrLgBmru++ TiprHuQyLxbW6RlzpOkuYQax1xXuVvpneCra4= Received: by 10.43.134.8 with SMTP id ia8mr1461709icc.93.1301773081315; Sat, 02 Apr 2011 12:38:01 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id wo11sm2198513icb.20.2011.04.02.12.37.59 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Apr 2011 12:38:00 -0700 (PDT) Message-ID: <4D977B45.4000703@gmail.com> Date: Sat, 02 Apr 2011 12:38:45 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: <4D97426B.8010302@gmail.com> <4D977259.2090307@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 19:36:22 -0000 I have no doubt that people could publish how, where, and why exploits exist, yet most of these are obvious (or become obvious) when keen-enough peeps actually implement (and even re-implement) those ideas that sound great on paper with reasons given (limited from real world execution). Moot? "Use-cases are under review..." -- http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375#Resources_.26_Capabilities Of course, I'm not gonna describe how, where, and why... nor further implement such obvious exploits. I'm surprised for how much you argued about trust and security. Yes, I could expand the URI lookup cache to handle security by obscurity. Ok, moot point now. Morgaine wrote: > I have no doubt that you /*could*/ adapt SNOW-375 to hash-based > addressing, but that is not what SNOW-375 currently describes, so the > point is moot. > > > Morgaine. > > > > > ===================== > > On Sat, Apr 2, 2011 at 8:00 PM, Dzonatas Sol > wrote: > > Again, you assumed too much and narrowed it down too some > straw-man argument of UUID only. There are many ways to cache. > > SNOW-375 has the functionality for hash-based, if you want to > further the public/private implementation of URIs. The > functionality for private-URI being based on public URIs (as > documented) is just cache and redirect, not much different from > hash-based as you describe. I just haven't implemented login > option create a digest for private URIs (as noted in the > documentation section about "feature freeze"). Purposely waited... > (and I'm in multi-point/multi-client/full-duplex/anti-exploit > mindset )... > > ...and waited... > > Despite my reasons to wait and do other things, open virtual > worlds vs legacy... > > I'll lean more towards organic and analog based types then > identical assets, especially if virtual worlds include real world > peripherals. > > > Morgaine wrote: > > Hash-based addressing is very different to UUID-based > addressing as used in SNOW-375, so I expect there is some > misunderstanding of how hash digests are applied in this scheme, > > The universal address of the item is the hash digest over the > data of the item using a specified digest algorithm, and is > not a UUID. It is invariant regardless of who computes it, > although it would normally be computed only once by the asset > service at the time that the item is being stored in the > service. All asset services everywhere will use the same > digest as an address for this item, because the digest > algorithm is specified. > > Data that is addressed and indexed in this way can of course > be used in a REST architecture with appropriate design, but > because hash digests are not UUIDs, there is quite a different > semantic to it. A UUID cannot be used as a shared cache index > in a multi-world architecture, because identical content in N > different worlds will have different UUIDs associated with it > in each world. In contrast, identical content in N different > worlds will have an identical hash in every world, and > therefore only a single storage entry is needed in a > multi-world cache. > > The effect of this is dramatic. Every time that an Object > ARchive is loaded to populate a new region, this can generate > another several hundred thousand (and soon, millions) of new > assets which in a UUID-addressed scheme will typically just > grow the asset storage without bound. In a hash-addressed > scheme, that OAR can be loaded a million times and the asset > data storage doesn't increase by 1 byte, neither in the asset > server, the region, nor in client caches. Only metadata > storage need grow for repeated assets in asset services, but > it's not even needed in client-side caches, so the benefits > are huge. > > A nice mental image that really brings this home is that of > grass patches and trees and other common environmental objects > reused in countless worlds across the metaverse, yet requiring > no downloads at all as you tour around the worlds because > visiting just one world has populated your persistent cache > with those common items already. > > This can represents storage savings of thousands or even > millions to 1, and corresponding time savings too because the > remote fetches from asset services are avoided entirely. The > impact of this scheme on user experience can be expected to be > outstanding even in today's humble beginnings, and much more > so as the metaverse blooms. It's the scheme with the best > performance and scalability of any we have examined so far. > > UUID-based asset storage does not have these excellent > properties, nor the other advantages that I have described > previously. > > > Morgaine. > > > > > > ===================== > > On Sat, Apr 2, 2011 at 4:36 PM, Dzonatas Sol > > >> wrote: > > Your hash/digest method is similar to basic REST and what I > already implemented. Icesphere already has implementations and > methods and even furthers them with burst modes so where > there is > no worry to have a URI for each asset. The URI can specify > a list > of assets or single asset (content varies as such), which > can be > returned immediately or when each is ready for transfer, > individually. Uses LLIDL with proposed changes: > > Everything is documented here: > > http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Inventory > (Last edited that doc in August 2010 & Icesphere's > implementation > has been used for awhile since then) > > > > Morgaine wrote: > > Back in September 2010, I wrote this post which > proposes that > we use in VWRAP a form of asset addressing that provides > massive scalability at the same time as a very high > degree of > resilience -- > > http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html > .� It is based on the concept of the URI containing a host > part and a hash part, where the hash is generated (once, at > the time of storage to the asset service) using a specified > digest algorithm over the content of the asset being > referenced.� You may wish to note that if this design were > used, the failure of an asset service to deliver a > requested > item would result in a failover request for the item to > one or > more backup services, using the same hash part but with a > different host address. > > > > -- --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, > Consultant > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Sat Apr 2 12:56:53 2011 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 EEF223A688C for ; Sat, 2 Apr 2011 12:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 ZW8WNSiI48cG for ; Sat, 2 Apr 2011 12:56:49 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 8FC4E3A688A for ; Sat, 2 Apr 2011 12:56:48 -0700 (PDT) Received: by qyk7 with SMTP id 7so2937558qyk.10 for ; Sat, 02 Apr 2011 12:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CHB3QmC1KsuhCx+Oq9ed1CG5z9LsJfOGB43AUFJHz1w=; b=hOOOEdsfG0JMkfgw66bIGnL/sKRf4LbHL1dm/sAZWhouCLCYlIAf/ClhJ+IVzE0uYH zlE4R1lWU+THKZENXJOlpMRTF03ouabiTTuHzw0YlCEf9uJa6hJiKbid8EVfll9mqT+U ErTcC70Fhl07yVMOaHA1KAzY7R80WT1upn8qA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nx2HioC8ea1uTVelWkXz9IhTo+QOOacrfklRs7ZnpOMZOQxz+qGZlKociGKJkArRr5 3Vu/V0+k8sKz+ZqoqaBsPY+cSespkgN3hBJvr6BIJoFtqfSS+wYyn24Ld5hFVJFTztU6 XB8L2uHbzTsMhrU/0fTBr/F/uZfhBirT3Sak4= MIME-Version: 1.0 Received: by 10.229.37.130 with SMTP id x2mr4537945qcd.147.1301774309338; Sat, 02 Apr 2011 12:58:29 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sat, 2 Apr 2011 12:58:29 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Apr 2011 20:58:29 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016368340c049300b049ff4f33a Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 19:56:53 -0000 --0016368340c049300b049ff4f33a Content-Type: text/plain; charset=ISO-8859-1 Izzy, when designing for scalability, the model to bear in mind is that of seasoned virtual world travelers whose inventories contain assets from many different worlds, those assets being served by many different asset services. Both worlds and asset services may include commercial, community, and personal services, and as the metaverse grows, that set is highly likely to become progressively less clustered and more diverse. When those seasoned travelers click on an advertised VW link and perform an inter-world teleport to one particular world's region to share an experience, their "worn" assets (the only ones of interest to the region) will contain references to asset services spread widely across the Internet. The fetches by the travelers' clients occur over many parallel paths from clients to asset services, so one can reasonably expect reduced network contention and reduced asset server loading because they are both spread out over however many asset services are being referenced by the overall set of assets in the region. This is very different to the case of a proxying region, which would get slammed for every asset worn by every avatar present. In our current architecture, regions run many different CPU-intensive tasks, including physics simulation and server-side scripting, and absolutely cannot afford to serve assets too unless your scalability requirements are very low indeed, ie. just a few dozen avatars of today's kind. We've hit the ceiling already on region scalability done that way. There is nowhere to go in that direction at all beyond improving the code like Intel demonstrated, and that work is subject to a law of diminishing returns. This is why we have to go parallel, and I think you're wrong that it has to cost much money. As we spread the load across more and more asset services, we are simply better utilizing all the hardware that's already out there on the Internet, at least in respect of community and private resources. But add to the community and private resources the commercial asset services that are likely to appear to exploit this opportunity, and not only will the number of asset services leap, but the power of each one will rocket too, because, after all, these businesses will be heavily optimized for the job. As to why a world would want clients to access external asset services instead of providing its own implementation, that's an easy question. It costs money to host a high performance and scalable asset service and a high bandwidth network to handle the traffic. A *lot* of money. In contrast, it costs a world nothing to let others serve the assets to clients. And that matters to the bottom line. Morgaine. ====================== On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis wrote: > > As always though, it's a trade-off, since the proxied design has very > poor scalability compared to the distributed one. > > I don't agree with that... If a user enters a highly populated region, > every other client is going to (could and should be trying to) hit the > asset server(s) for the assets that the user is wearing (assuming > they're not cached locally). Every asset server has to be scaled up > to the point that it can handle that load from all over... > > If I'm hosting a region that supports 10s of thousands of simultaneous > users (thinking of the future), I already have to scale to meet that > demand. If the region is proxying the assets, then, yes the region has > to be scaled to meet that asset demand too, but it already has to be > scaled to meet other demands of being a region server... and why is > scaling those asset proxy services hard? It's going to cost $, but is > not technically challenging. So, if I want to host a region like > that... sure it will cost me, but the simulation will be consistent > and users will be able to participate equally, regardless of the > capabilities of their individual asset services. > > > > > On Fri, Apr 1, 2011 at 11:55 PM, Morgaine > wrote: > > Every design choice results in a trade-off, Vaughn, improving one thing > at > > the expense of something else. If every time we offered a service we had > to > > inform its users about the downsides of all the trade-offs we have made, > > they would have an awful lot to read. ;-) > > > > The specific trade-off that you are discussing is no different. A region > > that proxies all content has the "benefit" of acquiring control from the > > asset servers over the items in the region, so that it can ensure that > > everyone in the region not only obtains the items but obtains the same > items > > as everyone else. That does indeed provide a greater guarantee of > > consistency than a deployment in which the region only passes asset URIs > to > > clients who then fetch the items from asset services separately. As > always > > though, it's a trade-off, since the proxied design has very poor > scalability > > compared to the distributed one. > > > > If we're going to warn users of the potential for inconsistency in the > > distributed deployment as you suggest, are we also going to warn them of > > non-scalability in the proxied one? I really don't see much merit in the > > idea of warning about design choices. Many such choices are technical, > and > > the issues are quite likely to be of little interest to non-technical > users > > anyway. In any case, the better services are likely to provide such > > information in their online documentation, I would guess. > > > > You mentioned users "voting with their feet" or choosing to accept the > risk > > of inconsistency. Well that will happen anyway, when services fail and > > users get annoyed. If some asset services refuse to send the requested > > items to some users, those services will get a bad reputation and people > > will choose different asset services instead. Likewise, if a world > service > > proxies everything and so it can't handle a large number of assets or of > > people, users will get annoyed at the lag and will go elsewhere. This > user > > evaluation and "voting with their feet" happens already with online > services > > all over the Internet, and I am sure that this human process will > continue > > to work when the services are asset and region services. > > > > Back in September 2010, I wrote this post which proposes that we use in > > VWRAP a form of asset addressing that provides massive scalability at the > > same time as a very high degree of resilience -- > > http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html . It > is > > based on the concept of the URI containing a host part and a hash part, > > where the hash is generated (once, at the time of storage to the asset > > service) using a specified digest algorithm over the content of the asset > > being referenced. You may wish to note that if this design were used, > the > > failure of an asset service to deliver a requested item would result in a > > failover request for the item to one or more backup services, using the > same > > hash part but with a different host address. > > > > This can go some way towards overcoming the problem that you think might > > occur when assets are fetched by clients from asset services directly. > > Although it won't help when the missing item is available from only a > single > > asset service, it will help in many other cases, and it will compensate > for > > service failures and network outages automatically at the same time. > > > > PS. This design for hash-based asset addressing is already being tested > by > > Mojito Sorbet in her experimental world and client. It would give > > VWRAP-based worlds an improved level of service availability, so I think > it > > should be a core feature of our protocol. > > > > > > Morgaine. > > > > > > > > > > =========================== > > > > On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca > > wrote: > >> > >> This is a question i discussed with Morgaine off-list a while ago (I > >> intended to send it to the list but pushed the wrong button...) I > >> think we need to address this problem, and decide how to deal with it. > >> > >> In Davids deployment draft, section 7.3.1.1 an overview is given van > >> ways to deliver content to the region. One way is only passing a > >> capability that allows access to (part of) the resource: > >> > >> 7.3.1.1. Content delivery models > >> A range of possible represenations can be passed to a region > for > >> simulation. [...] The other end of the delivery spectrum > >> involves passing > >> only a URI or capability used to access the rendering > >> information and a > >> collision mesh,and related data for physical simulation. > >> In such a model, the client is responsible for fetching the > >> additional > >> information needed to render the item's visual presence from a > >> separate > >> service. This fetch can be done *under the credentials of the > >> end user* > >> viewing the material [my emphasis--VD] , and divorces the > >> simulation from > >> the trust chain needed to manage content. Any automation > >> is done on a > >> separate host which the content creator or owner trusts, > >> interacting with the > >> object through remoted interfaces. > >> > >> I can see the need for such a setup, however, i feel we are > >> unpleasantly close to a situation were the coherence of the simulation > >> falls apart. > >> In this deployment pattern the region advertises the presence of the > >> asset, and *some* clients will be able to get it as expected, while > >> -based on the arbitrary whims of the asset service- others might not. > >> > >> My hope would be that after the asset server provides the region with > >> the capability to get the asset, it gives up control. That would mean > >> that if the client finds the inventory server is unwilling to serve > >> the content - in spire of the region saying it is present-, the client > >> should be able to turn around ask the *region* for the asset, (and get > >> is after all). > >> > >> If that is not the case, -and there are probably good reasons for the > >> deployment pattern as described- shouldn't we *warn* clients that the > >> region might be inconsistent, so the users behind the client can vote > >> with their feet, (or take the risk)? > >> > >> --Vaughn > >> _______________________________________________ > >> 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 > > > > > --0016368340c049300b049ff4f33a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Izzy, when designing for scalability, the model to bear in mind is that of = seasoned virtual world travelers whose inventories contain assets from many= different worlds, those assets being served by many different asset servic= es.=A0 Both worlds and asset services may include commercial, community, an= d personal services, and as the metaverse grows, that set is highly likely = to become progressively less clustered and more diverse.

When those seasoned travelers click on an advertised VW link and perfor= m an inter-world teleport to one particular world's region to share an = experience, their "worn" assets (the only ones of interest to the= region) will contain references to asset services spread widely across the= Internet.=A0 The fetches by the travelers' clients occur over many par= allel paths from clients to asset services, so one can reasonably expect re= duced network contention and reduced asset server loading because they are = both spread out over however many asset services are being referenced by th= e overall set of assets in the region.

This is very different to the case of a proxying region, which would ge= t slammed for every asset worn by every avatar present.=A0 In our current a= rchitecture, regions run many different CPU-intensive tasks, including phys= ics simulation and server-side scripting, and absolutely cannot afford to s= erve assets too unless your scalability requirements are very low indeed, i= e. just a few dozen avatars of today's kind.=A0 We've hit the ceili= ng already on region scalability done that way.=A0 There is nowhere to go i= n that direction at all beyond improving the code like Intel demonstrated, = and that work is subject to a law of diminishing returns.

This is why we have to go parallel, and I think you're wrong that i= t has to cost much money.=A0 As we spread the load across more and more ass= et services, we are simply better utilizing all the hardware that's alr= eady out there on the Internet, at least in respect of community and privat= e resources.=A0 But add to the community and private resources the commerci= al asset services that are likely to appear to exploit this opportunity, an= d not only will the number of asset services leap, but the power of each on= e will rocket too, because, after all, these businesses will be heavily opt= imized for the job.

As to why a world would want clients to access external asset services = instead of providing its own implementation, that's an easy question.= =A0 It costs money to host a high performance and scalable asset service an= d a high bandwidth network to handle the traffic.=A0 A lot of money.= =A0 In contrast, it costs a world nothing to let others serve the assets to= clients.=A0 And that matters to the bottom line.


Morgaine.




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

On Sat, Ap= r 2, 2011 at 7:05 PM, Izzy Alanis <izzyalanis@gmail.com> = wrote:
> As always though, it's a trade-off, since the proxied design = has very poor scalability compared to the distributed one.

I don't agree with that... If a user enters a highly populated re= gion,
every other client is going to (could and should be trying to) hit the
asset server(s) for the assets that the user is wearing (assuming
they're not cached locally). =A0Every asset server has to be scaled up<= br> to the point that it can handle that load from all over...

If I'm hosting a region that supports 10s of thousands of simultaneous<= br> users (thinking of the future), I already have to scale to meet that
demand. If the region is proxying the assets, then, yes the region has
to be scaled to meet that asset demand too, but it already has to be
scaled to meet other demands of being a region server... and why is
scaling those asset proxy services hard? =A0It's going to cost $, but i= s
not technically challenging. So, if I want to host a region like
that... sure it will cost me, but the simulation will be consistent
and users will be able to participate equally, regardless of the
capabilities of their individual asset services.




On Fri, Apr 1, 2011 at 11:55 PM, Morgaine
> Every design choice results in a trade-off,= Vaughn, improving one thing at
> the expense of something else.=A0 If every time we offered a service w= e had to
> inform its users about the downsides of all the trade-offs we have mad= e,
> they would have an awful lot to read. ;-)
>
> The specific trade-off that you are discussing is no different.=A0 A r= egion
> that proxies all content has the "benefit" of acquiring cont= rol from the
> asset servers over the items in the region, so that it can ensure that=
> everyone in the region not only obtains the items but obtains the same= items
> as everyone else.=A0 That does indeed provide a greater guarantee of > consistency than a deployment in which the region only passes asset UR= Is to
> clients who then fetch the items from asset services separately.=A0 As= always
> though, it's a trade-off, since the proxied design has very poor s= calability
> compared to the distributed one.
>
> If we're going to warn users of the potential for inconsistency in= the
> distributed deployment as you suggest, are we also going to warn them = of
> non-scalability in the proxied one?=A0 I really don't see much mer= it in the
> idea of warning about design choices.=A0 Many such choices are technic= al, and
> the issues are quite likely to be of little interest to non-technical = users
> anyway.=A0 In any case, the better services are likely to provide such=
> information in their online documentation, I would guess.
>
> You mentioned users "voting with their feet" or choosing to = accept the risk
> of inconsistency.=A0 Well that will happen anyway, when services fail = and
> users get annoyed.=A0 If some asset services refuse to send the reques= ted
> items to some users, those services will get a bad reputation and peop= le
> will choose different asset services instead.=A0 Likewise, if a world = service
> proxies everything and so it can't handle a large number of assets= or of
> people, users will get annoyed at the lag and will go elsewhere.=A0 Th= is user
> evaluation and "voting with their feet" happens already with= online services
> all over the Internet, and I am sure that this human process will cont= inue
> to work when the services are asset and region services.
>
> Back in September 2010, I wrote this post which proposes that we use i= n
> VWRAP a form of asset addressing that provides massive scalability at = the
> same time as a very high degree of resilience --
> http://www.ietf.org/mail-archive/web/vwrap/current= /msg00463.html .=A0 It is
> based on the concept of the URI containing a host part and a hash part= ,
> where the hash is generated (once, at the time of storage to the asset=
> service) using a specified digest algorithm over the content of the as= set
> being referenced.=A0 You may wish to note that if this design were use= d, the
> failure of an asset service to deliver a requested item would result i= n a
> failover request for the item to one or more backup services, using th= e same
> hash part but with a different host address.
>
> This can go some way towards overcoming the problem that you think mig= ht
> occur when assets are fetched by clients from asset services directly.=
> Although it won't help when the missing item is available from onl= y a single
> asset service, it will help in many other cases, and it will compensat= e for
> service failures and network outages automatically at the same time. >
> PS. This design for hash-based asset addressing is already being teste= d by
> Mojito Sorbet in her experimental world and client.=A0 It would give > VWRAP-based worlds an improved level of service availability, so I thi= nk it
> should be a core feature of our protocol.
>
>
> Morgaine.
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
>
> On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca <vaughn.deluca@gmail.com> > wrote:
>>
>> This is a question i discussed with Morgaine off-list a while ago = (I
>> intended to send it to the list but pushed the wrong button...) I<= br> >> think we need to address this problem, and decide how to deal with= it.
>>
>> =A0In Davids deployment draft, section 7.3.1.1 an overview is give= n van
>> ways to deliver content to the region. One way is only passing a >> capability that allows access to (part of) the resource:
>>
>> =A0 =A0 =A0 =A0 =A0 7.3.1.1. =A0Content delivery models
>> =A0 =A0 =A0 =A0 =A0 A range of possible represenations can be pass= ed to a region for
>> =A0 =A0 =A0 =A0 =A0 simulation. [...] The other end of the deliver= y spectrum
>> involves passing
>> =A0 =A0 =A0 =A0 =A0 only a URI or capability used to access the re= ndering
>> information and a
>> =A0 =A0 =A0 =A0 =A0 collision mesh,and related data for physical s= imulation.
>> =A0 =A0 =A0 =A0 =A0 In such a model, the client is responsible for= fetching the
>> additional
>> =A0 =A0 =A0 =A0 =A0 information needed to render the item's vi= sual presence from a
>> separate
>> =A0 =A0 =A0 =A0 =A0 service. =A0This fetch can be done *under the = credentials of the
>> end user*
>> =A0 =A0 =A0 =A0 =A0 viewing the material [my emphasis--VD] , and d= ivorces the
>> simulation from
>> =A0 =A0 =A0 =A0 =A0 the trust chain needed to manage content. =A0A= ny automation
>> is done on a
>> =A0 =A0 =A0 =A0 =A0 separate host which the content creator or own= er trusts,
>> interacting with the
>> =A0 =A0 =A0 =A0 =A0 object through remoted interfaces.
>>
>> =A0I can see the need for such a setup, however, i feel we are
>> unpleasantly close to a situation were the coherence of the simula= tion
>> falls apart.
>> In this deployment pattern the region advertises the presence of t= he
>> asset, and *some* clients will be able to get it as expected, whil= e
>> -based on the arbitrary whims of the asset service- others might n= ot.
>>
>> My hope would be that after the asset server provides the region w= ith
>> the capability to get the asset, it gives up control. That would m= ean
>> that if the client finds the inventory server is unwilling to serv= e
>> the content - in spire of the region saying it is present-, the cl= ient
>> should be able to turn around ask the *region* for the asset, (and= get
>> is after all).
>>
>> =A0If that is not the case, -and there are probably good reasons f= or the
>> deployment pattern as described- =A0shouldn't we *warn* client= s that the
>> region might be inconsistent, so the users behind the client can v= ote
>> with their feet, (or take the risk)?
>>
>> --Vaughn
>> _______________________________________________
>> 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
>
>

--0016368340c049300b049ff4f33a-- From morgaine.dinova@googlemail.com Sat Apr 2 13:10:52 2011 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 6975A3A68A9 for ; Sat, 2 Apr 2011 13:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.842 X-Spam-Level: X-Spam-Status: No, score=-2.842 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RofHoCzp0GxC for ; Sat, 2 Apr 2011 13:10:49 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 1E39E3A68A2 for ; Sat, 2 Apr 2011 13:10:49 -0700 (PDT) Received: by qyk29 with SMTP id 29so297094qyk.10 for ; Sat, 02 Apr 2011 13:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Nx/Og/NvOfVSNOn1QcP1pRsbG2DBvXbfI/ZnSDcS2Pw=; b=u9mT4NcvgznRsT1BMR3d/kRv9M2DeyCwP+QwHSF3eov/1UxAJJZ8OKy3kTrSGKoyrS Oop7tsxjfJ2LCUiDRqUB7n6PfIGBSvgauu0/akQN2lWudIFX4Fe0h4Btx7+jGofYDrn6 hlJfkFc6yTyOmjSVRALNkVCIDUK/KQAYIG3SM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Q0172ENMtzIYCCerXaL4xKeayt2cVX9A+25y1Y8cAlFH5la42cxw5QmHQVR3i/iFdu Mf5iYaJChZBx47SBWCnnIkMX4R8Ab6AZY8+DoBB4YRKahqfK0xgArsBB3OUNEZ0xjKBD tST15QqE7y1+pd3nDrjvzM/HpfC6X8j0/3Zds= MIME-Version: 1.0 Received: by 10.229.78.22 with SMTP id i22mr2001241qck.33.1301775150012; Sat, 02 Apr 2011 13:12:30 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sat, 2 Apr 2011 13:12:29 -0700 (PDT) In-Reply-To: <20110402190853.7c525764@hikaru.localdomain> References: <20110402190853.7c525764@hikaru.localdomain> Date: Sat, 2 Apr 2011 21:12:29 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00235429d8f464db6b049ff525bb Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 20:10:52 -0000 --00235429d8f464db6b049ff525bb Content-Type: text/plain; charset=ISO-8859-1 You've provided a nice use case for client-side scripting there, Carlo. :-) Indeed, your client could catch the error response code and switch worn assets around in whichever way you wish to program or configure, and resubmit the TP request transparently. Lots of interesting possibilities there. Morgaine. ==================== On Sat, Apr 2, 2011 at 6:08 PM, Carlo Wood wrote: > On Sat, 2 Apr 2011 16:09:49 +0100 > Morgaine wrote: > > That easily maps to an optional capability request of course. If the > > asset service answers "No" to you, then you can deny the incoming > > avatar entry to your region, returning a status that indicates > > > > RESPONSE: "*Asset service X referenced by asset Y does not meet the > > re-distribution requirement requested for entry to region Z*". > > At which point, as a user, I'd like to have the option to > detach / take off (replace) whatever I'm using from asset > service X, rather than to completely be banned from entering > the region. If the result is that I look aweful, then the > only requirement I have is that I see the same thing as > others, after I can I make the decision to either avoid using > asset server Y for future purchases, or to avoid entering > this region. > > -- > Carlo Wood > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --00235429d8f464db6b049ff525bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You've provided a nice use case for client-side scripting there, Carlo.= :-)

Indeed, your client could catch the error response code and swi= tch worn assets around in whichever way you wish to program or configure, a= nd resubmit the TP request transparently.=A0 Lots of interesting possibilit= ies there.


Morgaine.




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

On Sat, Apr 2, 2= 011 at 6:08 PM, Carlo Wood <carlo@alinoe.com> wrote:
On Sat, 2 Apr 201= 1 16:09:49 +0100
Morgaine <morgaine.dinova@googlemail.com> wrote:
> That easily maps to an optional capability req= uest of course. =A0If the
> asset service answers "No" to you, then you can deny the inc= oming
> avatar entry to your region, returning a status that indicates
>
> RESPONSE: "*Asset service X referenced by asset Y does not meet t= he
> re-distribution requirement requested for entry to region Z*&quo= t;.

At which point, as a user, I'd like to have the option to
detach / take off (replace) whatever I'm using from asset
service X, rather than to completely be banned from entering
the region. =A0If the result is that I look aweful, then the
only requirement I have is that I see the same thing as
others, after I can I make the decision to either avoid using
asset server Y for future purchases, or to avoid entering
this region.

--
Carlo Wood <carlo@alinoe.com>
___________________________________= ____________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--00235429d8f464db6b049ff525bb-- From dyerbrookme@juno.com Sat Apr 2 13:11:47 2011 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 56A733A68AA for ; Sat, 2 Apr 2011 13:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.772 X-Spam-Level: X-Spam-Status: No, score=-2.772 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 WPKAVVZ-65zH for ; Sat, 2 Apr 2011 13:11:32 -0700 (PDT) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 4680A3A68A2 for ; Sat, 2 Apr 2011 13:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juno.com; s=alpha; t=1301775191; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; l=0; h=From:Date:To:Cc:Subject:Message-Id:Content-Type; b=RqAX/uk2JBm9nv8z3RulnjCOmOqrDbbVO1Z6ZYvl/Ks4eBcCo7YgXBq5TlNv4gF1d p0At9NsCyXgtmg7xDTVgPOolLZGNPpoBzbo0ZHywHPBQgYICRcPbz7kz5nxy23ynj0 /i2MyVqpzfGC+u6AOS5XBAN8hvZn+O71K8UW/In4= X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail07.vgs.untd.com [10.181.12.147]) by smtpout02.vgs.untd.com with SMTP id AABG3RA4CAF4G7TS for (sender ); Sat, 2 Apr 2011 13:12:50 -0700 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucf6HyplTnjJhGNruM8uj+MIpHjhETcs0lg== Received: (from dyerbrookme@juno.com) by webmail07.vgs.untd.com (jqueuemail) id Q7WLLNBR; Sat, 02 Apr 2011 13:12:44 PDT Received: from [173.52.3.243] by webmail07.vgs.untd.com with HTTP: Sat, 2 Apr 2011 20:12:42 GMT X-Originating-IP: [173.52.3.243] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sat, 2 Apr 2011 20:12:42 GMT To: djshag@hotmail.com X-Mailer: Webmail Version 6.1_P2 Message-Id: <20110402.161242.14055.0@webmail07.vgs.untd.com> Content-Type: multipart/alternative;boundary="--__JWM__J5cc3.6bbfS.7958M" X-UNTD-BodySize: 34987 X-ContentStamp: 1:1:3619582741 X-MAIL-INFO: 48654500451d6d01413c010ce1a5c925694d0d0d15d5a1cc19ac25797985652908cc65ec7805d5002d281d08794c4c6d79398df9584c413d3d61c988b5715c694dc1f1891cf11c09895d5dac85d811add9bcd99df8c859f89518187159b14869c19108f84df12d0959891d4c493c1d2c6985589935e81c5ded9c0d8c31ec7c05f52d017c5c4c4cb1391895f5a93895a9c8c8ddf8f821ed317561e1a5b9e1b5317c5868b9b8317cbc85ad1cad11d8dcf518add9912c3cbcd1f11871955971c1c9c1612cc15d69e800b51cc5d5a828714df155acecbc15ec2578e50d850d7d191d59c9250c1dbdd5bdc82145a521d13c2cbd X-UNTD-Peer-Info: 10.181.12.147|webmail07.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 20:11:47 -0000 ----__JWM__J5cc3.6bbfS.7958M Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 Dear Patnad, I post on this list about twice a year. My post is not a ra= nt, it is not a flame, it is not a troll, it is not a personal attack. T= hese are all specious characterizations that are politically-motivated. = I'm not the one "flaming" here; those who feel the need to "set me strai= ght" are the "flamers" -- although such petty notions as "trolling" and = "flaming" really should have been left at the back door of the Well 20 y= ears ago, if not at the gate of war game forums 15 years ago. They are n= otions merely used to silence critics and discredit dissidents. Carlo us= ed my purported position to create a kind of story and the argumentation= s against it. I replied and dismissed a lot of his bad argumentations --= they were all arguments from contrived, exotic and strictly personal an= d ideologized use cases. In his "story" he characterized me as "paranoid= " and worried about "cryptocommunism," etc. This sort of flame and perso= nal attack didn't elicit any comment from you, despite your vigilance fo= r such things and your keen sensitivities. So it's all fake. And you are= proving once again my point about critics being deterred and even forci= bly removed (from places like the SL JIRA) in a blatant political grab f= or power for a group with only one perspective. As I am not a technologi= st, I don't contribute to the technical discussions on this list. But as= it is open to interested parties I can and will comment when I see the = discussion is heavily skewed and politicized. The notion you have that t= here can only be the copyleftist route to making the Metaverse is really= the most appalling thing about the group. The options have to be kept o= pen and free for a variety of systems. Prokofy ---------- Original Mes= sage ---------- From: "Patnad Babii" To: , Cc: Subject: Re: [vwrap] [wvrap] Simulation consistency Date: Sat, 2 Apr 2011 13:49:30 -0400 Look i have no idea why you make personal attack in this IETF working gr= oup list, but you should stop it, if you don’t have anything cons= tructive to say in here, please go rant in some other places, i`m sure = there's plenty of places where you can just go about it. Why don’= t you just blog about it and don’t use the list. I’m not tr= ying to tell you that you can’t express yourself here, but flamin= g others really doesn’t have a place in a list like this. Please s= top it, every time your posting in here turn out in a flaming war and w= e really don’t need this. Thank you From: dyerbrookme@juno.co= m Sent: Saturday, April 02, 2011 1:14 PM To: carlo@alinoe.com Cc: vwrap@= ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency Carlo, = Why, after 7 years (or more like 15 years) of discussions about the Me= taverse do you feel the need to come and state the obvious about the ana= log hole once again? And the obvious about the inability to stop rogue = viewers once again because they can all spoof things? We get all that= -- and got a million times ago when you smugly explained it the first = million times. The reality is, companies use a variety of techniques t= o battle these problems, some engineered in code, some in organic polic= y. Indeed they use DRM and paywalls despite everything that you think o= r that Apple has done. And that's ok. We all get that there is no 100 p= ercent solution. But if you cease to think in the rigid binary manner o= f 0/1, if you have 67 percent of a solution, that's still pretty good. = If you combine that with 6 other methods, some engineered, some managed = by people, you have a pretty good system. You don't admit or counsel = defeat or assume a knowier-than-thou defeatist position about the probl= em of copying on the Internet just because there's copyablity. = As Jaron Lanier has explained a number of times, "It's this way because = we made it this way." The ideology was baked in; it can be baked out *= shrugs*. Why you would have to rehearse, in numbing, boring detail for= the millionth time in this discussion, the way textures operate -- fac= ts we who are not technologists but who use SL already got the first mi= llion times you discussed it -- can only be explained by a belief that = if you say something enough times it will "make it true" -- as a policy= , and not just as code. The reality is, most people don't copy. The re= ality is, most people find c/m/t works pretty good. In fact, so good th= at the entire economy thrives on it. The reality is, the Lindens do cat= ch rogue viewers. The reality is, most people have absolutely no need t= o liberate their own or other's content. It's a completely contrived cl= aim that they do, just because you as the copyleftist sect have this "n= eed". And again THE PROBLEM IS EXAGGERATED and indeed those latest sta= tistics in fact let us know that. 9 million scans of X thousands of ava= tars, and only 78,000 found with rogue viewers. And DER we get it tha= t the real rogues are not going to show up as "known rogues". So what? = *There aren't that many of them either*. Psychological advantage *matte= rs*. = "And don't tell me software exists that can detect if an uploaded texture "looks like" one of the already existing billion textures that were uploaded before. If the texture is converted twice, ie from jpeg2000 to jpg to tga and then uploaded, then you'd need a human to look at the original and the newly uploaded texture at the same time to judge that it is MAYBE a copy - which then can only be proved in court if the original creator can prove that his original textures are 100% his own and not, for example, downloaded from the internet somewhere (because in that case the other uploader could have used the same source). Well, maybe it does, and maybe it doesn't.= In fact, YOU would not be a source on this because you and your confre= res here already have one perspective, and that's the copyleftist one. = You're already predisposed to see every nail of attempt to find mechanic= al means, even if not perfect, with the hammer of your default copyleft= ism. So you're not the person to consult about this. You and the others= here are not trustworthy; you are not good stewards of the public trus= t. You have no credibility. The idea that there is "the complete lack = of support for FREE things" in Second Life is outrageously laughable. I= t's the sort of thing only the most extreme, lunatic Stillmanite could = say. Every store has freebies. There are zillions of divas who have lo= ss leaders. There are thousands of people who like helping the masses w= ith free crap. There is a concerned, aggressive, obsessive sect of open= source freaks in SL who constantly release things for free, especially = if they can ruin someone else's proprietary business that they don't th= ink they should have -- for example, CrystalShar Foo's infamous Freevie= w TV, cumbersome and unworkable but free, and designed to undermine the= proprietary TV scripts (ultimately an unsuccessful gambit, but one whi= ch still continues to wreck havoc). So there's no shortage of "free" an= d "free on all perms" -- to claim the opposite is to defy what we can a= ll see before our eyes on every sim. There is no customer demand for r= ezzing prims defaulting to the collectivist mode of all perms. That's a= minority, sectarian opinion of some copyleftists and they've aggressiv= ely mounted a JIRA demanding the first step toward this (with an aim to = undermine the default), and it's no accident, comrade, that I am banned= from the JIRA for precisely objecting that exact stealth campaign, bar= ely camouflaged because the originators' petition and comments on tech p= ublications are all available to see on the Internet to determine their= real agenda. NO ONE is complaining that prims rez to default to no-tr= ansfer. THAT'S OK. It prevents people especially when new from giving a= way their creations accidently. It takes one click to change them to th= e share-bear freebie mode if needed. No one has ever been deterred in t= heir zeal to make everything "free for the masses" -- communism abounds= in SL. It's a completely false use case to claim that there are all t= hese people who are fussing that they can't manage builds or objects be= cause of permissions problems. There aren't. Instead, there are way mor= e people complaining that there is too much unpunished copybotting and = too much aggressiveness freebie flooding from a small concerted clique = with an agenda. It's just you don't hear from these far greater masses = of people because they aren't technologists. But even without computer = science degrees, people become very savvy about running JIRA proposals = and getting votes, and the votes show it: people do not need the copyle= ftist regime in SL; they need the copyright regime in SL. That's all the= re is to it. Pretending this isn't the case is done for ideological rea= sons and not science. The use case of "my friend needs to me to chang= e all the objects on my sim" is an isolated one and one that is remedie= d with build perms most of the time. I've commissioned numerous builds = and worked with builders and other residents constantly. Nobody has eve= r been deterred from collaboration or assistance with management by the= permissions system. Businesses make group avatars that multiple use or= they make company avatars just for that build to use. If a creator "f= orgot" to set some root prim some way, you can contact them and work it= out. Most prefab creators put houses on copy/mod but not transfer prec= isely so you can easily change their buildings, in fact. Those that put = their item on no-copy/transfer will send you another copy or sell you a= box with 6 back ups -- but the overwhelming majority put their items o= n copy/mod. These fake claims of "entire sims" with "builds I can't mov= e or transfer" are artificial exoticisms used to make copyleftist argum= ents -- I've gone and examined a few of them and found things like Sigg= y Romulus' beach house, which was issued 7 years ago on all perms, and = which ends up in somebody's inventory without all the perms, but *which= can be gotten again easily on all perms* -- that is, gosh, if you can'= t live without an ugly brown newbie building and can't make one yoursel= f (and even I can do that). I discovered the two educators bellowing th= e loudest about not being able to copy content to open sim when they mo= ved due to price hikes last fall were people with a couple of free or ve= ry cheap prefabs on their sims -- to hear them talk, they had the 65,00= 0 proprietary works of Scope Cleaver and had paid tens of thousands of = dollars and were now wailing. Had that actually been the case, of cours= e, they could contact Scope and pay him for a transfer. To invoke fake = use cases of builders long gone from the grid doesn't cut it -- most th= ings in SL can be be built quickly anew, and the same textures purchase= d. Using common sense and logic you sustain the economy; making up fake= use cases and cranking up the tech or demanding changes to policy to m= atch those fake use cases, you undermine the economy. With builders I = work with, I'm able to copy their items because I have their build perm= s. So I could put something again if it disappears in a sim rolling res= tart, something that happens about once every few months. If I copy som= e large block of concrete and put it out inworld, I can't then keep pull= ing on and copying that block, I have to take it again from inventory. = Same with commissioned works I resell. I have to carefully rez each cop= y out of my inventory and reset the perms to make sure I don't sell the= m all perm. I have to do this with several items a few times a month. A= nd it's worth it to preserve the intellectual property rights of those = creators, and my investment in commissioning content. I'm not a RL stor= e owner who has to unpack a crate and dust off the peanuts and manually= put them on real shelves, I'm a virtual store owner who...clicks a few= times. Big deal. I am NOT INTERESTED in CHANGES TO SERVER-SIDE CODE th= at remove the Berne inherency: http://secondthoughts.typepad.com/second_= thoughts/2011/02/the-berne-inherency-and-the-interop-flop-reply-to-meadh= .html None of the "hardships" you describe are real. They all have wor= karounds. And they all have solutions in the long run that will keep va= lue *when this technological exercise is in other hands*. There is no= thing "missing" from the protocol because a friend who has created some= thing who somehow now needs you to fiddle with his prims can't turn ove= r every aspect of them to you. If he loves you that much, he can give yo= u his log on and you can log on as him. There is no "annoyance" that = an object is "non free". That's assigning anthropomorphic features to a= piece of code rendering as a block. Catherine Pfeffer, flogging the al= l-perms JIRA, does exactly the same gambit, accusing the server of "ens= laving" objects. Nonsense. The server, the system, the protocols prese= rve value by keeping the maximum of choices OPEN as a default. We value= that. You don't. Go on open sim and play in your Leninist sandboxes an= d stop trying to build a bridge between two systems merely designed to = flush the content out for free. We're not interested; indeed we will vi= gorously oppose it. Freebies that are non-transfer are designed that w= ay because freebies are usually tethered to a purpose: serving as a los= s-leader to drive people back to the store where they were issued so th= at people might buy things as well as take the loss-leaders. And that's= ok, that's normal, and that's what most people want. You're ALREADY = free to create content and set all the perms to support the collectivis= t ideals you wish to support. There is CHOICE. When open source copylef= tism is imposed on defaults, then THERE IS NO CHOICE. As for this noti= on: "I think you might find a lot of people, like myself, a lot more wi= lling to help out with thinking of ways on how to protect property in v= irtual worlds when first it is assured that those who want to create things th= at are FREE are equally supported as the commercial guys out there. You're already FREE because there is already CHOICE and you are banging= on an open door -- with only the aim to close it and impose the coerciv= e copyleftist agenda with is NOT FREE for those who want to keep the in= tegration of copyright and commerce, a laudable aim. Once again, I want= to remind everyone what VWRAP and metaversestandards.org and other sim= ilar exercises are about: ideological control by copyleftism, not techn= ology. And ideological control that is only able to keep itself in powe= r by silencing people on the JIRA, kicking people off lists like this, = silencing them on the opensource Linden list, etc. etc. Just as the rea= l-life coercion of Soviet communism failed, so will this technocommunis= t version of it fail precisely because of this coercion -- coercion in = controlling speech criticizing of its hijacking of the agenda, coercion= in opposition to exposure of false use cases, and coercion in demanding= technical exigencies to suit copyleftism. Leave Second Life alone. = Prokofy Neva ____________________________________________________________ Groupon.com Official Site 1 huge daily deal on the best stuff to do in your city. Try it today! Groupon.com = _______________________________________________ vwrap mailing list vwrap@ietf.org https://www.ietf.org/mailman/listinfo/vwrap ____________________________________________________________ Groupon.com Official Site 1 huge daily deal on the best stuff to do in your city. Try it today! http://thirdpartyoffers.juno.com/TGL3141/4d978342a0e0750fab1st02vuc ----__JWM__J5cc3.6bbfS.7958M Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/html; charset=ISO-8859-1
Dear Patnad,
 
I post on this list a= bout twice a year.
 
My post is not a rant, it = is not a flame, it is not a troll, it is not a personal attack. These ar= e all specious characterizations that are politically-motivated. I'm not= the one "flaming" here; those who feel the need to "set me straight" ar= e the "flamers" -- although such petty notions as "trolling" and "flamin= g" really should have been left at the back door of the Well 20 years ag= o, if not at the gate of war game forums 15 years ago. They are notions = merely used to silence critics and discredit dissidents.
 = ;
Carlo used my purported position to create a kind of story a= nd the argumentations against it. I replied and dismissed a lot of his b= ad argumentations -- they were all arguments from contrived, exotic and = strictly personal and ideologized use cases.
 
= In his "story" he characterized me as "paranoid" and worried about "cryp= tocommunism," etc. This sort of flame and personal attack didn't elicit = any comment from you, despite your vigilance for such things and your ke= en sensitivities.
 
So it's all fake. And you a= re proving once again my point about critics being deterred and even for= cibly removed (from places like the SL JIRA) in a blatant political grab= for power for a group with only one perspective.
 
=
As I am not a technologist, I don't contribute to the technical dis= cussions on this list. But as it is open to interested parties I can and= will comment when I see the discussion is heavily skewed and politicize= d.
 
The notion you have that there can only be= the copyleftist route to making the Metaverse is really the most appall= ing thing about the group. The options have to be kept open and free for= a variety of systems.
 
Prokofy
&nbs= p;
 
 
---------- Original Messa= ge ----------
From: "Patnad Babii" <djshag@hotmail.com>
To: = <dyerbrookme@juno.com>, <carlo@alinoe.com>
Cc: <vwrap@= ietf.org>
Subject: Re: [vwrap] [wvrap] Simulation consistency
D= ate: Sat, 2 Apr 2011 13:49:30 -0400

Lo= ok i have no idea why you make personal attack in this IETF working grou= p list, but you should stop it, if you don’t have anything constr= uctive to say in here, please go rant in some other places, i`m sure th= ere's plenty of places where you can just go about it. Why don’t = you just blog about it and don’t use the list. I’m not tryi= ng to tell you that you can’t express yourself here, but flaming = others really doesn’t have a place in a list like this. Please sto= p it, every time your posting in here turn out in a flaming war and we = really don’t need this.
 
Thank you
 
Sent:= Saturday, April 02, 2011 1:14 PM
Subject: Re: [vwrap] [wvrap] Simulation consistency
 
Carlo,
 
Why, after 7 years (or more like 15 years) of discussions about the Me= taverse do you feel the need to come and state the obvious about the ana= log hole once again?
And the obvious about the inability to = stop rogue viewers once again because they can all spoof things?
=
 
We get all that -- and got a million times ago wh= en you smugly explained it the first million times.
 
The reality is, companies use a variety of techniques to battl= e these problems, some engineered in code, some in organic policy. Inde= ed they use DRM and paywalls despite everything that you think or that = Apple has done. And that's ok. We all get that there is no 100 percent = solution. But if you cease to think in the rigid binary manner of 0/1, = if you have 67 percent of a solution, that's still pretty good. If you<= /div>
combine that with 6 other methods, some engineered, some mana= ged by people, you have a pretty good system.
 
<= div>You don't admit or counsel defeat or assume a knowier-than-thou defe= atist position about the problem of copying on the Internet just becaus= e there's copyablity.

As Jaron Lanier has explained a nu= mber of times, "It's this way because we made it this way." The ideolog= y was baked in; it can be baked out *shrugs*.
 
<= div>Why you would have to rehearse, in numbing, boring detail for the mi= llionth time in this discussion, the way textures operate -- facts we w= ho are not technologists
but who use SL already got the firs= t million times you discussed it -- can only be explained by a belief t= hat if you say something enough times it will "make it true" -- as a po= licy, and not just as code.
 
The reality is,= most people don't copy. The reality is, most people find c/m/t works p= retty good. In fact, so good that the entire economy thrives on it. The= reality is, the Lindens do catch rogue viewers. The reality is, most pe= ople have absolutely no need to liberate their own or other's content. = It's a completely contrived claim that they do, just because you as the= copyleftist sect have this "need".
 
And ag= ain THE PROBLEM IS EXAGGERATED and indeed those latest statistics in fa= ct let us know that. 9 million scans of X thousands of avatars, and only= 78,000 found with rogue viewers.
 
And DER = we get it that the real rogues are not going to show up as "known rogue= s". So what? *There aren't that many of them either*. Psychological adv= antage *matters*.
 

"And don't tell me so= ftware exists that can detect if
an uploaded texture "looks like" on= e of the already existing billion
textures that were uploaded before= . If the texture is converted twice,
ie from jpeg2000 to jpg to tga = and then uploaded, then you'd need a
human to look at the original an= d the newly uploaded texture at the
same time to judge that it is MA= YBE a copy - which then can only be
proved in court if the original = creator can prove that his original
textures are 100% his own and no= t, for example, downloaded from the
internet somewhere (because in t= hat case the other uploader could
have used the same source).
=
 
Well, maybe it does, and maybe it doesn't. In fac= t, YOU would not be a source on this because you and your confreres her= e already have one perspective, and that's the copyleftist one.
<= div>You're already predisposed to see every nail of attempt to find mech= anical means, even if not perfect, with the hammer of your default copy= leftism. So you're not the person to consult about this.
You= and the others here are not trustworthy; you are not good stewards of = the public trust. You have no credibility.
 
= The idea that there is "the complete lack of support for FREE things" in= Second Life is outrageously laughable. It's the sort of thing only the= most extreme, lunatic Stillmanite could say.
 
<= div>Every store has freebies. There are zillions of divas who have loss = leaders. There are thousands of people who like helping the masses with= free crap. There is a concerned, aggressive, obsessive sect of opensou= rce freaks in SL who constantly release things for free, especially if = they can ruin someone else's proprietary business that they don't think= they should have -- for example, CrystalShar Foo's infamous Freeview T= V, cumbersome and unworkable but free, and designed to undermine the pr= oprietary TV scripts (ultimately an unsuccessful gambit, but one which = still continues to wreck havoc). So there's no shortage of "free" and "= free on all perms" -- to claim the opposite is to defy what we can all = see before our eyes on every sim.
 
There is = no customer demand for rezzing prims defaulting to the collectivist mod= e of all perms. That's a minority, sectarian opinion of some copyleftis= ts and they've aggressively mounted a JIRA demanding
the firs= t step toward this (with an aim to undermine the default), and it's no = accident, comrade, that I am banned from the JIRA for precisely objectin= g that exact stealth campaign, barely camouflaged because
th= e originators' petition and comments on tech publications are all avail= able to see on the Internet to determine their real agenda.
&= nbsp;
NO ONE is complaining that prims rez to default to no-t= ransfer. THAT'S OK. It prevents people especially when new from giving = away their creations accidently. It takes one click to change them to t= he share-bear freebie mode if needed. No one has ever been deterred in = their zeal to make everything "free for the masses" -- communism abound= s in SL.
 
It's a completely false use case t= o claim that there are all these people who are fussing that they can't= manage builds or objects because of permissions problems. There aren't= . Instead, there are way more people complaining that there is too much= unpunished copybotting and too much aggressiveness freebie flooding fr= om a small concerted clique with an agenda. It's just you don't hear fr= om these far greater masses of people because they aren't technologists.= But even without computer science degrees, people become very savvy ab= out running JIRA proposals and getting votes, and the votes show it: pe= ople do not need the copyleftist regime in SL; they need the copyright = regime in SL. That's all there is to it. Pretending this isn't the case= is done for ideological reasons and not science.
 
The use case of "my friend needs to me to change all the objects= on my sim" is an isolated one and one that is remedied with build perm= s most of the time. I've commissioned numerous builds and worked with b= uilders and other residents constantly. Nobody has ever been deterred f= rom collaboration or assistance with management by the permissions syst= em. Businesses make group avatars that multiple use or they make compan= y avatars just for that build to use.
 
If a = creator "forgot" to set some root prim some way, you can contact them a= nd work it out. Most prefab creators put houses on copy/mod but not tran= sfer precisely so you can easily change their buildings, in fact. Those= that put their item on no-copy/transfer will send you another copy or = sell you a box with 6 back ups -- but the overwhelming majority put the= ir items on copy/mod. These fake claims of "entire sims" with "builds I= can't move or transfer" are artificial exoticisms used to make copylef= tist arguments -- I've gone and examined a few of them and found things= like Siggy Romulus' beach house, which was issued 7 years ago on all p= erms, and which ends up in somebody's inventory without all the perms, = but *which can be gotten again easily on all perms* -- that is, gosh, i= f you can't live without an ugly brown newbie building and can't make o= ne yourself (and even I can do that). I discovered the two educators be= llowing the loudest about not being able to copy content to open sim whe= n they moved due to price hikes last fall were people with a couple of = free or very cheap prefabs on their sims -- to hear them talk, they had= the 65,000 proprietary works of Scope Cleaver and had paid tens of tho= usands of dollars and were now wailing. Had that actually been the case= , of course, they could contact Scope and pay him for a transfer. To in= voke fake use cases of builders long gone from the grid doesn't cut it = -- most things in SL can be be built quickly anew, and the same texture= s purchased. Using common sense and logic you sustain the economy; maki= ng up fake use cases and cranking up the tech or demanding changes to p= olicy to match those fake use cases, you undermine the economy.
 
With builders I work with, I'm able to copy their i= tems because I have their build perms. So I could put something again i= f it disappears in a sim rolling restart, something that happens about = once every few months. If I copy some large block of concrete and put i= t out inworld, I can't then keep pulling on and copying that block, I h= ave to take it again from inventory. Same with commissioned works I res= ell. I have to carefully rez each copy out of my inventory and reset th= e perms to make sure I don't sell them all perm. I have to do this with= several items a few times a month. And it's worth it to preserve the i= ntellectual property rights of those creators, and my investment in com= missioning content. I'm not a RL store owner who has to unpack a crate a= nd dust off the peanuts and manually put them on real shelves, I'm a vi= rtual store owner who...clicks a few times. Big deal. I am NOT INTEREST= ED in CHANGES TO SERVER-SIDE CODE that remove the Berne inherency:
http://secondthoughts.typepad.com/second_thoughts/2011/02/the-ber= ne-inherency-and-the-interop-flop-reply-to-meadh.html
 <= /div>
None of the "hardships" you describe are real. They all have = workarounds. And they all have solutions in the long run that will keep= value *when this technological exercise is in other hands*.
 
There is nothing "missing" from the protocol because = a friend who has created something who somehow now needs you to fiddle = with his prims can't turn over every aspect of them to you. If he loves= you that much, he can give you his log on and you can log on as him.
 
There is no "annoyance" that an object is "n= on free". That's assigning anthropomorphic features to a piece of code = rendering as a block. Catherine Pfeffer, flogging the all-perms JIRA, d= oes exactly the same gambit, accusing the server of "enslaving" objects= .
 
Nonsense. The server, the system, the pro= tocols preserve value by keeping the maximum of choices OPEN as a defau= lt. We value that. You don't. Go on open sim and play in your Leninist = sandboxes and stop trying to build a bridge between two systems merely = designed to flush the content out for free. We're not interested; indee= d we will vigorously oppose it.
 
Freebies th= at are non-transfer are designed that way because freebies are usually = tethered to a purpose: serving as a loss-leader to drive people back to = the store where they were issued so that people might buy things as wel= l as take the loss-leaders. And that's ok, that's normal, and that's wh= at most people want.
 
You're ALREADY free t= o create content and set all the perms to support the collectivist idea= ls you wish to support. There is CHOICE. When open source copyleftism i= s imposed on defaults, then THERE IS NO CHOICE.
 
=
As for this notion: "I think you might find a lot of people, like m= yself, a lot more willing to help out with thinking of ways on how to p= rotect property in virtual
worlds when first it is assured that thos= e who want to create things that are FREE are equally supported as the = commercial guys out there.

You're already FREE because there is = already CHOICE and you are banging on an open door -- with only the aim= to close it and impose the coercive copyleftist agenda with is NOT FRE= E for those who want to keep the integration of copyright and commerce,= a laudable aim. Once again, I want to remind everyone what VWRAP and m= etaversestandards.org and other similar exercises are about: ideologica= l control by copyleftism, not technology. And ideological control that = is only able to keep itself in power by silencing people on the JIRA, ki= cking people off lists like this, silencing them on the opensource Lind= en list, etc. etc. Just as the real-life coercion of Soviet communism f= ailed, so will this technocommunist version of it fail precisely becaus= e of this coercion -- coercion in controlling speech criticizing of its= hijacking of the agenda, coercion in opposition to exposure of false u= se cases, and coercion in demanding technical exigencies to suit copyle= ftism.
 
Leave Second Life alone.
=  
Prokofy Neva


________________________________________________= ____________
Groupon.com Official Site
1 huge daily de= al on the best stuff to do in your city. Try it today!
= Groupon.com

 

_________________________= ______________________
vwrap mailing list
vwrap@ietf.org
https= ://www.ietf.org/mailman/listinfo/vwrap
----__JWM__J5cc3.6bbfS.7958M-- From dahliatrimble@gmail.com Sat Apr 2 13:36:22 2011 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 5827A3A6820 for ; Sat, 2 Apr 2011 13:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 Y8f83h5SiXbI for ; Sat, 2 Apr 2011 13:36:18 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id D4CFF3A6816 for ; Sat, 2 Apr 2011 13:36:17 -0700 (PDT) Received: by iye19 with SMTP id 19so5462491iye.31 for ; Sat, 02 Apr 2011 13:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ZxWAUAYbhenCRqLnXuM1h2PyFsCWfGJRf7AS2kRXgOI=; b=Zgai021MKcx7eo7mujcQdV5Im8+r2PGUepHXobeadu+umlBXdv25fjkD+oLfQt71da Vx+qDIHCiJ05Ady+XKg886mGKPHV3B0leLKpcV5LeSsG6LuChjlu5D3BZO4oJHUZuyh6 T3n8GK33JbnEQihyy80gM4p3SDRa6vrj4dQSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=GMTqPupY4CEdJQmKxl/LiiMyKS6yV8nslXymXlFU0c441Te1fl1f0CC8ugb5+7UmMq G1TvR0Xwg3AtPz17MG+EgwXAvrOIjeHz0iVXKU7Kocb+ejxsOt9rs+7Oa7u6U4qDP14K wgBroVQ05Xo/wrpYmhnyLNnbuN3EfcobwAPmk= MIME-Version: 1.0 Received: by 10.231.192.197 with SMTP id dr5mr1750525ibb.2.1301776678978; Sat, 02 Apr 2011 13:37:58 -0700 (PDT) Received: by 10.231.140.40 with HTTP; Sat, 2 Apr 2011 13:37:58 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Apr 2011 13:37:58 -0700 Message-ID: From: Dahlia Trimble To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016e6d279f88706fe049ff58033 Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 20:36:22 -0000 --0016e6d279f88706fe049ff58033 Content-Type: text/plain; charset=ISO-8859-1 I can see another reason to allow the region to proxy assets, or at least some service to proxy assets in the same domain as the region. "Sandboxed" clients such as those which may be based on products as Unity3d or Adobe Flash may be subject to a "same origin" policy (1), where they may be restricted from making network connections outside of the domain from which the application is served. There are workarounds but they may require additional administration overhead for both asset and region service providers, or a separate provider which proxies all traffic. I would hope a VWRAP protocol definition would include the possibility of regions proxying assets so such sandboxed clients can play a part in a VWRAP multiverse. (1) http://en.wikipedia.org/wiki/Same_origin_policy On Sat, Apr 2, 2011 at 8:09 AM, Morgaine wrote: > Vaughn, I left your final (and very important) point for the end of my > response, and then I fired off my email without addressing it ... Sorry. :P > > > On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca wrote: > >> So I want methods to prevent breaking my highly emergent world as much as >> possible. >> > > > Yes indeed!!! > > You have a perfectly reasonable requirement for the service that you want > to operate, and you need some means of meeting it. I agree with that > wholeheartedly. I only begin to disagree when you hint that your > requirement must be imposed on everyone, whether they want it or not. That > I cannot support, and I expect that you did not mean it that way anyway. > After all, some of my requirements are probably not of interest to you > either, and you would not wish me to impose them on you. It cuts both ways. > > So, how can we enable you to offer a service with many 9's of simulation > consistency, without imposing that requirement on those who prefer a > different trade-off? You hinted at the solution yourself, so I'll merely > elaborate on it. You wrote: > > > > I would like to argue that the region *should* get the capability to fetch >> all details. [...] Note that this does not mean that the region *has* to >> proxy the asset, just that in case the asset service refuses to serve a >> client it does not like, the region can insist on delivery based on the >> capability it originally got. >> > > > > Perfect. All you need then is an optional query in the protocol that > allows a region to ask each asset service referenced by assets carried by > newly arriving avatars the following question: > > QUERY: "*Do I have your permission to fetch from your asset service the > assets normally reserved for client fetches, and to distribute these assets > to clients directly in the (unexpected) event that I want to?*" > > > That easily maps to an optional capability request of course. If the asset > service answers "No" to you, then you can deny the incoming avatar entry to > your region, returning a status that indicates > > RESPONSE: "*Asset service X referenced by asset Y does not meet the > re-distribution requirement requested for entry to region Z*". > > > Your requirement is then satisfied (I believe) without imposing that > requirement on a region operator who does not need it because they desire a > different trade-off. Those who don't have your requirement simply won't > request the capability. > > For example, it would be pointless to even ask an asset service founded > entirely around Creative Commons assets that question, since all CC content > is perpetually and non-revocably redistributable by anyone and to anyone. > By not issuing the query we can save ourselves the round-trip time and allow > faster entry to the region. > > Would something like that get the nod from you? > > > PS. You need to note that when an asset service answers "Yes" to your > query, this does not mean that it will necessarily honor its promise when > you actually attempt to fetch items. David's very important point about > independent parties not having control over each other applies here. You > can at most hope that it will behave well, and perhaps test the promise by > fetching something. However, if you truly want as many 9's of consistency > as is obtainable then you will have to fetch all the assets yourself prior > to allowing entry to the avatar, and that would be a dreadful overhead. > Most people will probably settle for "*best effort*" approaches, which are > quite likely to succeed. > > > Morgaine. > > > > > > ===================== > > > On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca wrote: > >> Morgaine, Meadhbh, >> >> Thanks for the answers, but i see that i have not been clear enough. >> I think the protocol should demand certain things to prevent the >> deterioration of the simulation to an unacceptable level. We need to be >> more precise to prevent problems and i think we can. >> >> I was arguing from the perspecive of a region service without making that >> explicit. Note i was *not* advocating the region proxies everything, just >> that it lives up to its promises about object presence. Also note that i do >> *not* always have the option to pick another high quality asset service, >> since I normally do not own the assets. I will use Prokofy as an example >> just for the fun of it. He is highly worried about content theft, so (in >> the unlikely case he wants to start selling stuff outside of SL) he might >> use this deployment pattern. Assume he sells wonderful sexy dresses to two >> customers, that can only be fetched from his own asset service for >> rendering. Both customers go off to "Vaughns highly immersive world" were a >> party is given. My region receives some physics properties of the dresses >> for simulation and an address of Proks asset service for high-res details >> and textures. In this case the region does not even get the capability to >> fetch the assets, just a link to the asset service and its up to viewer to >> request the details and show credentials to get them. The two girls meet, >> both their viewers request the details of the other dress, and Proks asset >> service grants those requests. They girls admire their dresses and >> compliment each other with their good taste. Now when i arrive and my viewer >> request the dress details, Prok's asset service recognises me as the >> copyleftists that i am. It refuses to serve the asset details -and depending >> on my viewers behaviour i might get to view two girls in sexy underwear -or >> wearing even less- instead of party dresses. From a consistency point of >> view this is a highly undesirable situation, it breaks immersion, and >> depending on the circumstances might also be embarrassing to the people >> involved. >> >> The key question is if we want to allow this situation to arise within >> VWRAP compliant worlds. >> I would like to argue that the region *should* get the capability to fetch >> all details. In other words, Prokofy would have to give up some control over >> the asset in case he allows it to be used by my region. Note that this does >> not mean that the region *has* to proxy the asset, just that in case the >> asset service refuses to serve a client it does not like, the region can >> insist on delivery based on the capability it originally got. If that fails >> Proks asset service can not be called VWRAP compliant. >> >> If Prokofy does not want to relinquish that level of control, fine, it is >> his right not to, but in that case the dresses should not be allowed to get >> into my region in the first place. If people visit my region and find >> themselves naked in the eyes of some others *I* will get the blame. As >> Morgaine says, the technical details of my innocence will not convince the >> general public. So I want methods to prevent breaking my highly emergent >> world as much as possible. >> My proposal would be that the whatever the region gets MUST be guaranteed >> by protocol to be delivered to anybody within the region requesting it. If >> the asset service does not want to serve a cryptocomunist copyleftist, fine, >> but IF it has given the region a capability, it MUST serve the full asset to >> be VWRAP compliant. Its *my* choice as a region deployer to download the >> full asset to be able to guarantee region consistency if I want to. I will >> try to avoid that as much as possible, but if my customers complain, i will >> be forces to start doing this for certain asset services that i know show >> discriminatory behaviour against for instance copyleftist. >> >> Finally Morgaine, you keep hammering on the fact that proxying by the >> region does not scale. (I tend to disagree, but that is beside the point >> here). I do agree the asset should not be needlessly transfered, but i >> strongly feel we must insist in the protocol on transferring the *rights* to >> view the asset. If that leads to to the region not getting the asset at all, >> so be it, it can warn visitors that their assets will not be visible and >> even offer to serve simple replacements (1). This in turn will encourage the >> end users to avoid this type of asset service, and Prokofy will go out of >> business, as should be the case given the behaviour of the service. And if >> he pulls it off, thats fine with me also, as long as i do not have to suffer >> from it due to lack of rigour in the protocol specs. >> >> So, in summary, I very well see that there is no way to enforce consistent >> serving behaviour but it should at least be clear that it is non-standard >> and not conform the protocol. The way I am understanding you now, your >> argument seems to be just one step to far in the direction of anarchy. >> Or am i misreading you? >> >> --Vaughn >> >> >> (1) I just realise that the region might cheat and advertise its own asset >> brands claiming the competitions assets could not be rendered... Oh well, >> one might hope that if there is enough choice in worlds such regions will be >> forced out of business as well. >> >> On Sat, Apr 2, 2011 at 7:31 AM, Morgaine wrote: >> >>> Further to my last post, it's worth noting that if you find that you >>> suffer poor quality behavior from a particular asset service and it is >>> breaking the consistency of your simulation, with hash-based item addressing >>> you can also automatically use an alternative asset service *in >>> preference* to the one specified in a given URI. >>> >>> Your client could be configured to attempt the item fetch at a known good >>> quality asset service *first* (perhaps one that you paid to use because >>> of its better service), automatically, and maybe even dynamically depending >>> on the type of item. >>> >>> The scheme has a long list of benefits, and overcoming (to some extent) >>> poor quality asset services is just one of them. >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> >>> =================== >>> >>> >>> On Sat, Apr 2, 2011 at 4:55 AM, Morgaine >> > wrote: >>> >>>> Every design choice results in a trade-off, Vaughn, improving one thing >>>> at the expense of something else. If every time we offered a service we had >>>> to inform its users about the downsides of all the trade-offs we have made, >>>> they would have an awful lot to read. ;-) >>>> >>>> The specific trade-off that you are discussing is no different. A >>>> region that proxies all content has the "benefit" of acquiring control from >>>> the asset servers over the items in the region, so that it can ensure that >>>> everyone in the region not only obtains the items but obtains the *same >>>> * items as everyone else. That does indeed provide a greater guarantee >>>> of consistency than a deployment in which the region only passes asset URIs >>>> to clients who then fetch the items from asset services separately. As >>>> always though, it's a trade-off, since the proxied design has very poor >>>> scalability compared to the distributed one. >>>> >>>> If we're going to warn users of the potential for inconsistency in the >>>> distributed deployment as you suggest, are we also going to warn them of >>>> non-scalability in the proxied one? I really don't see much merit in the >>>> idea of warning about design choices. Many such choices are technical, and >>>> the issues are quite likely to be of little interest to non-technical users >>>> anyway. In any case, the better services are likely to provide such >>>> information in their online documentation, I would guess. >>>> >>>> You mentioned users "voting with their feet" or choosing to accept the >>>> risk of inconsistency. Well that will happen anyway, when services fail and >>>> users get annoyed. If some asset services refuse to send the requested >>>> items to some users, those services will get a bad reputation and people >>>> will choose different asset services instead. Likewise, if a world service >>>> proxies everything and so it can't handle a large number of assets or of >>>> people, users will get annoyed at the lag and will go elsewhere. This user >>>> evaluation and "voting with their feet" happens already with online services >>>> all over the Internet, and I am sure that this human process will continue >>>> to work when the services are asset and region services. >>>> >>>> Back in September 2010, I wrote this post which proposes that we use in >>>> VWRAP a form of asset addressing that provides massive scalability at the >>>> same time as a very high degree of resilience -- >>>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html . It >>>> is based on the concept of the URI containing a host part and a hash part, >>>> where the hash is generated (once, at the time of storage to the asset >>>> service) using a specified digest algorithm over the content of the asset >>>> being referenced. You may wish to note that if this design were used, the >>>> failure of an asset service to deliver a requested item would result in a >>>> failover request for the item to one or more backup services, using the same >>>> hash part but with a different host address. >>>> >>>> This can go some way towards overcoming the problem that you think might >>>> occur when assets are fetched by clients from asset services directly. >>>> Although it won't help when the missing item is available from only a single >>>> asset service, it will help in many other cases, and it will compensate for >>>> service failures and network outages automatically at the same time. >>>> >>>> PS. This design for hash-based asset addressing is already being tested >>>> by Mojito Sorbet in her experimental world and client. It would give >>>> VWRAP-based worlds an improved level of service availability, so I think it >>>> should be a core feature of our protocol. >>>> >>>> >>>> Morgaine. >>>> >>>> >>>> >>>> >>>> =========================== >>>> >>>> >>>> On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca >>> > wrote: >>>> >>>>> This is a question i discussed with Morgaine off-list a while ago (I >>>>> intended to send it to the list but pushed the wrong button...) I >>>>> think we need to address this problem, and decide how to deal with it. >>>>> >>>>> In Davids deployment draft, section 7.3.1.1 an overview is given van >>>>> ways to deliver content to the region. One way is only passing a >>>>> capability that allows access to (part of) the resource: >>>>> >>>>> 7.3.1.1. Content delivery models >>>>> A range of possible represenations can be passed to a region >>>>> for >>>>> simulation. [...] The other end of the delivery spectrum >>>>> involves passing >>>>> only a URI or capability used to access the rendering >>>>> information and a >>>>> collision mesh,and related data for physical simulation. >>>>> In such a model, the client is responsible for fetching the >>>>> additional >>>>> information needed to render the item's visual presence from >>>>> a separate >>>>> service. This fetch can be done *under the credentials of >>>>> the end user* >>>>> viewing the material [my emphasis--VD] , and divorces the >>>>> simulation from >>>>> the trust chain needed to manage content. Any automation >>>>> is done on a >>>>> separate host which the content creator or owner trusts, >>>>> interacting with the >>>>> object through remoted interfaces. >>>>> >>>>> I can see the need for such a setup, however, i feel we are >>>>> unpleasantly close to a situation were the coherence of the simulation >>>>> falls apart. >>>>> In this deployment pattern the region advertises the presence of the >>>>> asset, and *some* clients will be able to get it as expected, while >>>>> -based on the arbitrary whims of the asset service- others might not. >>>>> >>>>> My hope would be that after the asset server provides the region with >>>>> the capability to get the asset, it gives up control. That would mean >>>>> that if the client finds the inventory server is unwilling to serve >>>>> the content - in spire of the region saying it is present-, the client >>>>> should be able to turn around ask the *region* for the asset, (and get >>>>> is after all). >>>>> >>>>> If that is not the case, -and there are probably good reasons for the >>>>> deployment pattern as described- shouldn't we *warn* clients that the >>>>> region might be inconsistent, so the users behind the client can vote >>>>> with their feet, (or take the risk)? >>>>> >>>>> --Vaughn >>>>> _______________________________________________ >>>>> 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 > > --0016e6d279f88706fe049ff58033 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I can see another reason to allow the region to proxy assets, or at least s= ome service to proxy assets in the same domain as the region. "Sandbox= ed" clients such as those which may be based on products as Unity3d or= Adobe Flash may be subject to a "same origin" policy (1), where = they may be restricted from making network connections outside of the domai= n from which the application is served. There are workarounds but they may = require additional administration overhead for both asset and region servic= e providers, or a separate provider which proxies all traffic. I would hope= a VWRAP protocol definition would include the possibility of regions proxy= ing assets so such sandboxed clients can play a part in a VWRAP multiverse.=

(1) http://= en.wikipedia.org/wiki/Same_origin_policy



On Sat, Apr 2, 2011 at 8:09 AM, Morgaine <= morgaine.dinova@googlemai= l.com> wrote:
Vaughn, I left yo= ur final (and very important) point for the end of my response, and then I = fired off my email without addressing it ...=A0 Sorry. :P


On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca &l= t;vaughn.deluc= a@gmail.com> wrote:
=A0So I want= methods=20 to prevent breaking my highly emergent world as much as possible.


Yes indeed!!!

You have a perfectly reaso= nable requirement for the service that you want to operate, and you need so= me means of meeting it.=A0 I agree with that wholeheartedly.=A0 I only begi= n to disagree when you hint that your requirement must be imposed on everyo= ne, whether they want it or not.=A0 That I cannot support, and I expect tha= t you did not mean it that way anyway.=A0 After all, some of my requirement= s are probably not of interest to you either, and you would not wish me to = impose them on you.=A0 It cuts both ways.

So, how can we enable you to offer a service with many 9's of simul= ation consistency, without imposing that requirement on those who prefer a = different trade-off?=A0 You hinted at the solution yourself, so I'll me= rely elaborate on it.=A0 You wrote:



= I would like to argue that the region *should* get the capability to=20 fetch all details. [...]=A0=20 Note that this does not mean that the region *has* to proxy the asset,=20 just that in case the asset service refuses to serve a client it does=20 not like, the region can insist on delivery =A0based on the capability it= =20 originally got.



Perfect.=A0 All you need then= is an optional query in the protocol that allows a region to ask each asse= t service referenced by assets carried by newly arriving avatars the follow= ing question:

QUERY: "Do I have your permis= sion to fetch from your asset service the assets normally reserved for clie= nt fetches, and to distribute these assets to clients directly in the (unex= pected) event that I want to?"


That easily maps to an optional capability request of course.= =A0 If the asset service answers "No" to you, then you can deny t= he incoming avatar entry to your region, returning a status that indicates<= br>
RESPONSE: "Asset service X re= ferenced by asset Y does not meet the re-distribution requirement requested= for entry to region Z".


Your requirement is then= satisfied (I believe) without imposing that requirement on a region operat= or who does not need it because they desire a different trade-off.=A0 Those= who don't have your requirement simply won't request the capabilit= y.

For example, it would be pointless to even ask an asset service founded= entirely around Creative Commons assets that question, since all CC conten= t is perpetually and non-revocably redistributable by anyone and to anyone.= =A0 By not issuing the query we can save ourselves the round-trip time and = allow faster entry to the region.

Would something like that get the nod from you?


PS. You need= to note that when an asset service answers "Yes" to your query, = this does not mean that it will necessarily honor its promise when you actu= ally attempt to fetch items.=A0 David's very important point about inde= pendent parties not having control over each other applies here.=A0 You can= at most hope that it will behave well, and perhaps test the promise by fet= ching something.=A0 However, if you truly want as many 9's of consisten= cy as is obtainable then you will have to fetch all the assets yourself pri= or to allowing entry to the avatar, and that would be a dreadful overhead.= =A0 Most people will probably settle for "best effort" app= roaches, which are quite likely to succeed.


Morgaine.





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

=
On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Delu= ca <vaughn.deluca@gmail.com> wrote:
Morgaine, Me= adhbh,

Thanks for the answers, but i see that i ha= ve not been clear enough.
I think the protocol should demand certain things to prevent the =A0de= terioration of the simulation to an unacceptable level. We need to be more = precise to prevent problems and i think we can.

I was arguing from the perspecive of a region service w= ithout making that explicit. Note i was *not* advocating the region proxies= everything, just that it lives up to its promises about object presence. A= lso note that i do =A0*not* always have the option to pick another high qua= lity asset service, since I normally do not own the assets. I will use Prok= ofy as an example just for the fun of it. =A0He is highly worried about con= tent theft, so (in the unlikely case he wants to start selling stuff outsid= e of SL) he might use this deployment pattern. =A0Assume he sells wonderful= sexy dresses to two customers, that can only be fetched from his own asset= service for rendering. Both customers go off to "Vaughns highly immer= sive world" were a party is given. =A0My region receives some physics = properties of the dresses for simulation and an address of Proks asset serv= ice for high-res details and textures. In this case the region does not eve= n get the capability to fetch the assets, just a link to the asset service = and its up to viewer to request the details and show credentials to get the= m. The two girls meet, both their viewers request the details of the other = dress, and Proks asset service grants those requests. They girls admire the= ir dresses and compliment each other with their good taste. Now when i arri= ve and my viewer request the dress details, Prok's asset service recogn= ises me as the copyleftists that i am. It refuses to serve the asset detail= s -and depending on my viewers behaviour i might get to view two girls in s= exy underwear -or wearing even less- instead of party dresses. From a consi= stency point of view this is a highly undesirable situation, it breaks imme= rsion, and depending on the circumstances might also be embarrassing to the= people involved.=A0

The key question is if we want to allow this situation = to arise within VWRAP compliant worlds.
I would like to argue tha= t the region *should* get the capability to fetch all details. In other wor= ds, Prokofy would have to give up some control over the asset in case he al= lows it to be used by my region. Note that this does not mean that the regi= on *has* to proxy the asset, just that in case the asset service refuses to= serve a client it does not like, the region can insist on delivery =A0base= d on the capability it originally got. If that fails Proks asset service ca= n not be called VWRAP compliant. =A0

If Prokofy does not want to relinquish =A0that level of= control, fine, it is his right not to, but in that case the dresses should= not be allowed to get into my region in the first place. =A0If people visi= t my region and find themselves naked in the eyes of some others *I* will g= et the blame. =A0As Morgaine says, the technical details of my innocence wi= ll not convince the general public. So I want methods to prevent breaking m= y highly emergent world as much as possible.=A0
My proposal would be that the whatever the region gets MUST be guarant= eed by protocol to be delivered to =A0anybody within the region requesting = it. If the asset service does not want to serve a cryptocomunist copyleftis= t, fine, but IF it has given the region a capability, it MUST serve the ful= l asset to be VWRAP compliant. Its *my* choice as a region deployer to down= load the full asset to be able to guarantee region consistency if I want to= . I will try to avoid that as much as possible, but if my customers complai= n, i will be forces to start doing this for certain asset services that i k= now show discriminatory behaviour against for instance copyleftist.=A0

Finally Morgaine, you keep hammering on the fact that p= roxying by the region does not scale. (I tend to disagree, but that is besi= de the point here). I do agree the asset should not be needlessly transfere= d, but i strongly feel we must insist in the protocol on transferring the *= rights* to view the asset. If that leads to to the region not getting the a= sset at all, so be it, it can warn visitors that their assets will not be v= isible and even offer to serve simple replacements (1). This in turn will e= ncourage the end users to avoid this type of asset service, and Prokofy wil= l go out of business, as should be the case given the behaviour of the serv= ice. And if he pulls it off, thats fine with me also, as long as i do not h= ave to suffer from it due to lack of rigour in the protocol specs. =A0

So, in summary, I very well see that there is no way to= enforce consistent serving behaviour but it should at least be clear that = it is non-standard and not conform the protocol. The way I am understanding= you now, your argument seems to be just one step to far in the direction o= f anarchy.
Or am i misreading you?

--Vaughn

(1) I just realise that the region might cheat = and advertise its own asset brands claiming the competitions assets =A0coul= d not be rendered... Oh well, one might hope that if there is enough choice= in worlds such regions will be forced =A0out of business as well.=A0

On Sat, Apr 2, 2011 at 7:31 AM, Morgaine <morgaine.dinova@googlemail.com> wrote:
Further to my last post, it's worth noting that if you find that you su= ffer poor quality behavior from a particular asset service and it is breaki= ng the consistency of your simulation, with hash-based item addressing you = can also automatically use an alternative asset service in preference= to the one specified in a given URI.

Your client could be configured to attempt the item fetch at a known go= od quality asset service first (perhaps one that you paid to use bec= ause of its better service), automatically, and maybe even dynamically depe= nding on the type of item.

The scheme has a long list of benefits, and overcoming (to some extent)= poor quality asset services is just one of them.


Morgaine.





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


On Sat, Apr 2, 2011 at 4:55 AM, Morgaine <morgaine.dinova@goo= glemail.com> wrote:
Every design choice results in a trade-off, Vaughn, improving one thing at = the expense of something else.=A0 If every time we offered a service we had= to inform its users about the downsides of all the trade-offs we have made= , they would have an awful lot to read. ;-)

The specific trade-off that you are discussing is no different.=A0 A re= gion that proxies all content has the "benefit" of acquiring cont= rol from the asset servers over the items in the region, so that it can ens= ure that everyone in the region not only obtains the items but obtains the = same items as everyone else.=A0 That does indeed provide a greater g= uarantee of consistency than a deployment in which the region only passes a= sset URIs to clients who then fetch the items from asset services separatel= y.=A0 As always though, it's a trade-off, since the proxied design has = very poor scalability compared to the distributed one.

If we're going to warn users of the potential for inconsistency in = the distributed deployment as you suggest, are we also going to warn them o= f non-scalability in the proxied one?=A0 I really don't see much merit = in the idea of warning about design choices.=A0 Many such choices are techn= ical, and the issues are quite likely to be of little interest to non-techn= ical users anyway.=A0 In any case, the better services are likely to provid= e such information in their online documentation, I would guess.

You mentioned users "voting with their feet" or choosing to a= ccept the risk of inconsistency.=A0 Well that will happen anyway, when serv= ices fail and users get annoyed.=A0 If some asset services refuse to send t= he requested items to some users, those services will get a bad reputation = and people will choose different asset services instead.=A0 Likewise, if a = world service proxies everything and so it can't handle a large number = of assets or of people, users will get annoyed at the lag and will go elsew= here.=A0 This user evaluation and "voting with their feet" happen= s already with online services all over the Internet, and I am sure that th= is human process will continue to work when the services are asset and regi= on services.

Back in September 2010, I wrote this post which proposes that we use in= VWRAP a form of asset addressing that provides massive scalability at the = same time as a very high degree of resilience -- http:/= /www.ietf.org/mail-archive/web/vwrap/current/msg00463.html .=A0 It is b= ased on the concept of the URI containing a host part and a hash part, wher= e the hash is generated (once, at the time of storage to the asset service)= using a specified digest algorithm over the content of the asset being ref= erenced.=A0 You may wish to note that if this design were used, the failure= of an asset service to deliver a requested item would result in a failover= request for the item to one or more backup services, using the same hash p= art but with a different host address.

This can go some way towards overcoming the problem that you think migh= t occur when assets are fetched by clients from asset services directly.=A0= Although it won't help when the missing item is available from only a = single asset service, it will help in many other cases, and it will compens= ate for service failures and network outages automatically at the same time= .

PS. This design for hash-based asset addressing is already being tested= by Mojito Sorbet in her experimental world and client.=A0 It would give VW= RAP-based worlds an improved level of service availability, so I think it s= hould be a core feature of our protocol.


Morgaine.




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

On Fri, Apr 1, 2011 at 11:17 PM, Vaughn De= luca <vaughn.deluca@gmail.com> wrote:
This is a questio= n i discussed with Morgaine off-list a while ago (I
intended to send it to the list but pushed the wrong button...) I
think we need to address this problem, and decide how to deal with it.

=A0In Davids deployment draft, section 7.3.1.1 an overview is given van
ways to deliver content to the region. One way is only passing a
capability that allows access to (part of) the resource:

=A0 =A0 =A0 =A0 =A0 7.3.1.1. =A0Content delivery models
=A0 =A0 =A0 =A0 =A0 A range of possible represenations can be passed to a = region for
=A0 =A0 =A0 =A0 =A0 simulation. [...] The other end of the delivery spectr= um involves passing
=A0 =A0 =A0 =A0 =A0 only a URI or capability used to access the rendering<= br> information and a
=A0 =A0 =A0 =A0 =A0 collision mesh,and related data for physical simulatio= n.
=A0 =A0 =A0 =A0 =A0 In such a model, the client is responsible for fetchin= g the additional
=A0 =A0 =A0 =A0 =A0 information needed to render the item's visual pre= sence from a separate
=A0 =A0 =A0 =A0 =A0 service. =A0This fetch can be done *under the credenti= als of the end user*
=A0 =A0 =A0 =A0 =A0 viewing the material [my emphasis--VD] , and divorces = the
simulation from
=A0 =A0 =A0 =A0 =A0 the trust chain needed to manage content. =A0Any autom= ation
is done on a
=A0 =A0 =A0 =A0 =A0 separate host which the content creator or owner trust= s,
interacting with the
=A0 =A0 =A0 =A0 =A0 object through remoted interfaces.

=A0I can see the need for such a setup, however, i feel we are
unpleasantly close to a situation were the coherence of the simulation
falls apart.
In this deployment pattern the region advertises the presence of the
asset, and *some* clients will be able to get it as expected, while
-based on the arbitrary whims of the asset service- others might not.

My hope would be that after the asset server provides the region with
the capability to get the asset, it gives up control. That would mean
that if the client finds the inventory server is unwilling to serve
the content - in spire of the region saying it is present-, the client
should be able to turn around ask the *region* for the asset, (and get
is after all).

=A0If that is not the case, -and there are probably good reasons for the deployment pattern as described- =A0shouldn't we *warn* clients that th= e
region might be inconsistent, so the users behind the client can vote
with their feet, (or take the risk)?

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





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


--0016e6d279f88706fe049ff58033-- From morgaine.dinova@googlemail.com Sat Apr 2 14:09:50 2011 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 1F4573A68C2 for ; Sat, 2 Apr 2011 14:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 qdZQuQ6Nk4PF for ; Sat, 2 Apr 2011 14:09:42 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 054C33A68BF for ; Sat, 2 Apr 2011 14:09:41 -0700 (PDT) Received: by qyk7 with SMTP id 7so2954563qyk.10 for ; Sat, 02 Apr 2011 14:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DrtIkJJ3s7m8urLJKezlPytSDS2teYPHne1xq8d8NOk=; b=Jpi4Jp0olJIugjn95sftydJiJxxsMEhkX5WNEqW09uF0MGVpg21FKspy6W6uK2dK2z srHAkyFuRvI3IkBiFp4Mz/NzOvq4tjvt9bktvfVcW1ZhsJyXqhwk2l01jVoqMdRVXIz8 P7RN/97t9vJ+MWDtRXdsX7OjwwmQcHm9lagmc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=p61R+5LzfUeHUB7qoT4MppGQy4X7qYgmm0eQfx+wP7NPgFc70kWIS/NJvB7cYLVdpd 9n7e7Ds38kwFPxviLHPNlV70cUuWEY+TtQ+y6SVLZC6tDN7zkKpTzfGxdqjRAe4iIyJr AJr40Mbc+pJQhQ8oKGCDbdAaDhUEHIM9Y+8OU= MIME-Version: 1.0 Received: by 10.229.105.82 with SMTP id s18mr179324qco.109.1301778683050; Sat, 02 Apr 2011 14:11:23 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sat, 2 Apr 2011 14:11:22 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Apr 2011 22:11:22 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=002354470e60fab98b049ff5f764 Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 21:09:50 -0000 --002354470e60fab98b049ff5f764 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 2, 2011 at 9:37 PM, Dahlia Trimble wrote: > I would hope a VWRAP protocol definition would include the possibility of > regions proxying assets so such sandboxed clients can play a part in a VWRAP > multiverse. You'll be glad to hear Dahlia that VWRAP is being planned to include that possibility. :-) We have in VWRAP the concept of "deployment patterns" (David wrote a document about them), which are architectural topologies and data flows representing a range of common cases that have been identified as important. The architectures that we see today in SL and in Opensim are among them, and not only for backwards compatibility --- it is expected that some providers will wish to continue to use them indefinitely. As the VWRAP protocols are worked out, this set of documented deployment patterns is intended to act as a requirements check on protocol structure and options, so that we remain on track to meet all our requirements. Of course, that is all theory at the moment, but the intention is there. :-) That said, I think the exact case you describe is a good one to add explicitly to the list of deployment patterns, rather than just hitching a ride on the back of existing proxy architecture. Morgaine. ========================== On Sat, Apr 2, 2011 at 9:37 PM, Dahlia Trimble wrote: > I can see another reason to allow the region to proxy assets, or at least > some service to proxy assets in the same domain as the region. "Sandboxed" > clients such as those which may be based on products as Unity3d or Adobe > Flash may be subject to a "same origin" policy (1), where they may be > restricted from making network connections outside of the domain from which > the application is served. There are workarounds but they may require > additional administration overhead for both asset and region service > providers, or a separate provider which proxies all traffic. I would hope a > VWRAP protocol definition would include the possibility of regions proxying > assets so such sandboxed clients can play a part in a VWRAP multiverse. > > (1) http://en.wikipedia.org/wiki/Same_origin_policy > > > > > On Sat, Apr 2, 2011 at 8:09 AM, Morgaine wrote: > >> Vaughn, I left your final (and very important) point for the end of my >> response, and then I fired off my email without addressing it ... Sorry. :P >> >> >> On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca wrote: >> >>> So I want methods to prevent breaking my highly emergent world as much >>> as possible. >>> >> >> >> Yes indeed!!! >> >> You have a perfectly reasonable requirement for the service that you want >> to operate, and you need some means of meeting it. I agree with that >> wholeheartedly. I only begin to disagree when you hint that your >> requirement must be imposed on everyone, whether they want it or not. That >> I cannot support, and I expect that you did not mean it that way anyway. >> After all, some of my requirements are probably not of interest to you >> either, and you would not wish me to impose them on you. It cuts both ways. >> >> So, how can we enable you to offer a service with many 9's of simulation >> consistency, without imposing that requirement on those who prefer a >> different trade-off? You hinted at the solution yourself, so I'll merely >> elaborate on it. You wrote: >> >> >> >> I would like to argue that the region *should* get the capability to fetch >>> all details. [...] Note that this does not mean that the region *has* to >>> proxy the asset, just that in case the asset service refuses to serve a >>> client it does not like, the region can insist on delivery based on the >>> capability it originally got. >>> >> >> >> >> Perfect. All you need then is an optional query in the protocol that >> allows a region to ask each asset service referenced by assets carried by >> newly arriving avatars the following question: >> >> QUERY: "*Do I have your permission to fetch from your asset service the >> assets normally reserved for client fetches, and to distribute these assets >> to clients directly in the (unexpected) event that I want to?*" >> >> >> That easily maps to an optional capability request of course. If the >> asset service answers "No" to you, then you can deny the incoming avatar >> entry to your region, returning a status that indicates >> >> RESPONSE: "*Asset service X referenced by asset Y does not meet the >> re-distribution requirement requested for entry to region Z*". >> >> >> Your requirement is then satisfied (I believe) without imposing that >> requirement on a region operator who does not need it because they desire a >> different trade-off. Those who don't have your requirement simply won't >> request the capability. >> >> For example, it would be pointless to even ask an asset service founded >> entirely around Creative Commons assets that question, since all CC content >> is perpetually and non-revocably redistributable by anyone and to anyone. >> By not issuing the query we can save ourselves the round-trip time and allow >> faster entry to the region. >> >> Would something like that get the nod from you? >> >> >> PS. You need to note that when an asset service answers "Yes" to your >> query, this does not mean that it will necessarily honor its promise when >> you actually attempt to fetch items. David's very important point about >> independent parties not having control over each other applies here. You >> can at most hope that it will behave well, and perhaps test the promise by >> fetching something. However, if you truly want as many 9's of consistency >> as is obtainable then you will have to fetch all the assets yourself prior >> to allowing entry to the avatar, and that would be a dreadful overhead. >> Most people will probably settle for "*best effort*" approaches, which >> are quite likely to succeed. >> >> >> Morgaine. >> >> >> >> >> >> ===================== >> >> >> On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca wrote: >> >>> Morgaine, Meadhbh, >>> >>> Thanks for the answers, but i see that i have not been clear enough. >>> I think the protocol should demand certain things to prevent the >>> deterioration of the simulation to an unacceptable level. We need to be >>> more precise to prevent problems and i think we can. >>> >>> I was arguing from the perspecive of a region service without making that >>> explicit. Note i was *not* advocating the region proxies everything, just >>> that it lives up to its promises about object presence. Also note that i do >>> *not* always have the option to pick another high quality asset service, >>> since I normally do not own the assets. I will use Prokofy as an example >>> just for the fun of it. He is highly worried about content theft, so (in >>> the unlikely case he wants to start selling stuff outside of SL) he might >>> use this deployment pattern. Assume he sells wonderful sexy dresses to two >>> customers, that can only be fetched from his own asset service for >>> rendering. Both customers go off to "Vaughns highly immersive world" were a >>> party is given. My region receives some physics properties of the dresses >>> for simulation and an address of Proks asset service for high-res details >>> and textures. In this case the region does not even get the capability to >>> fetch the assets, just a link to the asset service and its up to viewer to >>> request the details and show credentials to get them. The two girls meet, >>> both their viewers request the details of the other dress, and Proks asset >>> service grants those requests. They girls admire their dresses and >>> compliment each other with their good taste. Now when i arrive and my viewer >>> request the dress details, Prok's asset service recognises me as the >>> copyleftists that i am. It refuses to serve the asset details -and depending >>> on my viewers behaviour i might get to view two girls in sexy underwear -or >>> wearing even less- instead of party dresses. From a consistency point of >>> view this is a highly undesirable situation, it breaks immersion, and >>> depending on the circumstances might also be embarrassing to the people >>> involved. >>> >>> The key question is if we want to allow this situation to arise within >>> VWRAP compliant worlds. >>> I would like to argue that the region *should* get the capability to >>> fetch all details. In other words, Prokofy would have to give up some >>> control over the asset in case he allows it to be used by my region. Note >>> that this does not mean that the region *has* to proxy the asset, just that >>> in case the asset service refuses to serve a client it does not like, the >>> region can insist on delivery based on the capability it originally got. If >>> that fails Proks asset service can not be called VWRAP compliant. >>> >>> If Prokofy does not want to relinquish that level of control, fine, it >>> is his right not to, but in that case the dresses should not be allowed to >>> get into my region in the first place. If people visit my region and find >>> themselves naked in the eyes of some others *I* will get the blame. As >>> Morgaine says, the technical details of my innocence will not convince the >>> general public. So I want methods to prevent breaking my highly emergent >>> world as much as possible. >>> My proposal would be that the whatever the region gets MUST be guaranteed >>> by protocol to be delivered to anybody within the region requesting it. If >>> the asset service does not want to serve a cryptocomunist copyleftist, fine, >>> but IF it has given the region a capability, it MUST serve the full asset to >>> be VWRAP compliant. Its *my* choice as a region deployer to download the >>> full asset to be able to guarantee region consistency if I want to. I will >>> try to avoid that as much as possible, but if my customers complain, i will >>> be forces to start doing this for certain asset services that i know show >>> discriminatory behaviour against for instance copyleftist. >>> >>> Finally Morgaine, you keep hammering on the fact that proxying by the >>> region does not scale. (I tend to disagree, but that is beside the point >>> here). I do agree the asset should not be needlessly transfered, but i >>> strongly feel we must insist in the protocol on transferring the *rights* to >>> view the asset. If that leads to to the region not getting the asset at all, >>> so be it, it can warn visitors that their assets will not be visible and >>> even offer to serve simple replacements (1). This in turn will encourage the >>> end users to avoid this type of asset service, and Prokofy will go out of >>> business, as should be the case given the behaviour of the service. And if >>> he pulls it off, thats fine with me also, as long as i do not have to suffer >>> from it due to lack of rigour in the protocol specs. >>> >>> So, in summary, I very well see that there is no way to enforce >>> consistent serving behaviour but it should at least be clear that it is >>> non-standard and not conform the protocol. The way I am understanding you >>> now, your argument seems to be just one step to far in the direction of >>> anarchy. >>> Or am i misreading you? >>> >>> --Vaughn >>> >>> >>> (1) I just realise that the region might cheat and advertise its own >>> asset brands claiming the competitions assets could not be rendered... Oh >>> well, one might hope that if there is enough choice in worlds such regions >>> will be forced out of business as well. >>> >>> On Sat, Apr 2, 2011 at 7:31 AM, Morgaine >> > wrote: >>> >>>> Further to my last post, it's worth noting that if you find that you >>>> suffer poor quality behavior from a particular asset service and it is >>>> breaking the consistency of your simulation, with hash-based item addressing >>>> you can also automatically use an alternative asset service *in >>>> preference* to the one specified in a given URI. >>>> >>>> Your client could be configured to attempt the item fetch at a known >>>> good quality asset service *first* (perhaps one that you paid to use >>>> because of its better service), automatically, and maybe even dynamically >>>> depending on the type of item. >>>> >>>> The scheme has a long list of benefits, and overcoming (to some extent) >>>> poor quality asset services is just one of them. >>>> >>>> >>>> Morgaine. >>>> >>>> >>>> >>>> >>>> >>>> =================== >>>> >>>> >>>> On Sat, Apr 2, 2011 at 4:55 AM, Morgaine < >>>> morgaine.dinova@googlemail.com> wrote: >>>> >>>>> Every design choice results in a trade-off, Vaughn, improving one thing >>>>> at the expense of something else. If every time we offered a service we had >>>>> to inform its users about the downsides of all the trade-offs we have made, >>>>> they would have an awful lot to read. ;-) >>>>> >>>>> The specific trade-off that you are discussing is no different. A >>>>> region that proxies all content has the "benefit" of acquiring control from >>>>> the asset servers over the items in the region, so that it can ensure that >>>>> everyone in the region not only obtains the items but obtains the * >>>>> same* items as everyone else. That does indeed provide a greater >>>>> guarantee of consistency than a deployment in which the region only passes >>>>> asset URIs to clients who then fetch the items from asset services >>>>> separately. As always though, it's a trade-off, since the proxied design >>>>> has very poor scalability compared to the distributed one. >>>>> >>>>> If we're going to warn users of the potential for inconsistency in the >>>>> distributed deployment as you suggest, are we also going to warn them of >>>>> non-scalability in the proxied one? I really don't see much merit in the >>>>> idea of warning about design choices. Many such choices are technical, and >>>>> the issues are quite likely to be of little interest to non-technical users >>>>> anyway. In any case, the better services are likely to provide such >>>>> information in their online documentation, I would guess. >>>>> >>>>> You mentioned users "voting with their feet" or choosing to accept the >>>>> risk of inconsistency. Well that will happen anyway, when services fail and >>>>> users get annoyed. If some asset services refuse to send the requested >>>>> items to some users, those services will get a bad reputation and people >>>>> will choose different asset services instead. Likewise, if a world service >>>>> proxies everything and so it can't handle a large number of assets or of >>>>> people, users will get annoyed at the lag and will go elsewhere. This user >>>>> evaluation and "voting with their feet" happens already with online services >>>>> all over the Internet, and I am sure that this human process will continue >>>>> to work when the services are asset and region services. >>>>> >>>>> Back in September 2010, I wrote this post which proposes that we use in >>>>> VWRAP a form of asset addressing that provides massive scalability at the >>>>> same time as a very high degree of resilience -- >>>>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html . It >>>>> is based on the concept of the URI containing a host part and a hash part, >>>>> where the hash is generated (once, at the time of storage to the asset >>>>> service) using a specified digest algorithm over the content of the asset >>>>> being referenced. You may wish to note that if this design were used, the >>>>> failure of an asset service to deliver a requested item would result in a >>>>> failover request for the item to one or more backup services, using the same >>>>> hash part but with a different host address. >>>>> >>>>> This can go some way towards overcoming the problem that you think >>>>> might occur when assets are fetched by clients from asset services >>>>> directly. Although it won't help when the missing item is available from >>>>> only a single asset service, it will help in many other cases, and it will >>>>> compensate for service failures and network outages automatically at the >>>>> same time. >>>>> >>>>> PS. This design for hash-based asset addressing is already being tested >>>>> by Mojito Sorbet in her experimental world and client. It would give >>>>> VWRAP-based worlds an improved level of service availability, so I think it >>>>> should be a core feature of our protocol. >>>>> >>>>> >>>>> Morgaine. >>>>> >>>>> >>>>> >>>>> >>>>> =========================== >>>>> >>>>> >>>>> On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca < >>>>> vaughn.deluca@gmail.com> wrote: >>>>> >>>>>> This is a question i discussed with Morgaine off-list a while ago (I >>>>>> intended to send it to the list but pushed the wrong button...) I >>>>>> think we need to address this problem, and decide how to deal with it. >>>>>> >>>>>> In Davids deployment draft, section 7.3.1.1 an overview is given van >>>>>> ways to deliver content to the region. One way is only passing a >>>>>> capability that allows access to (part of) the resource: >>>>>> >>>>>> 7.3.1.1. Content delivery models >>>>>> A range of possible represenations can be passed to a region >>>>>> for >>>>>> simulation. [...] The other end of the delivery spectrum >>>>>> involves passing >>>>>> only a URI or capability used to access the rendering >>>>>> information and a >>>>>> collision mesh,and related data for physical simulation. >>>>>> In such a model, the client is responsible for fetching the >>>>>> additional >>>>>> information needed to render the item's visual presence from >>>>>> a separate >>>>>> service. This fetch can be done *under the credentials of >>>>>> the end user* >>>>>> viewing the material [my emphasis--VD] , and divorces the >>>>>> simulation from >>>>>> the trust chain needed to manage content. Any automation >>>>>> is done on a >>>>>> separate host which the content creator or owner trusts, >>>>>> interacting with the >>>>>> object through remoted interfaces. >>>>>> >>>>>> I can see the need for such a setup, however, i feel we are >>>>>> unpleasantly close to a situation were the coherence of the simulation >>>>>> falls apart. >>>>>> In this deployment pattern the region advertises the presence of the >>>>>> asset, and *some* clients will be able to get it as expected, while >>>>>> -based on the arbitrary whims of the asset service- others might not. >>>>>> >>>>>> My hope would be that after the asset server provides the region with >>>>>> the capability to get the asset, it gives up control. That would mean >>>>>> that if the client finds the inventory server is unwilling to serve >>>>>> the content - in spire of the region saying it is present-, the client >>>>>> should be able to turn around ask the *region* for the asset, (and get >>>>>> is after all). >>>>>> >>>>>> If that is not the case, -and there are probably good reasons for the >>>>>> deployment pattern as described- shouldn't we *warn* clients that the >>>>>> region might be inconsistent, so the users behind the client can vote >>>>>> with their feet, (or take the risk)? >>>>>> >>>>>> --Vaughn >>>>>> _______________________________________________ >>>>>> 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 > > --002354470e60fab98b049ff5f764 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Apr 2, 2011 at 9:37 PM, Dahlia Trimble <dahliatrimble@gmail.com>= wrote:
I would hope a VWRAP protocol definition would include the=20 possibility of regions proxying assets so such sandboxed clients can=20 play a part in a VWRAP multiverse.


You'll be glad t= o hear Dahlia that VWRAP is being planned to include that possibility. :-)<= br>
We have in VWRAP the concept of "deployment patterns" (Dav= id wrote a document about them), which are architectural topologies and dat= a flows representing a range of common cases that have been identified as i= mportant.=A0 The architectures that we see today in SL and in Opensim are a= mong them, and not only for backwards compatibility ---=A0 it is expected t= hat some providers will wish to continue to use them indefinitely.

As the VWRAP protocols are worked out, this set of documented deploymen= t patterns is intended to act as a requirements check on protocol structure= and options, so that we remain on track to meet all our requirements.

Of course, that is all theory at the moment, but the intention is there= . :-)

That said, I think the exact case you describe is a good one t= o add explicitly to the list of deployment patterns, rather than just hitch= ing a ride on the back of existing proxy architecture.



Morgaine.




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

On Sat, Apr 2, 2011 at 9:37 PM, Dahlia Trimble <<= a href=3D"mailto:dahliatrimble@gmail.com">dahliatrimble@gmail.com> wrote:
I can see another= reason to allow the region to proxy assets, or at least some service to pr= oxy assets in the same domain as the region. "Sandboxed" clients = such as those which may be based on products as Unity3d or Adobe Flash may = be subject to a "same origin" policy (1), where they may be restr= icted from making network connections outside of the domain from which the = application is served. There are workarounds but they may require additiona= l administration overhead for both asset and region service providers, or a= separate provider which proxies all traffic. I would hope a VWRAP protocol= definition would include the possibility of regions proxying assets so suc= h sandboxed clients can play a part in a VWRAP multiverse.

(1) http://en.wikipedia.org/wiki/Same_origin_policy




On Sat, Ap= r 2, 2011 at 8:09 AM, Morgaine <morgaine.dinova@googlemail.co= m> wrote:
Vaughn, I left yo= ur final (and very important) point for the end of my response, and then I = fired off my email without addressing it ...=A0 Sorry. :P


On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca &l= t;vaughn.deluc= a@gmail.com> wrote:
=A0So I want= methods=20 to prevent breaking my highly emergent world as much as possible.


Yes indeed!!!

You have a perfectly reaso= nable requirement for the service that you want to operate, and you need so= me means of meeting it.=A0 I agree with that wholeheartedly.=A0 I only begi= n to disagree when you hint that your requirement must be imposed on everyo= ne, whether they want it or not.=A0 That I cannot support, and I expect tha= t you did not mean it that way anyway.=A0 After all, some of my requirement= s are probably not of interest to you either, and you would not wish me to = impose them on you.=A0 It cuts both ways.

So, how can we enable you to offer a service with many 9's of simul= ation consistency, without imposing that requirement on those who prefer a = different trade-off?=A0 You hinted at the solution yourself, so I'll me= rely elaborate on it.=A0 You wrote:



= I would like to argue that the region *should* get the capability to=20 fetch all details. [...]=A0=20 Note that this does not mean that the region *has* to proxy the asset,=20 just that in case the asset service refuses to serve a client it does=20 not like, the region can insist on delivery =A0based on the capability it= =20 originally got.



Perfect.=A0 All you need then= is an optional query in the protocol that allows a region to ask each asse= t service referenced by assets carried by newly arriving avatars the follow= ing question:

QUERY: "Do I have your permis= sion to fetch from your asset service the assets normally reserved for clie= nt fetches, and to distribute these assets to clients directly in the (unex= pected) event that I want to?"


That easily maps to an optional capability request of course.= =A0 If the asset service answers "No" to you, then you can deny t= he incoming avatar entry to your region, returning a status that indicates<= br>
RESPONSE: "Asset service X re= ferenced by asset Y does not meet the re-distribution requirement requested= for entry to region Z".


Your requirement is then= satisfied (I believe) without imposing that requirement on a region operat= or who does not need it because they desire a different trade-off.=A0 Those= who don't have your requirement simply won't request the capabilit= y.

For example, it would be pointless to even ask an asset service founded= entirely around Creative Commons assets that question, since all CC conten= t is perpetually and non-revocably redistributable by anyone and to anyone.= =A0 By not issuing the query we can save ourselves the round-trip time and = allow faster entry to the region.

Would something like that get the nod from you?


PS. You need= to note that when an asset service answers "Yes" to your query, = this does not mean that it will necessarily honor its promise when you actu= ally attempt to fetch items.=A0 David's very important point about inde= pendent parties not having control over each other applies here.=A0 You can= at most hope that it will behave well, and perhaps test the promise by fet= ching something.=A0 However, if you truly want as many 9's of consisten= cy as is obtainable then you will have to fetch all the assets yourself pri= or to allowing entry to the avatar, and that would be a dreadful overhead.= =A0 Most people will probably settle for "best effort" app= roaches, which are quite likely to succeed.


Morgaine.





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


On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca <v= aughn.deluca@gmail.com> wrote:
Morgaine, Me= adhbh,

Thanks for the answers, but i see that i ha= ve not been clear enough.
I think the protocol should demand certain things to prevent the =A0de= terioration of the simulation to an unacceptable level. We need to be more = precise to prevent problems and i think we can.

I was arguing from the perspecive of a region service w= ithout making that explicit. Note i was *not* advocating the region proxies= everything, just that it lives up to its promises about object presence. A= lso note that i do =A0*not* always have the option to pick another high qua= lity asset service, since I normally do not own the assets. I will use Prok= ofy as an example just for the fun of it. =A0He is highly worried about con= tent theft, so (in the unlikely case he wants to start selling stuff outsid= e of SL) he might use this deployment pattern. =A0Assume he sells wonderful= sexy dresses to two customers, that can only be fetched from his own asset= service for rendering. Both customers go off to "Vaughns highly immer= sive world" were a party is given. =A0My region receives some physics = properties of the dresses for simulation and an address of Proks asset serv= ice for high-res details and textures. In this case the region does not eve= n get the capability to fetch the assets, just a link to the asset service = and its up to viewer to request the details and show credentials to get the= m. The two girls meet, both their viewers request the details of the other = dress, and Proks asset service grants those requests. They girls admire the= ir dresses and compliment each other with their good taste. Now when i arri= ve and my viewer request the dress details, Prok's asset service recogn= ises me as the copyleftists that i am. It refuses to serve the asset detail= s -and depending on my viewers behaviour i might get to view two girls in s= exy underwear -or wearing even less- instead of party dresses. From a consi= stency point of view this is a highly undesirable situation, it breaks imme= rsion, and depending on the circumstances might also be embarrassing to the= people involved.=A0

The key question is if we want to allow this situation = to arise within VWRAP compliant worlds.
I would like to argue tha= t the region *should* get the capability to fetch all details. In other wor= ds, Prokofy would have to give up some control over the asset in case he al= lows it to be used by my region. Note that this does not mean that the regi= on *has* to proxy the asset, just that in case the asset service refuses to= serve a client it does not like, the region can insist on delivery =A0base= d on the capability it originally got. If that fails Proks asset service ca= n not be called VWRAP compliant. =A0

If Prokofy does not want to relinquish =A0that level of= control, fine, it is his right not to, but in that case the dresses should= not be allowed to get into my region in the first place. =A0If people visi= t my region and find themselves naked in the eyes of some others *I* will g= et the blame. =A0As Morgaine says, the technical details of my innocence wi= ll not convince the general public. So I want methods to prevent breaking m= y highly emergent world as much as possible.=A0
My proposal would be that the whatever the region gets MUST be guarant= eed by protocol to be delivered to =A0anybody within the region requesting = it. If the asset service does not want to serve a cryptocomunist copyleftis= t, fine, but IF it has given the region a capability, it MUST serve the ful= l asset to be VWRAP compliant. Its *my* choice as a region deployer to down= load the full asset to be able to guarantee region consistency if I want to= . I will try to avoid that as much as possible, but if my customers complai= n, i will be forces to start doing this for certain asset services that i k= now show discriminatory behaviour against for instance copyleftist.=A0

Finally Morgaine, you keep hammering on the fact that p= roxying by the region does not scale. (I tend to disagree, but that is besi= de the point here). I do agree the asset should not be needlessly transfere= d, but i strongly feel we must insist in the protocol on transferring the *= rights* to view the asset. If that leads to to the region not getting the a= sset at all, so be it, it can warn visitors that their assets will not be v= isible and even offer to serve simple replacements (1). This in turn will e= ncourage the end users to avoid this type of asset service, and Prokofy wil= l go out of business, as should be the case given the behaviour of the serv= ice. And if he pulls it off, thats fine with me also, as long as i do not h= ave to suffer from it due to lack of rigour in the protocol specs. =A0

So, in summary, I very well see that there is no way to= enforce consistent serving behaviour but it should at least be clear that = it is non-standard and not conform the protocol. The way I am understanding= you now, your argument seems to be just one step to far in the direction o= f anarchy.
Or am i misreading you?

--Vaughn

(1) I just realise that the region might cheat = and advertise its own asset brands claiming the competitions assets =A0coul= d not be rendered... Oh well, one might hope that if there is enough choice= in worlds such regions will be forced =A0out of business as well.=A0

On Sat, Apr 2, 2011 at 7:31 AM, Morgaine <morgaine.dinova@googlemail.com> wrote:
Further to my last post, it's worth noting that if you find that you su= ffer poor quality behavior from a particular asset service and it is breaki= ng the consistency of your simulation, with hash-based item addressing you = can also automatically use an alternative asset service in preference= to the one specified in a given URI.

Your client could be configured to attempt the item fetch at a known go= od quality asset service first (perhaps one that you paid to use bec= ause of its better service), automatically, and maybe even dynamically depe= nding on the type of item.

The scheme has a long list of benefits, and overcoming (to some extent)= poor quality asset services is just one of them.


Morgaine.





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


On Sat, Apr 2, 2011 at 4:55 AM, Morgaine <morgaine.dinova@goo= glemail.com> wrote:
Every design choice results in a trade-off, Vaughn, improving one thing at = the expense of something else.=A0 If every time we offered a service we had= to inform its users about the downsides of all the trade-offs we have made= , they would have an awful lot to read. ;-)

The specific trade-off that you are discussing is no different.=A0 A re= gion that proxies all content has the "benefit" of acquiring cont= rol from the asset servers over the items in the region, so that it can ens= ure that everyone in the region not only obtains the items but obtains the = same items as everyone else.=A0 That does indeed provide a greater g= uarantee of consistency than a deployment in which the region only passes a= sset URIs to clients who then fetch the items from asset services separatel= y.=A0 As always though, it's a trade-off, since the proxied design has = very poor scalability compared to the distributed one.

If we're going to warn users of the potential for inconsistency in = the distributed deployment as you suggest, are we also going to warn them o= f non-scalability in the proxied one?=A0 I really don't see much merit = in the idea of warning about design choices.=A0 Many such choices are techn= ical, and the issues are quite likely to be of little interest to non-techn= ical users anyway.=A0 In any case, the better services are likely to provid= e such information in their online documentation, I would guess.

You mentioned users "voting with their feet" or choosing to a= ccept the risk of inconsistency.=A0 Well that will happen anyway, when serv= ices fail and users get annoyed.=A0 If some asset services refuse to send t= he requested items to some users, those services will get a bad reputation = and people will choose different asset services instead.=A0 Likewise, if a = world service proxies everything and so it can't handle a large number = of assets or of people, users will get annoyed at the lag and will go elsew= here.=A0 This user evaluation and "voting with their feet" happen= s already with online services all over the Internet, and I am sure that th= is human process will continue to work when the services are asset and regi= on services.

Back in September 2010, I wrote this post which proposes that we use in= VWRAP a form of asset addressing that provides massive scalability at the = same time as a very high degree of resilience -- http:/= /www.ietf.org/mail-archive/web/vwrap/current/msg00463.html .=A0 It is b= ased on the concept of the URI containing a host part and a hash part, wher= e the hash is generated (once, at the time of storage to the asset service)= using a specified digest algorithm over the content of the asset being ref= erenced.=A0 You may wish to note that if this design were used, the failure= of an asset service to deliver a requested item would result in a failover= request for the item to one or more backup services, using the same hash p= art but with a different host address.

This can go some way towards overcoming the problem that you think migh= t occur when assets are fetched by clients from asset services directly.=A0= Although it won't help when the missing item is available from only a = single asset service, it will help in many other cases, and it will compens= ate for service failures and network outages automatically at the same time= .

PS. This design for hash-based asset addressing is already being tested= by Mojito Sorbet in her experimental world and client.=A0 It would give VW= RAP-based worlds an improved level of service availability, so I think it s= hould be a core feature of our protocol.


Morgaine.




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

On Fri, Apr 1, 2011 at 11:17 PM, Vaughn De= luca <vaughn.deluca@gmail.com> wrote:
This is a questio= n i discussed with Morgaine off-list a while ago (I
intended to send it to the list but pushed the wrong button...) I
think we need to address this problem, and decide how to deal with it.

=A0In Davids deployment draft, section 7.3.1.1 an overview is given van
ways to deliver content to the region. One way is only passing a
capability that allows access to (part of) the resource:

=A0 =A0 =A0 =A0 =A0 7.3.1.1. =A0Content delivery models
=A0 =A0 =A0 =A0 =A0 A range of possible represenations can be passed to a = region for
=A0 =A0 =A0 =A0 =A0 simulation. [...] The other end of the delivery spectr= um involves passing
=A0 =A0 =A0 =A0 =A0 only a URI or capability used to access the rendering<= br> information and a
=A0 =A0 =A0 =A0 =A0 collision mesh,and related data for physical simulatio= n.
=A0 =A0 =A0 =A0 =A0 In such a model, the client is responsible for fetchin= g the additional
=A0 =A0 =A0 =A0 =A0 information needed to render the item's visual pre= sence from a separate
=A0 =A0 =A0 =A0 =A0 service. =A0This fetch can be done *under the credenti= als of the end user*
=A0 =A0 =A0 =A0 =A0 viewing the material [my emphasis--VD] , and divorces = the
simulation from
=A0 =A0 =A0 =A0 =A0 the trust chain needed to manage content. =A0Any autom= ation
is done on a
=A0 =A0 =A0 =A0 =A0 separate host which the content creator or owner trust= s,
interacting with the
=A0 =A0 =A0 =A0 =A0 object through remoted interfaces.

=A0I can see the need for such a setup, however, i feel we are
unpleasantly close to a situation were the coherence of the simulation
falls apart.
In this deployment pattern the region advertises the presence of the
asset, and *some* clients will be able to get it as expected, while
-based on the arbitrary whims of the asset service- others might not.

My hope would be that after the asset server provides the region with
the capability to get the asset, it gives up control. That would mean
that if the client finds the inventory server is unwilling to serve
the content - in spire of the region saying it is present-, the client
should be able to turn around ask the *region* for the asset, (and get
is after all).

=A0If that is not the case, -and there are probably good reasons for the deployment pattern as described- =A0shouldn't we *warn* clients that th= e
region might be inconsistent, so the users behind the client can vote
with their feet, (or take the risk)?

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





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



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


--002354470e60fab98b049ff5f764-- From vaughn.deluca@gmail.com Sat Apr 2 15:00:43 2011 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 16A743A68D4 for ; Sat, 2 Apr 2011 15:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 IeRTV2x4Oxkb for ; Sat, 2 Apr 2011 15:00:38 -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 982103A68DA for ; Sat, 2 Apr 2011 15:00:37 -0700 (PDT) Received: by ewy19 with SMTP id 19so1568052ewy.31 for ; Sat, 02 Apr 2011 15:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zu2ZetF5Ll76kBj3mtxM/7702JbO9i2cqoocpphtjMo=; b=Sid5CA+6l8nbjaIB7narbPXviY9R1POyeCoVd+XREnOFEkeBZeNElp2uK7f3zJvjyQ 7iWSyIEEtsoPHJ/7rOodkPCKFYnL6s+tFJxIR3wyT2neDE84zjjTogarTmHHvRxNLP8c z1L/hCgPn8JhnbyPXH1Ro6ARyKGdFY1xaUqjI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=b1DUdPp1s903OC5B6Ewqmu+3LI6iC5Osh0ySGSBc/8wBIqgkF8ofFzgBSbYYJzcvHI aLylCHjCeQVhaGBRsyrUN65ZxsqXDfdylDUg5zbPgXeLRsbGu3fuRIUND1bR7kY3o8o1 JMVt1zD2JG7E2f5sQdQqjqonSYbYBkRSJL9aw= MIME-Version: 1.0 Received: by 10.213.0.202 with SMTP id 10mr2991311ebc.79.1301781737084; Sat, 02 Apr 2011 15:02:17 -0700 (PDT) Received: by 10.213.17.17 with HTTP; Sat, 2 Apr 2011 15:02:16 -0700 (PDT) In-Reply-To: References: Date: Sun, 3 Apr 2011 00:02:16 +0200 Message-ID: From: Vaughn Deluca To: Morgaine Content-Type: multipart/alternative; boundary=000e0cdfd9f80399f4049ff6aeed Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 22:00:43 -0000 --000e0cdfd9f80399f4049ff6aeed Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Morgain, all, Ahha!, i was halfway my reply explaining that i was *not* asking for the impossible, and did *not* want to impose my rules on others, but that i jus= t wanted to be able to know that stuff that i get into my region will be visible to everybody present, and now i see that you got that. Good! We are on the same page again :) The way the draft relating tot the tourist model is now written i can *never* be sure my visitors all get the same data, because i just juggle th= e crude physics representation, and the viewers negotiate about anything else with the asset service, fully out of my control. You formulated a solution (requesting the transfer rights explicitly). I was originally thinking of a solution where the protocol specifies that the capability to get the crude physics representation of the asset in my region would be *automatically* give me the right to download the full asse= t (if I asked for that). After reading your replies i now see that requestin= g the transfer rights, just like like the viewers will do, is a better solution. The same protocol messages could even be used, The region present its credentials and either gets the capability or not. The region can now tells the agent service which of the assets agent service requested transfe= r the avatar can bring. Its up to the viewer to deal with that information, i= t might simply ignore it. In the latter case the avatar will be simulated by the region without the offending asset. The asset service will subsequently get requests from all viewers connected to the region for the assets in the region. Some of those might not pass trust checks of the asset service. Bad luck for the asset service, it has given a capability to the region and the region will use that to get the asset. If the asset service has second thoughts to often - causing download costs and lag, it will eventually end up on the black list of the region service, and next time around the region might tell the agent service it can't allow asset Y from servivce X becasu= e it does not trust assert service X. It all sounds logical and transparent to me. It also fits what meadhbh said: >my recommendation has always been... "define mechanism, not policy." As far as i can see that is what we do here. Now, this brings me to a point of order. In september Kevin Tweedy made thi= s observation: " Date: Wed, 22 Sep 2010 13:40:15 -0400 May I suggest we stop arbitrarily trying to define things in emails and com= e up with some kind of process into how to define what the first draft specification should include? Doesn=92t W3C have a process on how this wor= ks? I think this is the fundamental problem of this group; we are mixing vision, requirements, and design in the same email. We are making design decisions when we haven=92t even defined the requirements." I fully agree. We used to brainstorm in the group and assumed the editors o= f the drafts would incorporate the generated ideas in new versions of the draft. At times that worked really well, at other times it did work not so well. But currently we have no editors, so we need to do something new.... My question to the group is how do we consolidate this bit of discussion? In general it seems to me we have managed to generate new enthusiasm in the group, and we are on -or close to- the point were we have enough critical mass to continue. In my view we would really benefit from a true editor, an= d it seems nobody is willing to take that responsibility yet. Can we really d= o it collectively on the wiki? It would be a break with the way i think ietf groups normally work, but i might be kind off fitting for this highly diverse group :) So will it work? What alternatives do we have? comments please. --Vaughn On Sat, Apr 2, 2011 at 5:09 PM, Morgaine wr= ote: > Vaughn, I left your final (and very important) point for the end of my > response, and then I fired off my email without addressing it ... Sorry.= :P > > > On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca w= rote: > >> So I want methods to prevent breaking my highly emergent world as much = as >> possible. >> > > > Yes indeed!!! > > You have a perfectly reasonable requirement for the service that you want > to operate, and you need some means of meeting it. I agree with that > wholeheartedly. I only begin to disagree when you hint that your > requirement must be imposed on everyone, whether they want it or not. Th= at > I cannot support, and I expect that you did not mean it that way anyway. > After all, some of my requirements are probably not of interest to you > either, and you would not wish me to impose them on you. It cuts both wa= ys. > > So, how can we enable you to offer a service with many 9's of simulation > consistency, without imposing that requirement on those who prefer a > different trade-off? You hinted at the solution yourself, so I'll merely > elaborate on it. You wrote: > > > > I would like to argue that the region *should* get the capability to fetc= h >> all details. [...] Note that this does not mean that the region *has* t= o >> proxy the asset, just that in case the asset service refuses to serve a >> client it does not like, the region can insist on delivery based on the >> capability it originally got. >> > > > > Perfect. All you need then is an optional query in the protocol that > allows a region to ask each asset service referenced by assets carried by > newly arriving avatars the following question: > > QUERY: "*Do I have your permission to fetch from your asset service the > assets normally reserved for client fetches, and to distribute these asse= ts > to clients directly in the (unexpected) event that I want to?*" > > > That easily maps to an optional capability request of course. If the ass= et > service answers "No" to you, then you can deny the incoming avatar entry = to > your region, returning a status that indicates > > RESPONSE: "*Asset service X referenced by asset Y does not meet the > re-distribution requirement requested for entry to region Z*". > > > Your requirement is then satisfied (I believe) without imposing that > requirement on a region operator who does not need it because they desire= a > different trade-off. Those who don't have your requirement simply won't > request the capability. > > For example, it would be pointless to even ask an asset service founded > entirely around Creative Commons assets that question, since all CC conte= nt > is perpetually and non-revocably redistributable by anyone and to anyone. > By not issuing the query we can save ourselves the round-trip time and al= low > faster entry to the region. > > Would something like that get the nod from you? > > > PS. You need to note that when an asset service answers "Yes" to your > query, this does not mean that it will necessarily honor its promise when > you actually attempt to fetch items. David's very important point about > independent parties not having control over each other applies here. You > can at most hope that it will behave well, and perhaps test the promise b= y > fetching something. However, if you truly want as many 9's of consistenc= y > as is obtainable then you will have to fetch all the assets yourself prio= r > to allowing entry to the avatar, and that would be a dreadful overhead. > Most people will probably settle for "*best effort*" approaches, which ar= e > quite likely to succeed. > > > Morgaine. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca w= rote: > >> Morgaine, Meadhbh, >> >> Thanks for the answers, but i see that i have not been clear enough. >> I think the protocol should demand certain things to prevent the >> deterioration of the simulation to an unacceptable level. We need to be >> more precise to prevent problems and i think we can. >> >> I was arguing from the perspecive of a region service without making tha= t >> explicit. Note i was *not* advocating the region proxies everything, jus= t >> that it lives up to its promises about object presence. Also note that i= do >> *not* always have the option to pick another high quality asset service= , >> since I normally do not own the assets. I will use Prokofy as an example >> just for the fun of it. He is highly worried about content theft, so (i= n >> the unlikely case he wants to start selling stuff outside of SL) he migh= t >> use this deployment pattern. Assume he sells wonderful sexy dresses to = two >> customers, that can only be fetched from his own asset service for >> rendering. Both customers go off to "Vaughns highly immersive world" wer= e a >> party is given. My region receives some physics properties of the dress= es >> for simulation and an address of Proks asset service for high-res detail= s >> and textures. In this case the region does not even get the capability t= o >> fetch the assets, just a link to the asset service and its up to viewer = to >> request the details and show credentials to get them. The two girls meet= , >> both their viewers request the details of the other dress, and Proks ass= et >> service grants those requests. They girls admire their dresses and >> compliment each other with their good taste. Now when i arrive and my vi= ewer >> request the dress details, Prok's asset service recognises me as the >> copyleftists that i am. It refuses to serve the asset details -and depen= ding >> on my viewers behaviour i might get to view two girls in sexy underwear = -or >> wearing even less- instead of party dresses. From a consistency point of >> view this is a highly undesirable situation, it breaks immersion, and >> depending on the circumstances might also be embarrassing to the people >> involved. >> >> The key question is if we want to allow this situation to arise within >> VWRAP compliant worlds. >> I would like to argue that the region *should* get the capability to fet= ch >> all details. In other words, Prokofy would have to give up some control = over >> the asset in case he allows it to be used by my region. Note that this d= oes >> not mean that the region *has* to proxy the asset, just that in case the >> asset service refuses to serve a client it does not like, the region can >> insist on delivery based on the capability it originally got. If that f= ails >> Proks asset service can not be called VWRAP compliant. >> >> If Prokofy does not want to relinquish that level of control, fine, it = is >> his right not to, but in that case the dresses should not be allowed to = get >> into my region in the first place. If people visit my region and find >> themselves naked in the eyes of some others *I* will get the blame. As >> Morgaine says, the technical details of my innocence will not convince t= he >> general public. So I want methods to prevent breaking my highly emergent >> world as much as possible. >> My proposal would be that the whatever the region gets MUST be guarantee= d >> by protocol to be delivered to anybody within the region requesting it.= If >> the asset service does not want to serve a cryptocomunist copyleftist, f= ine, >> but IF it has given the region a capability, it MUST serve the full asse= t to >> be VWRAP compliant. Its *my* choice as a region deployer to download the >> full asset to be able to guarantee region consistency if I want to. I wi= ll >> try to avoid that as much as possible, but if my customers complain, i w= ill >> be forces to start doing this for certain asset services that i know sho= w >> discriminatory behaviour against for instance copyleftist. >> >> Finally Morgaine, you keep hammering on the fact that proxying by the >> region does not scale. (I tend to disagree, but that is beside the point >> here). I do agree the asset should not be needlessly transfered, but i >> strongly feel we must insist in the protocol on transferring the *rights= * to >> view the asset. If that leads to to the region not getting the asset at = all, >> so be it, it can warn visitors that their assets will not be visible and >> even offer to serve simple replacements (1). This in turn will encourage= the >> end users to avoid this type of asset service, and Prokofy will go out o= f >> business, as should be the case given the behaviour of the service. And = if >> he pulls it off, thats fine with me also, as long as i do not have to su= ffer >> from it due to lack of rigour in the protocol specs. >> >> So, in summary, I very well see that there is no way to enforce consiste= nt >> serving behaviour but it should at least be clear that it is non-standar= d >> and not conform the protocol. The way I am understanding you now, your >> argument seems to be just one step to far in the direction of anarchy. >> Or am i misreading you? >> >> --Vaughn >> >> >> (1) I just realise that the region might cheat and advertise its own ass= et >> brands claiming the competitions assets could not be rendered... Oh wel= l, >> one might hope that if there is enough choice in worlds such regions wil= l be >> forced out of business as well. >> >> On Sat, Apr 2, 2011 at 7:31 AM, Morgaine wrote: >> >>> Further to my last post, it's worth noting that if you find that you >>> suffer poor quality behavior from a particular asset service and it is >>> breaking the consistency of your simulation, with hash-based item addre= ssing >>> you can also automatically use an alternative asset service *in >>> preference* to the one specified in a given URI. >>> >>> Your client could be configured to attempt the item fetch at a known go= od >>> quality asset service *first* (perhaps one that you paid to use because >>> of its better service), automatically, and maybe even dynamically depen= ding >>> on the type of item. >>> >>> The scheme has a long list of benefits, and overcoming (to some extent) >>> poor quality asset services is just one of them. >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> >>> On Sat, Apr 2, 2011 at 4:55 AM, Morgaine >> > wrote: >>> >>>> Every design choice results in a trade-off, Vaughn, improving one thin= g >>>> at the expense of something else. If every time we offered a service = we had >>>> to inform its users about the downsides of all the trade-offs we have = made, >>>> they would have an awful lot to read. ;-) >>>> >>>> The specific trade-off that you are discussing is no different. A >>>> region that proxies all content has the "benefit" of acquiring control= from >>>> the asset servers over the items in the region, so that it can ensure = that >>>> everyone in the region not only obtains the items but obtains the *sam= e >>>> * items as everyone else. That does indeed provide a greater guarante= e >>>> of consistency than a deployment in which the region only passes asset= URIs >>>> to clients who then fetch the items from asset services separately. A= s >>>> always though, it's a trade-off, since the proxied design has very poo= r >>>> scalability compared to the distributed one. >>>> >>>> If we're going to warn users of the potential for inconsistency in the >>>> distributed deployment as you suggest, are we also going to warn them = of >>>> non-scalability in the proxied one? I really don't see much merit in = the >>>> idea of warning about design choices. Many such choices are technical= , and >>>> the issues are quite likely to be of little interest to non-technical = users >>>> anyway. In any case, the better services are likely to provide such >>>> information in their online documentation, I would guess. >>>> >>>> You mentioned users "voting with their feet" or choosing to accept the >>>> risk of inconsistency. Well that will happen anyway, when services fa= il and >>>> users get annoyed. If some asset services refuse to send the requeste= d >>>> items to some users, those services will get a bad reputation and peop= le >>>> will choose different asset services instead. Likewise, if a world se= rvice >>>> proxies everything and so it can't handle a large number of assets or = of >>>> people, users will get annoyed at the lag and will go elsewhere. This= user >>>> evaluation and "voting with their feet" happens already with online se= rvices >>>> all over the Internet, and I am sure that this human process will cont= inue >>>> to work when the services are asset and region services. >>>> >>>> Back in September 2010, I wrote this post which proposes that we use i= n >>>> VWRAP a form of asset addressing that provides massive scalability at = the >>>> same time as a very high degree of resilience -- >>>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html . It >>>> is based on the concept of the URI containing a host part and a hash p= art, >>>> where the hash is generated (once, at the time of storage to the asset >>>> service) using a specified digest algorithm over the content of the as= set >>>> being referenced. You may wish to note that if this design were used,= the >>>> failure of an asset service to deliver a requested item would result i= n a >>>> failover request for the item to one or more backup services, using th= e same >>>> hash part but with a different host address. >>>> >>>> This can go some way towards overcoming the problem that you think mig= ht >>>> occur when assets are fetched by clients from asset services directly. >>>> Although it won't help when the missing item is available from only a = single >>>> asset service, it will help in many other cases, and it will compensat= e for >>>> service failures and network outages automatically at the same time. >>>> >>>> PS. This design for hash-based asset addressing is already being teste= d >>>> by Mojito Sorbet in her experimental world and client. It would give >>>> VWRAP-based worlds an improved level of service availability, so I thi= nk it >>>> should be a core feature of our protocol. >>>> >>>> >>>> Morgaine. >>>> >>>> >>>> >>>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>> >>>> >>>> On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca >>> > wrote: >>>> >>>>> This is a question i discussed with Morgaine off-list a while ago (I >>>>> intended to send it to the list but pushed the wrong button...) I >>>>> think we need to address this problem, and decide how to deal with it= . >>>>> >>>>> In Davids deployment draft, section 7.3.1.1 an overview is given van >>>>> ways to deliver content to the region. One way is only passing a >>>>> capability that allows access to (part of) the resource: >>>>> >>>>> 7.3.1.1. Content delivery models >>>>> A range of possible represenations can be passed to a regio= n >>>>> for >>>>> simulation. [...] The other end of the delivery spectrum >>>>> involves passing >>>>> only a URI or capability used to access the rendering >>>>> information and a >>>>> collision mesh,and related data for physical simulation. >>>>> In such a model, the client is responsible for fetching the >>>>> additional >>>>> information needed to render the item's visual presence fro= m >>>>> a separate >>>>> service. This fetch can be done *under the credentials of >>>>> the end user* >>>>> viewing the material [my emphasis--VD] , and divorces the >>>>> simulation from >>>>> the trust chain needed to manage content. Any automation >>>>> is done on a >>>>> separate host which the content creator or owner trusts, >>>>> interacting with the >>>>> object through remoted interfaces. >>>>> >>>>> I can see the need for such a setup, however, i feel we are >>>>> unpleasantly close to a situation were the coherence of the simulatio= n >>>>> falls apart. >>>>> In this deployment pattern the region advertises the presence of the >>>>> asset, and *some* clients will be able to get it as expected, while >>>>> -based on the arbitrary whims of the asset service- others might not. >>>>> >>>>> My hope would be that after the asset server provides the region with >>>>> the capability to get the asset, it gives up control. That would mean >>>>> that if the client finds the inventory server is unwilling to serve >>>>> the content - in spire of the region saying it is present-, the clien= t >>>>> should be able to turn around ask the *region* for the asset, (and ge= t >>>>> is after all). >>>>> >>>>> If that is not the case, -and there are probably good reasons for th= e >>>>> deployment pattern as described- shouldn't we *warn* clients that th= e >>>>> region might be inconsistent, so the users behind the client can vote >>>>> with their feet, (or take the risk)? >>>>> >>>>> --Vaughn >>>>> _______________________________________________ >>>>> vwrap mailing list >>>>> vwrap@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/vwrap >>>>> >>>> >>>> >>> >> > --000e0cdfd9f80399f4049ff6aeed Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Morgain, all,

Ahha!, i was halfway my reply e= xplaining that i was *not* asking for the impossible, and did *not* want to= impose my rules on others, but that i just wanted to be able to know that = stuff that i get into my region will be visible to everybody present, and n= ow i see that you got that. Good!
We are on the same page again :)

The way the = draft relating tot the tourist model is now written i can *never* be sure m= y visitors all get the same data, because i just juggle the crude physics r= epresentation, and the viewers negotiate about anything else with the asset= service, fully out of my control.=A0

You formulated a solution (requesting the transfer righ= ts explicitly). =A0
I was originally thinking of a solution where= the protocol specifies that the capability to get the crude physics repres= entation of the asset in my region would be *automatically* give me the rig= ht to download the full asset (if I asked for that). =A0After reading your = replies i now see that requesting the transfer rights, just like like the v= iewers will do, is a better solution. The same protocol messages could even= be used, The region present its credentials and either gets the capability= or not. =A0The region can now tells the agent service which of the assets = agent service requested transfer the avatar can bring. Its up to the viewer= to deal with that information, it might simply ignore it. In the latter ca= se the avatar will be simulated by the region without the offending asset. = The asset service will subsequently get requests from all viewers connected= to the region for the assets in the region. Some of those might not pass t= rust checks of the asset service. Bad luck for the asset service, it has gi= ven a capability to the region and the region will use that to get the asse= t. If the asset service has second thoughts to often - causing download cos= ts and lag, it will eventually end up on the black list of the region servi= ce, and next time around the region =A0might tell the agent service it can&= #39;t allow asset Y from servivce X becasue it does not trust assert servic= e X. =A0
It all sounds logical and transparent to me.

= It also fits what meadhbh said:
>my recommendation has always = been... "define mechanism, not policy."
As far as i can= see that is what we do here.

Now, this brings me to a point of order. In september K= evin Tweedy made this observation:

"<kevin= .tweedy at xrgrid.com>
Date:= Wed, 22 Sep 2010 13:40:15 -0400
May I suggest we stop arbitrarily trying to define things in emails an= d come up with some kind of process into how to define what the first draft= specification should include? =A0Doesn=92t W3C have a process on how this = works? =A0I think this is the fundamental problem of this group; we are mix= ing vision, requirements, and design in the same email. =A0We are making de= sign decisions when we haven=92t even defined the requirements."

I fully agree. We used to brainstorm in the group and a= ssumed the editors of the drafts would incorporate the generated ideas in n= ew versions of the draft. =A0At times that worked really well, at other tim= es it did work not so well. But currently we have no editors, so we need to= do something new....

My question to the group is how do we consolidate this = bit of discussion?=A0

In general it seems to me we= have managed to generate new enthusiasm in the group, and we are on -or cl= ose to- the =A0point were we have enough critical mass to continue. In my v= iew we would really benefit from a true editor, and it seems nobody is will= ing to take that responsibility yet. Can we really do it collectively on th= e wiki? It would be a break with the way i think ietf groups normally work,= but i might be =A0kind off fitting for this highly diverse group =A0:)

So will it work? What alternatives do we have? =A0comme= nts please.

--Vaughn

On Sat, Apr 2, 2011 at 5:09 PM, Morgaine <morgaine.dinova@googlemail.com= > wrote:
Vaughn, I left your final (and very importa= nt) point for the end of my response, and then I fired off my email without= addressing it ...=A0 Sorry. :P


On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca &l= t;vaughn.deluc= a@gmail.com> wrote:
=A0So I want metho= ds=20 to prevent breaking my highly emergent world as much as possible.


Yes indeed!!!

You have a perfectly reaso= nable requirement for the service that you want to operate, and you need so= me means of meeting it.=A0 I agree with that wholeheartedly.=A0 I only begi= n to disagree when you hint that your requirement must be imposed on everyo= ne, whether they want it or not.=A0 That I cannot support, and I expect tha= t you did not mean it that way anyway.=A0 After all, some of my requirement= s are probably not of interest to you either, and you would not wish me to = impose them on you.=A0 It cuts both ways.

So, how can we enable you to offer a service with many 9's of simul= ation consistency, without imposing that requirement on those who prefer a = different trade-off?=A0 You hinted at the solution yourself, so I'll me= rely elaborate on it.=A0 You wrote:



I would like to argue that the region *should* get the capability to=20 fetch all details. [...]=A0=20 Note that this does not mean that the region *has* to proxy the asset,=20 just that in case the asset service refuses to serve a client it does=20 not like, the region can insist on delivery =A0based on the capability it= =20 originally got.



Perfect.=A0 All you need then= is an optional query in the protocol that allows a region to ask each asse= t service referenced by assets carried by newly arriving avatars the follow= ing question:

QUERY: "Do I have your permissi= on to fetch from your asset service the assets normally reserved for client= fetches, and to distribute these assets to clients directly in the (unexpe= cted) event that I want to?"


That easily maps to an optional capability request of course.= =A0 If the asset service answers "No" to you, then you can deny t= he incoming avatar entry to your region, returning a status that indicates<= br>
RESPONSE: "Asset service X refe= renced by asset Y does not meet the re-distribution requirement requested f= or entry to region Z".


Your requirement is then s= atisfied (I believe) without imposing that requirement on a region operator= who does not need it because they desire a different trade-off.=A0 Those w= ho don't have your requirement simply won't request the capability.=

For example, it would be pointless to even ask an asset service founded= entirely around Creative Commons assets that question, since all CC conten= t is perpetually and non-revocably redistributable by anyone and to anyone.= =A0 By not issuing the query we can save ourselves the round-trip time and = allow faster entry to the region.

Would something like that get the nod from you?


PS. You need= to note that when an asset service answers "Yes" to your query, = this does not mean that it will necessarily honor its promise when you actu= ally attempt to fetch items.=A0 David's very important point about inde= pendent parties not having control over each other applies here.=A0 You can= at most hope that it will behave well, and perhaps test the promise by fet= ching something.=A0 However, if you truly want as many 9's of consisten= cy as is obtainable then you will have to fetch all the assets yourself pri= or to allowing entry to the avatar, and that would be a dreadful overhead.= =A0 Most people will probably settle for "best effort" app= roaches, which are quite likely to succeed.


Morgaine.





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

=
On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Delu= ca <vaughn.deluca@gmail.com> wrote:
Morgaine, Meadhbh,=

Thanks for the answers, but i see that i have not= been clear enough.
I think the protocol should demand certain things to prevent the =A0de= terioration of the simulation to an unacceptable level. We need to be more = precise to prevent problems and i think we can.

I was arguing from the perspecive of a region service w= ithout making that explicit. Note i was *not* advocating the region proxies= everything, just that it lives up to its promises about object presence. A= lso note that i do =A0*not* always have the option to pick another high qua= lity asset service, since I normally do not own the assets. I will use Prok= ofy as an example just for the fun of it. =A0He is highly worried about con= tent theft, so (in the unlikely case he wants to start selling stuff outsid= e of SL) he might use this deployment pattern. =A0Assume he sells wonderful= sexy dresses to two customers, that can only be fetched from his own asset= service for rendering. Both customers go off to "Vaughns highly immer= sive world" were a party is given. =A0My region receives some physics = properties of the dresses for simulation and an address of Proks asset serv= ice for high-res details and textures. In this case the region does not eve= n get the capability to fetch the assets, just a link to the asset service = and its up to viewer to request the details and show credentials to get the= m. The two girls meet, both their viewers request the details of the other = dress, and Proks asset service grants those requests. They girls admire the= ir dresses and compliment each other with their good taste. Now when i arri= ve and my viewer request the dress details, Prok's asset service recogn= ises me as the copyleftists that i am. It refuses to serve the asset detail= s -and depending on my viewers behaviour i might get to view two girls in s= exy underwear -or wearing even less- instead of party dresses. From a consi= stency point of view this is a highly undesirable situation, it breaks imme= rsion, and depending on the circumstances might also be embarrassing to the= people involved.=A0

The key question is if we want to allow this situation = to arise within VWRAP compliant worlds.
I would like to argue tha= t the region *should* get the capability to fetch all details. In other wor= ds, Prokofy would have to give up some control over the asset in case he al= lows it to be used by my region. Note that this does not mean that the regi= on *has* to proxy the asset, just that in case the asset service refuses to= serve a client it does not like, the region can insist on delivery =A0base= d on the capability it originally got. If that fails Proks asset service ca= n not be called VWRAP compliant. =A0

If Prokofy does not want to relinquish =A0that level of= control, fine, it is his right not to, but in that case the dresses should= not be allowed to get into my region in the first place. =A0If people visi= t my region and find themselves naked in the eyes of some others *I* will g= et the blame. =A0As Morgaine says, the technical details of my innocence wi= ll not convince the general public. So I want methods to prevent breaking m= y highly emergent world as much as possible.=A0
My proposal would be that the whatever the region gets MUST be guarant= eed by protocol to be delivered to =A0anybody within the region requesting = it. If the asset service does not want to serve a cryptocomunist copyleftis= t, fine, but IF it has given the region a capability, it MUST serve the ful= l asset to be VWRAP compliant. Its *my* choice as a region deployer to down= load the full asset to be able to guarantee region consistency if I want to= . I will try to avoid that as much as possible, but if my customers complai= n, i will be forces to start doing this for certain asset services that i k= now show discriminatory behaviour against for instance copyleftist.=A0

Finally Morgaine, you keep hammering on the fact that p= roxying by the region does not scale. (I tend to disagree, but that is besi= de the point here). I do agree the asset should not be needlessly transfere= d, but i strongly feel we must insist in the protocol on transferring the *= rights* to view the asset. If that leads to to the region not getting the a= sset at all, so be it, it can warn visitors that their assets will not be v= isible and even offer to serve simple replacements (1). This in turn will e= ncourage the end users to avoid this type of asset service, and Prokofy wil= l go out of business, as should be the case given the behaviour of the serv= ice. And if he pulls it off, thats fine with me also, as long as i do not h= ave to suffer from it due to lack of rigour in the protocol specs. =A0

So, in summary, I very well see that there is no way to= enforce consistent serving behaviour but it should at least be clear that = it is non-standard and not conform the protocol. The way I am understanding= you now, your argument seems to be just one step to far in the direction o= f anarchy.
Or am i misreading you?

--Vaughn

(1) I just realise that the region might cheat = and advertise its own asset brands claiming the competitions assets =A0coul= d not be rendered... Oh well, one might hope that if there is enough choice= in worlds such regions will be forced =A0out of business as well.=A0

On Sat, Apr 2, 2011 at 7:31 AM, Morgaine <morgaine.dinova@googlemail.com> wrote:
Further to my last post, it's worth noting that if you find that you su= ffer poor quality behavior from a particular asset service and it is breaki= ng the consistency of your simulation, with hash-based item addressing you = can also automatically use an alternative asset service in preference= to the one specified in a given URI.

Your client could be configured to attempt the item fetch at a known go= od quality asset service first (perhaps one that you paid to use bec= ause of its better service), automatically, and maybe even dynamically depe= nding on the type of item.

The scheme has a long list of benefits, and overcoming (to some extent)= poor quality asset services is just one of them.


Morgaine.





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


On Sat, Apr 2, 2011 at 4:55 AM, Morgaine <morgaine.dinova@goo= glemail.com> wrote:
Every design choice results in a trade-off, Vaughn, improving one thing at = the expense of something else.=A0 If every time we offered a service we had= to inform its users about the downsides of all the trade-offs we have made= , they would have an awful lot to read. ;-)

The specific trade-off that you are discussing is no different.=A0 A re= gion that proxies all content has the "benefit" of acquiring cont= rol from the asset servers over the items in the region, so that it can ens= ure that everyone in the region not only obtains the items but obtains the = same items as everyone else.=A0 That does indeed provide a greater g= uarantee of consistency than a deployment in which the region only passes a= sset URIs to clients who then fetch the items from asset services separatel= y.=A0 As always though, it's a trade-off, since the proxied design has = very poor scalability compared to the distributed one.

If we're going to warn users of the potential for inconsistency in = the distributed deployment as you suggest, are we also going to warn them o= f non-scalability in the proxied one?=A0 I really don't see much merit = in the idea of warning about design choices.=A0 Many such choices are techn= ical, and the issues are quite likely to be of little interest to non-techn= ical users anyway.=A0 In any case, the better services are likely to provid= e such information in their online documentation, I would guess.

You mentioned users "voting with their feet" or choosing to a= ccept the risk of inconsistency.=A0 Well that will happen anyway, when serv= ices fail and users get annoyed.=A0 If some asset services refuse to send t= he requested items to some users, those services will get a bad reputation = and people will choose different asset services instead.=A0 Likewise, if a = world service proxies everything and so it can't handle a large number = of assets or of people, users will get annoyed at the lag and will go elsew= here.=A0 This user evaluation and "voting with their feet" happen= s already with online services all over the Internet, and I am sure that th= is human process will continue to work when the services are asset and regi= on services.

Back in September 2010, I wrote this post which proposes that we use in= VWRAP a form of asset addressing that provides massive scalability at the = same time as a very high degree of resilience -- http:/= /www.ietf.org/mail-archive/web/vwrap/current/msg00463.html .=A0 It is b= ased on the concept of the URI containing a host part and a hash part, wher= e the hash is generated (once, at the time of storage to the asset service)= using a specified digest algorithm over the content of the asset being ref= erenced.=A0 You may wish to note that if this design were used, the failure= of an asset service to deliver a requested item would result in a failover= request for the item to one or more backup services, using the same hash p= art but with a different host address.

This can go some way towards overcoming the problem that you think migh= t occur when assets are fetched by clients from asset services directly.=A0= Although it won't help when the missing item is available from only a = single asset service, it will help in many other cases, and it will compens= ate for service failures and network outages automatically at the same time= .

PS. This design for hash-based asset addressing is already being tested= by Mojito Sorbet in her experimental world and client.=A0 It would give VW= RAP-based worlds an improved level of service availability, so I think it s= hould be a core feature of our protocol.


Morgaine.




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

On Fri, Apr 1, 2011 at 11:17 PM, Vaughn De= luca <vaughn.deluca@gmail.com> wrote:
This is a question i di= scussed with Morgaine off-list a while ago (I
intended to send it to the list but pushed the wrong button...) I
think we need to address this problem, and decide how to deal with it.

=A0In Davids deployment draft, section 7.3.1.1 an overview is given van
ways to deliver content to the region. One way is only passing a
capability that allows access to (part of) the resource:

=A0 =A0 =A0 =A0 =A0 7.3.1.1. =A0Content delivery models
=A0 =A0 =A0 =A0 =A0 A range of possible represenations can be passed to a = region for
=A0 =A0 =A0 =A0 =A0 simulation. [...] The other end of the delivery spectr= um involves passing
=A0 =A0 =A0 =A0 =A0 only a URI or capability used to access the rendering<= br> information and a
=A0 =A0 =A0 =A0 =A0 collision mesh,and related data for physical simulatio= n.
=A0 =A0 =A0 =A0 =A0 In such a model, the client is responsible for fetchin= g the additional
=A0 =A0 =A0 =A0 =A0 information needed to render the item's visual pre= sence from a separate
=A0 =A0 =A0 =A0 =A0 service. =A0This fetch can be done *under the credenti= als of the end user*
=A0 =A0 =A0 =A0 =A0 viewing the material [my emphasis--VD] , and divorces = the
simulation from
=A0 =A0 =A0 =A0 =A0 the trust chain needed to manage content. =A0Any autom= ation
is done on a
=A0 =A0 =A0 =A0 =A0 separate host which the content creator or owner trust= s,
interacting with the
=A0 =A0 =A0 =A0 =A0 object through remoted interfaces.

=A0I can see the need for such a setup, however, i feel we are
unpleasantly close to a situation were the coherence of the simulation
falls apart.
In this deployment pattern the region advertises the presence of the
asset, and *some* clients will be able to get it as expected, while
-based on the arbitrary whims of the asset service- others might not.

My hope would be that after the asset server provides the region with
the capability to get the asset, it gives up control. That would mean
that if the client finds the inventory server is unwilling to serve
the content - in spire of the region saying it is present-, the client
should be able to turn around ask the *region* for the asset, (and get
is after all).

=A0If that is not the case, -and there are probably good reasons for the deployment pattern as described- =A0shouldn't we *warn* clients that th= e
region might be inconsistent, so the users behind the client can vote
with their feet, (or take the risk)?

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





--000e0cdfd9f80399f4049ff6aeed-- From morgaine.dinova@googlemail.com Sat Apr 2 15:08:14 2011 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 785E83A68D4 for ; Sat, 2 Apr 2011 15:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=-0.687, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 117j23cvntxP for ; Sat, 2 Apr 2011 15:08:12 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 265493A68D1 for ; Sat, 2 Apr 2011 15:08:12 -0700 (PDT) Received: by qwg5 with SMTP id 5so3206608qwg.31 for ; Sat, 02 Apr 2011 15:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=BgOZGU4ww0SDUBvaKRfUUGKK6y4w+DDbtZjVUMoP8tg=; b=TIYbV0AiP3fdKkbHvqXe2O0lfqA1+oimLC4Z+McPtqZC+u8kp0n6hRAT9ixLmEE1E1 BxR6oPkUF0tjsn34mEl5784WzbfsoU3q9wO324ryTPmxWhnQT/1VR8+3IayJY2JEKIhP kjJL0zOxblnc9FTJnKo6iV4SeLnUzh8RKJzjY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=m+lokZnqFzxcZ+wGhU6J0DU5beehu8LXtmxRKNxJkfRLdoSS+9AgWjBZNww8uMjNy6 vSVqEsjuQbCudFcFttzZ5J+ygQWv81DF1JyMoQGTBfUM2pVQEQ0r7C+1bUZM/ivOLI4e 7/djylq7vIH5tlsxsa8R3z437OPoV/5RpknW4= MIME-Version: 1.0 Received: by 10.229.105.82 with SMTP id s18mr200303qco.109.1301782192223; Sat, 02 Apr 2011 15:09:52 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sat, 2 Apr 2011 15:09:52 -0700 (PDT) In-Reply-To: References: <20110402.101259.14412.0@webmail09.vgs.untd.com> <20110402171923.13176462@hikaru.localdomain> Date: Sat, 2 Apr 2011 23:09:52 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=002354470e60247707049ff6c9a9 Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 22:08:14 -0000 --002354470e60247707049ff6c9a9 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 2, 2011 at 6:01 PM, Meadhbh Hamrick wrote: > > if you're a *company* like Linden that needs to respond to DMCA takedown > requests, you're likely to require the client trust knob turned up a > bit. if you're an *enterprise*, you're going to want that trust knob > turned all the way up. if you're the *pirate bay*, you're going to > intentionally want that trust knob turned all the way down. > > To avoid the possibility that new readers might get the wrong impression, I'll point out that there aren't just two types of player in the virtual worlds scene, honest enterprise people and evil pirates. I wouldn't want anyone new to think that such an impression was being conveyed or endorsed by anyone here, and of course I'm positive it was not the intention in Meadhbh's comment. Education, research, Free/Open Source Software and Creative Commons communities and a plethora of other groups deal either largely or exclusively in free/libre content, sharing their work with each other totally legally and honestly, and very frequently using content licenses that permit unlimited distribution and require neither DRM nor any machinery of trust when this content is conveyed. Groups such as these make up what is sometimes called the "open community" segment of Internet users, and it is a huge, vibrant, and very forward looking community. Many of us here share a mindset with that open community as users or developers and consider ourselves part of it, and we are working towards VW interop protocols that will allow our worlds to bloom and flourish as a result of freely sharing open-licensed content and creating enormous synergy by combining people's efforts without inappropriate barriers. It is this open community which has important requirements that differ in some ways from corporate ones, not some pirates, and I would strongly encourage that the security aspects of VWRAP be addressed in this light, before someone accuses us of fear-mongering. As Carlo pointed out very well, the needs of the open community are not being met *at all* by current VW services, and this is a major shortcoming which we will need to remedy in VWRAP. I am looking forward eagerly to that aspect of our protocol design effort. Morgaine. ========================= On Sat, Apr 2, 2011 at 6:01 PM, Meadhbh Hamrick wrote: > yes. there is something missing in the protocol. it's trust. you don't > put "trust" in a protocol, you put "security" in a protocol. at the > end of the day, the people using this protocol will need to decide > whom they trust. this is why there was a security model and the > ability of the protocol to "securely carry trust." > > the idea is that the protocol would carry cryptographically > unforgeable attestations of an endpoint's identity. this identity > would then be evaluated by protocol participants to see if it is > "trusted." > > there's no place in the protocol that says "you must trust a specific > entity," but rather a mechanism deployers can use to carry the > identity of people wishing to be trusted. > > at the end of the day, an asset service should only barf up assets to > trusted simulation services. simulators SHOULD only allow people on > the grid they trust (for some definition of the word "trust.") > > if you're a company like Linden that needs to respond to DMCA takedown > requests, you're likely to require the client trust knob turned up a > bit. if you're an enterprise, you're going to want that trust knob > turned all the way up. if you're the pirate bay, you're going to > intentionally want that trust knob turned all the way down. > > as protocol developers, it's our duty to create a protocol that meets > everyone's use cases. so... i mean... feel free to try to define a > protocol that mandates the use of DRM or blesses a particular trust > point, but the likelihood of it being widely supported is.. > approximately nil. > > my recommendation has always been... "define mechanism, not policy." > > -cheers > -meadhbh > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Sat, Apr 2, 2011 at 8:19 AM, Carlo Wood wrote: > > On Sat, 2 Apr 2011 14:12:59 GMT > > "dyerbrookme@juno.com" wrote: > > > >> BTW, the Red Zone statistics of 9 million scans with only 78,000 > >> rogue viewers captured lets us know that this problem is exaggerated > >> -- and usually by engineers who claim there is no technical solution. > > > > Just for the record, from a hacker/engineer: there is no technical > > solution. It is possible to copy everything (and without being detected > > by a "Red Zone" which can only detect rogue viewers that were released > > to the public and explicitly make a point of being detectable > > in the first place (call that bragging: no fun in releasing a "k3wl" > > viewer if others (or even the coder himself) can't see that it is being > > used.) So, there is a psychological advantage for the detectors, but > > not really a technical one. > > > > Lets concentrate on textures for the moment to explain this. > > > > In order to see an object, or clothing, with the appropriate textures, > > those textures have to be downloadable for the viewer. There is nothing > > you can do about that short of running the whole viewer server-side > > and providing a video. But even in that case it would technically be > > possible to rip the textures: they are still visible (ie, you could > > make a screenshot of the surface of a wall). I don't consider the > > video-broadcast to even be remotely interesting, certainly not from the > > viewpoint of VWRAP so lets forget that for the moment and just accept > > that it is possible for anyone to store whatever they SEE to their > harddisk. > > > > Secondly, if the first creator could upload this texture then so can > > the ripper. And don't tell me software exists that can detect if > > an uploaded texture "looks like" one of the already existing billion > > textures that were uploaded before. If the texture is converted twice, > > ie from jpeg2000 to jpg to tga and then uploaded, then you'd need a > > human to look at the original and the newly uploaded texture at the > > same time to judge that it is MAYBE a copy - which then can only be > > proved in court if the original creator can prove that his original > > textures are 100% his own and not, for example, downloaded from the > > internet somewhere (because in that case the other uploader could > > have used the same source). > > > > A real problem, currently in SL, is imho the complete lack of > > support for FREE things. The amount of restriction (for people with > > honest viewers) is tremendous: if you're not an expert or do not pay > > attention for a second, then your creation is not truely free anymore. > > Everything defaults to very copyleft unfriendly settings. I'm trying to > > get my friends, who are very willing in that regard, to only create > > full permission stuff, but it's simply near impossible to keep > > something full permission and often we're stuck with something nobody > > else can change or edit because the creator forgot to set the bit of > > the contents of an object after changing the group etc blah blah... > > > > For example, last a good friend of me wanted my help with making a > > large amount of changes on his sim: hunderds of objects had to be > > adjusted... He was willing to: > > 1) Add me to any group necessary. > > 2) Give me his build rights > > 3) Transfer any object to me (temporary ownership transfer) > > 4) Make any adjustments to the objects and the objects contents > > needed to allow me to access what I needed to access. > > etc etc > > > > The end result: He had to do it all by himself. It was impossible to > > give me enough access to help him (for those who don't believe that, > > one of things involved changing the "anyone can move" bit of an > > object in the contents of objects: it is not possible to take anything > > out of the contents (ie copy it to your inventory) when it's no > > transfer, and therefore you can't edit it, even though it's modify > > and you get all the rights that the owner can give you). > > > > Sorry, but that is unacceptable; and it CLEARLY shows that something is > > missing from the protocol. > > > > Now the above example doesn't show that a free object is not supported, > > it only make clear that non-free objects can be very annoying even in > > situations where the owner has all the rights to do what he wants to > > do. There are many other such examples. Hence, it shows that it is very > > annoying that an object is non-free by default at so many levels that > > you need an IQ of over 140 to create one and those permissions erode > > quickly to non-free. Even the so called "freebies" are non-free by the > > way: they are almost always no transfer. Hell, even the default shape > > that you can when you create a new account is no transfer, what kind of > > insanity is that?! > > > > I think you might find a lot of people, like myself, a lot more willing > > to help out with thinking of ways on how to protect property in virtual > > worlds when first it is assured that those who want to create things > > that are FREE are equally supported as the commercial guys out there. > > > > -- > > Carlo Wood > > _______________________________________________ > > 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 > --002354470e60247707049ff6c9a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Apr 2, 2011 at 6:01 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com= > wrote:

if you're a company like Linden that needs to respond to DMCA ta= kedown
requests, you're likely to require the client trust knob turned up a bit. if you're an enterprise, you're going to want that trus= t knob
turned all the way up. if you're the pirate bay, you're goin= g to
intentionally want that trust knob turned all the way down.


To avoid the possibility that new readers might get th= e wrong impression, I'll point out that there aren't just two types= of player in the virtual worlds scene, honest enterprise people and evil p= irates.=A0 I wouldn't want anyone new to think that such an impression = was being conveyed or endorsed by anyone here, and of course I'm positi= ve it was not the intention in Meadhbh's comment.

Education, research, Free/Open Source Software and Creative Commons com= munities and a plethora of other groups deal either largely or exclusively = in free/libre content, sharing their work with each other totally legally a= nd honestly, and very frequently using content licenses that permit unlimit= ed distribution and require neither DRM nor any machinery of trust when thi= s content is conveyed.

Groups such as these make up what is sometimes called the "open co= mmunity" segment of Internet users, and it is a huge, vibrant, and ver= y forward looking community.

Many of us here share a mindset with th= at open community as users or developers and consider ourselves part of it,= and we are working towards VW interop protocols that will allow our worlds= to bloom and flourish as a result of freely sharing open-licensed content = and creating enormous synergy by combining people's efforts without ina= ppropriate barriers.

It is this open community which has important requirements that differ = in some ways from corporate ones, not some pirates, and I would strongly en= courage that the security aspects of VWRAP be addressed in this light, befo= re someone accuses us of fear-mongering.

As Carlo pointed out very well, the needs of the open community are not= being met at all by current VW services, and this is a major shortc= oming which we will need to remedy in VWRAP.=A0 I am looking forward eagerl= y to that aspect of our protocol design effort.


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

On Sat,= Apr 2, 2011 at 6:01 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com> wrote:
yes. there is something missing in the protocol. it's trust. you don= 9;t
put "trust" in a protocol, you put "security" in a prot= ocol. at the
end of the day, the people using this protocol will need to decide
whom they trust. this is why there was a security model and the
ability of the protocol to "securely carry trust."

the idea is that the protocol would carry cryptographically
unforgeable attestations of an endpoint's identity. this identity
would then be evaluated by protocol participants to see if it is
"trusted."

there's no place in the protocol that says "you must trust a speci= fic
entity," but rather a mechanism deployers can use to carry the
identity of people wishing to be trusted.

at the end of the day, an asset service should only barf up assets to
trusted simulation services. simulators SHOULD only allow people on
the grid they trust (for some definition of the word "trust.")
if you're a company like Linden that needs to respond to DMCA takedown<= br> requests, you're likely to require the client trust knob turned up a bit. if you're an enterprise, you're going to want that trust knob<= br> turned all the way up. if you're the pirate bay, you're going to intentionally want that trust knob turned all the way down.

as protocol developers, it's our duty to create a protocol that meets everyone's use cases. so... i mean... feel free to try to define a
protocol that mandates the use of DRM or blesses a particular trust
point, but the likelihood of it being widely supported is..
approximately nil.

my recommendation has always been... "define mechanism, not policy.&qu= ot;

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



On Sat, Apr 2, 2011 at 8:19 AM, Carlo Wood <<= a href=3D"mailto:carlo@alinoe.com" target=3D"_blank">carlo@alinoe.com&g= t; wrote:
> On Sat, 2 Apr 2011 14:12:59 GMT
> "dyerbr= ookme@juno.com" <dyerbrookme@juno.com> wrote:
>
>> BTW, the Red Zone statistics of 9 million =A0scans with only 78,00= 0
>> rogue viewers captured lets us know that this =A0problem is exagge= rated
>> -- and usually by engineers who claim there is no =A0technical sol= ution.
>
> Just for the record, from a hacker/engineer: there is no technical
> solution. It is possible to copy everything (and without being detecte= d
> by a "Red Zone" which can only detect rogue viewers that wer= e released
> to the public and explicitly make a point of being detectable
> in the first place (call that bragging: no fun in releasing a "k3= wl"
> viewer if others (or even the coder himself) can't see that it is = being
> used.) So, there is a psychological advantage for the detectors, but > not really a technical one.
>
> Lets concentrate on textures for the moment to explain this.
>
> In order to see an object, or clothing, with the appropriate textures,=
> those textures have to be downloadable for the viewer. There is nothin= g
> you can do about that short of running the whole viewer server-side > and providing a video. But even in that case it would technically be > possible to rip the textures: they are still visible (ie, you could > make a screenshot of the surface of a wall). I don't consider the<= br> > video-broadcast to even be remotely interesting, certainly not from th= e
> viewpoint of VWRAP so lets forget that for the moment and just accept<= br> > that it is possible for anyone to store whatever they SEE to their har= ddisk.
>
> Secondly, if the first creator could upload this texture then so can > the ripper. And don't tell me software exists that can detect if > an uploaded texture "looks like" one of the already existing= billion
> textures that were uploaded before. If the texture is converted twice,=
> ie from jpeg2000 to jpg to tga and then uploaded, then you'd need = a
> human to look at the original and the newly uploaded texture at the > same time to judge that it is MAYBE a copy - which then can only be > proved in court if the original creator can prove that his original > textures are 100% his own and not, for example, downloaded from the > internet somewhere (because in that case the other uploader could
> have used the same source).
>
> A real problem, currently in SL, is imho the complete lack of
> support for FREE things. The amount of restriction (for people with > honest viewers) is tremendous: if you're not an expert or do not p= ay
> attention for a second, then your creation is not truely free anymore.=
> Everything defaults to very copyleft unfriendly settings. I'm tryi= ng to
> get my friends, who are very willing in that regard, to only create > full permission stuff, but it's simply near impossible to keep
> something full permission and often we're stuck with something nob= ody
> else can change or edit because the creator forgot to set the bit of > the contents of an object after changing the group etc blah blah... >
> For example, last a good friend of me wanted my help with making a
> large amount of changes on his sim: hunderds of objects had to be
> adjusted... He was willing to:
> 1) Add me to any group necessary.
> 2) Give me his build rights
> 3) Transfer any object to me (temporary ownership transfer)
> 4) Make any adjustments to the objects and the objects contents
> =A0 needed to allow me to access what I needed to access.
> etc etc
>
> The end result: He had to do it all by himself. It was impossible to > give me enough access to help him (for those who don't believe tha= t,
> one of things involved changing the "anyone can move" bit of= an
> object in the contents of objects: it is not possible to take anything=
> out of the contents (ie copy it to your inventory) when it's no > transfer, and therefore you can't edit it, even though it's mo= dify
> and you get all the rights that the owner can give you).
>
> Sorry, but that is unacceptable; and it CLEARLY shows that something i= s
> missing from the protocol.
>
> Now the above example doesn't show that a free object is not suppo= rted,
> it only make clear that non-free objects can be very annoying even in<= br> > situations where the owner has all the rights to do what he wants to > do. There are many other such examples. Hence, it shows that it is ver= y
> annoying that an object is non-free by default at so many levels that<= br> > you need an IQ of over 140 to create one and those permissions erode > quickly to non-free. Even the so called "freebies" are non-f= ree by the
> way: they are almost always no transfer. Hell, even the default shape<= br> > that you can when you create a new account is no transfer, what kind o= f
> insanity is that?!
>
> I think you might find a lot of people, like myself, a lot more willin= g
> to help out with thinking of ways on how to protect property in virtua= l
> worlds when first it is assured that those who want to create things > that are FREE are equally supported as the commercial guys out there.<= br> >
> --
> Carlo Wood <c= arlo@alinoe.com>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org=
> https://www.ietf.org/mailman/listinfo/vwrap
>
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--002354470e60247707049ff6c9a9-- From vaughn.deluca@gmail.com Sat Apr 2 15:25:24 2011 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 6A8A928B56A for ; Sat, 2 Apr 2011 15:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.036 X-Spam-Level: X-Spam-Status: No, score=-3.036 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 LrFiVcoIzInx for ; Sat, 2 Apr 2011 15:25:20 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 9B0ED3A68E2 for ; Sat, 2 Apr 2011 15:25:19 -0700 (PDT) Received: by eye13 with SMTP id 13so1567808eye.31 for ; Sat, 02 Apr 2011 15:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=xaxe32pGAAV+ZJEeLA2DvtfMInUUMsgK4iYmNbp3j40=; b=RYXYItCRm1ygAozt8H7Vl3+YjJod8FjKPCFnVLnnCZNZFpXtHL/vJY+tis/0Q6ev3m L6pVhKuNW9x5BKdLP2e8mwnhIAm3tMJki4UHqavo1JgXf4MPsShlUPkyv9u5ZAQLQyQN KSc83ZfyILggE7LckX5+ZUbHNoqxmYGb+nGeE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=RBdaRWqEqw8lFyO2w/VKKdzwcJ9sSpE9ImH+xUPNJbdKdhg8gKiZ2veEGqrAYhuRq9 nCIQog5mW5zS6pIwzVqsPd9v3c27xr9hvqXYdE0duUSb9mwlUsfgKqgxAJTo+B2OIUh4 lundB/GmzwujvsxJunMB7oBBCn/GRTq6r/VtA= MIME-Version: 1.0 Received: by 10.213.25.79 with SMTP id y15mr2977329ebb.41.1301783218349; Sat, 02 Apr 2011 15:26:58 -0700 (PDT) Received: by 10.213.17.17 with HTTP; Sat, 2 Apr 2011 15:26:58 -0700 (PDT) In-Reply-To: References: Date: Sun, 3 Apr 2011 00:26:58 +0200 Message-ID: From: Vaughn Deluca To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0ce0b7264de735049ff7069f Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 02 Apr 2011 22:25:24 -0000 --000e0ce0b7264de735049ff7069f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I wrote: >The region can now tells the agent service which of the assets agent service requested transfer the avatar can bring. I meant to say: The region can now tell the agent service which of the assets the agent service requested transfer for, can actually be transfered. (its late here...) On Sun, Apr 3, 2011 at 12:02 AM, Vaughn Deluca wro= te: > Morgain, all, > > Ahha!, i was halfway my reply explaining that i was *not* asking for the > impossible, and did *not* want to impose my rules on others, but that i j= ust > wanted to be able to know that stuff that i get into my region will be > visible to everybody present, and now i see that you got that. Good! > We are on the same page again :) > > The way the draft relating tot the tourist model is now written i can > *never* be sure my visitors all get the same data, because i just juggle = the > crude physics representation, and the viewers negotiate about anything el= se > with the asset service, fully out of my control. > > You formulated a solution (requesting the transfer rights explicitly). > I was originally thinking of a solution where the protocol specifies that > the capability to get the crude physics representation of the asset in my > region would be *automatically* give me the right to download the full as= set > (if I asked for that). After reading your replies i now see that request= ing > the transfer rights, just like like the viewers will do, is a better > solution. The same protocol messages could even be used, The region prese= nt > its credentials and either gets the capability or not. The region can no= w > tells the agent service which of the assets agent service requested trans= fer > the avatar can bring. Its up to the viewer to deal with that information,= it > might simply ignore it. In the latter case the avatar will be simulated b= y > the region without the offending asset. The asset service will subsequent= ly > get requests from all viewers connected to the region for the assets in t= he > region. Some of those might not pass trust checks of the asset service. B= ad > luck for the asset service, it has given a capability to the region and t= he > region will use that to get the asset. If the asset service has second > thoughts to often - causing download costs and lag, it will eventually en= d > up on the black list of the region service, and next time around the regi= on > might tell the agent service it can't allow asset Y from servivce X beca= sue > it does not trust assert service X. > It all sounds logical and transparent to me. > > It also fits what meadhbh said: > >my recommendation has always been... "define mechanism, not policy." > As far as i can see that is what we do here. > > Now, this brings me to a point of order. In september Kevin Tweedy made > this observation: > > " > Date: Wed, 22 Sep 2010 13:40:15 -0400 > May I suggest we stop arbitrarily trying to define things in emails and > come up with some kind of process into how to define what the first draft > specification should include? Doesn=92t W3C have a process on how this w= orks? > I think this is the fundamental problem of this group; we are mixing > vision, requirements, and design in the same email. We are making design > decisions when we haven=92t even defined the requirements." > > I fully agree. We used to brainstorm in the group and assumed the editors > of the drafts would incorporate the generated ideas in new versions of th= e > draft. At times that worked really well, at other times it did work not = so > well. But currently we have no editors, so we need to do something new...= . > > My question to the group is how do we consolidate this bit of discussion? > > In general it seems to me we have managed to generate new enthusiasm in t= he > group, and we are on -or close to- the point were we have enough critica= l > mass to continue. In my view we would really benefit from a true editor, = and > it seems nobody is willing to take that responsibility yet. Can we really= do > it collectively on the wiki? It would be a break with the way i think iet= f > groups normally work, but i might be kind off fitting for this highly > diverse group :) > > So will it work? What alternatives do we have? comments please. > > --Vaughn > > On Sat, Apr 2, 2011 at 5:09 PM, Morgaine = wrote: > >> Vaughn, I left your final (and very important) point for the end of my >> response, and then I fired off my email without addressing it ... Sorry= . :P >> >> >> On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca = wrote: >> >>> So I want methods to prevent breaking my highly emergent world as much >>> as possible. >>> >> >> >> Yes indeed!!! >> >> You have a perfectly reasonable requirement for the service that you wan= t >> to operate, and you need some means of meeting it. I agree with that >> wholeheartedly. I only begin to disagree when you hint that your >> requirement must be imposed on everyone, whether they want it or not. T= hat >> I cannot support, and I expect that you did not mean it that way anyway. >> After all, some of my requirements are probably not of interest to you >> either, and you would not wish me to impose them on you. It cuts both w= ays. >> >> So, how can we enable you to offer a service with many 9's of simulation >> consistency, without imposing that requirement on those who prefer a >> different trade-off? You hinted at the solution yourself, so I'll merel= y >> elaborate on it. You wrote: >> >> >> >> I would like to argue that the region *should* get the capability to fet= ch >>> all details. [...] Note that this does not mean that the region *has* = to >>> proxy the asset, just that in case the asset service refuses to serve a >>> client it does not like, the region can insist on delivery based on th= e >>> capability it originally got. >>> >> >> >> >> Perfect. All you need then is an optional query in the protocol that >> allows a region to ask each asset service referenced by assets carried b= y >> newly arriving avatars the following question: >> >> QUERY: "*Do I have your permission to fetch from your asset service the >> assets normally reserved for client fetches, and to distribute these ass= ets >> to clients directly in the (unexpected) event that I want to?*" >> >> >> That easily maps to an optional capability request of course. If the >> asset service answers "No" to you, then you can deny the incoming avatar >> entry to your region, returning a status that indicates >> >> RESPONSE: "*Asset service X referenced by asset Y does not meet the >> re-distribution requirement requested for entry to region Z*". >> >> >> Your requirement is then satisfied (I believe) without imposing that >> requirement on a region operator who does not need it because they desir= e a >> different trade-off. Those who don't have your requirement simply won't >> request the capability. >> >> For example, it would be pointless to even ask an asset service founded >> entirely around Creative Commons assets that question, since all CC cont= ent >> is perpetually and non-revocably redistributable by anyone and to anyone= . >> By not issuing the query we can save ourselves the round-trip time and a= llow >> faster entry to the region. >> >> Would something like that get the nod from you? >> >> >> PS. You need to note that when an asset service answers "Yes" to your >> query, this does not mean that it will necessarily honor its promise whe= n >> you actually attempt to fetch items. David's very important point about >> independent parties not having control over each other applies here. Yo= u >> can at most hope that it will behave well, and perhaps test the promise = by >> fetching something. However, if you truly want as many 9's of consisten= cy >> as is obtainable then you will have to fetch all the assets yourself pri= or >> to allowing entry to the avatar, and that would be a dreadful overhead. >> Most people will probably settle for "*best effort*" approaches, which >> are quite likely to succeed. >> >> >> Morgaine. >> >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca = wrote: >> >>> Morgaine, Meadhbh, >>> >>> Thanks for the answers, but i see that i have not been clear enough. >>> I think the protocol should demand certain things to prevent the >>> deterioration of the simulation to an unacceptable level. We need to b= e >>> more precise to prevent problems and i think we can. >>> >>> I was arguing from the perspecive of a region service without making th= at >>> explicit. Note i was *not* advocating the region proxies everything, ju= st >>> that it lives up to its promises about object presence. Also note that = i do >>> *not* always have the option to pick another high quality asset servic= e, >>> since I normally do not own the assets. I will use Prokofy as an exampl= e >>> just for the fun of it. He is highly worried about content theft, so (= in >>> the unlikely case he wants to start selling stuff outside of SL) he mig= ht >>> use this deployment pattern. Assume he sells wonderful sexy dresses to= two >>> customers, that can only be fetched from his own asset service for >>> rendering. Both customers go off to "Vaughns highly immersive world" we= re a >>> party is given. My region receives some physics properties of the dres= ses >>> for simulation and an address of Proks asset service for high-res detai= ls >>> and textures. In this case the region does not even get the capability = to >>> fetch the assets, just a link to the asset service and its up to viewer= to >>> request the details and show credentials to get them. The two girls mee= t, >>> both their viewers request the details of the other dress, and Proks as= set >>> service grants those requests. They girls admire their dresses and >>> compliment each other with their good taste. Now when i arrive and my v= iewer >>> request the dress details, Prok's asset service recognises me as the >>> copyleftists that i am. It refuses to serve the asset details -and depe= nding >>> on my viewers behaviour i might get to view two girls in sexy underwear= -or >>> wearing even less- instead of party dresses. From a consistency point o= f >>> view this is a highly undesirable situation, it breaks immersion, and >>> depending on the circumstances might also be embarrassing to the people >>> involved. >>> >>> The key question is if we want to allow this situation to arise within >>> VWRAP compliant worlds. >>> I would like to argue that the region *should* get the capability to >>> fetch all details. In other words, Prokofy would have to give up some >>> control over the asset in case he allows it to be used by my region. No= te >>> that this does not mean that the region *has* to proxy the asset, just = that >>> in case the asset service refuses to serve a client it does not like, t= he >>> region can insist on delivery based on the capability it originally go= t. If >>> that fails Proks asset service can not be called VWRAP compliant. >>> >>> If Prokofy does not want to relinquish that level of control, fine, it >>> is his right not to, but in that case the dresses should not be allowed= to >>> get into my region in the first place. If people visit my region and f= ind >>> themselves naked in the eyes of some others *I* will get the blame. As >>> Morgaine says, the technical details of my innocence will not convince = the >>> general public. So I want methods to prevent breaking my highly emergen= t >>> world as much as possible. >>> My proposal would be that the whatever the region gets MUST be guarante= ed >>> by protocol to be delivered to anybody within the region requesting it= . If >>> the asset service does not want to serve a cryptocomunist copyleftist, = fine, >>> but IF it has given the region a capability, it MUST serve the full ass= et to >>> be VWRAP compliant. Its *my* choice as a region deployer to download th= e >>> full asset to be able to guarantee region consistency if I want to. I w= ill >>> try to avoid that as much as possible, but if my customers complain, i = will >>> be forces to start doing this for certain asset services that i know sh= ow >>> discriminatory behaviour against for instance copyleftist. >>> >>> Finally Morgaine, you keep hammering on the fact that proxying by the >>> region does not scale. (I tend to disagree, but that is beside the poin= t >>> here). I do agree the asset should not be needlessly transfered, but i >>> strongly feel we must insist in the protocol on transferring the *right= s* to >>> view the asset. If that leads to to the region not getting the asset at= all, >>> so be it, it can warn visitors that their assets will not be visible an= d >>> even offer to serve simple replacements (1). This in turn will encourag= e the >>> end users to avoid this type of asset service, and Prokofy will go out = of >>> business, as should be the case given the behaviour of the service. And= if >>> he pulls it off, thats fine with me also, as long as i do not have to s= uffer >>> from it due to lack of rigour in the protocol specs. >>> >>> So, in summary, I very well see that there is no way to enforce >>> consistent serving behaviour but it should at least be clear that it is >>> non-standard and not conform the protocol. The way I am understanding y= ou >>> now, your argument seems to be just one step to far in the direction of >>> anarchy. >>> Or am i misreading you? >>> >>> --Vaughn >>> >>> >>> (1) I just realise that the region might cheat and advertise its own >>> asset brands claiming the competitions assets could not be rendered...= Oh >>> well, one might hope that if there is enough choice in worlds such regi= ons >>> will be forced out of business as well. >>> >>> On Sat, Apr 2, 2011 at 7:31 AM, Morgaine >> > wrote: >>> >>>> Further to my last post, it's worth noting that if you find that you >>>> suffer poor quality behavior from a particular asset service and it is >>>> breaking the consistency of your simulation, with hash-based item addr= essing >>>> you can also automatically use an alternative asset service *in >>>> preference* to the one specified in a given URI. >>>> >>>> Your client could be configured to attempt the item fetch at a known >>>> good quality asset service *first* (perhaps one that you paid to use >>>> because of its better service), automatically, and maybe even dynamica= lly >>>> depending on the type of item. >>>> >>>> The scheme has a long list of benefits, and overcoming (to some extent= ) >>>> poor quality asset services is just one of them. >>>> >>>> >>>> Morgaine. >>>> >>>> >>>> >>>> >>>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> >>>> On Sat, Apr 2, 2011 at 4:55 AM, Morgaine < >>>> morgaine.dinova@googlemail.com> wrote: >>>> >>>>> Every design choice results in a trade-off, Vaughn, improving one thi= ng >>>>> at the expense of something else. If every time we offered a service= we had >>>>> to inform its users about the downsides of all the trade-offs we have= made, >>>>> they would have an awful lot to read. ;-) >>>>> >>>>> The specific trade-off that you are discussing is no different. A >>>>> region that proxies all content has the "benefit" of acquiring contro= l from >>>>> the asset servers over the items in the region, so that it can ensure= that >>>>> everyone in the region not only obtains the items but obtains the * >>>>> same* items as everyone else. That does indeed provide a greater >>>>> guarantee of consistency than a deployment in which the region only p= asses >>>>> asset URIs to clients who then fetch the items from asset services >>>>> separately. As always though, it's a trade-off, since the proxied de= sign >>>>> has very poor scalability compared to the distributed one. >>>>> >>>>> If we're going to warn users of the potential for inconsistency in th= e >>>>> distributed deployment as you suggest, are we also going to warn them= of >>>>> non-scalability in the proxied one? I really don't see much merit in= the >>>>> idea of warning about design choices. Many such choices are technica= l, and >>>>> the issues are quite likely to be of little interest to non-technical= users >>>>> anyway. In any case, the better services are likely to provide such >>>>> information in their online documentation, I would guess. >>>>> >>>>> You mentioned users "voting with their feet" or choosing to accept th= e >>>>> risk of inconsistency. Well that will happen anyway, when services f= ail and >>>>> users get annoyed. If some asset services refuse to send the request= ed >>>>> items to some users, those services will get a bad reputation and peo= ple >>>>> will choose different asset services instead. Likewise, if a world s= ervice >>>>> proxies everything and so it can't handle a large number of assets or= of >>>>> people, users will get annoyed at the lag and will go elsewhere. Thi= s user >>>>> evaluation and "voting with their feet" happens already with online s= ervices >>>>> all over the Internet, and I am sure that this human process will con= tinue >>>>> to work when the services are asset and region services. >>>>> >>>>> Back in September 2010, I wrote this post which proposes that we use = in >>>>> VWRAP a form of asset addressing that provides massive scalability at= the >>>>> same time as a very high degree of resilience -- >>>>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html . I= t >>>>> is based on the concept of the URI containing a host part and a hash = part, >>>>> where the hash is generated (once, at the time of storage to the asse= t >>>>> service) using a specified digest algorithm over the content of the a= sset >>>>> being referenced. You may wish to note that if this design were used= , the >>>>> failure of an asset service to deliver a requested item would result = in a >>>>> failover request for the item to one or more backup services, using t= he same >>>>> hash part but with a different host address. >>>>> >>>>> This can go some way towards overcoming the problem that you think >>>>> might occur when assets are fetched by clients from asset services >>>>> directly. Although it won't help when the missing item is available = from >>>>> only a single asset service, it will help in many other cases, and it= will >>>>> compensate for service failures and network outages automatically at = the >>>>> same time. >>>>> >>>>> PS. This design for hash-based asset addressing is already being test= ed >>>>> by Mojito Sorbet in her experimental world and client. It would give >>>>> VWRAP-based worlds an improved level of service availability, so I th= ink it >>>>> should be a core feature of our protocol. >>>>> >>>>> >>>>> Morgaine. >>>>> >>>>> >>>>> >>>>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>>> >>>>> >>>>> On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca < >>>>> vaughn.deluca@gmail.com> wrote: >>>>> >>>>>> This is a question i discussed with Morgaine off-list a while ago (I >>>>>> intended to send it to the list but pushed the wrong button...) I >>>>>> think we need to address this problem, and decide how to deal with i= t. >>>>>> >>>>>> In Davids deployment draft, section 7.3.1.1 an overview is given va= n >>>>>> ways to deliver content to the region. One way is only passing a >>>>>> capability that allows access to (part of) the resource: >>>>>> >>>>>> 7.3.1.1. Content delivery models >>>>>> A range of possible represenations can be passed to a regi= on >>>>>> for >>>>>> simulation. [...] The other end of the delivery spectrum >>>>>> involves passing >>>>>> only a URI or capability used to access the rendering >>>>>> information and a >>>>>> collision mesh,and related data for physical simulation. >>>>>> In such a model, the client is responsible for fetching th= e >>>>>> additional >>>>>> information needed to render the item's visual presence fr= om >>>>>> a separate >>>>>> service. This fetch can be done *under the credentials of >>>>>> the end user* >>>>>> viewing the material [my emphasis--VD] , and divorces the >>>>>> simulation from >>>>>> the trust chain needed to manage content. Any automation >>>>>> is done on a >>>>>> separate host which the content creator or owner trusts, >>>>>> interacting with the >>>>>> object through remoted interfaces. >>>>>> >>>>>> I can see the need for such a setup, however, i feel we are >>>>>> unpleasantly close to a situation were the coherence of the simulati= on >>>>>> falls apart. >>>>>> In this deployment pattern the region advertises the presence of the >>>>>> asset, and *some* clients will be able to get it as expected, while >>>>>> -based on the arbitrary whims of the asset service- others might not= . >>>>>> >>>>>> My hope would be that after the asset server provides the region wit= h >>>>>> the capability to get the asset, it gives up control. That would mea= n >>>>>> that if the client finds the inventory server is unwilling to serve >>>>>> the content - in spire of the region saying it is present-, the clie= nt >>>>>> should be able to turn around ask the *region* for the asset, (and g= et >>>>>> is after all). >>>>>> >>>>>> If that is not the case, -and there are probably good reasons for t= he >>>>>> deployment pattern as described- shouldn't we *warn* clients that t= he >>>>>> region might be inconsistent, so the users behind the client can vot= e >>>>>> with their feet, (or take the risk)? >>>>>> >>>>>> --Vaughn >>>>>> _______________________________________________ >>>>>> vwrap mailing list >>>>>> vwrap@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/vwrap >>>>>> >>>>> >>>>> >>>> >>> >> > --000e0ce0b7264de735049ff7069f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I wrote:
>The region can now tells the agent service which of the assets= agent service requested transfer the avatar can bring.

I meant to say:

The region can n= ow tell the agent service which of the assets the agent service requested t= ransfer for, can actually be transfered.

(its late here...)

On Sun, Apr 3, 2011 at 12:02 AM, Vaughn Deluca <<= a href=3D"mailto:vaughn.deluca@gmail.com">vaughn.deluca@gmail.com> wrote:
Morgain, all,

Ahha!, i was halfway my reply explaining that i was *not* asking for the i= mpossible, and did *not* want to impose my rules on others, but that i just= wanted to be able to know that stuff that i get into my region will be vis= ible to everybody present, and now i see that you got that. Good!
We are on the same page again :)

The way the = draft relating tot the tourist model is now written i can *never* be sure m= y visitors all get the same data, because i just juggle the crude physics r= epresentation, and the viewers negotiate about anything else with the asset= service, fully out of my control.=A0

You formulated a solution (requesting the transfer righ= ts explicitly). =A0
I was originally thinking of a solution where= the protocol specifies that the capability to get the crude physics repres= entation of the asset in my region would be *automatically* give me the rig= ht to download the full asset (if I asked for that). =A0After reading your = replies i now see that requesting the transfer rights, just like like the v= iewers will do, is a better solution. The same protocol messages could even= be used, The region present its credentials and either gets the capability= or not. =A0The region can now tells the agent service which of the assets = agent service requested transfer the avatar can bring. Its up to the viewer= to deal with that information, it might simply ignore it. In the latter ca= se the avatar will be simulated by the region without the offending asset. = The asset service will subsequently get requests from all viewers connected= to the region for the assets in the region. Some of those might not pass t= rust checks of the asset service. Bad luck for the asset service, it has gi= ven a capability to the region and the region will use that to get the asse= t. If the asset service has second thoughts to often - causing download cos= ts and lag, it will eventually end up on the black list of the region servi= ce, and next time around the region =A0might tell the agent service it can&= #39;t allow asset Y from servivce X becasue it does not trust assert servic= e X. =A0
It all sounds logical and transparent to me.

It also fits what meadhbh said:
>my recommen= dation has always been... "define mechanism, not policy."
As far as i can see that is what we do here.

Now, this brings me to a point of order. In september K= evin Tweedy made this observation:

"<kevin= .tweedy at xrgrid.com&g= t;
Date: Wed, 22 Sep 2010 13:40:15 -0400
May I suggest we stop arbitrarily trying to define things in emails an= d come up with some kind of process into how to define what the first draft= specification should include? =A0Doesn=92t W3C have a process on how this = works? =A0I think this is the fundamental problem of this group; we are mix= ing vision, requirements, and design in the same email. =A0We are making de= sign decisions when we haven=92t even defined the requirements."

I fully agree. We used to brainstorm in the group and a= ssumed the editors of the drafts would incorporate the generated ideas in n= ew versions of the draft. =A0At times that worked really well, at other tim= es it did work not so well. But currently we have no editors, so we need to= do something new....

My question to the group is how do we consolidate this = bit of discussion?=A0

In general it seems to me we= have managed to generate new enthusiasm in the group, and we are on -or cl= ose to- the =A0point were we have enough critical mass to continue. In my v= iew we would really benefit from a true editor, and it seems nobody is will= ing to take that responsibility yet. Can we really do it collectively on th= e wiki? It would be a break with the way i think ietf groups normally work,= but i might be =A0kind off fitting for this highly diverse group =A0:)

So will it work? What alternatives do we have? =A0comme= nts please.

--Vaughn
=

On = Sat, Apr 2, 2011 at 5:09 PM, Morgaine <morgaine.dinova@google= mail.com> wrote:
Vaughn, I left your final (and very importan= t) point for the end of my response, and then I fired off my email without = addressing it ...=A0 Sorry. :P


On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca &l= t;vaughn.deluc= a@gmail.com> wrote:
=A0So I want metho= ds=20 to prevent breaking my highly emergent world as much as possible.


Yes indeed!!!

You have a perfectly reaso= nable requirement for the service that you want to operate, and you need so= me means of meeting it.=A0 I agree with that wholeheartedly.=A0 I only begi= n to disagree when you hint that your requirement must be imposed on everyo= ne, whether they want it or not.=A0 That I cannot support, and I expect tha= t you did not mean it that way anyway.=A0 After all, some of my requirement= s are probably not of interest to you either, and you would not wish me to = impose them on you.=A0 It cuts both ways.

So, how can we enable you to offer a service with many 9's of simul= ation consistency, without imposing that requirement on those who prefer a = different trade-off?=A0 You hinted at the solution yourself, so I'll me= rely elaborate on it.=A0 You wrote:



I would like to argue that the region *should* get the capability to=20 fetch all details. [...]=A0=20 Note that this does not mean that the region *has* to proxy the asset,=20 just that in case the asset service refuses to serve a client it does=20 not like, the region can insist on delivery =A0based on the capability it= =20 originally got.



Perfect.=A0 All you need then= is an optional query in the protocol that allows a region to ask each asse= t service referenced by assets carried by newly arriving avatars the follow= ing question:

QUERY: "Do I have your permissi= on to fetch from your asset service the assets normally reserved for client= fetches, and to distribute these assets to clients directly in the (unexpe= cted) event that I want to?"


That easily maps to an optional capability request of course.= =A0 If the asset service answers "No" to you, then you can deny t= he incoming avatar entry to your region, returning a status that indicates<= br>
RESPONSE: "Asset service X refe= renced by asset Y does not meet the re-distribution requirement requested f= or entry to region Z".


Your requirement is then s= atisfied (I believe) without imposing that requirement on a region operator= who does not need it because they desire a different trade-off.=A0 Those w= ho don't have your requirement simply won't request the capability.=

For example, it would be pointless to even ask an asset service founded= entirely around Creative Commons assets that question, since all CC conten= t is perpetually and non-revocably redistributable by anyone and to anyone.= =A0 By not issuing the query we can save ourselves the round-trip time and = allow faster entry to the region.

Would something like that get the nod from you?


PS. You need= to note that when an asset service answers "Yes" to your query, = this does not mean that it will necessarily honor its promise when you actu= ally attempt to fetch items.=A0 David's very important point about inde= pendent parties not having control over each other applies here.=A0 You can= at most hope that it will behave well, and perhaps test the promise by fet= ching something.=A0 However, if you truly want as many 9's of consisten= cy as is obtainable then you will have to fetch all the assets yourself pri= or to allowing entry to the avatar, and that would be a dreadful overhead.= =A0 Most people will probably settle for "best effort" app= roaches, which are quite likely to succeed.


Morgaine.





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


On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca <v= aughn.deluca@gmail.com> wrote:
Morgaine, Meadhbh,=

Thanks for the answers, but i see that i have not= been clear enough.
I think the protocol should demand certain things to prevent the =A0de= terioration of the simulation to an unacceptable level. We need to be more = precise to prevent problems and i think we can.

I was arguing from the perspecive of a region service w= ithout making that explicit. Note i was *not* advocating the region proxies= everything, just that it lives up to its promises about object presence. A= lso note that i do =A0*not* always have the option to pick another high qua= lity asset service, since I normally do not own the assets. I will use Prok= ofy as an example just for the fun of it. =A0He is highly worried about con= tent theft, so (in the unlikely case he wants to start selling stuff outsid= e of SL) he might use this deployment pattern. =A0Assume he sells wonderful= sexy dresses to two customers, that can only be fetched from his own asset= service for rendering. Both customers go off to "Vaughns highly immer= sive world" were a party is given. =A0My region receives some physics = properties of the dresses for simulation and an address of Proks asset serv= ice for high-res details and textures. In this case the region does not eve= n get the capability to fetch the assets, just a link to the asset service = and its up to viewer to request the details and show credentials to get the= m. The two girls meet, both their viewers request the details of the other = dress, and Proks asset service grants those requests. They girls admire the= ir dresses and compliment each other with their good taste. Now when i arri= ve and my viewer request the dress details, Prok's asset service recogn= ises me as the copyleftists that i am. It refuses to serve the asset detail= s -and depending on my viewers behaviour i might get to view two girls in s= exy underwear -or wearing even less- instead of party dresses. From a consi= stency point of view this is a highly undesirable situation, it breaks imme= rsion, and depending on the circumstances might also be embarrassing to the= people involved.=A0

The key question is if we want to allow this situation = to arise within VWRAP compliant worlds.
I would like to argue tha= t the region *should* get the capability to fetch all details. In other wor= ds, Prokofy would have to give up some control over the asset in case he al= lows it to be used by my region. Note that this does not mean that the regi= on *has* to proxy the asset, just that in case the asset service refuses to= serve a client it does not like, the region can insist on delivery =A0base= d on the capability it originally got. If that fails Proks asset service ca= n not be called VWRAP compliant. =A0

If Prokofy does not want to relinquish =A0that level of= control, fine, it is his right not to, but in that case the dresses should= not be allowed to get into my region in the first place. =A0If people visi= t my region and find themselves naked in the eyes of some others *I* will g= et the blame. =A0As Morgaine says, the technical details of my innocence wi= ll not convince the general public. So I want methods to prevent breaking m= y highly emergent world as much as possible.=A0
My proposal would be that the whatever the region gets MUST be guarant= eed by protocol to be delivered to =A0anybody within the region requesting = it. If the asset service does not want to serve a cryptocomunist copyleftis= t, fine, but IF it has given the region a capability, it MUST serve the ful= l asset to be VWRAP compliant. Its *my* choice as a region deployer to down= load the full asset to be able to guarantee region consistency if I want to= . I will try to avoid that as much as possible, but if my customers complai= n, i will be forces to start doing this for certain asset services that i k= now show discriminatory behaviour against for instance copyleftist.=A0

Finally Morgaine, you keep hammering on the fact that p= roxying by the region does not scale. (I tend to disagree, but that is besi= de the point here). I do agree the asset should not be needlessly transfere= d, but i strongly feel we must insist in the protocol on transferring the *= rights* to view the asset. If that leads to to the region not getting the a= sset at all, so be it, it can warn visitors that their assets will not be v= isible and even offer to serve simple replacements (1). This in turn will e= ncourage the end users to avoid this type of asset service, and Prokofy wil= l go out of business, as should be the case given the behaviour of the serv= ice. And if he pulls it off, thats fine with me also, as long as i do not h= ave to suffer from it due to lack of rigour in the protocol specs. =A0

So, in summary, I very well see that there is no way to= enforce consistent serving behaviour but it should at least be clear that = it is non-standard and not conform the protocol. The way I am understanding= you now, your argument seems to be just one step to far in the direction o= f anarchy.
Or am i misreading you?

--Vaughn

(1) I just realise that the region might cheat = and advertise its own asset brands claiming the competitions assets =A0coul= d not be rendered... Oh well, one might hope that if there is enough choice= in worlds such regions will be forced =A0out of business as well.=A0

On Sat, Apr 2, 2011 at 7:31 AM, Morgaine <morgaine.dinova@googlemail.com> wrote:
Further to my last post, it's worth noting that if you find that you su= ffer poor quality behavior from a particular asset service and it is breaki= ng the consistency of your simulation, with hash-based item addressing you = can also automatically use an alternative asset service in preference= to the one specified in a given URI.

Your client could be configured to attempt the item fetch at a known go= od quality asset service first (perhaps one that you paid to use bec= ause of its better service), automatically, and maybe even dynamically depe= nding on the type of item.

The scheme has a long list of benefits, and overcoming (to some extent)= poor quality asset services is just one of them.


Morgaine.





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


On Sat, Apr 2, 2011 at 4:55 AM, Morgaine <morgaine.dinova@goo= glemail.com> wrote:
Every design choice results in a trade-off, Vaughn, improving one thing at = the expense of something else.=A0 If every time we offered a service we had= to inform its users about the downsides of all the trade-offs we have made= , they would have an awful lot to read. ;-)

The specific trade-off that you are discussing is no different.=A0 A re= gion that proxies all content has the "benefit" of acquiring cont= rol from the asset servers over the items in the region, so that it can ens= ure that everyone in the region not only obtains the items but obtains the = same items as everyone else.=A0 That does indeed provide a greater g= uarantee of consistency than a deployment in which the region only passes a= sset URIs to clients who then fetch the items from asset services separatel= y.=A0 As always though, it's a trade-off, since the proxied design has = very poor scalability compared to the distributed one.

If we're going to warn users of the potential for inconsistency in = the distributed deployment as you suggest, are we also going to warn them o= f non-scalability in the proxied one?=A0 I really don't see much merit = in the idea of warning about design choices.=A0 Many such choices are techn= ical, and the issues are quite likely to be of little interest to non-techn= ical users anyway.=A0 In any case, the better services are likely to provid= e such information in their online documentation, I would guess.

You mentioned users "voting with their feet" or choosing to a= ccept the risk of inconsistency.=A0 Well that will happen anyway, when serv= ices fail and users get annoyed.=A0 If some asset services refuse to send t= he requested items to some users, those services will get a bad reputation = and people will choose different asset services instead.=A0 Likewise, if a = world service proxies everything and so it can't handle a large number = of assets or of people, users will get annoyed at the lag and will go elsew= here.=A0 This user evaluation and "voting with their feet" happen= s already with online services all over the Internet, and I am sure that th= is human process will continue to work when the services are asset and regi= on services.

Back in September 2010, I wrote this post which proposes that we use in= VWRAP a form of asset addressing that provides massive scalability at the = same time as a very high degree of resilience -- http:/= /www.ietf.org/mail-archive/web/vwrap/current/msg00463.html .=A0 It is b= ased on the concept of the URI containing a host part and a hash part, wher= e the hash is generated (once, at the time of storage to the asset service)= using a specified digest algorithm over the content of the asset being ref= erenced.=A0 You may wish to note that if this design were used, the failure= of an asset service to deliver a requested item would result in a failover= request for the item to one or more backup services, using the same hash p= art but with a different host address.

This can go some way towards overcoming the problem that you think migh= t occur when assets are fetched by clients from asset services directly.=A0= Although it won't help when the missing item is available from only a = single asset service, it will help in many other cases, and it will compens= ate for service failures and network outages automatically at the same time= .

PS. This design for hash-based asset addressing is already being tested= by Mojito Sorbet in her experimental world and client.=A0 It would give VW= RAP-based worlds an improved level of service availability, so I think it s= hould be a core feature of our protocol.


Morgaine.




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

On Fri, Apr 1, 2011 at 11:17 PM, Vaughn De= luca <vaughn.deluca@gmail.com> wrote:
This is a question i di= scussed with Morgaine off-list a while ago (I
intended to send it to the list but pushed the wrong button...) I
think we need to address this problem, and decide how to deal with it.

=A0In Davids deployment draft, section 7.3.1.1 an overview is given van
ways to deliver content to the region. One way is only passing a
capability that allows access to (part of) the resource:

=A0 =A0 =A0 =A0 =A0 7.3.1.1. =A0Content delivery models
=A0 =A0 =A0 =A0 =A0 A range of possible represenations can be passed to a = region for
=A0 =A0 =A0 =A0 =A0 simulation. [...] The other end of the delivery spectr= um involves passing
=A0 =A0 =A0 =A0 =A0 only a URI or capability used to access the rendering<= br> information and a
=A0 =A0 =A0 =A0 =A0 collision mesh,and related data for physical simulatio= n.
=A0 =A0 =A0 =A0 =A0 In such a model, the client is responsible for fetchin= g the additional
=A0 =A0 =A0 =A0 =A0 information needed to render the item's visual pre= sence from a separate
=A0 =A0 =A0 =A0 =A0 service. =A0This fetch can be done *under the credenti= als of the end user*
=A0 =A0 =A0 =A0 =A0 viewing the material [my emphasis--VD] , and divorces = the
simulation from
=A0 =A0 =A0 =A0 =A0 the trust chain needed to manage content. =A0Any autom= ation
is done on a
=A0 =A0 =A0 =A0 =A0 separate host which the content creator or owner trust= s,
interacting with the
=A0 =A0 =A0 =A0 =A0 object through remoted interfaces.

=A0I can see the need for such a setup, however, i feel we are
unpleasantly close to a situation were the coherence of the simulation
falls apart.
In this deployment pattern the region advertises the presence of the
asset, and *some* clients will be able to get it as expected, while
-based on the arbitrary whims of the asset service- others might not.

My hope would be that after the asset server provides the region with
the capability to get the asset, it gives up control. That would mean
that if the client finds the inventory server is unwilling to serve
the content - in spire of the region saying it is present-, the client
should be able to turn around ask the *region* for the asset, (and get
is after all).

=A0If that is not the case, -and there are probably good reasons for the deployment pattern as described- =A0shouldn't we *warn* clients that th= e
region might be inconsistent, so the users behind the client can vote
with their feet, (or take the risk)?

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






--000e0ce0b7264de735049ff7069f-- From izzyalanis@gmail.com Sat Apr 2 20:04:54 2011 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 AA1CB28C0DC for ; Sat, 2 Apr 2011 20:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 GQ3Cd5rc+RXk for ; Sat, 2 Apr 2011 20:04:52 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 0318528C0D6 for ; Sat, 2 Apr 2011 20:04:51 -0700 (PDT) Received: by qyk29 with SMTP id 29so375649qyk.10 for ; Sat, 02 Apr 2011 20:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to:x-mailer; bh=iBxAqLHpJwUTqihqqPxfEm+/zTSs+HNL4ZrrxMQ4Ddg=; b=swk77HlbkQht4fibQPIrEyWiPrWhFDwAcCrjokYuFbDx4XvEs4AG1ov9PfphJsc8Sz FiVspEILx2vULJ3Cq2RajZbkusbfhXYiRcDWO8ty7Om+lERhHFS80wWsGO7+ajMETxv5 HQsMAbhEcUPC48HM+19UsZcAM/HPGv+sY9ezM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=VNlnSevxQi8AodmrgMP9StuYlCLIKw9fAeRe5/jpsCsNI9Nvt2YsueUIY8mKn+ZeOf o0uCoehitQ6TK1iQ842vG1XeKdvYwQSkKvWulU+l07GUfMGX1cWXz+wv2FLLW2391l18 9Kk9Gx4UN9Fl/dyL8zYDMbhz1aZyVejRBABPE= Received: by 10.224.135.136 with SMTP id n8mr4495985qat.95.1301799991468; Sat, 02 Apr 2011 20:06:31 -0700 (PDT) Received: from [192.168.1.102] (c-75-68-52-200.hsd1.nh.comcast.net [75.68.52.200]) by mx.google.com with ESMTPS id l12sm2568178qcu.19.2011.04.02.20.06.28 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Apr 2011 20:06:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-1--778663196 From: Israel Alanis In-Reply-To: Date: Sat, 2 Apr 2011 22:42:47 -0400 Message-Id: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> References: To: Morgaine X-Mailer: Apple Mail (2.1082) Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 03 Apr 2011 03:04:54 -0000 --Apple-Mail-1--778663196 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > when designing for scalability, the model to bear in mind is ... Well, there are a lot of different models to keep in mind, and many = different use cases. One particular use case to keep in mind is: "User = acquires new outfit, and wants to 'show it off' in a highly populated = region". > Both worlds and asset services may include commercial, community, and = personal services Yes, yes and yes. I'm particularly concerned about how the model affects = the ability to host personal asset services. > a proxying region, which would get slammed for every asset worn by = every avatar present. Granted the collection of services that are provided by the region need = to be scaled to meet the demands of that region. That's all part of = capacity planning. > regions run many different CPU-intensive tasks, including physics = simulation and server-side scripting, and absolutely cannot afford to = serve assets too=20 Well... who said the same CPU's have to do proxying, physics simulation = and server-side scripting? Asset proxying is a different service than = physics simulation and can be on separate hardware, could make use of = geographically distributed caching, and in certain deployment patterns, = the same caching services could be shared by different regions. = (Server-side scripting is a discussion for another day). > This is why we have to go parallel... Totally agree, and a proxying model could and should also take advantage = of parallelism. > I think you're wrong that it has to cost much money.=20 ?vs? > It costs money to host a high performance and scalable asset service = and a high bandwidth network to handle the traffic. A lot of money.=20 I think what you're saying is: "It costs a lot of money to build a = scalable asset service, but if assets are spread throughout the internet = they don't have to be scalable." But that's not quite right. You're = opening up every asset server to the VW equivalent of being slashdotted, = so are you sure you're not forcing *every* asset service to be scalable = and handle a lot of bandwith and network traffic? It's the exact = opposite of your intention, but I think that's the result, all the same. This particular design decision has a big effect on the economics of the = VW infrastructure. I'd rather the economics to work out such that a = region provider who wishes to build a region that supports a small = population, can do so economically. A region that wants to host a = *large* population has to bear that cost of providing that scalable = asset service.=20 I want the economics of hosting a small asset service to be a non-issue = (as to best promote creation and creativity). Creating a high bar to = provide asset services will mean that service will cost money and people = shouldn't have to pay money just to create or own VW objects (I'm using = 'own' here to refer to maintaining their existence, I'm not trying to = make a 'leftist'/'communist' statement about ownership ;) - Izzy On Apr 2, 2011, at 3:58 PM, Morgaine wrote: > Izzy, when designing for scalability, the model to bear in mind is = that of seasoned virtual world travelers whose inventories contain = assets from many different worlds, those assets being served by many = different asset services. Both worlds and asset services may include = commercial, community, and personal services, and as the metaverse = grows, that set is highly likely to become progressively less clustered = and more diverse. >=20 > When those seasoned travelers click on an advertised VW link and = perform an inter-world teleport to one particular world's region to = share an experience, their "worn" assets (the only ones of interest to = the region) will contain references to asset services spread widely = across the Internet. The fetches by the travelers' clients occur over = many parallel paths from clients to asset services, so one can = reasonably expect reduced network contention and reduced asset server = loading because they are both spread out over however many asset = services are being referenced by the overall set of assets in the = region. >=20 > This is very different to the case of a proxying region, which would = get slammed for every asset worn by every avatar present. In our = current architecture, regions run many different CPU-intensive tasks, = including physics simulation and server-side scripting, and absolutely = cannot afford to serve assets too unless your scalability requirements = are very low indeed, ie. just a few dozen avatars of today's kind. = We've hit the ceiling already on region scalability done that way. = There is nowhere to go in that direction at all beyond improving the = code like Intel demonstrated, and that work is subject to a law of = diminishing returns. >=20 > This is why we have to go parallel, and I think you're wrong that it = has to cost much money. As we spread the load across more and more = asset services, we are simply better utilizing all the hardware that's = already out there on the Internet, at least in respect of community and = private resources. But add to the community and private resources the = commercial asset services that are likely to appear to exploit this = opportunity, and not only will the number of asset services leap, but = the power of each one will rocket too, because, after all, these = businesses will be heavily optimized for the job. >=20 > As to why a world would want clients to access external asset services = instead of providing its own implementation, that's an easy question. = It costs money to host a high performance and scalable asset service and = a high bandwidth network to handle the traffic. A lot of money. In = contrast, it costs a world nothing to let others serve the assets to = clients. And that matters to the bottom line. >=20 >=20 > Morgaine. >=20 >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis = wrote: > > As always though, it's a trade-off, since the proxied design has = very poor scalability compared to the distributed one. >=20 > I don't agree with that... If a user enters a highly populated region, > every other client is going to (could and should be trying to) hit the > asset server(s) for the assets that the user is wearing (assuming > they're not cached locally). Every asset server has to be scaled up > to the point that it can handle that load from all over... >=20 > If I'm hosting a region that supports 10s of thousands of simultaneous > users (thinking of the future), I already have to scale to meet that > demand. If the region is proxying the assets, then, yes the region has > to be scaled to meet that asset demand too, but it already has to be > scaled to meet other demands of being a region server... and why is > scaling those asset proxy services hard? It's going to cost $, but is > not technically challenging. So, if I want to host a region like > that... sure it will cost me, but the simulation will be consistent > and users will be able to participate equally, regardless of the > capabilities of their individual asset services. >=20 >=20 >=20 >=20 > On Fri, Apr 1, 2011 at 11:55 PM, Morgaine > wrote: > > Every design choice results in a trade-off, Vaughn, improving one = thing at > > the expense of something else. If every time we offered a service = we had to > > inform its users about the downsides of all the trade-offs we have = made, > > they would have an awful lot to read. ;-) > > > > The specific trade-off that you are discussing is no different. A = region > > that proxies all content has the "benefit" of acquiring control from = the > > asset servers over the items in the region, so that it can ensure = that > > everyone in the region not only obtains the items but obtains the = same items > > as everyone else. That does indeed provide a greater guarantee of > > consistency than a deployment in which the region only passes asset = URIs to > > clients who then fetch the items from asset services separately. As = always > > though, it's a trade-off, since the proxied design has very poor = scalability > > compared to the distributed one. > > > > If we're going to warn users of the potential for inconsistency in = the > > distributed deployment as you suggest, are we also going to warn = them of > > non-scalability in the proxied one? I really don't see much merit = in the > > idea of warning about design choices. Many such choices are = technical, and > > the issues are quite likely to be of little interest to = non-technical users > > anyway. In any case, the better services are likely to provide such > > information in their online documentation, I would guess. > > > > You mentioned users "voting with their feet" or choosing to accept = the risk > > of inconsistency. Well that will happen anyway, when services fail = and > > users get annoyed. If some asset services refuse to send the = requested > > items to some users, those services will get a bad reputation and = people > > will choose different asset services instead. Likewise, if a world = service > > proxies everything and so it can't handle a large number of assets = or of > > people, users will get annoyed at the lag and will go elsewhere. = This user > > evaluation and "voting with their feet" happens already with online = services > > all over the Internet, and I am sure that this human process will = continue > > to work when the services are asset and region services. > > > > Back in September 2010, I wrote this post which proposes that we use = in > > VWRAP a form of asset addressing that provides massive scalability = at the > > same time as a very high degree of resilience -- > > http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html . = It is > > based on the concept of the URI containing a host part and a hash = part, > > where the hash is generated (once, at the time of storage to the = asset > > service) using a specified digest algorithm over the content of the = asset > > being referenced. You may wish to note that if this design were = used, the > > failure of an asset service to deliver a requested item would result = in a > > failover request for the item to one or more backup services, using = the same > > hash part but with a different host address. > > > > This can go some way towards overcoming the problem that you think = might > > occur when assets are fetched by clients from asset services = directly. > > Although it won't help when the missing item is available from only = a single > > asset service, it will help in many other cases, and it will = compensate for > > service failures and network outages automatically at the same time. > > > > PS. This design for hash-based asset addressing is already being = tested by > > Mojito Sorbet in her experimental world and client. It would give > > VWRAP-based worlds an improved level of service availability, so I = think it > > should be a core feature of our protocol. > > > > > > Morgaine. > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > > > On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca = > > wrote: > >> > >> This is a question i discussed with Morgaine off-list a while ago = (I > >> intended to send it to the list but pushed the wrong button...) I > >> think we need to address this problem, and decide how to deal with = it. > >> > >> In Davids deployment draft, section 7.3.1.1 an overview is given = van > >> ways to deliver content to the region. One way is only passing a > >> capability that allows access to (part of) the resource: > >> > >> 7.3.1.1. Content delivery models > >> A range of possible represenations can be passed to a = region for > >> simulation. [...] The other end of the delivery spectrum > >> involves passing > >> only a URI or capability used to access the rendering > >> information and a > >> collision mesh,and related data for physical simulation. > >> In such a model, the client is responsible for fetching = the > >> additional > >> information needed to render the item's visual presence = from a > >> separate > >> service. This fetch can be done *under the credentials = of the > >> end user* > >> viewing the material [my emphasis--VD] , and divorces the > >> simulation from > >> the trust chain needed to manage content. Any automation > >> is done on a > >> separate host which the content creator or owner trusts, > >> interacting with the > >> object through remoted interfaces. > >> > >> I can see the need for such a setup, however, i feel we are > >> unpleasantly close to a situation were the coherence of the = simulation > >> falls apart. > >> In this deployment pattern the region advertises the presence of = the > >> asset, and *some* clients will be able to get it as expected, while > >> -based on the arbitrary whims of the asset service- others might = not. > >> > >> My hope would be that after the asset server provides the region = with > >> the capability to get the asset, it gives up control. That would = mean > >> that if the client finds the inventory server is unwilling to serve > >> the content - in spire of the region saying it is present-, the = client > >> should be able to turn around ask the *region* for the asset, (and = get > >> is after all). > >> > >> If that is not the case, -and there are probably good reasons for = the > >> deployment pattern as described- shouldn't we *warn* clients that = the > >> region might be inconsistent, so the users behind the client can = vote > >> with their feet, (or take the risk)? > >> > >> --Vaughn > >> _______________________________________________ > >> 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 > > > > >=20 --Apple-Mail-1--778663196 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

> Both worlds and asset = services may include commercial, community, and personal = services

Yes, yes and yes. I'm particularly = concerned about how the model affects the ability to host personal asset = services.

> a proxying region, which = would get slammed for every asset worn by every avatar = present.

Granted the collection of services = that are provided by the region need to be scaled to meet the demands of = that region. That's all part of capacity = planning.

> regions run many different = CPU-intensive tasks, including physics simulation and server-side = scripting, and absolutely cannot afford to serve assets = too 

Well... who said the same CPU's have = to do proxying, physics simulation and server-side scripting? Asset = proxying is a different service than physics simulation and can be on = separate hardware, could make use of geographically distributed caching, = and in certain deployment patterns, the same caching services could be = shared by different regions. (Server-side scripting is a discussion for = another day).

> This is why we have to = go parallel...

Totally agree, and a proxying = model could and should also take advantage of = parallelism.

> I think you're wrong = that it has to cost much = money. 
?vs?
> It costs money to host a = high performance and scalable asset service and a high bandwidth network = to handle the traffic.  A lot of = money. 

I think what you're saying is: "It = costs a lot of money to build a scalable asset service, but if assets = are spread throughout the internet they don't have to be scalable." But = that's not quite right. You're opening up every asset server to the VW = equivalent of being slashdotted, so are you sure you're not forcing = *every* asset service to be scalable and handle a lot of bandwith and = network traffic? It's the exact opposite of your intention, but I think = that's the result, all the same.

This = particular design decision has a big effect on the economics of the VW = infrastructure. I'd rather the economics to work out such that a region = provider who wishes to build a region that supports a small population, = can do so economically. A region that wants to host a *large* population = has to bear that cost of providing that scalable asset = service. 

I want the economics of hosting = a small asset service to be a non-issue (as to best promote creation and = creativity). Creating a high bar to provide asset services will mean = that service will cost money and people shouldn't have to pay money just = to create or own VW objects (I'm using 'own' here to refer to = maintaining their existence, I'm not trying to make a = 'leftist'/'communist' statement about ownership = ;)

- Izzy


On = Apr 2, 2011, at 3:58 PM, Morgaine wrote:

Izzy, when = designing for scalability, the model to bear in mind is that of seasoned = virtual world travelers whose inventories contain assets from many = different worlds, those assets being served by many different asset = services.  Both worlds and asset services may include commercial, = community, and personal services, and as the metaverse grows, that set = is highly likely to become progressively less clustered and more = diverse.

When those seasoned travelers click on an advertised VW link and = perform an inter-world teleport to one particular world's region to = share an experience, their "worn" assets (the only ones of interest to = the region) will contain references to asset services spread widely = across the Internet.  The fetches by the travelers' clients occur = over many parallel paths from clients to asset services, so one can = reasonably expect reduced network contention and reduced asset server = loading because they are both spread out over however many asset = services are being referenced by the overall set of assets in the = region.

This is very different to the case of a proxying region, which would = get slammed for every asset worn by every avatar present.  In our = current architecture, regions run many different CPU-intensive tasks, = including physics simulation and server-side scripting, and absolutely = cannot afford to serve assets too unless your scalability requirements = are very low indeed, ie. just a few dozen avatars of today's kind.  = We've hit the ceiling already on region scalability done that way.  = There is nowhere to go in that direction at all beyond improving the = code like Intel demonstrated, and that work is subject to a law of = diminishing returns.

This is why we have to go parallel, and I think you're wrong that it = has to cost much money.  As we spread the load across more and more = asset services, we are simply better utilizing all the hardware that's = already out there on the Internet, at least in respect of community and = private resources.  But add to the community and private resources = the commercial asset services that are likely to appear to exploit this = opportunity, and not only will the number of asset services leap, but = the power of each one will rocket too, because, after all, these = businesses will be heavily optimized for the job.

As to why a world would want clients to access external asset = services instead of providing its own implementation, that's an easy = question.  It costs money to host a high performance and scalable = asset service and a high bandwidth network to handle the traffic.  = A lot of money.  In contrast, it costs a world nothing to = let others serve the assets to clients.  And that matters to the = bottom line.


Morgaine.




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

On Sat, = Apr 2, 2011 at 7:05 PM, Izzy Alanis <izzyalanis@gmail.com> wrote:
> As always though, it's a trade-off, since the proxied design = has very poor scalability compared to the distributed one.

I don't agree with that... If a user enters a highly populated = region,
every other client is going to (could and should be trying to) hit = the
asset server(s) for the assets that the user is wearing (assuming
they're not cached locally).  Every asset server has to be scaled = up
to the point that it can handle that load from all over...

If I'm hosting a region that supports 10s of thousands of = simultaneous
users (thinking of the future), I already have to scale to meet that
demand. If the region is proxying the assets, then, yes the region = has
to be scaled to meet that asset demand too, but it already has to be
scaled to meet other demands of being a region server... and why is
scaling those asset proxy services hard?  It's going to cost $, but = is
not technically challenging. So, if I want to host a region like
that... sure it will cost me, but the simulation will be consistent
and users will be able to participate equally, regardless of the
capabilities of their individual asset services.




On Fri, Apr 1, 2011 at 11:55 PM, Morgaine
> Every design choice results in a = trade-off, Vaughn, improving one thing at
> the expense of something else.  If every time we offered a = service we had to
> inform its users about the downsides of all the trade-offs we have = made,
> they would have an awful lot to read. ;-)
>
> The specific trade-off that you are discussing is no = different.  A region
> that proxies all content has the "benefit" of acquiring control = from the
> asset servers over the items in the region, so that it can ensure = that
> everyone in the region not only obtains the items but obtains the = same items
> as everyone else.  That does indeed provide a greater = guarantee of
> consistency than a deployment in which the region only passes asset = URIs to
> clients who then fetch the items from asset services = separately.  As always
> though, it's a trade-off, since the proxied design has very poor = scalability
> compared to the distributed one.
>
> If we're going to warn users of the potential for inconsistency in = the
> distributed deployment as you suggest, are we also going to warn = them of
> non-scalability in the proxied one?  I really don't see much = merit in the
> idea of warning about design choices.  Many such choices are = technical, and
> the issues are quite likely to be of little interest to = non-technical users
> anyway.  In any case, the better services are likely to = provide such
> information in their online documentation, I would guess.
>
> You mentioned users "voting with their feet" or choosing to accept = the risk
> of inconsistency.  Well that will happen anyway, when services = fail and
> users get annoyed.  If some asset services refuse to send the = requested
> items to some users, those services will get a bad reputation and = people
> will choose different asset services instead.  Likewise, if a = world service
> proxies everything and so it can't handle a large number of assets = or of
> people, users will get annoyed at the lag and will go = elsewhere.  This user
> evaluation and "voting with their feet" happens already with online = services
> all over the Internet, and I am sure that this human process will = continue
> to work when the services are asset and region services.
>
> Back in September 2010, I wrote this post which proposes that we = use in
> VWRAP a form of asset addressing that provides massive scalability = at the
> same time as a very high degree of resilience --
> http://www.ietf.org/mail-archive/web/vwrap/current/msg00= 463.html .  It is
> based on the concept of the URI containing a host part and a hash = part,
> where the hash is generated (once, at the time of storage to the = asset
> service) using a specified digest algorithm over the content of the = asset
> being referenced.  You may wish to note that if this design = were used, the
> failure of an asset service to deliver a requested item would = result in a
> failover request for the item to one or more backup services, using = the same
> hash part but with a different host address.
>
> This can go some way towards overcoming the problem that you think = might
> occur when assets are fetched by clients from asset services = directly.
> Although it won't help when the missing item is available from only = a single
> asset service, it will help in many other cases, and it will = compensate for
> service failures and network outages automatically at the same = time.
>
> PS. This design for hash-based asset addressing is already being = tested by
> Mojito Sorbet in her experimental world and client.  It would = give
> VWRAP-based worlds an improved level of service availability, so I = think it
> should be a core feature of our protocol.
>
>
> Morgaine.
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
>
> On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca <vaughn.deluca@gmail.com>
> wrote:
>>
>> This is a question i discussed with Morgaine off-list a while = ago (I
>> intended to send it to the list but pushed the wrong button...) = I
>> think we need to address this problem, and decide how to deal = with it.
>>
>>  In Davids deployment draft, section 7.3.1.1 an overview = is given van
>> ways to deliver content to the region. One way is only passing = a
>> capability that allows access to (part of) the resource:
>>
>>           7.3.1.1.  Content = delivery models
>>           A range of possible = represenations can be passed to a region for
>>           simulation. [...] The other = end of the delivery spectrum
>> involves passing
>>           only a URI or capability = used to access the rendering
>> information and a
>>           collision mesh,and related = data for physical simulation.
>>           In such a model, the client = is responsible for fetching the
>> additional
>>           information needed to render = the item's visual presence from a
>> separate
>>           service.  This fetch = can be done *under the credentials of the
>> end user*
>>           viewing the material [my = emphasis--VD] , and divorces the
>> simulation from
>>           the trust chain needed to = manage content.  Any automation
>> is done on a
>>           separate host which the = content creator or owner trusts,
>> interacting with the
>>           object through remoted = interfaces.
>>
>>  I can see the need for such a setup, however, i feel we = are
>> unpleasantly close to a situation were the coherence of the = simulation
>> falls apart.
>> In this deployment pattern the region advertises the presence = of the
>> asset, and *some* clients will be able to get it as expected, = while
>> -based on the arbitrary whims of the asset service- others = might not.
>>
>> My hope would be that after the asset server provides the = region with
>> the capability to get the asset, it gives up control. That = would mean
>> that if the client finds the inventory server is unwilling to = serve
>> the content - in spire of the region saying it is present-, the = client
>> should be able to turn around ask the *region* for the asset, = (and get
>> is after all).
>>
>>  If that is not the case, -and there are probably good = reasons for the
>> deployment pattern as described-  shouldn't we *warn* = clients that the
>> region might be inconsistent, so the users behind the client = can vote
>> with their feet, (or take the risk)?
>>
>> --Vaughn
>> _______________________________________________
>> 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
>
>


= --Apple-Mail-1--778663196-- From dzonatas@gmail.com Sat Apr 2 20:20:18 2011 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 3CED53A690F for ; Sat, 2 Apr 2011 20:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.111 X-Spam-Level: X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 L4FREr-Arn9m for ; Sat, 2 Apr 2011 20:20:16 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id CECCB3A690B for ; Sat, 2 Apr 2011 20:20:14 -0700 (PDT) Received: by iwn39 with SMTP id 39so5475207iwn.31 for ; Sat, 02 Apr 2011 20:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=IRpxK8WiyCnF3c1WN+YPF661KaK6rjYt/3A1XBrFe+4=; b=Fvb001ENJKK/l8cxhxL5juT6HvD6a56jFZKJMwAeLZKw2oW7gkvLZRKX8K3fczK1v5 dLUiNWAvf/N6gS3PBXteeISF5kREWo6/DoZzPzT8LGMk72njsy7N0GDd2oN6sJ3jEWR2 kmOAuWNkM0q3RkYTMx/crir/QSWLp3BVggVnE= 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=MMpOz1LJ401OSwKoZ742NC1aW60GQHn9VMDk3htzIbQRvF/57+XFkM/RfEp3TRBgQH NHkMQYRnh0xMFaa4UUuykjuVUody4QXJiyWLpJth0SJ8fGp5obnSVa4qF4452iIsGeoU p/KH67HGc5yR+Mw/3gF62EiVOF/jpYQr+Qn8Y= Received: by 10.42.131.6 with SMTP id x6mr3641886ics.30.1301800914364; Sat, 02 Apr 2011 20:21:54 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id wo15sm2441186icb.4.2011.04.02.20.21.52 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Apr 2011 20:21:53 -0700 (PDT) Message-ID: <4D97E7FE.7010104@gmail.com> Date: Sat, 02 Apr 2011 20:22:38 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Israel Alanis References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> In-Reply-To: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 03 Apr 2011 03:20:18 -0000 Somehow I feel the basic asset server being able to login and download assets is now priority, yet I also wondered the best way to patch this into the current mode of viewers. Maybe offer (1) by proxy (sim-side) and (2) by patch (viewer-side) that either of these two are optional and neither are mandatory for now. Thoughts? Israel Alanis wrote: > > > when designing for scalability, the model to bear in mind is ... > > Well, there are a lot of different models to keep in mind, and many > different use cases. One particular use case to keep in mind is: "User > acquires new outfit, and wants to 'show it off' in a highly populated > region". > > > Both worlds and asset services may include commercial, community, > and personal services > > Yes, yes and yes. I'm particularly concerned about how the model > affects the ability to host personal asset services. > > > a proxying region, which would get slammed for every asset worn by > every avatar present. > > Granted the collection of services that are provided by the region > need to be scaled to meet the demands of that region. That's all part > of capacity planning. > > > regions run many different CPU-intensive tasks, including physics > simulation and server-side scripting, and absolutely cannot afford to > serve assets too > > Well... who said the same CPU's have to do proxying, physics > simulation and server-side scripting? Asset proxying is a different > service than physics simulation and can be on separate hardware, could > make use of geographically distributed caching, and in certain > deployment patterns, the same caching services could be shared by > different regions. (Server-side scripting is a discussion for another > day). > > > This is why we have to go parallel... > > Totally agree, and a proxying model could and should also take > advantage of parallelism. > > > I think you're wrong that it has to cost much money. > ?vs? > > It costs money to host a high performance and scalable asset service > and a high bandwidth network to handle the traffic. A *lot* of money. > > I think what you're saying is: "It costs a lot of money to build a > scalable asset service, but if assets are spread throughout the > internet they don't have to be scalable." But that's not quite right. > You're opening up every asset server to the VW equivalent of being > slashdotted, so are you sure you're not forcing *every* asset service > to be scalable and handle a lot of bandwith and network traffic? It's > the exact opposite of your intention, but I think that's the result, > all the same. > > This particular design decision has a big effect on the economics of > the VW infrastructure. I'd rather the economics to work out such that > a region provider who wishes to build a region that supports a small > population, can do so economically. A region that wants to host a > *large* population has to bear that cost of providing that scalable > asset service. > > I want the economics of hosting a small asset service to be a > non-issue (as to best promote creation and creativity). Creating a > high bar to provide asset services will mean that service will cost > money and people shouldn't have to pay money just to create or own VW > objects (I'm using 'own' here to refer to maintaining their existence, > I'm not trying to make a 'leftist'/'communist' statement about > ownership ;) > > - Izzy > > > On Apr 2, 2011, at 3:58 PM, Morgaine wrote: > >> Izzy, when designing for scalability, the model to bear in mind is >> that of seasoned virtual world travelers whose inventories contain >> assets from many different worlds, those assets being served by many >> different asset services. Both worlds and asset services may include >> commercial, community, and personal services, and as the metaverse >> grows, that set is highly likely to become progressively less >> clustered and more diverse. >> >> When those seasoned travelers click on an advertised VW link and >> perform an inter-world teleport to one particular world's region to >> share an experience, their "worn" assets (the only ones of interest >> to the region) will contain references to asset services spread >> widely across the Internet. The fetches by the travelers' clients >> occur over many parallel paths from clients to asset services, so one >> can reasonably expect reduced network contention and reduced asset >> server loading because they are both spread out over however many >> asset services are being referenced by the overall set of assets in >> the region. >> >> This is very different to the case of a proxying region, which would >> get slammed for every asset worn by every avatar present. In our >> current architecture, regions run many different CPU-intensive tasks, >> including physics simulation and server-side scripting, and >> absolutely cannot afford to serve assets too unless your scalability >> requirements are very low indeed, ie. just a few dozen avatars of >> today's kind. We've hit the ceiling already on region scalability >> done that way. There is nowhere to go in that direction at all >> beyond improving the code like Intel demonstrated, and that work is >> subject to a law of diminishing returns. >> >> This is why we have to go parallel, and I think you're wrong that it >> has to cost much money. As we spread the load across more and more >> asset services, we are simply better utilizing all the hardware >> that's already out there on the Internet, at least in respect of >> community and private resources. But add to the community and >> private resources the commercial asset services that are likely to >> appear to exploit this opportunity, and not only will the number of >> asset services leap, but the power of each one will rocket too, >> because, after all, these businesses will be heavily optimized for >> the job. >> >> As to why a world would want clients to access external asset >> services instead of providing its own implementation, that's an easy >> question. It costs money to host a high performance and scalable >> asset service and a high bandwidth network to handle the traffic. A >> *lot* of money. In contrast, it costs a world nothing to let others >> serve the assets to clients. And that matters to the bottom line. >> >> >> Morgaine. >> >> >> >> >> ====================== >> >> On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis > > wrote: >> >> > As always though, it's a trade-off, since the proxied design >> has very poor scalability compared to the distributed one. >> >> I don't agree with that... If a user enters a highly populated >> region, >> every other client is going to (could and should be trying to) >> hit the >> asset server(s) for the assets that the user is wearing (assuming >> they're not cached locally). Every asset server has to be scaled up >> to the point that it can handle that load from all over... >> >> If I'm hosting a region that supports 10s of thousands of >> simultaneous >> users (thinking of the future), I already have to scale to meet that >> demand. If the region is proxying the assets, then, yes the >> region has >> to be scaled to meet that asset demand too, but it already has to be >> scaled to meet other demands of being a region server... and why is >> scaling those asset proxy services hard? It's going to cost $, >> but is >> not technically challenging. So, if I want to host a region like >> that... sure it will cost me, but the simulation will be consistent >> and users will be able to participate equally, regardless of the >> capabilities of their individual asset services. >> >> >> >> >> On Fri, Apr 1, 2011 at 11:55 PM, Morgaine >> > > wrote: >> > Every design choice results in a trade-off, Vaughn, improving >> one thing at >> > the expense of something else. If every time we offered a >> service we had to >> > inform its users about the downsides of all the trade-offs we >> have made, >> > they would have an awful lot to read. ;-) >> > >> > The specific trade-off that you are discussing is no >> different. A region >> > that proxies all content has the "benefit" of acquiring control >> from the >> > asset servers over the items in the region, so that it can >> ensure that >> > everyone in the region not only obtains the items but obtains >> the same items >> > as everyone else. That does indeed provide a greater guarantee of >> > consistency than a deployment in which the region only passes >> asset URIs to >> > clients who then fetch the items from asset services >> separately. As always >> > though, it's a trade-off, since the proxied design has very >> poor scalability >> > compared to the distributed one. >> > >> > If we're going to warn users of the potential for inconsistency >> in the >> > distributed deployment as you suggest, are we also going to >> warn them of >> > non-scalability in the proxied one? I really don't see much >> merit in the >> > idea of warning about design choices. Many such choices are >> technical, and >> > the issues are quite likely to be of little interest to >> non-technical users >> > anyway. In any case, the better services are likely to provide >> such >> > information in their online documentation, I would guess. >> > >> > You mentioned users "voting with their feet" or choosing to >> accept the risk >> > of inconsistency. Well that will happen anyway, when services >> fail and >> > users get annoyed. If some asset services refuse to send the >> requested >> > items to some users, those services will get a bad reputation >> and people >> > will choose different asset services instead. Likewise, if a >> world service >> > proxies everything and so it can't handle a large number of >> assets or of >> > people, users will get annoyed at the lag and will go >> elsewhere. This user >> > evaluation and "voting with their feet" happens already with >> online services >> > all over the Internet, and I am sure that this human process >> will continue >> > to work when the services are asset and region services. >> > >> > Back in September 2010, I wrote this post which proposes that >> we use in >> > VWRAP a form of asset addressing that provides massive >> scalability at the >> > same time as a very high degree of resilience -- >> > >> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >> . It is >> > based on the concept of the URI containing a host part and a >> hash part, >> > where the hash is generated (once, at the time of storage to >> the asset >> > service) using a specified digest algorithm over the content of >> the asset >> > being referenced. You may wish to note that if this design >> were used, the >> > failure of an asset service to deliver a requested item would >> result in a >> > failover request for the item to one or more backup services, >> using the same >> > hash part but with a different host address. >> > >> > This can go some way towards overcoming the problem that you >> think might >> > occur when assets are fetched by clients from asset services >> directly. >> > Although it won't help when the missing item is available from >> only a single >> > asset service, it will help in many other cases, and it will >> compensate for >> > service failures and network outages automatically at the same >> time. >> > >> > PS. This design for hash-based asset addressing is already >> being tested by >> > Mojito Sorbet in her experimental world and client. It would give >> > VWRAP-based worlds an improved level of service availability, >> so I think it >> > should be a core feature of our protocol. >> > >> > >> > Morgaine. >> > >> > >> > >> > >> > =========================== >> > >> > On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca >> > >> > wrote: >> >> >> >> This is a question i discussed with Morgaine off-list a while >> ago (I >> >> intended to send it to the list but pushed the wrong button...) I >> >> think we need to address this problem, and decide how to deal >> with it. >> >> >> >> In Davids deployment draft, section 7.3.1.1 an overview is >> given van >> >> ways to deliver content to the region. One way is only passing a >> >> capability that allows access to (part of) the resource: >> >> >> >> 7.3.1.1. Content delivery models >> >> A range of possible represenations can be passed to >> a region for >> >> simulation. [...] The other end of the delivery spectrum >> >> involves passing >> >> only a URI or capability used to access the rendering >> >> information and a >> >> collision mesh,and related data for physical simulation. >> >> In such a model, the client is responsible for >> fetching the >> >> additional >> >> information needed to render the item's visual >> presence from a >> >> separate >> >> service. This fetch can be done *under the >> credentials of the >> >> end user* >> >> viewing the material [my emphasis--VD] , and >> divorces the >> >> simulation from >> >> the trust chain needed to manage content. Any >> automation >> >> is done on a >> >> separate host which the content creator or owner trusts, >> >> interacting with the >> >> object through remoted interfaces. >> >> >> >> I can see the need for such a setup, however, i feel we are >> >> unpleasantly close to a situation were the coherence of the >> simulation >> >> falls apart. >> >> In this deployment pattern the region advertises the presence >> of the >> >> asset, and *some* clients will be able to get it as expected, >> while >> >> -based on the arbitrary whims of the asset service- others >> might not. >> >> >> >> My hope would be that after the asset server provides the >> region with >> >> the capability to get the asset, it gives up control. That >> would mean >> >> that if the client finds the inventory server is unwilling to >> serve >> >> the content - in spire of the region saying it is present-, >> the client >> >> should be able to turn around ask the *region* for the asset, >> (and get >> >> is after all). >> >> >> >> If that is not the case, -and there are probably good reasons >> for the >> >> deployment pattern as described- shouldn't we *warn* clients >> that the >> >> region might be inconsistent, so the users behind the client >> can vote >> >> with their feet, (or take the risk)? >> >> >> >> --Vaughn >> >> _______________________________________________ >> >> vwrap mailing list >> >> vwrap@ietf.org >> >> https://www.ietf.org/mailman/listinfo/vwrap >> > >> > >> > _______________________________________________ >> > vwrap mailing list >> > vwrap@ietf.org >> > https://www.ietf.org/mailman/listinfo/vwrap >> > >> > >> >> > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Sat Apr 2 20:49:07 2011 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 61B9928C0DE for ; Sat, 2 Apr 2011 20:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 82s5LWMJtJHV for ; Sat, 2 Apr 2011 20:49:05 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 0006228C0D0 for ; Sat, 2 Apr 2011 20:49:04 -0700 (PDT) Received: by iye19 with SMTP id 19so5674625iye.31 for ; Sat, 02 Apr 2011 20:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LHla97CVZ2CCZf1x/UhxD7jMYkVM3GGBM17VLy0gI44=; b=MJIdij0g4s2G9lTdvbmwqZVSlOaZ+tfIUOOUtvMoY0qfGyUJ0ah1qgpJyhshi1PWya 2uOrPKq8wsaJug/LPFD/Rz5vSlCdsJiN1jMyUIN+PeEHASYAtU/xYW6cTIMCRXKjGghp TLt38lEQIjeKdJ5sWlh8sXJRoXDopdHMAElYc= 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=em8ycbtsMQmmf18a2EjYwxGpSDazOcGpungIiDA1HZfAD6m5z9FuhA90I+QSDQv4Ah 1BT6uZNwnnSdxWhX7Vw3PPBSkPdsjjIR+X8cIFiJLfsuSxozwgXOD5HORYyS9sUS9PEH H4RMBSb4NJn2sRAEW/QvIUdGotEP8xRPSWzV4= Received: by 10.43.62.10 with SMTP id wy10mr4802184icb.37.1301802645963; Sat, 02 Apr 2011 20:50:45 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id gy41sm2670627ibb.39.2011.04.02.20.50.42 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Apr 2011 20:50:44 -0700 (PDT) Message-ID: <4D97EEC1.7020207@gmail.com> Date: Sat, 02 Apr 2011 20:51:29 -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: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> In-Reply-To: <4D97E7FE.7010104@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 03 Apr 2011 03:49:07 -0000 Some stated the proxy-to-asset-server is built into the sim; however, keep in mind possible legacy support where the asset server may proxy the simulator. Dzonatas Sol wrote: > Somehow I feel the basic asset server being able to login and download > assets is now priority, yet I also wondered the best way to patch this > into the current mode of viewers. > > Maybe offer (1) by proxy (sim-side) and (2) by patch (viewer-side) > that either of these two are optional and neither are mandatory for > now. Thoughts? > > Israel Alanis wrote: >> >> > when designing for scalability, the model to bear in mind is ... >> >> Well, there are a lot of different models to keep in mind, and many >> different use cases. One particular use case to keep in mind is: >> "User acquires new outfit, and wants to 'show it off' in a highly >> populated region". >> >> > Both worlds and asset services may include commercial, community, >> and personal services >> >> Yes, yes and yes. I'm particularly concerned about how the model >> affects the ability to host personal asset services. >> >> > a proxying region, which would get slammed for every asset worn by >> every avatar present. >> >> Granted the collection of services that are provided by the region >> need to be scaled to meet the demands of that region. That's all part >> of capacity planning. >> >> > regions run many different CPU-intensive tasks, including physics >> simulation and server-side scripting, and absolutely cannot afford to >> serve assets too >> Well... who said the same CPU's have to do proxying, physics >> simulation and server-side scripting? Asset proxying is a different >> service than physics simulation and can be on separate hardware, >> could make use of geographically distributed caching, and in certain >> deployment patterns, the same caching services could be shared by >> different regions. (Server-side scripting is a discussion for another >> day). >> >> > This is why we have to go parallel... >> >> Totally agree, and a proxying model could and should also take >> advantage of parallelism. >> >> > I think you're wrong that it has to cost much money. ?vs? >> > It costs money to host a high performance and scalable asset >> service and a high bandwidth network to handle the traffic. A *lot* >> of money. >> I think what you're saying is: "It costs a lot of money to build a >> scalable asset service, but if assets are spread throughout the >> internet they don't have to be scalable." But that's not quite right. >> You're opening up every asset server to the VW equivalent of being >> slashdotted, so are you sure you're not forcing *every* asset service >> to be scalable and handle a lot of bandwith and network traffic? It's >> the exact opposite of your intention, but I think that's the result, >> all the same. >> >> This particular design decision has a big effect on the economics of >> the VW infrastructure. I'd rather the economics to work out such that >> a region provider who wishes to build a region that supports a small >> population, can do so economically. A region that wants to host a >> *large* population has to bear that cost of providing that scalable >> asset service. >> I want the economics of hosting a small asset service to be a >> non-issue (as to best promote creation and creativity). Creating a >> high bar to provide asset services will mean that service will cost >> money and people shouldn't have to pay money just to create or own VW >> objects (I'm using 'own' here to refer to maintaining their >> existence, I'm not trying to make a 'leftist'/'communist' statement >> about ownership ;) >> >> - Izzy >> >> >> On Apr 2, 2011, at 3:58 PM, Morgaine wrote: >> >>> Izzy, when designing for scalability, the model to bear in mind is >>> that of seasoned virtual world travelers whose inventories contain >>> assets from many different worlds, those assets being served by many >>> different asset services. Both worlds and asset services may >>> include commercial, community, and personal services, and as the >>> metaverse grows, that set is highly likely to become progressively >>> less clustered and more diverse. >>> >>> When those seasoned travelers click on an advertised VW link and >>> perform an inter-world teleport to one particular world's region to >>> share an experience, their "worn" assets (the only ones of interest >>> to the region) will contain references to asset services spread >>> widely across the Internet. The fetches by the travelers' clients >>> occur over many parallel paths from clients to asset services, so >>> one can reasonably expect reduced network contention and reduced >>> asset server loading because they are both spread out over however >>> many asset services are being referenced by the overall set of >>> assets in the region. >>> >>> This is very different to the case of a proxying region, which would >>> get slammed for every asset worn by every avatar present. In our >>> current architecture, regions run many different CPU-intensive >>> tasks, including physics simulation and server-side scripting, and >>> absolutely cannot afford to serve assets too unless your scalability >>> requirements are very low indeed, ie. just a few dozen avatars of >>> today's kind. We've hit the ceiling already on region scalability >>> done that way. There is nowhere to go in that direction at all >>> beyond improving the code like Intel demonstrated, and that work is >>> subject to a law of diminishing returns. >>> >>> This is why we have to go parallel, and I think you're wrong that it >>> has to cost much money. As we spread the load across more and more >>> asset services, we are simply better utilizing all the hardware >>> that's already out there on the Internet, at least in respect of >>> community and private resources. But add to the community and >>> private resources the commercial asset services that are likely to >>> appear to exploit this opportunity, and not only will the number of >>> asset services leap, but the power of each one will rocket too, >>> because, after all, these businesses will be heavily optimized for >>> the job. >>> >>> As to why a world would want clients to access external asset >>> services instead of providing its own implementation, that's an easy >>> question. It costs money to host a high performance and scalable >>> asset service and a high bandwidth network to handle the traffic. A >>> *lot* of money. In contrast, it costs a world nothing to let others >>> serve the assets to clients. And that matters to the bottom line. >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> ====================== >>> >>> On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis >> > wrote: >>> >>> > As always though, it's a trade-off, since the proxied design >>> has very poor scalability compared to the distributed one. >>> >>> I don't agree with that... If a user enters a highly populated >>> region, >>> every other client is going to (could and should be trying to) >>> hit the >>> asset server(s) for the assets that the user is wearing (assuming >>> they're not cached locally). Every asset server has to be >>> scaled up >>> to the point that it can handle that load from all over... >>> >>> If I'm hosting a region that supports 10s of thousands of >>> simultaneous >>> users (thinking of the future), I already have to scale to meet >>> that >>> demand. If the region is proxying the assets, then, yes the >>> region has >>> to be scaled to meet that asset demand too, but it already has >>> to be >>> scaled to meet other demands of being a region server... and why is >>> scaling those asset proxy services hard? It's going to cost $, >>> but is >>> not technically challenging. So, if I want to host a region like >>> that... sure it will cost me, but the simulation will be consistent >>> and users will be able to participate equally, regardless of the >>> capabilities of their individual asset services. >>> >>> >>> >>> >>> On Fri, Apr 1, 2011 at 11:55 PM, Morgaine >>> >> > wrote: >>> > Every design choice results in a trade-off, Vaughn, improving >>> one thing at >>> > the expense of something else. If every time we offered a >>> service we had to >>> > inform its users about the downsides of all the trade-offs we >>> have made, >>> > they would have an awful lot to read. ;-) >>> > >>> > The specific trade-off that you are discussing is no >>> different. A region >>> > that proxies all content has the "benefit" of acquiring control >>> from the >>> > asset servers over the items in the region, so that it can >>> ensure that >>> > everyone in the region not only obtains the items but obtains >>> the same items >>> > as everyone else. That does indeed provide a greater >>> guarantee of >>> > consistency than a deployment in which the region only passes >>> asset URIs to >>> > clients who then fetch the items from asset services >>> separately. As always >>> > though, it's a trade-off, since the proxied design has very >>> poor scalability >>> > compared to the distributed one. >>> > >>> > If we're going to warn users of the potential for inconsistency >>> in the >>> > distributed deployment as you suggest, are we also going to >>> warn them of >>> > non-scalability in the proxied one? I really don't see much >>> merit in the >>> > idea of warning about design choices. Many such choices are >>> technical, and >>> > the issues are quite likely to be of little interest to >>> non-technical users >>> > anyway. In any case, the better services are likely to provide >>> such >>> > information in their online documentation, I would guess. >>> > >>> > You mentioned users "voting with their feet" or choosing to >>> accept the risk >>> > of inconsistency. Well that will happen anyway, when services >>> fail and >>> > users get annoyed. If some asset services refuse to send the >>> requested >>> > items to some users, those services will get a bad reputation >>> and people >>> > will choose different asset services instead. Likewise, if a >>> world service >>> > proxies everything and so it can't handle a large number of >>> assets or of >>> > people, users will get annoyed at the lag and will go >>> elsewhere. This user >>> > evaluation and "voting with their feet" happens already with >>> online services >>> > all over the Internet, and I am sure that this human process >>> will continue >>> > to work when the services are asset and region services. >>> > >>> > Back in September 2010, I wrote this post which proposes that >>> we use in >>> > VWRAP a form of asset addressing that provides massive >>> scalability at the >>> > same time as a very high degree of resilience -- >>> > >>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >>> . It is >>> > based on the concept of the URI containing a host part and a >>> hash part, >>> > where the hash is generated (once, at the time of storage to >>> the asset >>> > service) using a specified digest algorithm over the content of >>> the asset >>> > being referenced. You may wish to note that if this design >>> were used, the >>> > failure of an asset service to deliver a requested item would >>> result in a >>> > failover request for the item to one or more backup services, >>> using the same >>> > hash part but with a different host address. >>> > >>> > This can go some way towards overcoming the problem that you >>> think might >>> > occur when assets are fetched by clients from asset services >>> directly. >>> > Although it won't help when the missing item is available from >>> only a single >>> > asset service, it will help in many other cases, and it will >>> compensate for >>> > service failures and network outages automatically at the same >>> time. >>> > >>> > PS. This design for hash-based asset addressing is already >>> being tested by >>> > Mojito Sorbet in her experimental world and client. It would >>> give >>> > VWRAP-based worlds an improved level of service availability, >>> so I think it >>> > should be a core feature of our protocol. >>> > >>> > >>> > Morgaine. >>> > >>> > >>> > >>> > >>> > =========================== >>> > >>> > On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca >>> > >>> > wrote: >>> >> >>> >> This is a question i discussed with Morgaine off-list a while >>> ago (I >>> >> intended to send it to the list but pushed the wrong >>> button...) I >>> >> think we need to address this problem, and decide how to deal >>> with it. >>> >> >>> >> In Davids deployment draft, section 7.3.1.1 an overview is >>> given van >>> >> ways to deliver content to the region. One way is only passing a >>> >> capability that allows access to (part of) the resource: >>> >> >>> >> 7.3.1.1. Content delivery models >>> >> A range of possible represenations can be passed to >>> a region for >>> >> simulation. [...] The other end of the delivery >>> spectrum >>> >> involves passing >>> >> only a URI or capability used to access the rendering >>> >> information and a >>> >> collision mesh,and related data for physical >>> simulation. >>> >> In such a model, the client is responsible for >>> fetching the >>> >> additional >>> >> information needed to render the item's visual >>> presence from a >>> >> separate >>> >> service. This fetch can be done *under the >>> credentials of the >>> >> end user* >>> >> viewing the material [my emphasis--VD] , and >>> divorces the >>> >> simulation from >>> >> the trust chain needed to manage content. Any >>> automation >>> >> is done on a >>> >> separate host which the content creator or owner >>> trusts, >>> >> interacting with the >>> >> object through remoted interfaces. >>> >> >>> >> I can see the need for such a setup, however, i feel we are >>> >> unpleasantly close to a situation were the coherence of the >>> simulation >>> >> falls apart. >>> >> In this deployment pattern the region advertises the presence >>> of the >>> >> asset, and *some* clients will be able to get it as expected, >>> while >>> >> -based on the arbitrary whims of the asset service- others >>> might not. >>> >> >>> >> My hope would be that after the asset server provides the >>> region with >>> >> the capability to get the asset, it gives up control. That >>> would mean >>> >> that if the client finds the inventory server is unwilling to >>> serve >>> >> the content - in spire of the region saying it is present-, >>> the client >>> >> should be able to turn around ask the *region* for the asset, >>> (and get >>> >> is after all). >>> >> >>> >> If that is not the case, -and there are probably good reasons >>> for the >>> >> deployment pattern as described- shouldn't we *warn* clients >>> that the >>> >> region might be inconsistent, so the users behind the client >>> can vote >>> >> with their feet, (or take the risk)? >>> >> >>> >> --Vaughn >>> >> _______________________________________________ >>> >> vwrap mailing list >>> >> vwrap@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/vwrap >>> > >>> > >>> > _______________________________________________ >>> > vwrap mailing list >>> > vwrap@ietf.org >>> > https://www.ietf.org/mailman/listinfo/vwrap >>> > >>> > >>> >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From vaughn.deluca@gmail.com Sat Apr 2 23:54:39 2011 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 E6ED53A692F for ; Sat, 2 Apr 2011 23:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.016 X-Spam-Level: X-Spam-Status: No, score=-3.016 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 iSS5DURM-vXx for ; Sat, 2 Apr 2011 23:54:36 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id A81733A692E for ; Sat, 2 Apr 2011 23:54:35 -0700 (PDT) Received: by eye13 with SMTP id 13so1628181eye.31 for ; Sat, 02 Apr 2011 23:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/xFg8zYb/SGVv1rVvWT65GsmaYPZ+xEUen4LqgJr29s=; b=vDrGLxPhyg1SobbA4UYPVCY+irtzyCnvsCzu654i76U/ZsOEyeYGV53KlNEFxVjjy+ YD/g31K4/Wlq7ovzNenWE3mluUDB5zM3xiWLDny3b2W4pVJLvtO4chSpoxWGQspOeg0F tz4v0BuRdgvSIfgrqigQ12MgQPwZzlBFkw02M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fyCIISK7QTgVINpCD8xIDQzNh9q5pqcNuVPL5z/0H2NH+IioF/Ku5j3ag3WFtzXCo4 uNdLMhZ/f3DOpwDwJ85fy0wxfGPWNMjksMpfMmDbCgEYA+nRCaga4CbDwWghAatKAFmK zkDmVnZWgaTg0lC9GGZaN1CS0t+f/71rFTpNk= MIME-Version: 1.0 Received: by 10.213.34.209 with SMTP id m17mr3060712ebd.3.1301813775355; Sat, 02 Apr 2011 23:56:15 -0700 (PDT) Received: by 10.213.17.17 with HTTP; Sat, 2 Apr 2011 23:56:15 -0700 (PDT) In-Reply-To: <4D97EEC1.7020207@gmail.com> References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> Date: Sun, 3 Apr 2011 08:56:15 +0200 Message-ID: From: Vaughn Deluca To: Dzonatas Sol Content-Type: multipart/alternative; boundary=0015174c177ca4d0a0049ffe23a4 Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 03 Apr 2011 06:54:40 -0000 --0015174c177ca4d0a0049ffe23a4 Content-Type: text/plain; charset=ISO-8859-1 Hi Dzonatas Can you expand on that, what would be needed for legacy support in VWAP terms ?, If i want to read up on how the asset server may proxy the simulator, what would you recommend me to read? -- Vaughn On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol wrote: > Some stated the proxy-to-asset-server is built into the sim; however, keep > in mind possible legacy support where the asset server may proxy the > simulator. > > > Dzonatas Sol wrote: > >> Somehow I feel the basic asset server being able to login and download >> assets is now priority, yet I also wondered the best way to patch this into >> the current mode of viewers. >> >> Maybe offer (1) by proxy (sim-side) and (2) by patch (viewer-side) that >> either of these two are optional and neither are mandatory for now. >> Thoughts? >> >> Israel Alanis wrote: >> >>> >>> > when designing for scalability, the model to bear in mind is ... >>> >>> Well, there are a lot of different models to keep in mind, and many >>> different use cases. One particular use case to keep in mind is: "User >>> acquires new outfit, and wants to 'show it off' in a highly populated >>> region". >>> >>> > Both worlds and asset services may include commercial, community, and >>> personal services >>> >>> Yes, yes and yes. I'm particularly concerned about how the model affects >>> the ability to host personal asset services. >>> >>> > a proxying region, which would get slammed for every asset worn by >>> every avatar present. >>> >>> Granted the collection of services that are provided by the region need >>> to be scaled to meet the demands of that region. That's all part of capacity >>> planning. >>> >>> > regions run many different CPU-intensive tasks, including physics >>> simulation and server-side scripting, and absolutely cannot afford to serve >>> assets too >>> Well... who said the same CPU's have to do proxying, physics simulation >>> and server-side scripting? Asset proxying is a different service than >>> physics simulation and can be on separate hardware, could make use of >>> geographically distributed caching, and in certain deployment patterns, the >>> same caching services could be shared by different regions. (Server-side >>> scripting is a discussion for another day). >>> >>> > This is why we have to go parallel... >>> >>> Totally agree, and a proxying model could and should also take advantage >>> of parallelism. >>> >>> > I think you're wrong that it has to cost much money. ?vs? >>> > It costs money to host a high performance and scalable asset service >>> and a high bandwidth network to handle the traffic. A *lot* of money. >>> I think what you're saying is: "It costs a lot of money to build a >>> scalable asset service, but if assets are spread throughout the internet >>> they don't have to be scalable." But that's not quite right. You're opening >>> up every asset server to the VW equivalent of being slashdotted, so are you >>> sure you're not forcing *every* asset service to be scalable and handle a >>> lot of bandwith and network traffic? It's the exact opposite of your >>> intention, but I think that's the result, all the same. >>> >>> This particular design decision has a big effect on the economics of the >>> VW infrastructure. I'd rather the economics to work out such that a region >>> provider who wishes to build a region that supports a small population, can >>> do so economically. A region that wants to host a *large* population has to >>> bear that cost of providing that scalable asset service. >>> I want the economics of hosting a small asset service to be a non-issue >>> (as to best promote creation and creativity). Creating a high bar to provide >>> asset services will mean that service will cost money and people shouldn't >>> have to pay money just to create or own VW objects (I'm using 'own' here to >>> refer to maintaining their existence, I'm not trying to make a >>> 'leftist'/'communist' statement about ownership ;) >>> >>> - Izzy >>> >>> >>> On Apr 2, 2011, at 3:58 PM, Morgaine wrote: >>> >>> Izzy, when designing for scalability, the model to bear in mind is that >>>> of seasoned virtual world travelers whose inventories contain assets from >>>> many different worlds, those assets being served by many different asset >>>> services. Both worlds and asset services may include commercial, community, >>>> and personal services, and as the metaverse grows, that set is highly likely >>>> to become progressively less clustered and more diverse. >>>> >>>> When those seasoned travelers click on an advertised VW link and perform >>>> an inter-world teleport to one particular world's region to share an >>>> experience, their "worn" assets (the only ones of interest to the region) >>>> will contain references to asset services spread widely across the Internet. >>>> The fetches by the travelers' clients occur over many parallel paths from >>>> clients to asset services, so one can reasonably expect reduced network >>>> contention and reduced asset server loading because they are both spread out >>>> over however many asset services are being referenced by the overall set of >>>> assets in the region. >>>> >>>> This is very different to the case of a proxying region, which would get >>>> slammed for every asset worn by every avatar present. In our current >>>> architecture, regions run many different CPU-intensive tasks, including >>>> physics simulation and server-side scripting, and absolutely cannot afford >>>> to serve assets too unless your scalability requirements are very low >>>> indeed, ie. just a few dozen avatars of today's kind. We've hit the ceiling >>>> already on region scalability done that way. There is nowhere to go in that >>>> direction at all beyond improving the code like Intel demonstrated, and that >>>> work is subject to a law of diminishing returns. >>>> >>>> This is why we have to go parallel, and I think you're wrong that it has >>>> to cost much money. As we spread the load across more and more asset >>>> services, we are simply better utilizing all the hardware that's already out >>>> there on the Internet, at least in respect of community and private >>>> resources. But add to the community and private resources the commercial >>>> asset services that are likely to appear to exploit this opportunity, and >>>> not only will the number of asset services leap, but the power of each one >>>> will rocket too, because, after all, these businesses will be heavily >>>> optimized for the job. >>>> >>>> As to why a world would want clients to access external asset services >>>> instead of providing its own implementation, that's an easy question. It >>>> costs money to host a high performance and scalable asset service and a high >>>> bandwidth network to handle the traffic. A *lot* of money. In contrast, it >>>> costs a world nothing to let others serve the assets to clients. And that >>>> matters to the bottom line. >>>> >>>> >>>> Morgaine. >>>> >>>> >>>> >>>> >>>> ====================== >>>> >>>> On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis >>> izzyalanis@gmail.com>> wrote: >>>> >>>> > As always though, it's a trade-off, since the proxied design >>>> has very poor scalability compared to the distributed one. >>>> >>>> I don't agree with that... If a user enters a highly populated >>>> region, >>>> every other client is going to (could and should be trying to) >>>> hit the >>>> asset server(s) for the assets that the user is wearing (assuming >>>> they're not cached locally). Every asset server has to be scaled up >>>> to the point that it can handle that load from all over... >>>> >>>> If I'm hosting a region that supports 10s of thousands of >>>> simultaneous >>>> users (thinking of the future), I already have to scale to meet that >>>> demand. If the region is proxying the assets, then, yes the >>>> region has >>>> to be scaled to meet that asset demand too, but it already has to be >>>> scaled to meet other demands of being a region server... and why is >>>> scaling those asset proxy services hard? It's going to cost $, >>>> but is >>>> not technically challenging. So, if I want to host a region like >>>> that... sure it will cost me, but the simulation will be consistent >>>> and users will be able to participate equally, regardless of the >>>> capabilities of their individual asset services. >>>> >>>> >>>> >>>> >>>> On Fri, Apr 1, 2011 at 11:55 PM, Morgaine >>>> >>> > wrote: >>>> > Every design choice results in a trade-off, Vaughn, improving >>>> one thing at >>>> > the expense of something else. If every time we offered a >>>> service we had to >>>> > inform its users about the downsides of all the trade-offs we >>>> have made, >>>> > they would have an awful lot to read. ;-) >>>> > >>>> > The specific trade-off that you are discussing is no >>>> different. A region >>>> > that proxies all content has the "benefit" of acquiring control >>>> from the >>>> > asset servers over the items in the region, so that it can >>>> ensure that >>>> > everyone in the region not only obtains the items but obtains >>>> the same items >>>> > as everyone else. That does indeed provide a greater guarantee of >>>> > consistency than a deployment in which the region only passes >>>> asset URIs to >>>> > clients who then fetch the items from asset services >>>> separately. As always >>>> > though, it's a trade-off, since the proxied design has very >>>> poor scalability >>>> > compared to the distributed one. >>>> > >>>> > If we're going to warn users of the potential for inconsistency >>>> in the >>>> > distributed deployment as you suggest, are we also going to >>>> warn them of >>>> > non-scalability in the proxied one? I really don't see much >>>> merit in the >>>> > idea of warning about design choices. Many such choices are >>>> technical, and >>>> > the issues are quite likely to be of little interest to >>>> non-technical users >>>> > anyway. In any case, the better services are likely to provide >>>> such >>>> > information in their online documentation, I would guess. >>>> > >>>> > You mentioned users "voting with their feet" or choosing to >>>> accept the risk >>>> > of inconsistency. Well that will happen anyway, when services >>>> fail and >>>> > users get annoyed. If some asset services refuse to send the >>>> requested >>>> > items to some users, those services will get a bad reputation >>>> and people >>>> > will choose different asset services instead. Likewise, if a >>>> world service >>>> > proxies everything and so it can't handle a large number of >>>> assets or of >>>> > people, users will get annoyed at the lag and will go >>>> elsewhere. This user >>>> > evaluation and "voting with their feet" happens already with >>>> online services >>>> > all over the Internet, and I am sure that this human process >>>> will continue >>>> > to work when the services are asset and region services. >>>> > >>>> > Back in September 2010, I wrote this post which proposes that >>>> we use in >>>> > VWRAP a form of asset addressing that provides massive >>>> scalability at the >>>> > same time as a very high degree of resilience -- >>>> > >>>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >>>> . It is >>>> > based on the concept of the URI containing a host part and a >>>> hash part, >>>> > where the hash is generated (once, at the time of storage to >>>> the asset >>>> > service) using a specified digest algorithm over the content of >>>> the asset >>>> > being referenced. You may wish to note that if this design >>>> were used, the >>>> > failure of an asset service to deliver a requested item would >>>> result in a >>>> > failover request for the item to one or more backup services, >>>> using the same >>>> > hash part but with a different host address. >>>> > >>>> > This can go some way towards overcoming the problem that you >>>> think might >>>> > occur when assets are fetched by clients from asset services >>>> directly. >>>> > Although it won't help when the missing item is available from >>>> only a single >>>> > asset service, it will help in many other cases, and it will >>>> compensate for >>>> > service failures and network outages automatically at the same >>>> time. >>>> > >>>> > PS. This design for hash-based asset addressing is already >>>> being tested by >>>> > Mojito Sorbet in her experimental world and client. It would give >>>> > VWRAP-based worlds an improved level of service availability, >>>> so I think it >>>> > should be a core feature of our protocol. >>>> > >>>> > >>>> > Morgaine. >>>> > >>>> > >>>> > >>>> > >>>> > =========================== >>>> > >>>> > On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca >>>> > >>>> > wrote: >>>> >> >>>> >> This is a question i discussed with Morgaine off-list a while >>>> ago (I >>>> >> intended to send it to the list but pushed the wrong button...) I >>>> >> think we need to address this problem, and decide how to deal >>>> with it. >>>> >> >>>> >> In Davids deployment draft, section 7.3.1.1 an overview is >>>> given van >>>> >> ways to deliver content to the region. One way is only passing a >>>> >> capability that allows access to (part of) the resource: >>>> >> >>>> >> 7.3.1.1. Content delivery models >>>> >> A range of possible represenations can be passed to >>>> a region for >>>> >> simulation. [...] The other end of the delivery spectrum >>>> >> involves passing >>>> >> only a URI or capability used to access the rendering >>>> >> information and a >>>> >> collision mesh,and related data for physical simulation. >>>> >> In such a model, the client is responsible for >>>> fetching the >>>> >> additional >>>> >> information needed to render the item's visual >>>> presence from a >>>> >> separate >>>> >> service. This fetch can be done *under the >>>> credentials of the >>>> >> end user* >>>> >> viewing the material [my emphasis--VD] , and >>>> divorces the >>>> >> simulation from >>>> >> the trust chain needed to manage content. Any >>>> automation >>>> >> is done on a >>>> >> separate host which the content creator or owner trusts, >>>> >> interacting with the >>>> >> object through remoted interfaces. >>>> >> >>>> >> I can see the need for such a setup, however, i feel we are >>>> >> unpleasantly close to a situation were the coherence of the >>>> simulation >>>> >> falls apart. >>>> >> In this deployment pattern the region advertises the presence >>>> of the >>>> >> asset, and *some* clients will be able to get it as expected, >>>> while >>>> >> -based on the arbitrary whims of the asset service- others >>>> might not. >>>> >> >>>> >> My hope would be that after the asset server provides the >>>> region with >>>> >> the capability to get the asset, it gives up control. That >>>> would mean >>>> >> that if the client finds the inventory server is unwilling to >>>> serve >>>> >> the content - in spire of the region saying it is present-, >>>> the client >>>> >> should be able to turn around ask the *region* for the asset, >>>> (and get >>>> >> is after all). >>>> >> >>>> >> If that is not the case, -and there are probably good reasons >>>> for the >>>> >> deployment pattern as described- shouldn't we *warn* clients >>>> that the >>>> >> region might be inconsistent, so the users behind the client >>>> can vote >>>> >> with their feet, (or take the risk)? >>>> >> >>>> >> --Vaughn >>>> >> _______________________________________________ >>>> >> vwrap mailing list >>>> >> vwrap@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/vwrap >>>> > >>>> > >>>> > _______________________________________________ >>>> > vwrap mailing list >>>> > vwrap@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/vwrap >>>> > >>>> > >>>> >>>> >>>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> vwrap mailing list >>> vwrap@ietf.org >>> https://www.ietf.org/mailman/listinfo/vwrap >>> >>> >> >> >> > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --0015174c177ca4d0a0049ffe23a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi=A0Dzonatas

Ca= n you expand on that, what would be needed for legacy support in VWAP terms= =A0?,
If i want to read up on how the=A0asset server may proxy the simulator= , what would you recommend me to read?

-- Vaughn
On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas S= ol <dzonatas@gma= il.com> wrote:
Some stated the proxy-to-asset-server is bu= ilt into the sim; however, keep in mind possible legacy support where the a= sset server may proxy the simulator.


Dzonatas Sol wrote:
Somehow I feel the basic asset server being able to login and download asse= ts is now priority, yet I also wondered the best way to patch this into the= current mode of viewers.

Maybe offer (1) by proxy (sim-side) and (2) by patch (viewer-side) that eit= her of these two are optional and neither are mandatory for now. Thoughts?<= br>
Israel Alanis wrote:

> when designing for scalability, the model to bear in mind is ...

Well, there are a lot of different models to keep in mind, and many differe= nt use cases. One particular use case to keep in mind is: "User acquir= es new outfit, and wants to 'show it off' in a highly populated reg= ion".

> Both worlds and asset services may include commercial, community, and = personal services

Yes, yes and yes. I'm particularly concerned about how the model affect= s the ability to host personal asset services.

> a proxying region, which would get slammed for every asset worn by eve= ry avatar present.

Granted the collection of services that are provided by the region need to = be scaled to meet the demands of that region. That's all part of capaci= ty planning.

> regions run many different CPU-intensive tasks, including physics simu= lation and server-side scripting, and absolutely cannot afford to serve ass= ets too
Well... who said the same CPU's have to do proxying, physics simulation= and server-side scripting? Asset proxying is a different service than phys= ics simulation and can be on separate hardware, could make use of geographi= cally distributed caching, and in certain deployment patterns, the same cac= hing services could be shared by different regions. (Server-side scripting = is a discussion for another day).

> This is why we have to go parallel...

Totally agree, and a proxying model could and should also take advantage of= parallelism.

> I think you're wrong that it has to cost much money. ?vs?
> It costs money to host a high performance and scalable asset service a= nd a high bandwidth network to handle the traffic. =A0A *lot* of money.
I think what you're saying is: "It costs a lot of money to build a= scalable asset service, but if assets are spread throughout the internet t= hey don't have to be scalable." But that's not quite right. Yo= u're opening up every asset server to the VW equivalent of being slashd= otted, so are you sure you're not forcing *every* asset service to be s= calable and handle a lot of bandwith and network traffic? It's the exac= t opposite of your intention, but I think that's the result, all the sa= me.

This particular design decision has a big effect on the economics of the VW= infrastructure. I'd rather the economics to work out such that a regio= n provider who wishes to build a region that supports a small population, c= an do so economically. A region that wants to host a *large* population has= to bear that cost of providing that scalable asset service.
I want the economics of hosting a small asset service to be a non-issue (as= to best promote creation and creativity). Creating a high bar to provide a= sset services will mean that service will cost money and people shouldn'= ;t have to pay money just to create or own VW objects (I'm using 'o= wn' here to refer to maintaining their existence, I'm not trying to= make a 'leftist'/'communist' statement about ownership ;)<= br>
- Izzy


On Apr 2, 2011, at 3:58 PM, Morgaine wrote:

Izzy, when designing for scalability, the model to bear in mind is that of = seasoned virtual world travelers whose inventories contain assets from many= different worlds, those assets being served by many different asset servic= es. =A0Both worlds and asset services may include commercial, community, an= d personal services, and as the metaverse grows, that set is highly likely = to become progressively less clustered and more diverse.

When those seasoned travelers click on an advertised VW link and perform an= inter-world teleport to one particular world's region to share an expe= rience, their "worn" assets (the only ones of interest to the reg= ion) will contain references to asset services spread widely across the Int= ernet. =A0The fetches by the travelers' clients occur over many paralle= l paths from clients to asset services, so one can reasonably expect reduce= d network contention and reduced asset server loading because they are both= spread out over however many asset services are being referenced by the ov= erall set of assets in the region.

This is very different to the case of a proxying region, which would get sl= ammed for every asset worn by every avatar present. =A0In our current archi= tecture, regions run many different CPU-intensive tasks, including physics = simulation and server-side scripting, and absolutely cannot afford to serve= assets too unless your scalability requirements are very low indeed, ie. j= ust a few dozen avatars of today's kind. =A0We've hit the ceiling a= lready on region scalability done that way. =A0There is nowhere to go in th= at direction at all beyond improving the code like Intel demonstrated, and = that work is subject to a law of diminishing returns.

This is why we have to go parallel, and I think you're wrong that it ha= s to cost much money. =A0As we spread the load across more and more asset s= ervices, we are simply better utilizing all the hardware that's already= out there on the Internet, at least in respect of community and private re= sources. =A0But add to the community and private resources the commercial a= sset services that are likely to appear to exploit this opportunity, and no= t only will the number of asset services leap, but the power of each one wi= ll rocket too, because, after all, these businesses will be heavily optimiz= ed for the job.

As to why a world would want clients to access external asset services inst= ead of providing its own implementation, that's an easy question. =A0It= costs money to host a high performance and scalable asset service and a hi= gh bandwidth network to handle the traffic. =A0A *lot* of money. =A0In cont= rast, it costs a world nothing to let others serve the assets to clients. = =A0And that matters to the bottom line.


Morgaine.




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

On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis <izzyalanis@gmail.com <mailto:izzyalanis@gmail.com= >> wrote:

=A0 =A0> As always though, it's a trade-off, since the proxied desi= gn
=A0 =A0has very poor scalability compared to the distributed one.

=A0 =A0I don't agree with that... If a user enters a highly populated<= br> =A0 =A0region,
=A0 =A0every other client is going to (could and should be trying to)
=A0 =A0hit the
=A0 =A0asset server(s) for the assets that the user is wearing (assuming =A0 =A0they're not cached locally). =A0Every asset server has to be sc= aled up
=A0 =A0to the point that it can handle that load from all over...

=A0 =A0If I'm hosting a region that supports 10s of thousands of
=A0 =A0simultaneous
=A0 =A0users (thinking of the future), I already have to scale to meet tha= t
=A0 =A0demand. If the region is proxying the assets, then, yes the
=A0 =A0region has
=A0 =A0to be scaled to meet that asset demand too, but it already has to b= e
=A0 =A0scaled to meet other demands of being a region server... and why is=
=A0 =A0scaling those asset proxy services hard? =A0It's going to cost = $,
=A0 =A0but is
=A0 =A0not technically challenging. So, if I want to host a region like =A0 =A0that... sure it will cost me, but the simulation will be consistent=
=A0 =A0and users will be able to participate equally, regardless of the =A0 =A0capabilities of their individual asset services.




=A0 =A0On Fri, Apr 1, 2011 at 11:55 PM, Morgaine
=A0 =A0<morgaine.dinova@googlemail.com
=A0 =A0<mailto:morgaine.dinova@googlemail.com>> wrote:
=A0 =A0> Every design choice results in a trade-off, Vaughn, improving<= br> =A0 =A0one thing at
=A0 =A0> the expense of something else. =A0If every time we offered a =A0 =A0service we had to
=A0 =A0> inform its users about the downsides of all the trade-offs we<= br> =A0 =A0have made,
=A0 =A0> they would have an awful lot to read. ;-)
=A0 =A0>
=A0 =A0> The specific trade-off that you are discussing is no
=A0 =A0different. =A0A region
=A0 =A0> that proxies all content has the "benefit" of acquir= ing control
=A0 =A0from the
=A0 =A0> asset servers over the items in the region, so that it can
=A0 =A0ensure that
=A0 =A0> everyone in the region not only obtains the items but obtains<= br> =A0 =A0the same items
=A0 =A0> as everyone else. =A0That does indeed provide a greater guaran= tee of
=A0 =A0> consistency than a deployment in which the region only passes<= br> =A0 =A0asset URIs to
=A0 =A0> clients who then fetch the items from asset services
=A0 =A0separately. =A0As always
=A0 =A0> though, it's a trade-off, since the proxied design has ver= y
=A0 =A0poor scalability
=A0 =A0> compared to the distributed one.
=A0 =A0>
=A0 =A0> If we're going to warn users of the potential for inconsis= tency
=A0 =A0in the
=A0 =A0> distributed deployment as you suggest, are we also going to =A0 =A0warn them of
=A0 =A0> non-scalability in the proxied one? =A0I really don't see = much
=A0 =A0merit in the
=A0 =A0> idea of warning about design choices. =A0Many such choices are=
=A0 =A0technical, and
=A0 =A0> the issues are quite likely to be of little interest to
=A0 =A0non-technical users
=A0 =A0> anyway. =A0In any case, the better services are likely to prov= ide
=A0 =A0such
=A0 =A0> information in their online documentation, I would guess.
=A0 =A0>
=A0 =A0> You mentioned users "voting with their feet" or choo= sing to
=A0 =A0accept the risk
=A0 =A0> of inconsistency. =A0Well that will happen anyway, when servic= es
=A0 =A0fail and
=A0 =A0> users get annoyed. =A0If some asset services refuse to send th= e
=A0 =A0requested
=A0 =A0> items to some users, those services will get a bad reputation<= br> =A0 =A0and people
=A0 =A0> will choose different asset services instead. =A0Likewise, if = a
=A0 =A0world service
=A0 =A0> proxies everything and so it can't handle a large number o= f
=A0 =A0assets or of
=A0 =A0> people, users will get annoyed at the lag and will go
=A0 =A0elsewhere. =A0This user
=A0 =A0> evaluation and "voting with their feet" happens alre= ady with
=A0 =A0online services
=A0 =A0> all over the Internet, and I am sure that this human process =A0 =A0will continue
=A0 =A0> to work when the services are asset and region services.
=A0 =A0>
=A0 =A0> Back in September 2010, I wrote this post which proposes that<= br> =A0 =A0we use in
=A0 =A0> VWRAP a form of asset addressing that provides massive
=A0 =A0scalability at the
=A0 =A0> same time as a very high degree of resilience --
=A0 =A0>
=A0 =A0http://www.ietf.org/mail-archive/web/vwrap/curr= ent/msg00463.html
=A0 =A0. =A0It is
=A0 =A0> based on the concept of the URI containing a host part and a =A0 =A0hash part,
=A0 =A0> where the hash is generated (once, at the time of storage to =A0 =A0the asset
=A0 =A0> service) using a specified digest algorithm over the content o= f
=A0 =A0the asset
=A0 =A0> being referenced. =A0You may wish to note that if this design<= br> =A0 =A0were used, the
=A0 =A0> failure of an asset service to deliver a requested item would<= br> =A0 =A0result in a
=A0 =A0> failover request for the item to one or more backup services,<= br> =A0 =A0using the same
=A0 =A0> hash part but with a different host address.
=A0 =A0>
=A0 =A0> This can go some way towards overcoming the problem that you =A0 =A0think might
=A0 =A0> occur when assets are fetched by clients from asset services =A0 =A0directly.
=A0 =A0> Although it won't help when the missing item is available = from
=A0 =A0only a single
=A0 =A0> asset service, it will help in many other cases, and it will =A0 =A0compensate for
=A0 =A0> service failures and network outages automatically at the same=
=A0 =A0time.
=A0 =A0>
=A0 =A0> PS. This design for hash-based asset addressing is already
=A0 =A0being tested by
=A0 =A0> Mojito Sorbet in her experimental world and client. =A0It woul= d give
=A0 =A0> VWRAP-based worlds an improved level of service availability,<= br> =A0 =A0so I think it
=A0 =A0> should be a core feature of our protocol.
=A0 =A0>
=A0 =A0>
=A0 =A0> Morgaine.
=A0 =A0>
=A0 =A0>
=A0 =A0>
=A0 =A0>
=A0 =A0> =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
=A0 =A0>
=A0 =A0> On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca
=A0 =A0<va= ughn.deluca@gmail.com <mailto:vaughn.deluca@gmail.com>>
=A0 =A0> wrote:
=A0 =A0>>
=A0 =A0>> This is a question i discussed with Morgaine off-list a wh= ile
=A0 =A0ago (I
=A0 =A0>> intended to send it to the list but pushed the wrong butto= n...) I
=A0 =A0>> think we need to address this problem, and decide how to d= eal
=A0 =A0with it.
=A0 =A0>>
=A0 =A0>> =A0In Davids deployment draft, section 7.3.1.1 an overview= is
=A0 =A0given van
=A0 =A0>> ways to deliver content to the region. One way is only pas= sing a
=A0 =A0>> capability that allows access to (part of) the resource: =A0 =A0>>
=A0 =A0>> =A0 =A0 =A0 =A0 =A0 7.3.1.1. =A0Content delivery models =A0 =A0>> =A0 =A0 =A0 =A0 =A0 A range of possible represenations can= be passed to
=A0 =A0a region for
=A0 =A0>> =A0 =A0 =A0 =A0 =A0 simulation. [...] The other end of the= delivery spectrum
=A0 =A0>> involves passing
=A0 =A0>> =A0 =A0 =A0 =A0 =A0 only a URI or capability used to acces= s the rendering
=A0 =A0>> information and a
=A0 =A0>> =A0 =A0 =A0 =A0 =A0 collision mesh,and related data for ph= ysical simulation.
=A0 =A0>> =A0 =A0 =A0 =A0 =A0 In such a model, the client is respons= ible for
=A0 =A0fetching the
=A0 =A0>> additional
=A0 =A0>> =A0 =A0 =A0 =A0 =A0 information needed to render the item&= #39;s visual
=A0 =A0presence from a
=A0 =A0>> separate
=A0 =A0>> =A0 =A0 =A0 =A0 =A0 service. =A0This fetch can be done *un= der the
=A0 =A0credentials of the
=A0 =A0>> end user*
=A0 =A0>> =A0 =A0 =A0 =A0 =A0 viewing the material [my emphasis--VD]= , and
=A0 =A0divorces the
=A0 =A0>> simulation from
=A0 =A0>> =A0 =A0 =A0 =A0 =A0 the trust chain needed to manage conte= nt. =A0Any
=A0 =A0automation
=A0 =A0>> is done on a
=A0 =A0>> =A0 =A0 =A0 =A0 =A0 separate host which the content creato= r or owner trusts,
=A0 =A0>> interacting with the
=A0 =A0>> =A0 =A0 =A0 =A0 =A0 object through remoted interfaces.
=A0 =A0>>
=A0 =A0>> =A0I can see the need for such a setup, however, i feel we= are
=A0 =A0>> unpleasantly close to a situation were the coherence of th= e
=A0 =A0simulation
=A0 =A0>> falls apart.
=A0 =A0>> In this deployment pattern the region advertises the prese= nce
=A0 =A0of the
=A0 =A0>> asset, and *some* clients will be able to get it as expect= ed,
=A0 =A0while
=A0 =A0>> -based on the arbitrary whims of the asset service- others=
=A0 =A0might not.
=A0 =A0>>
=A0 =A0>> My hope would be that after the asset server provides the<= br> =A0 =A0region with
=A0 =A0>> the capability to get the asset, it gives up control. That=
=A0 =A0would mean
=A0 =A0>> that if the client finds the inventory server is unwilling= to
=A0 =A0serve
=A0 =A0>> the content - in spire of the region saying it is present-= ,
=A0 =A0the client
=A0 =A0>> should be able to turn around ask the *region* for the ass= et,
=A0 =A0(and get
=A0 =A0>> is after all).
=A0 =A0>>
=A0 =A0>> =A0If that is not the case, -and there are probably good r= easons
=A0 =A0for the
=A0 =A0>> deployment pattern as described- =A0shouldn't we *warn= * clients
=A0 =A0that the
=A0 =A0>> region might be inconsistent, so the users behind the clie= nt
=A0 =A0can vote
=A0 =A0>> with their feet, (or take the risk)?
=A0 =A0>>
=A0 =A0>> --Vaughn
=A0 =A0>> _______________________________________________
=A0 =A0>> vwrap mailing list
=A0 =A0>> vwrap@= ietf.org <mailto:vwrap@ietf.org>
=A0 =A0>> https://www.ietf.org/mailman/listinfo/vwrap
=A0 =A0>
=A0 =A0>
=A0 =A0> _______________________________________________
=A0 =A0> vwrap mailing list
=A0 =A0> vwrap@ietf= .org <mailto:vwr= ap@ietf.org>
=A0 =A0> https://www.ietf.org/mailman/listinfo/vwrap
=A0 =A0>
=A0 =A0>



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




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

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

--0015174c177ca4d0a0049ffe23a4-- From morgaine.dinova@googlemail.com Sun Apr 3 03:05:44 2011 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 9ECF13A6980 for ; Sun, 3 Apr 2011 03:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 zReCptSzjMnS for ; Sun, 3 Apr 2011 03:05:39 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 3C54F3A697B for ; Sun, 3 Apr 2011 03:05:39 -0700 (PDT) Received: by qwg5 with SMTP id 5so3351886qwg.31 for ; Sun, 03 Apr 2011 03:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=i2R0+o8IovoP1xzr+V6P5jaVmpjtU/wAeml8bKNlYEs=; b=qLS2bRsixvokGLEhWbcFi5JDIQV9rYmveTI30EZEUIUEOuvyjsddPMXRmTO6L/Esux 6MgdNoOKzYXI7pSiXfGxNAiGqOClR4qOWfOgfLTlQBddEYr/XvDmyR23ZOYdMZNvlG95 acRpRtfIGH9LtineCx8PJMk8udCaI7hb3c3i4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=b3DtFupvsoEIZGVYtAqB3GGRYXtip5xgRa0G6l5RSXK4+0wbL60sPRo2ZmUMr4zavZ d1lzBTRe0t1M8gQjDp4x0zZx9ttcQhCAlGZzuIEHPbKt+G+QYk2Zhy4rf9EC54Fyx5aP BqYmqHkT6k9ZaE6pIrRUqJd4jVyT6+jRmPVZE= MIME-Version: 1.0 Received: by 10.229.37.130 with SMTP id x2mr4845675qcd.147.1301825239418; Sun, 03 Apr 2011 03:07:19 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sun, 3 Apr 2011 03:07:19 -0700 (PDT) In-Reply-To: References: Date: Sun, 3 Apr 2011 11:07:19 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016368340c0f4863b04a000cefb Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 03 Apr 2011 10:05:44 -0000 --0016368340c0f4863b04a000cefb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Great to hear that we're on the same page, Vaughn! The detail is probably a bit different to how you described it, because region and agent policy scopes are separate, ie. the agent service doesn't have a role in determining region policy, it just provides an agent. Since asset services are entirely concerned with region functions alone, this put= s them out of scope for the agent service, at least according to the last set of list discussions we had on the topic. I expect it's the client that you need to consult for its current list of asset services, because it keeps tally as it encounters new ones in its travels. The agent service only supplies a seed cap to kick things off wit= h an initial asset service and inventory to hold the default avatar. This is legacy stuff though, dating back from when there was a single centralized asset store. It needs reworking now that we've gone beyond that singleton.= . This whole area of protocol design was never finalized because the Lab withdrew while we were still discussing how the OGP model was going to support VW interop. The OGP-based drafts became totally out of date as soo= n as the requirements for interop materialized, and we haven't recovered from that yet. I agree with your call which echoed Kevin's earlier one, that we need to ge= t on with this! However, it doesn't start with a doc, but with an agreed design concept, so that the first doc is roughly in the right area! This is a partial list of the requirements which I think need to be met: - Handle a dynamic set of asset services, one being the minimum (and onl= y usable in a walled garden), while the maximum is unlimited. - Never to disallow an agent from using its current agent credentials to travel to another world (agent registration must not be confused with wo= rld policy). - Let asset services determine asset distribution policy, and provide th= e means for regions to query that policy (your consistency requirement). - Decide where the user state is held. If it's in the agent service the= n the agent service must be agnostic to worlds and accept all travel requests. If we cannot agree to make the agent service VW agnostic, the= n state will have to be held in the client. Once we have a rough model of that in our minds, then we can: - Run through a few iterations of basic top-level pseudocode showing how the agent service, asset services and clients handle the above split of responsibilities. - Write the first draft document reflecting the above. - Rinse and repeat. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Sat, Apr 2, 2011 at 11:26 PM, Vaughn Deluca wro= te: > I wrote: > >The region can now tells the agent service which of the assets agent > service requested transfer the avatar can bring. > > I meant to say: > > The region can now tell the agent service which of the assets the agent > service requested transfer for, can actually be transfered. > > (its late here...) > > On Sun, Apr 3, 2011 at 12:02 AM, Vaughn Deluca w= rote: > >> Morgain, all, >> >> Ahha!, i was halfway my reply explaining that i was *not* asking for the >> impossible, and did *not* want to impose my rules on others, but that i = just >> wanted to be able to know that stuff that i get into my region will be >> visible to everybody present, and now i see that you got that. Good! >> We are on the same page again :) >> >> The way the draft relating tot the tourist model is now written i can >> *never* be sure my visitors all get the same data, because i just juggle= the >> crude physics representation, and the viewers negotiate about anything e= lse >> with the asset service, fully out of my control. >> >> You formulated a solution (requesting the transfer rights explicitly). >> I was originally thinking of a solution where the protocol specifies tha= t >> the capability to get the crude physics representation of the asset in m= y >> region would be *automatically* give me the right to download the full a= sset >> (if I asked for that). After reading your replies i now see that reques= ting >> the transfer rights, just like like the viewers will do, is a better >> solution. The same protocol messages could even be used, The region pres= ent >> its credentials and either gets the capability or not. The region can n= ow >> tells the agent service which of the assets agent service requested tran= sfer >> the avatar can bring. Its up to the viewer to deal with that information= , it >> might simply ignore it. In the latter case the avatar will be simulated = by >> the region without the offending asset. The asset service will subsequen= tly >> get requests from all viewers connected to the region for the assets in = the >> region. Some of those might not pass trust checks of the asset service. = Bad >> luck for the asset service, it has given a capability to the region and = the >> region will use that to get the asset. If the asset service has second >> thoughts to often - causing download costs and lag, it will eventually e= nd >> up on the black list of the region service, and next time around the reg= ion >> might tell the agent service it can't allow asset Y from servivce X bec= asue >> it does not trust assert service X. >> It all sounds logical and transparent to me. >> >> It also fits what meadhbh said: >> >my recommendation has always been... "define mechanism, not policy." >> As far as i can see that is what we do here. >> >> Now, this brings me to a point of order. In september Kevin Tweedy made >> this observation: >> >> " >> Date: Wed, 22 Sep 2010 13:40:15 -0400 >> May I suggest we stop arbitrarily trying to define things in emails and >> come up with some kind of process into how to define what the first draf= t >> specification should include? Doesn=92t W3C have a process on how this = works? >> I think this is the fundamental problem of this group; we are mixing >> vision, requirements, and design in the same email. We are making desig= n >> decisions when we haven=92t even defined the requirements." >> >> I fully agree. We used to brainstorm in the group and assumed the editor= s >> of the drafts would incorporate the generated ideas in new versions of t= he >> draft. At times that worked really well, at other times it did work not= so >> well. But currently we have no editors, so we need to do something new..= .. >> >> My question to the group is how do we consolidate this bit of discussion= ? >> >> In general it seems to me we have managed to generate new enthusiasm in >> the group, and we are on -or close to- the point were we have enough >> critical mass to continue. In my view we would really benefit from a tru= e >> editor, and it seems nobody is willing to take that responsibility yet. = Can >> we really do it collectively on the wiki? It would be a break with the w= ay i >> think ietf groups normally work, but i might be kind off fitting for th= is >> highly diverse group :) >> >> So will it work? What alternatives do we have? comments please. >> >> --Vaughn >> >> On Sat, Apr 2, 2011 at 5:09 PM, Morgaine wrote: >> >>> Vaughn, I left your final (and very important) point for the end of my >>> response, and then I fired off my email without addressing it ... Sorr= y. :P >>> >>> >>> On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca wrote: >>> >>>> So I want methods to prevent breaking my highly emergent world as muc= h >>>> as possible. >>>> >>> >>> >>> Yes indeed!!! >>> >>> You have a perfectly reasonable requirement for the service that you wa= nt >>> to operate, and you need some means of meeting it. I agree with that >>> wholeheartedly. I only begin to disagree when you hint that your >>> requirement must be imposed on everyone, whether they want it or not. = That >>> I cannot support, and I expect that you did not mean it that way anyway= . >>> After all, some of my requirements are probably not of interest to you >>> either, and you would not wish me to impose them on you. It cuts both = ways. >>> >>> So, how can we enable you to offer a service with many 9's of simulatio= n >>> consistency, without imposing that requirement on those who prefer a >>> different trade-off? You hinted at the solution yourself, so I'll mere= ly >>> elaborate on it. You wrote: >>> >>> >>> >>> I would like to argue that the region *should* get the capability to >>>> fetch all details. [...] Note that this does not mean that the region= *has* >>>> to proxy the asset, just that in case the asset service refuses to ser= ve a >>>> client it does not like, the region can insist on delivery based on t= he >>>> capability it originally got. >>>> >>> >>> >>> >>> Perfect. All you need then is an optional query in the protocol that >>> allows a region to ask each asset service referenced by assets carried = by >>> newly arriving avatars the following question: >>> >>> QUERY: "*Do I have your permission to fetch from your asset service the >>> assets normally reserved for client fetches, and to distribute these as= sets >>> to clients directly in the (unexpected) event that I want to?*" >>> >>> >>> That easily maps to an optional capability request of course. If the >>> asset service answers "No" to you, then you can deny the incoming avata= r >>> entry to your region, returning a status that indicates >>> >>> RESPONSE: "*Asset service X referenced by asset Y does not meet the >>> re-distribution requirement requested for entry to region Z*". >>> >>> >>> Your requirement is then satisfied (I believe) without imposing that >>> requirement on a region operator who does not need it because they desi= re a >>> different trade-off. Those who don't have your requirement simply won'= t >>> request the capability. >>> >>> For example, it would be pointless to even ask an asset service founded >>> entirely around Creative Commons assets that question, since all CC con= tent >>> is perpetually and non-revocably redistributable by anyone and to anyon= e. >>> By not issuing the query we can save ourselves the round-trip time and = allow >>> faster entry to the region. >>> >>> Would something like that get the nod from you? >>> >>> >>> PS. You need to note that when an asset service answers "Yes" to your >>> query, this does not mean that it will necessarily honor its promise wh= en >>> you actually attempt to fetch items. David's very important point abou= t >>> independent parties not having control over each other applies here. Y= ou >>> can at most hope that it will behave well, and perhaps test the promise= by >>> fetching something. However, if you truly want as many 9's of consiste= ncy >>> as is obtainable then you will have to fetch all the assets yourself pr= ior >>> to allowing entry to the avatar, and that would be a dreadful overhead. >>> Most people will probably settle for "*best effort*" approaches, which >>> are quite likely to succeed. >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> >>> On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca wrote: >>> >>>> Morgaine, Meadhbh, >>>> >>>> Thanks for the answers, but i see that i have not been clear enough. >>>> I think the protocol should demand certain things to prevent the >>>> deterioration of the simulation to an unacceptable level. We need to = be >>>> more precise to prevent problems and i think we can. >>>> >>>> I was arguing from the perspecive of a region service without making >>>> that explicit. Note i was *not* advocating the region proxies everythi= ng, >>>> just that it lives up to its promises about object presence. Also note= that >>>> i do *not* always have the option to pick another high quality asset >>>> service, since I normally do not own the assets. I will use Prokofy as= an >>>> example just for the fun of it. He is highly worried about content th= eft, >>>> so (in the unlikely case he wants to start selling stuff outside of SL= ) he >>>> might use this deployment pattern. Assume he sells wonderful sexy dre= sses >>>> to two customers, that can only be fetched from his own asset service = for >>>> rendering. Both customers go off to "Vaughns highly immersive world" w= ere a >>>> party is given. My region receives some physics properties of the dre= sses >>>> for simulation and an address of Proks asset service for high-res deta= ils >>>> and textures. In this case the region does not even get the capability= to >>>> fetch the assets, just a link to the asset service and its up to viewe= r to >>>> request the details and show credentials to get them. The two girls me= et, >>>> both their viewers request the details of the other dress, and Proks a= sset >>>> service grants those requests. They girls admire their dresses and >>>> compliment each other with their good taste. Now when i arrive and my = viewer >>>> request the dress details, Prok's asset service recognises me as the >>>> copyleftists that i am. It refuses to serve the asset details -and dep= ending >>>> on my viewers behaviour i might get to view two girls in sexy underwea= r -or >>>> wearing even less- instead of party dresses. From a consistency point = of >>>> view this is a highly undesirable situation, it breaks immersion, and >>>> depending on the circumstances might also be embarrassing to the peopl= e >>>> involved. >>>> >>>> The key question is if we want to allow this situation to arise within >>>> VWRAP compliant worlds. >>>> I would like to argue that the region *should* get the capability to >>>> fetch all details. In other words, Prokofy would have to give up some >>>> control over the asset in case he allows it to be used by my region. N= ote >>>> that this does not mean that the region *has* to proxy the asset, just= that >>>> in case the asset service refuses to serve a client it does not like, = the >>>> region can insist on delivery based on the capability it originally g= ot. If >>>> that fails Proks asset service can not be called VWRAP compliant. >>>> >>>> If Prokofy does not want to relinquish that level of control, fine, i= t >>>> is his right not to, but in that case the dresses should not be allowe= d to >>>> get into my region in the first place. If people visit my region and = find >>>> themselves naked in the eyes of some others *I* will get the blame. A= s >>>> Morgaine says, the technical details of my innocence will not convince= the >>>> general public. So I want methods to prevent breaking my highly emerge= nt >>>> world as much as possible. >>>> My proposal would be that the whatever the region gets MUST be >>>> guaranteed by protocol to be delivered to anybody within the region >>>> requesting it. If the asset service does not want to serve a cryptocom= unist >>>> copyleftist, fine, but IF it has given the region a capability, it MUS= T >>>> serve the full asset to be VWRAP compliant. Its *my* choice as a regio= n >>>> deployer to download the full asset to be able to guarantee region >>>> consistency if I want to. I will try to avoid that as much as possible= , but >>>> if my customers complain, i will be forces to start doing this for cer= tain >>>> asset services that i know show discriminatory behaviour against for >>>> instance copyleftist. >>>> >>>> Finally Morgaine, you keep hammering on the fact that proxying by the >>>> region does not scale. (I tend to disagree, but that is beside the poi= nt >>>> here). I do agree the asset should not be needlessly transfered, but i >>>> strongly feel we must insist in the protocol on transferring the *righ= ts* to >>>> view the asset. If that leads to to the region not getting the asset a= t all, >>>> so be it, it can warn visitors that their assets will not be visible a= nd >>>> even offer to serve simple replacements (1). This in turn will encoura= ge the >>>> end users to avoid this type of asset service, and Prokofy will go out= of >>>> business, as should be the case given the behaviour of the service. An= d if >>>> he pulls it off, thats fine with me also, as long as i do not have to = suffer >>>> from it due to lack of rigour in the protocol specs. >>>> >>>> So, in summary, I very well see that there is no way to enforce >>>> consistent serving behaviour but it should at least be clear that it i= s >>>> non-standard and not conform the protocol. The way I am understanding = you >>>> now, your argument seems to be just one step to far in the direction o= f >>>> anarchy. >>>> Or am i misreading you? >>>> >>>> --Vaughn >>>> >>>> >>>> (1) I just realise that the region might cheat and advertise its own >>>> asset brands claiming the competitions assets could not be rendered..= . Oh >>>> well, one might hope that if there is enough choice in worlds such reg= ions >>>> will be forced out of business as well. >>>> >>>> On Sat, Apr 2, 2011 at 7:31 AM, Morgaine < >>>> morgaine.dinova@googlemail.com> wrote: >>>> >>>>> Further to my last post, it's worth noting that if you find that you >>>>> suffer poor quality behavior from a particular asset service and it i= s >>>>> breaking the consistency of your simulation, with hash-based item add= ressing >>>>> you can also automatically use an alternative asset service *in >>>>> preference* to the one specified in a given URI. >>>>> >>>>> Your client could be configured to attempt the item fetch at a known >>>>> good quality asset service *first* (perhaps one that you paid to use >>>>> because of its better service), automatically, and maybe even dynamic= ally >>>>> depending on the type of item. >>>>> >>>>> The scheme has a long list of benefits, and overcoming (to some exten= t) >>>>> poor quality asset services is just one of them. >>>>> >>>>> >>>>> Morgaine. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> >>>>> >>>>> On Sat, Apr 2, 2011 at 4:55 AM, Morgaine < >>>>> morgaine.dinova@googlemail.com> wrote: >>>>> >>>>>> Every design choice results in a trade-off, Vaughn, improving one >>>>>> thing at the expense of something else. If every time we offered a = service >>>>>> we had to inform its users about the downsides of all the trade-offs= we have >>>>>> made, they would have an awful lot to read. ;-) >>>>>> >>>>>> The specific trade-off that you are discussing is no different. A >>>>>> region that proxies all content has the "benefit" of acquiring contr= ol from >>>>>> the asset servers over the items in the region, so that it can ensur= e that >>>>>> everyone in the region not only obtains the items but obtains the * >>>>>> same* items as everyone else. That does indeed provide a greater >>>>>> guarantee of consistency than a deployment in which the region only = passes >>>>>> asset URIs to clients who then fetch the items from asset services >>>>>> separately. As always though, it's a trade-off, since the proxied d= esign >>>>>> has very poor scalability compared to the distributed one. >>>>>> >>>>>> If we're going to warn users of the potential for inconsistency in t= he >>>>>> distributed deployment as you suggest, are we also going to warn the= m of >>>>>> non-scalability in the proxied one? I really don't see much merit i= n the >>>>>> idea of warning about design choices. Many such choices are technic= al, and >>>>>> the issues are quite likely to be of little interest to non-technica= l users >>>>>> anyway. In any case, the better services are likely to provide such >>>>>> information in their online documentation, I would guess. >>>>>> >>>>>> You mentioned users "voting with their feet" or choosing to accept t= he >>>>>> risk of inconsistency. Well that will happen anyway, when services = fail and >>>>>> users get annoyed. If some asset services refuse to send the reques= ted >>>>>> items to some users, those services will get a bad reputation and pe= ople >>>>>> will choose different asset services instead. Likewise, if a world = service >>>>>> proxies everything and so it can't handle a large number of assets o= r of >>>>>> people, users will get annoyed at the lag and will go elsewhere. Th= is user >>>>>> evaluation and "voting with their feet" happens already with online = services >>>>>> all over the Internet, and I am sure that this human process will co= ntinue >>>>>> to work when the services are asset and region services. >>>>>> >>>>>> Back in September 2010, I wrote this post which proposes that we use >>>>>> in VWRAP a form of asset addressing that provides massive scalabilit= y at the >>>>>> same time as a very high degree of resilience -- >>>>>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html . >>>>>> It is based on the concept of the URI containing a host part and a h= ash >>>>>> part, where the hash is generated (once, at the time of storage to t= he asset >>>>>> service) using a specified digest algorithm over the content of the = asset >>>>>> being referenced. You may wish to note that if this design were use= d, the >>>>>> failure of an asset service to deliver a requested item would result= in a >>>>>> failover request for the item to one or more backup services, using = the same >>>>>> hash part but with a different host address. >>>>>> >>>>>> This can go some way towards overcoming the problem that you think >>>>>> might occur when assets are fetched by clients from asset services >>>>>> directly. Although it won't help when the missing item is available= from >>>>>> only a single asset service, it will help in many other cases, and i= t will >>>>>> compensate for service failures and network outages automatically at= the >>>>>> same time. >>>>>> >>>>>> PS. This design for hash-based asset addressing is already being >>>>>> tested by Mojito Sorbet in her experimental world and client. It wo= uld give >>>>>> VWRAP-based worlds an improved level of service availability, so I t= hink it >>>>>> should be a core feature of our protocol. >>>>>> >>>>>> >>>>>> Morgaine. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>>> >>>>>> >>>>>> On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca < >>>>>> vaughn.deluca@gmail.com> wrote: >>>>>> >>>>>>> This is a question i discussed with Morgaine off-list a while ago (= I >>>>>>> intended to send it to the list but pushed the wrong button...) I >>>>>>> think we need to address this problem, and decide how to deal with >>>>>>> it. >>>>>>> >>>>>>> In Davids deployment draft, section 7.3.1.1 an overview is given v= an >>>>>>> ways to deliver content to the region. One way is only passing a >>>>>>> capability that allows access to (part of) the resource: >>>>>>> >>>>>>> 7.3.1.1. Content delivery models >>>>>>> A range of possible represenations can be passed to a >>>>>>> region for >>>>>>> simulation. [...] The other end of the delivery spectrum >>>>>>> involves passing >>>>>>> only a URI or capability used to access the rendering >>>>>>> information and a >>>>>>> collision mesh,and related data for physical simulation. >>>>>>> In such a model, the client is responsible for fetching t= he >>>>>>> additional >>>>>>> information needed to render the item's visual presence >>>>>>> from a separate >>>>>>> service. This fetch can be done *under the credentials o= f >>>>>>> the end user* >>>>>>> viewing the material [my emphasis--VD] , and divorces the >>>>>>> simulation from >>>>>>> the trust chain needed to manage content. Any automation >>>>>>> is done on a >>>>>>> separate host which the content creator or owner trusts, >>>>>>> interacting with the >>>>>>> object through remoted interfaces. >>>>>>> >>>>>>> I can see the need for such a setup, however, i feel we are >>>>>>> unpleasantly close to a situation were the coherence of the >>>>>>> simulation >>>>>>> falls apart. >>>>>>> In this deployment pattern the region advertises the presence of th= e >>>>>>> asset, and *some* clients will be able to get it as expected, while >>>>>>> -based on the arbitrary whims of the asset service- others might no= t. >>>>>>> >>>>>>> My hope would be that after the asset server provides the region wi= th >>>>>>> the capability to get the asset, it gives up control. That would me= an >>>>>>> that if the client finds the inventory server is unwilling to serve >>>>>>> the content - in spire of the region saying it is present-, the >>>>>>> client >>>>>>> should be able to turn around ask the *region* for the asset, (and >>>>>>> get >>>>>>> is after all). >>>>>>> >>>>>>> If that is not the case, -and there are probably good reasons for >>>>>>> the >>>>>>> deployment pattern as described- shouldn't we *warn* clients that >>>>>>> the >>>>>>> region might be inconsistent, so the users behind the client can vo= te >>>>>>> with their feet, (or take the risk)? >>>>>>> >>>>>>> --Vaughn >>>>>>> _______________________________________________ >>>>>>> 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 > > --0016368340c0f4863b04a000cefb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Great to hear that we're on the same page, Vaughn!

The detail is= probably a bit different to how you described it, because region and agent= policy scopes are separate, ie. the agent service doesn't have a role = in determining region policy, it just provides an agent.=A0 Since asset ser= vices are entirely concerned with region functions alone, this puts them ou= t of scope for the agent service, at least according to the last set of lis= t discussions we had on the topic.

I expect it's the client that you need to consult for its current l= ist of asset services, because it keeps tally as it encounters new ones in = its travels.=A0 The agent service only supplies a seed cap to kick things o= ff with an initial asset service and inventory to hold the default avatar.= =A0 This is legacy stuff though, dating back from when there was a single c= entralized asset store.=A0 It needs reworking now that we've gone beyon= d that singleton..

This whole area of protocol design was never finalized because the Lab = withdrew while we were still discussing how the OGP model was going to supp= ort VW interop.=A0 The OGP-based drafts became totally out of date as soon = as the requirements for interop materialized, and we haven't recovered = from that yet.

I agree with your call which echoed Kevin's earlier one, that we ne= ed to get on with this!=A0 However, it doesn't start with a doc, but wi= th an agreed design concept, so that the first doc is roughly in the right = area!

This is a partial list of the requirements which I think need to be met= :

  • Handle a dynamic set of asset services, one being the mini= mum (and only usable in a walled garden), while the maximum is unlimited.
  • Never to disallow an agent from using its current agent credentials to = travel to another world (agent registration must not be confused with world= policy).
  • Let asset services determine asset distribution polic= y, and provide the means for regions to query that policy (your consistency= requirement).
  • Decide where the user state is held.=A0 If it's in the agent servic= e then the agent service must be agnostic to worlds and accept all travel r= equests.=A0 If we cannot agree to make the agent service VW agnostic, then = state will have to be held in the client.

Once we have a rough model of that in our minds, then we can:=

  • Run through a few iterations of basic top-level pseudocode = showing how the agent service, asset services and clients handle the above = split of responsibilities.
  • Write the first draft document reflecting the above.
  • Rinse and = repeat.


Morgaine.





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

On S= at, Apr 2, 2011 at 11:26 PM, Vaughn Deluca <vaughn.deluca@gmail.com<= /a>> wrote:
I wrote:
>The region= can now tells the agent service which of the assets agent service requeste= d transfer the avatar can bring.

I meant = to say:

The region can no= w tell the agent service which of the assets the agent service requested tr= ansfer for, can actually be transfered.

(its late here...)

<= div class=3D"gmail_quote">On Sun, Apr 3, 2011 at 12:02 AM, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
Morgain, all= ,

Ahha!, i was halfway my reply explaining that i = was *not* asking for the impossible, and did *not* want to impose my rules = on others, but that i just wanted to be able to know that stuff that i get = into my region will be visible to everybody present, and now i see that you= got that. Good!
We are on the same page again :)

The way the = draft relating tot the tourist model is now written i can *never* be sure m= y visitors all get the same data, because i just juggle the crude physics r= epresentation, and the viewers negotiate about anything else with the asset= service, fully out of my control.=A0

You formulated a solution (requesting the transfer righ= ts explicitly). =A0
I was originally thinking of a solution where= the protocol specifies that the capability to get the crude physics repres= entation of the asset in my region would be *automatically* give me the rig= ht to download the full asset (if I asked for that). =A0After reading your = replies i now see that requesting the transfer rights, just like like the v= iewers will do, is a better solution. The same protocol messages could even= be used, The region present its credentials and either gets the capability= or not. =A0The region can now tells the agent service which of the assets = agent service requested transfer the avatar can bring. Its up to the viewer= to deal with that information, it might simply ignore it. In the latter ca= se the avatar will be simulated by the region without the offending asset. = The asset service will subsequently get requests from all viewers connected= to the region for the assets in the region. Some of those might not pass t= rust checks of the asset service. Bad luck for the asset service, it has gi= ven a capability to the region and the region will use that to get the asse= t. If the asset service has second thoughts to often - causing download cos= ts and lag, it will eventually end up on the black list of the region servi= ce, and next time around the region =A0might tell the agent service it can&= #39;t allow asset Y from servivce X becasue it does not trust assert servic= e X. =A0
It all sounds logical and transparent to me.

=
It also fits what meadhbh said:
>my recommendation has al= ways been... "define mechanism, not policy."
As far as i can see that is what we do here.

Now, this brings me to a point of order. In september K= evin Tweedy made this observation:

"<kevin= .tweedy at xrgrid.com&g= t;
Date: Wed, 22 Sep 2010 13:40:15 -0400
May I suggest we stop arbitrarily trying to define things in emails an= d come up with some kind of process into how to define what the first draft= specification should include? =A0Doesn=92t W3C have a process on how this = works? =A0I think this is the fundamental problem of this group; we are mix= ing vision, requirements, and design in the same email. =A0We are making de= sign decisions when we haven=92t even defined the requirements."

I fully agree. We used to brainstorm in the group and a= ssumed the editors of the drafts would incorporate the generated ideas in n= ew versions of the draft. =A0At times that worked really well, at other tim= es it did work not so well. But currently we have no editors, so we need to= do something new....

My question to the group is how do we consolidate this = bit of discussion?=A0

In general it seems to me we= have managed to generate new enthusiasm in the group, and we are on -or cl= ose to- the =A0point were we have enough critical mass to continue. In my v= iew we would really benefit from a true editor, and it seems nobody is will= ing to take that responsibility yet. Can we really do it collectively on th= e wiki? It would be a break with the way i think ietf groups normally work,= but i might be =A0kind off fitting for this highly diverse group =A0:)

So will it work? What alternatives do we have? =A0comme= nts please.

--Vaughn
=

On Sat, Apr 2, 2= 011 at 5:09 PM, Morgaine <morgaine.dinova@googlemail.com&= gt; wrote:
Vaughn, I left yo= ur final (and very important) point for the end of my response, and then I = fired off my email without addressing it ...=A0 Sorry. :P


On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca &l= t;vaughn.deluc= a@gmail.com> wrote:
=A0So I want= methods=20 to prevent breaking my highly emergent world as much as possible.


Yes indeed!!!

You have a perfectly reaso= nable requirement for the service that you want to operate, and you need so= me means of meeting it.=A0 I agree with that wholeheartedly.=A0 I only begi= n to disagree when you hint that your requirement must be imposed on everyo= ne, whether they want it or not.=A0 That I cannot support, and I expect tha= t you did not mean it that way anyway.=A0 After all, some of my requirement= s are probably not of interest to you either, and you would not wish me to = impose them on you.=A0 It cuts both ways.

So, how can we enable you to offer a service with many 9's of simul= ation consistency, without imposing that requirement on those who prefer a = different trade-off?=A0 You hinted at the solution yourself, so I'll me= rely elaborate on it.=A0 You wrote:



= I would like to argue that the region *should* get the capability to=20 fetch all details. [...]=A0=20 Note that this does not mean that the region *has* to proxy the asset,=20 just that in case the asset service refuses to serve a client it does=20 not like, the region can insist on delivery =A0based on the capability it= =20 originally got.



Perfect.=A0 All you need then= is an optional query in the protocol that allows a region to ask each asse= t service referenced by assets carried by newly arriving avatars the follow= ing question:

QUERY: "Do I have your permis= sion to fetch from your asset service the assets normally reserved for clie= nt fetches, and to distribute these assets to clients directly in the (unex= pected) event that I want to?"


That easily maps to an optional capability request of course.= =A0 If the asset service answers "No" to you, then you can deny t= he incoming avatar entry to your region, returning a status that indicates<= br>
RESPONSE: "Asset service X re= ferenced by asset Y does not meet the re-distribution requirement requested= for entry to region Z".


Your requirement is then= satisfied (I believe) without imposing that requirement on a region operat= or who does not need it because they desire a different trade-off.=A0 Those= who don't have your requirement simply won't request the capabilit= y.

For example, it would be pointless to even ask an asset service founded= entirely around Creative Commons assets that question, since all CC conten= t is perpetually and non-revocably redistributable by anyone and to anyone.= =A0 By not issuing the query we can save ourselves the round-trip time and = allow faster entry to the region.

Would something like that get the nod from you?


PS. You need= to note that when an asset service answers "Yes" to your query, = this does not mean that it will necessarily honor its promise when you actu= ally attempt to fetch items.=A0 David's very important point about inde= pendent parties not having control over each other applies here.=A0 You can= at most hope that it will behave well, and perhaps test the promise by fet= ching something.=A0 However, if you truly want as many 9's of consisten= cy as is obtainable then you will have to fetch all the assets yourself pri= or to allowing entry to the avatar, and that would be a dreadful overhead.= =A0 Most people will probably settle for "best effort" app= roaches, which are quite likely to succeed.


Morgaine.





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


On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca <v= aughn.deluca@gmail.com> wrote:
Morgaine, Me= adhbh,

Thanks for the answers, but i see that i ha= ve not been clear enough.
I think the protocol should demand certain things to prevent the =A0de= terioration of the simulation to an unacceptable level. We need to be more = precise to prevent problems and i think we can.

I was arguing from the perspecive of a region service w= ithout making that explicit. Note i was *not* advocating the region proxies= everything, just that it lives up to its promises about object presence. A= lso note that i do =A0*not* always have the option to pick another high qua= lity asset service, since I normally do not own the assets. I will use Prok= ofy as an example just for the fun of it. =A0He is highly worried about con= tent theft, so (in the unlikely case he wants to start selling stuff outsid= e of SL) he might use this deployment pattern. =A0Assume he sells wonderful= sexy dresses to two customers, that can only be fetched from his own asset= service for rendering. Both customers go off to "Vaughns highly immer= sive world" were a party is given. =A0My region receives some physics = properties of the dresses for simulation and an address of Proks asset serv= ice for high-res details and textures. In this case the region does not eve= n get the capability to fetch the assets, just a link to the asset service = and its up to viewer to request the details and show credentials to get the= m. The two girls meet, both their viewers request the details of the other = dress, and Proks asset service grants those requests. They girls admire the= ir dresses and compliment each other with their good taste. Now when i arri= ve and my viewer request the dress details, Prok's asset service recogn= ises me as the copyleftists that i am. It refuses to serve the asset detail= s -and depending on my viewers behaviour i might get to view two girls in s= exy underwear -or wearing even less- instead of party dresses. From a consi= stency point of view this is a highly undesirable situation, it breaks imme= rsion, and depending on the circumstances might also be embarrassing to the= people involved.=A0

The key question is if we want to allow this situation = to arise within VWRAP compliant worlds.
I would like to argue tha= t the region *should* get the capability to fetch all details. In other wor= ds, Prokofy would have to give up some control over the asset in case he al= lows it to be used by my region. Note that this does not mean that the regi= on *has* to proxy the asset, just that in case the asset service refuses to= serve a client it does not like, the region can insist on delivery =A0base= d on the capability it originally got. If that fails Proks asset service ca= n not be called VWRAP compliant. =A0

If Prokofy does not want to relinquish =A0that level of= control, fine, it is his right not to, but in that case the dresses should= not be allowed to get into my region in the first place. =A0If people visi= t my region and find themselves naked in the eyes of some others *I* will g= et the blame. =A0As Morgaine says, the technical details of my innocence wi= ll not convince the general public. So I want methods to prevent breaking m= y highly emergent world as much as possible.=A0
My proposal would be that the whatever the region gets MUST be guarant= eed by protocol to be delivered to =A0anybody within the region requesting = it. If the asset service does not want to serve a cryptocomunist copyleftis= t, fine, but IF it has given the region a capability, it MUST serve the ful= l asset to be VWRAP compliant. Its *my* choice as a region deployer to down= load the full asset to be able to guarantee region consistency if I want to= . I will try to avoid that as much as possible, but if my customers complai= n, i will be forces to start doing this for certain asset services that i k= now show discriminatory behaviour against for instance copyleftist.=A0

Finally Morgaine, you keep hammering on the fact that p= roxying by the region does not scale. (I tend to disagree, but that is besi= de the point here). I do agree the asset should not be needlessly transfere= d, but i strongly feel we must insist in the protocol on transferring the *= rights* to view the asset. If that leads to to the region not getting the a= sset at all, so be it, it can warn visitors that their assets will not be v= isible and even offer to serve simple replacements (1). This in turn will e= ncourage the end users to avoid this type of asset service, and Prokofy wil= l go out of business, as should be the case given the behaviour of the serv= ice. And if he pulls it off, thats fine with me also, as long as i do not h= ave to suffer from it due to lack of rigour in the protocol specs. =A0

So, in summary, I very well see that there is no way to= enforce consistent serving behaviour but it should at least be clear that = it is non-standard and not conform the protocol. The way I am understanding= you now, your argument seems to be just one step to far in the direction o= f anarchy.
Or am i misreading you?

--Vaughn

(1) I just realise that the region might cheat = and advertise its own asset brands claiming the competitions assets =A0coul= d not be rendered... Oh well, one might hope that if there is enough choice= in worlds such regions will be forced =A0out of business as well.=A0

On Sat, Apr 2, 2011 at 7:31 AM, Morgaine <morgaine.dinova@googlemail.com> wrote:
Further to my last post, it's worth noting that if you find that you su= ffer poor quality behavior from a particular asset service and it is breaki= ng the consistency of your simulation, with hash-based item addressing you = can also automatically use an alternative asset service in preference= to the one specified in a given URI.

Your client could be configured to attempt the item fetch at a known go= od quality asset service first (perhaps one that you paid to use bec= ause of its better service), automatically, and maybe even dynamically depe= nding on the type of item.

The scheme has a long list of benefits, and overcoming (to some extent)= poor quality asset services is just one of them.


Morgaine.





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


On Sat, Apr 2, 2011 at 4:55 AM, Morgaine <morgaine.dinova@goo= glemail.com> wrote:
Every design choice results in a trade-off, Vaughn, improving one thing at = the expense of something else.=A0 If every time we offered a service we had= to inform its users about the downsides of all the trade-offs we have made= , they would have an awful lot to read. ;-)

The specific trade-off that you are discussing is no different.=A0 A re= gion that proxies all content has the "benefit" of acquiring cont= rol from the asset servers over the items in the region, so that it can ens= ure that everyone in the region not only obtains the items but obtains the = same items as everyone else.=A0 That does indeed provide a greater g= uarantee of consistency than a deployment in which the region only passes a= sset URIs to clients who then fetch the items from asset services separatel= y.=A0 As always though, it's a trade-off, since the proxied design has = very poor scalability compared to the distributed one.

If we're going to warn users of the potential for inconsistency in = the distributed deployment as you suggest, are we also going to warn them o= f non-scalability in the proxied one?=A0 I really don't see much merit = in the idea of warning about design choices.=A0 Many such choices are techn= ical, and the issues are quite likely to be of little interest to non-techn= ical users anyway.=A0 In any case, the better services are likely to provid= e such information in their online documentation, I would guess.

You mentioned users "voting with their feet" or choosing to a= ccept the risk of inconsistency.=A0 Well that will happen anyway, when serv= ices fail and users get annoyed.=A0 If some asset services refuse to send t= he requested items to some users, those services will get a bad reputation = and people will choose different asset services instead.=A0 Likewise, if a = world service proxies everything and so it can't handle a large number = of assets or of people, users will get annoyed at the lag and will go elsew= here.=A0 This user evaluation and "voting with their feet" happen= s already with online services all over the Internet, and I am sure that th= is human process will continue to work when the services are asset and regi= on services.

Back in September 2010, I wrote this post which proposes that we use in= VWRAP a form of asset addressing that provides massive scalability at the = same time as a very high degree of resilience -- http:/= /www.ietf.org/mail-archive/web/vwrap/current/msg00463.html .=A0 It is b= ased on the concept of the URI containing a host part and a hash part, wher= e the hash is generated (once, at the time of storage to the asset service)= using a specified digest algorithm over the content of the asset being ref= erenced.=A0 You may wish to note that if this design were used, the failure= of an asset service to deliver a requested item would result in a failover= request for the item to one or more backup services, using the same hash p= art but with a different host address.

This can go some way towards overcoming the problem that you think migh= t occur when assets are fetched by clients from asset services directly.=A0= Although it won't help when the missing item is available from only a = single asset service, it will help in many other cases, and it will compens= ate for service failures and network outages automatically at the same time= .

PS. This design for hash-based asset addressing is already being tested= by Mojito Sorbet in her experimental world and client.=A0 It would give VW= RAP-based worlds an improved level of service availability, so I think it s= hould be a core feature of our protocol.


Morgaine.




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

On Fri, Apr 1, 2011 at 11:17 PM, Vaughn De= luca <vaughn.deluca@gmail.com> wrote:
This is a questio= n i discussed with Morgaine off-list a while ago (I
intended to send it to the list but pushed the wrong button...) I
think we need to address this problem, and decide how to deal with it.

=A0In Davids deployment draft, section 7.3.1.1 an overview is given van
ways to deliver content to the region. One way is only passing a
capability that allows access to (part of) the resource:

=A0 =A0 =A0 =A0 =A0 7.3.1.1. =A0Content delivery models
=A0 =A0 =A0 =A0 =A0 A range of possible represenations can be passed to a = region for
=A0 =A0 =A0 =A0 =A0 simulation. [...] The other end of the delivery spectr= um involves passing
=A0 =A0 =A0 =A0 =A0 only a URI or capability used to access the rendering<= br> information and a
=A0 =A0 =A0 =A0 =A0 collision mesh,and related data for physical simulatio= n.
=A0 =A0 =A0 =A0 =A0 In such a model, the client is responsible for fetchin= g the additional
=A0 =A0 =A0 =A0 =A0 information needed to render the item's visual pre= sence from a separate
=A0 =A0 =A0 =A0 =A0 service. =A0This fetch can be done *under the credenti= als of the end user*
=A0 =A0 =A0 =A0 =A0 viewing the material [my emphasis--VD] , and divorces = the
simulation from
=A0 =A0 =A0 =A0 =A0 the trust chain needed to manage content. =A0Any autom= ation
is done on a
=A0 =A0 =A0 =A0 =A0 separate host which the content creator or owner trust= s,
interacting with the
=A0 =A0 =A0 =A0 =A0 object through remoted interfaces.

=A0I can see the need for such a setup, however, i feel we are
unpleasantly close to a situation were the coherence of the simulation
falls apart.
In this deployment pattern the region advertises the presence of the
asset, and *some* clients will be able to get it as expected, while
-based on the arbitrary whims of the asset service- others might not.

My hope would be that after the asset server provides the region with
the capability to get the asset, it gives up control. That would mean
that if the client finds the inventory server is unwilling to serve
the content - in spire of the region saying it is present-, the client
should be able to turn around ask the *region* for the asset, (and get
is after all).

=A0If that is not the case, -and there are probably good reasons for the deployment pattern as described- =A0shouldn't we *warn* clients that th= e
region might be inconsistent, so the users behind the client can vote
with their feet, (or take the risk)?

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







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


--0016368340c0f4863b04a000cefb-- From morgaine.dinova@googlemail.com Sun Apr 3 03:59:59 2011 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 3B6CF3A6980 for ; Sun, 3 Apr 2011 03:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 YXYPVNBgairM for ; Sun, 3 Apr 2011 03:59:56 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id D19DA3A6403 for ; Sun, 3 Apr 2011 03:59:55 -0700 (PDT) Received: by qwg5 with SMTP id 5so3365205qwg.31 for ; Sun, 03 Apr 2011 04:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=M1YBM8IyjGnoTeUOlX8J4GWeR9qwOqA7jr7sCVcpWPg=; b=OcvsWyzf1m07KzJ2uDi6ppVKNqnfqidvzbds9w1KKEasfltmEgr1VMbDpI+ioTX+kS 4fnoXWZijX9f8PaZPo5vtMrVLH2W2ta8alOOk/deeEPmyV/dilFZsBg1qVsLyBPpgb7q h+hYMBlT2XENmqKuH6GHa/U/fNw6f/Vy29qrQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VYh+Psw3c/3yB+Vg39n+hWWS0UhAIivZ0rrGiXhTxAy1nQbwjF+FvgTMzZWolSC117 BDXjSCU+AOWgxslWdf0c5Wr5nunxQq0y03GbRT+v0EE9z8LBqaWo67RedwoWHMt6ZZJg vaK+5OWp+sKaV15wcQTDEZ+iZe8YMvJ7+6GEE= MIME-Version: 1.0 Received: by 10.229.124.145 with SMTP id u17mr4920746qcr.71.1301828496172; Sun, 03 Apr 2011 04:01:36 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sun, 3 Apr 2011 04:01:35 -0700 (PDT) In-Reply-To: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> Date: Sun, 3 Apr 2011 12:01:35 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd25cae12a6d804a0019143 Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 03 Apr 2011 10:59:59 -0000 --000e0cd25cae12a6d804a0019143 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Apr 3, 2011 at 3:42 AM, Israel Alanis wrote: > > I think what you're saying is: "It costs a lot of money to build a scalable > asset service, but if assets are spread throughout the internet they don't > have to be scalable." But that's not quite right. You're opening up every > asset server to the VW equivalent of being slashdotted, so are you sure > you're not forcing *every* asset service to be scalable and handle a lot of > bandwith and network traffic? It's the exact opposite of your intention, but > I think that's the result, all the same. > > We actually discussed this in the early days of the list, and I was advocating that part of the duties of a huge commercial service that supports VW interop needs to be to temporarily cache assets of new arrivals from other worlds, as an independent service of the large VW, ie. a Caching Service. The reason why I believe a separate Caching Service (unrelated to any Asset Service) is needed is because the commercial service will not be able to maintain a desired quality of service without it for its users. Imagine a Truly Awesome Commercial World, able to support media crowd events of 100,000 avatars. Lucy The Musical Furries Fan runs a tiny world for her family with its own midget integrated asset service, and hears that her adored Musical Furries are going to play at Truly Awesome Commercial World, so off she teleports to the venue. Instantly on arrival, 100,000 fans of the Musical Furries slashdot her asset service into a smoldering slag heap as they all try to fetch her avatar's assets. Clearly this is not going to work. Quite apart from Lucy's problem, it is the Truly Awesome Commercial World that suffers most, because it now has 100,000 fans who are faced with a broken simulation. It's no longer very awesome. (Not allowing entry to Lucy is not an option because the huge world relies on 100,000 people like Lucy arriving to support the event, many of whom are in Lucy's situation.) Unfortunately I never managed to get anyone interested in the concept of a Caching Service as an independent entity. Perhaps it's time to revive the idea. Note that the Caching Service would be yet another independent service, conceptually external and not related administratively with any other entity in our picture. It would be optionally engaged by a region that wants to open its doors to the metaverse but takes pride in offering a better quality of service than its visitors' asset services can provide by themselves. Morgaine. ============================ On Sun, Apr 3, 2011 at 3:42 AM, Israel Alanis wrote: > > > when designing for scalability, the model to bear in mind is ... > > Well, there are a lot of different models to keep in mind, and many > different use cases. One particular use case to keep in mind is: "User > acquires new outfit, and wants to 'show it off' in a highly populated > region". > > > Both worlds and asset services may include commercial, community, and > personal services > > Yes, yes and yes. I'm particularly concerned about how the model affects > the ability to host personal asset services. > > > a proxying region, which would get slammed for every asset worn by every > avatar present. > > Granted the collection of services that are provided by the region need to > be scaled to meet the demands of that region. That's all part of capacity > planning. > > > regions run many different CPU-intensive tasks, including physics > simulation and server-side scripting, and absolutely cannot afford to serve > assets too > > Well... who said the same CPU's have to do proxying, physics simulation and > server-side scripting? Asset proxying is a different service than physics > simulation and can be on separate hardware, could make use of geographically > distributed caching, and in certain deployment patterns, the same caching > services could be shared by different regions. (Server-side scripting is a > discussion for another day). > > > This is why we have to go parallel... > > Totally agree, and a proxying model could and should also take advantage of > parallelism. > > > I think you're wrong that it has to cost much money. > ?vs? > > It costs money to host a high performance and scalable asset service and > a high bandwidth network to handle the traffic. A *lot* of money. > > I think what you're saying is: "It costs a lot of money to build a scalable > asset service, but if assets are spread throughout the internet they don't > have to be scalable." But that's not quite right. You're opening up every > asset server to the VW equivalent of being slashdotted, so are you sure > you're not forcing *every* asset service to be scalable and handle a lot of > bandwith and network traffic? It's the exact opposite of your intention, but > I think that's the result, all the same. > > This particular design decision has a big effect on the economics of the VW > infrastructure. I'd rather the economics to work out such that a region > provider who wishes to build a region that supports a small population, can > do so economically. A region that wants to host a *large* population has to > bear that cost of providing that scalable asset service. > > I want the economics of hosting a small asset service to be a non-issue (as > to best promote creation and creativity). Creating a high bar to provide > asset services will mean that service will cost money and people shouldn't > have to pay money just to create or own VW objects (I'm using 'own' here to > refer to maintaining their existence, I'm not trying to make a > 'leftist'/'communist' statement about ownership ;) > > - Izzy > > > On Apr 2, 2011, at 3:58 PM, Morgaine wrote: > > Izzy, when designing for scalability, the model to bear in mind is that of > seasoned virtual world travelers whose inventories contain assets from many > different worlds, those assets being served by many different asset > services. Both worlds and asset services may include commercial, community, > and personal services, and as the metaverse grows, that set is highly likely > to become progressively less clustered and more diverse. > > When those seasoned travelers click on an advertised VW link and perform an > inter-world teleport to one particular world's region to share an > experience, their "worn" assets (the only ones of interest to the region) > will contain references to asset services spread widely across the > Internet. The fetches by the travelers' clients occur over many parallel > paths from clients to asset services, so one can reasonably expect reduced > network contention and reduced asset server loading because they are both > spread out over however many asset services are being referenced by the > overall set of assets in the region. > > This is very different to the case of a proxying region, which would get > slammed for every asset worn by every avatar present. In our current > architecture, regions run many different CPU-intensive tasks, including > physics simulation and server-side scripting, and absolutely cannot afford > to serve assets too unless your scalability requirements are very low > indeed, ie. just a few dozen avatars of today's kind. We've hit the ceiling > already on region scalability done that way. There is nowhere to go in that > direction at all beyond improving the code like Intel demonstrated, and that > work is subject to a law of diminishing returns. > > This is why we have to go parallel, and I think you're wrong that it has to > cost much money. As we spread the load across more and more asset services, > we are simply better utilizing all the hardware that's already out there on > the Internet, at least in respect of community and private resources. But > add to the community and private resources the commercial asset services > that are likely to appear to exploit this opportunity, and not only will the > number of asset services leap, but the power of each one will rocket too, > because, after all, these businesses will be heavily optimized for the job. > > As to why a world would want clients to access external asset services > instead of providing its own implementation, that's an easy question. It > costs money to host a high performance and scalable asset service and a high > bandwidth network to handle the traffic. A *lot* of money. In contrast, > it costs a world nothing to let others serve the assets to clients. And > that matters to the bottom line. > > > Morgaine. > > > > > ====================== > > On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis wrote: > >> > As always though, it's a trade-off, since the proxied design has very >> poor scalability compared to the distributed one. >> >> I don't agree with that... If a user enters a highly populated region, >> every other client is going to (could and should be trying to) hit the >> asset server(s) for the assets that the user is wearing (assuming >> they're not cached locally). Every asset server has to be scaled up >> to the point that it can handle that load from all over... >> >> If I'm hosting a region that supports 10s of thousands of simultaneous >> users (thinking of the future), I already have to scale to meet that >> demand. If the region is proxying the assets, then, yes the region has >> to be scaled to meet that asset demand too, but it already has to be >> scaled to meet other demands of being a region server... and why is >> scaling those asset proxy services hard? It's going to cost $, but is >> not technically challenging. So, if I want to host a region like >> that... sure it will cost me, but the simulation will be consistent >> and users will be able to participate equally, regardless of the >> capabilities of their individual asset services. >> >> >> >> >> On Fri, Apr 1, 2011 at 11:55 PM, Morgaine >> wrote: >> > Every design choice results in a trade-off, Vaughn, improving one thing >> at >> > the expense of something else. If every time we offered a service we >> had to >> > inform its users about the downsides of all the trade-offs we have made, >> > they would have an awful lot to read. ;-) >> > >> > The specific trade-off that you are discussing is no different. A >> region >> > that proxies all content has the "benefit" of acquiring control from the >> > asset servers over the items in the region, so that it can ensure that >> > everyone in the region not only obtains the items but obtains the same >> items >> > as everyone else. That does indeed provide a greater guarantee of >> > consistency than a deployment in which the region only passes asset URIs >> to >> > clients who then fetch the items from asset services separately. As >> always >> > though, it's a trade-off, since the proxied design has very poor >> scalability >> > compared to the distributed one. >> > >> > If we're going to warn users of the potential for inconsistency in the >> > distributed deployment as you suggest, are we also going to warn them of >> > non-scalability in the proxied one? I really don't see much merit in >> the >> > idea of warning about design choices. Many such choices are technical, >> and >> > the issues are quite likely to be of little interest to non-technical >> users >> > anyway. In any case, the better services are likely to provide such >> > information in their online documentation, I would guess. >> > >> > You mentioned users "voting with their feet" or choosing to accept the >> risk >> > of inconsistency. Well that will happen anyway, when services fail and >> > users get annoyed. If some asset services refuse to send the requested >> > items to some users, those services will get a bad reputation and people >> > will choose different asset services instead. Likewise, if a world >> service >> > proxies everything and so it can't handle a large number of assets or of >> > people, users will get annoyed at the lag and will go elsewhere. This >> user >> > evaluation and "voting with their feet" happens already with online >> services >> > all over the Internet, and I am sure that this human process will >> continue >> > to work when the services are asset and region services. >> > >> > Back in September 2010, I wrote this post which proposes that we use in >> > VWRAP a form of asset addressing that provides massive scalability at >> the >> > same time as a very high degree of resilience -- >> > http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html . It >> is >> > based on the concept of the URI containing a host part and a hash part, >> > where the hash is generated (once, at the time of storage to the asset >> > service) using a specified digest algorithm over the content of the >> asset >> > being referenced. You may wish to note that if this design were used, >> the >> > failure of an asset service to deliver a requested item would result in >> a >> > failover request for the item to one or more backup services, using the >> same >> > hash part but with a different host address. >> > >> > This can go some way towards overcoming the problem that you think might >> > occur when assets are fetched by clients from asset services directly. >> > Although it won't help when the missing item is available from only a >> single >> > asset service, it will help in many other cases, and it will compensate >> for >> > service failures and network outages automatically at the same time. >> > >> > PS. This design for hash-based asset addressing is already being tested >> by >> > Mojito Sorbet in her experimental world and client. It would give >> > VWRAP-based worlds an improved level of service availability, so I think >> it >> > should be a core feature of our protocol. >> > >> > >> > Morgaine. >> > >> > >> > >> > >> > =========================== >> > >> > On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca > > >> > wrote: >> >> >> >> This is a question i discussed with Morgaine off-list a while ago (I >> >> intended to send it to the list but pushed the wrong button...) I >> >> think we need to address this problem, and decide how to deal with it. >> >> >> >> In Davids deployment draft, section 7.3.1.1 an overview is given van >> >> ways to deliver content to the region. One way is only passing a >> >> capability that allows access to (part of) the resource: >> >> >> >> 7.3.1.1. Content delivery models >> >> A range of possible represenations can be passed to a region >> for >> >> simulation. [...] The other end of the delivery spectrum >> >> involves passing >> >> only a URI or capability used to access the rendering >> >> information and a >> >> collision mesh,and related data for physical simulation. >> >> In such a model, the client is responsible for fetching the >> >> additional >> >> information needed to render the item's visual presence from >> a >> >> separate >> >> service. This fetch can be done *under the credentials of >> the >> >> end user* >> >> viewing the material [my emphasis--VD] , and divorces the >> >> simulation from >> >> the trust chain needed to manage content. Any automation >> >> is done on a >> >> separate host which the content creator or owner trusts, >> >> interacting with the >> >> object through remoted interfaces. >> >> >> >> I can see the need for such a setup, however, i feel we are >> >> unpleasantly close to a situation were the coherence of the simulation >> >> falls apart. >> >> In this deployment pattern the region advertises the presence of the >> >> asset, and *some* clients will be able to get it as expected, while >> >> -based on the arbitrary whims of the asset service- others might not. >> >> >> >> My hope would be that after the asset server provides the region with >> >> the capability to get the asset, it gives up control. That would mean >> >> that if the client finds the inventory server is unwilling to serve >> >> the content - in spire of the region saying it is present-, the client >> >> should be able to turn around ask the *region* for the asset, (and get >> >> is after all). >> >> >> >> If that is not the case, -and there are probably good reasons for the >> >> deployment pattern as described- shouldn't we *warn* clients that the >> >> region might be inconsistent, so the users behind the client can vote >> >> with their feet, (or take the risk)? >> >> >> >> --Vaughn >> >> _______________________________________________ >> >> 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 >> > >> > >> > > > --000e0cd25cae12a6d804a0019143 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Apr 3, 2011 at 3:42 AM, Israel Alanis <izzyalanis@gmail.com> wrote:=

I think what you're saying is: "It costs a lot of money to build a= =20 scalable asset service, but if assets are spread throughout the internet they don't have to be scalable." But that's not quite right. = You're=20 opening up every asset server to the VW equivalent of being slashdotted, so are you sure you're not forcing *every* asset service to be scalabl= e and handle a lot of bandwith and network traffic? It's the exact=20 opposite of your intention, but I think that's the result, all the same= .



We actually discussed= this in the early days of the list, and I was advocating that part of the = duties of a huge commercial service that supports VW interop needs to be to= temporarily cache assets of new arrivals from other worlds, as an independ= ent service of the large VW, ie. a Caching Service.

The reason why I believe a separate Caching Service (unrelated to any A= sset Service) is needed is because the commercial service will not be able = to maintain a desired quality of service without it for its users.

Imagine a Truly Awesome Commercial World, able to support media crowd event= s of 100,000 avatars.=A0 Lucy The Musical Furries Fan runs a tiny world for= her family with its own midget integrated asset service, and hears that he= r adored Musical Furries are going to play at Truly Awesome Commercial Worl= d, so off she teleports to the venue.=A0 Instantly on arrival, 100,000 fans= of the Musical Furries slashdot her asset service into a smoldering slag h= eap as they all try to fetch her avatar's assets.

Clearly this is not going to work.=A0 Quite apart from Lucy's probl= em, it is the Truly Awesome Commercial World that suffers most, because it = now has 100,000 fans who are faced with a broken simulation.=A0 It's no= longer very awesome.

(Not allowing entry to Lucy is not an option because the huge world rel= ies on 100,000 people like Lucy arriving to support the event, many of whom= are in Lucy's situation.)

Unfortunately I never managed to get = anyone interested in the concept of a Caching Service as an independent ent= ity.=A0 Perhaps it's time to revive the idea.

Note that the Caching Service would be yet another independent service,= conceptually external and not related administratively with any other enti= ty in our picture.=A0 It would be optionally engaged by a region that wants= to open its doors to the metaverse but takes pride in offering a better qu= ality of service than its visitors' asset services can provide by thems= elves.

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


On Sun, Apr 3, 2011 at 3:42 AM, Israel Alanis <izzyalanis@gmail.com> wrote:

>=A0when designing for scalabil= ity, the model to bear in mind is ...

Well, there are a lot of different models to keep in mi= nd, and many different use cases. One particular use case to keep in mind i= s: "User acquires new outfit, and wants to 'show it off' in a = highly populated region".

>=A0Both worlds and asset services= may include commercial, community, and personal services

Yes, yes and yes. I'm particularly concerned about how th= e model affects the ability to host personal asset services.

>=A0a proxying region, which would= get slammed for every asset worn by every avatar present.

Granted the collection of services that are provided by the = region need to be scaled to meet the demands of that region. That's all= part of capacity planning.

>=A0regions run many different CPU= -intensive tasks, including physics simulation and server-side scripting, a= nd absolutely cannot afford to serve assets too=A0

Well... who said the same CPU's have to do proxying, physics simul= ation and server-side scripting? Asset proxying is a different service than= physics simulation and can be on separate hardware, could make use of geog= raphically distributed caching, and in certain deployment patterns, the sam= e caching services could be shared by different regions. (Server-side scrip= ting is a discussion for another day).

>=A0This is why we have to go parallel...
=
Totally agree, and a proxying model could and should also ta= ke advantage of parallelism.

>= ;=A0I think you're wrong that it has to cost much money.=A0
?vs?
>=A0It costs money to host a= high performance and scalable asset service and a high bandwidth network t= o handle the traffic.=A0 A=A0lot=A0of money.=A0

=
I think what you're saying is: "It costs a lot of money to build a= scalable asset service, but if assets are spread throughout the internet t= hey don't have to be scalable." But that's not quite right. Yo= u're opening up every asset server to the VW equivalent of being slashd= otted, so are you sure you're not forcing *every* asset service to be s= calable and handle a lot of bandwith and network traffic? It's the exac= t opposite of your intention, but I think that's the result, all the sa= me.

This particular design decision has a big effect on the= economics of the VW infrastructure. I'd rather the economics to work o= ut such that a region provider who wishes to build a region that supports a= small population, can do so economically. A region that wants to host a *l= arge* population has to bear that cost of providing that scalable asset ser= vice.=A0

I want the economics of hosting a small asset service t= o be a non-issue (as to best promote creation and creativity). Creating a h= igh bar to provide asset services will mean that service will cost money an= d people shouldn't have to pay money just to create or own VW objects (= I'm using 'own' here to refer to maintaining their existence, I= 'm not trying to make a 'leftist'/'communist' statement= about ownership ;)

- Izzy


On Apr 2, 2011, at 3:58 = PM, Morgaine wrote:

Izzy, when designing= for scalability, the model to bear in mind is that of seasoned virtual wor= ld travelers whose inventories contain assets from many different worlds, t= hose assets being served by many different asset services.=A0 Both worlds a= nd asset services may include commercial, community, and personal services,= and as the metaverse grows, that set is highly likely to become progressiv= ely less clustered and more diverse.

When those seasoned travelers click on an advertised VW link and perfor= m an inter-world teleport to one particular world's region to share an = experience, their "worn" assets (the only ones of interest to the= region) will contain references to asset services spread widely across the= Internet.=A0 The fetches by the travelers' clients occur over many par= allel paths from clients to asset services, so one can reasonably expect re= duced network contention and reduced asset server loading because they are = both spread out over however many asset services are being referenced by th= e overall set of assets in the region.

This is very different to the case of a proxying region, which would ge= t slammed for every asset worn by every avatar present.=A0 In our current a= rchitecture, regions run many different CPU-intensive tasks, including phys= ics simulation and server-side scripting, and absolutely cannot afford to s= erve assets too unless your scalability requirements are very low indeed, i= e. just a few dozen avatars of today's kind.=A0 We've hit the ceili= ng already on region scalability done that way.=A0 There is nowhere to go i= n that direction at all beyond improving the code like Intel demonstrated, = and that work is subject to a law of diminishing returns.

This is why we have to go parallel, and I think you're wrong that i= t has to cost much money.=A0 As we spread the load across more and more ass= et services, we are simply better utilizing all the hardware that's alr= eady out there on the Internet, at least in respect of community and privat= e resources.=A0 But add to the community and private resources the commerci= al asset services that are likely to appear to exploit this opportunity, an= d not only will the number of asset services leap, but the power of each on= e will rocket too, because, after all, these businesses will be heavily opt= imized for the job.

As to why a world would want clients to access external asset services = instead of providing its own implementation, that's an easy question.= =A0 It costs money to host a high performance and scalable asset service an= d a high bandwidth network to handle the traffic.=A0 A lot of money.= =A0 In contrast, it costs a world nothing to let others serve the assets to= clients.=A0 And that matters to the bottom line.


Morgaine.




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

On Sat, Ap= r 2, 2011 at 7:05 PM, Izzy Alanis <izzyalanis@gmail.com> = wrote:
> As always though, it's a trade-off, since the proxied design = has very poor scalability compared to the distributed one.

I don't agree with that... If a user enters a highly populated re= gion,
every other client is going to (could and should be trying to) hit the
asset server(s) for the assets that the user is wearing (assuming
they're not cached locally). =A0Every asset server has to be scaled up<= br> to the point that it can handle that load from all over...

If I'm hosting a region that supports 10s of thousands of simultaneous<= br> users (thinking of the future), I already have to scale to meet that
demand. If the region is proxying the assets, then, yes the region has
to be scaled to meet that asset demand too, but it already has to be
scaled to meet other demands of being a region server... and why is
scaling those asset proxy services hard? =A0It's going to cost $, but i= s
not technically challenging. So, if I want to host a region like
that... sure it will cost me, but the simulation will be consistent
and users will be able to participate equally, regardless of the
capabilities of their individual asset services.




On Fri, Apr 1, 2011 at 11:55 PM, Morgaine
> Every design choice results in a trade-off,= Vaughn, improving one thing at
> the expense of something else.=A0 If every time we offered a service w= e had to
> inform its users about the downsides of all the trade-offs we have mad= e,
> they would have an awful lot to read. ;-)
>
> The specific trade-off that you are discussing is no different.=A0 A r= egion
> that proxies all content has the "benefit" of acquiring cont= rol from the
> asset servers over the items in the region, so that it can ensure that=
> everyone in the region not only obtains the items but obtains the same= items
> as everyone else.=A0 That does indeed provide a greater guarantee of > consistency than a deployment in which the region only passes asset UR= Is to
> clients who then fetch the items from asset services separately.=A0 As= always
> though, it's a trade-off, since the proxied design has very poor s= calability
> compared to the distributed one.
>
> If we're going to warn users of the potential for inconsistency in= the
> distributed deployment as you suggest, are we also going to warn them = of
> non-scalability in the proxied one?=A0 I really don't see much mer= it in the
> idea of warning about design choices.=A0 Many such choices are technic= al, and
> the issues are quite likely to be of little interest to non-technical = users
> anyway.=A0 In any case, the better services are likely to provide such=
> information in their online documentation, I would guess.
>
> You mentioned users "voting with their feet" or choosing to = accept the risk
> of inconsistency.=A0 Well that will happen anyway, when services fail = and
> users get annoyed.=A0 If some asset services refuse to send the reques= ted
> items to some users, those services will get a bad reputation and peop= le
> will choose different asset services instead.=A0 Likewise, if a world = service
> proxies everything and so it can't handle a large number of assets= or of
> people, users will get annoyed at the lag and will go elsewhere.=A0 Th= is user
> evaluation and "voting with their feet" happens already with= online services
> all over the Internet, and I am sure that this human process will cont= inue
> to work when the services are asset and region services.
>
> Back in September 2010, I wrote this post which proposes that we use i= n
> VWRAP a form of asset addressing that provides massive scalability at = the
> same time as a very high degree of resilience --
> http://www.ietf.org/mail-archive/web/vwrap/current= /msg00463.html .=A0 It is
> based on the concept of the URI containing a host part and a hash part= ,
> where the hash is generated (once, at the time of storage to the asset=
> service) using a specified digest algorithm over the content of the as= set
> being referenced.=A0 You may wish to note that if this design were use= d, the
> failure of an asset service to deliver a requested item would result i= n a
> failover request for the item to one or more backup services, using th= e same
> hash part but with a different host address.
>
> This can go some way towards overcoming the problem that you think mig= ht
> occur when assets are fetched by clients from asset services directly.=
> Although it won't help when the missing item is available from onl= y a single
> asset service, it will help in many other cases, and it will compensat= e for
> service failures and network outages automatically at the same time. >
> PS. This design for hash-based asset addressing is already being teste= d by
> Mojito Sorbet in her experimental world and client.=A0 It would give > VWRAP-based worlds an improved level of service availability, so I thi= nk it
> should be a core feature of our protocol.
>
>
> Morgaine.
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
>
> On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca <vaughn.deluca@gmail.com> > wrote:
>>
>> This is a question i discussed with Morgaine off-list a while ago = (I
>> intended to send it to the list but pushed the wrong button...) I<= br> >> think we need to address this problem, and decide how to deal with= it.
>>
>> =A0In Davids deployment draft, section 7.3.1.1 an overview is give= n van
>> ways to deliver content to the region. One way is only passing a >> capability that allows access to (part of) the resource:
>>
>> =A0 =A0 =A0 =A0 =A0 7.3.1.1. =A0Content delivery models
>> =A0 =A0 =A0 =A0 =A0 A range of possible represenations can be pass= ed to a region for
>> =A0 =A0 =A0 =A0 =A0 simulation. [...] The other end of the deliver= y spectrum
>> involves passing
>> =A0 =A0 =A0 =A0 =A0 only a URI or capability used to access the re= ndering
>> information and a
>> =A0 =A0 =A0 =A0 =A0 collision mesh,and related data for physical s= imulation.
>> =A0 =A0 =A0 =A0 =A0 In such a model, the client is responsible for= fetching the
>> additional
>> =A0 =A0 =A0 =A0 =A0 information needed to render the item's vi= sual presence from a
>> separate
>> =A0 =A0 =A0 =A0 =A0 service. =A0This fetch can be done *under the = credentials of the
>> end user*
>> =A0 =A0 =A0 =A0 =A0 viewing the material [my emphasis--VD] , and d= ivorces the
>> simulation from
>> =A0 =A0 =A0 =A0 =A0 the trust chain needed to manage content. =A0A= ny automation
>> is done on a
>> =A0 =A0 =A0 =A0 =A0 separate host which the content creator or own= er trusts,
>> interacting with the
>> =A0 =A0 =A0 =A0 =A0 object through remoted interfaces.
>>
>> =A0I can see the need for such a setup, however, i feel we are
>> unpleasantly close to a situation were the coherence of the simula= tion
>> falls apart.
>> In this deployment pattern the region advertises the presence of t= he
>> asset, and *some* clients will be able to get it as expected, whil= e
>> -based on the arbitrary whims of the asset service- others might n= ot.
>>
>> My hope would be that after the asset server provides the region w= ith
>> the capability to get the asset, it gives up control. That would m= ean
>> that if the client finds the inventory server is unwilling to serv= e
>> the content - in spire of the region saying it is present-, the cl= ient
>> should be able to turn around ask the *region* for the asset, (and= get
>> is after all).
>>
>> =A0If that is not the case, -and there are probably good reasons f= or the
>> deployment pattern as described- =A0shouldn't we *warn* client= s that the
>> region might be inconsistent, so the users behind the client can v= ote
>> with their feet, (or take the risk)?
>>
>> --Vaughn
>> _______________________________________________
>> 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
>
>



--000e0cd25cae12a6d804a0019143-- From morgaine.dinova@googlemail.com Sun Apr 3 04:37:23 2011 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 37A6E28C0E6 for ; Sun, 3 Apr 2011 04:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 r5LQD21818XN for ; Sun, 3 Apr 2011 04:37:20 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 2A69F3A69A4 for ; Sun, 3 Apr 2011 04:37:19 -0700 (PDT) Received: by qyk7 with SMTP id 7so3119612qyk.10 for ; Sun, 03 Apr 2011 04:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BANSEfFtnueNyP6FArV2y7aZJTF8jlxeYMVwMXFIPoo=; b=CihDqzBAX8FlmJCv4SsFLNqSKZLK5i57TgJgyu08wbwZ2JDJfSz5t7mPS+/33TXQxR Q/+xbUtxbrzAm92woPjZ44VroAQ+Ke5QldZ5VT0SI6ZiTYNu0bsgn0a8x46NHvJojiPB 6cg33jLCtki4Tu/gnhq+0cHblKpMmR6j5zrBY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qbLmVFy4RkZm2obJpf3ZwOQ5BLLcBGAkskNGxfKu5s1TV/HKt8OCH3wbEQi59bSGvc FP+kO4IjHic7bqlcvaiUDfNNYTzPMucZhXurRl0LaNbBR5yqe9p3O8XxOD5Pa5IYsYXN 43t4Vr8/QHmq/95KFNG9P1+e49hvD4Hi3U+Ag= MIME-Version: 1.0 Received: by 10.229.37.130 with SMTP id x2mr4888786qcd.147.1301830738987; Sun, 03 Apr 2011 04:38:58 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sun, 3 Apr 2011 04:38:58 -0700 (PDT) In-Reply-To: References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> Date: Sun, 3 Apr 2011 12:38:58 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016368340c0c14b0a04a002161c Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 03 Apr 2011 11:37:23 -0000 --0016368340c0c14b0a04a002161c Content-Type: text/plain; charset=ISO-8859-1 I should mention that a Caching Service doesn't have to be a transparent cache working behind the scenes within the region. That kind of cache can always be introduced without our protocol needing to know about it, and such caches are in use by regions already I believe. Instead, it could be a negotiated facility for which the client can query the region to see if it exists, and if it exists then the client has the choice of using it or not, and the negotiation might also allow a different Caching Service to be nominated. (Lucy might work for IBM which runs an IBM Employee Caching Service using 5,000 Blue Gene machines as a perk for employees so that they always render instantly on any world they visit, giving IBM a good name worldwide ... :P So of course Lucy would want to tell the region to use her employer's Caching Service.) Also, a world might not necessarily be interested in maintaining a high quality of service, but very interested in revenue instead, and so requesting use of its Caching Service could be an extra-cost option at entry. Who knows. Maybe attending the Musical Furries gig is free, while paying for the Caching Service is the cost of admission. Nobody really knows where this is leading. :-) This is just one possibility out of many possible variations on the theme. Even if the Caching Service is hidden within the region and is totally transparent to the protocol, it still offers us the means to embrace VW interop while maintaining a high quality of service as region populations grow, and that's important. Morgaine. ====================== On Sun, Apr 3, 2011 at 12:01 PM, Morgaine wrote: > On Sun, Apr 3, 2011 at 3:42 AM, Israel Alanis wrote: > >> >> I think what you're saying is: "It costs a lot of money to build a >> scalable asset service, but if assets are spread throughout the internet >> they don't have to be scalable." But that's not quite right. You're opening >> up every asset server to the VW equivalent of being slashdotted, so are you >> sure you're not forcing *every* asset service to be scalable and handle a >> lot of bandwith and network traffic? It's the exact opposite of your >> intention, but I think that's the result, all the same. >> >> > > We actually discussed this in the early days of the list, and I was > advocating that part of the duties of a huge commercial service that > supports VW interop needs to be to temporarily cache assets of new arrivals > from other worlds, as an independent service of the large VW, ie. a Caching > Service. > > The reason why I believe a separate Caching Service (unrelated to any Asset > Service) is needed is because the commercial service will not be able to > maintain a desired quality of service without it for its users. > > Imagine a Truly Awesome Commercial World, able to support media crowd > events of 100,000 avatars. Lucy The Musical Furries Fan runs a tiny world > for her family with its own midget integrated asset service, and hears that > her adored Musical Furries are going to play at Truly Awesome Commercial > World, so off she teleports to the venue. Instantly on arrival, 100,000 > fans of the Musical Furries slashdot her asset service into a smoldering > slag heap as they all try to fetch her avatar's assets. > > Clearly this is not going to work. Quite apart from Lucy's problem, it is > the Truly Awesome Commercial World that suffers most, because it now has > 100,000 fans who are faced with a broken simulation. It's no longer very > awesome. > > (Not allowing entry to Lucy is not an option because the huge world relies > on 100,000 people like Lucy arriving to support the event, many of whom are > in Lucy's situation.) > > Unfortunately I never managed to get anyone interested in the concept of a > Caching Service as an independent entity. Perhaps it's time to revive the > idea. > > Note that the Caching Service would be yet another independent service, > conceptually external and not related administratively with any other entity > in our picture. It would be optionally engaged by a region that wants to > open its doors to the metaverse but takes pride in offering a better quality > of service than its visitors' asset services can provide by themselves. > > > Morgaine. > > > > ============================ > > > > On Sun, Apr 3, 2011 at 3:42 AM, Israel Alanis wrote: > >> >> > when designing for scalability, the model to bear in mind is ... >> >> Well, there are a lot of different models to keep in mind, and many >> different use cases. One particular use case to keep in mind is: "User >> acquires new outfit, and wants to 'show it off' in a highly populated >> region". >> >> > Both worlds and asset services may include commercial, community, and >> personal services >> >> Yes, yes and yes. I'm particularly concerned about how the model affects >> the ability to host personal asset services. >> >> > a proxying region, which would get slammed for every asset worn by every >> avatar present. >> >> Granted the collection of services that are provided by the region need to >> be scaled to meet the demands of that region. That's all part of capacity >> planning. >> >> > regions run many different CPU-intensive tasks, including physics >> simulation and server-side scripting, and absolutely cannot afford to serve >> assets too >> >> Well... who said the same CPU's have to do proxying, physics simulation >> and server-side scripting? Asset proxying is a different service than >> physics simulation and can be on separate hardware, could make use of >> geographically distributed caching, and in certain deployment patterns, the >> same caching services could be shared by different regions. (Server-side >> scripting is a discussion for another day). >> >> > This is why we have to go parallel... >> >> Totally agree, and a proxying model could and should also take advantage >> of parallelism. >> >> > I think you're wrong that it has to cost much money. >> ?vs? >> > It costs money to host a high performance and scalable asset service and >> a high bandwidth network to handle the traffic. A *lot* of money. >> >> I think what you're saying is: "It costs a lot of money to build a >> scalable asset service, but if assets are spread throughout the internet >> they don't have to be scalable." But that's not quite right. You're opening >> up every asset server to the VW equivalent of being slashdotted, so are you >> sure you're not forcing *every* asset service to be scalable and handle a >> lot of bandwith and network traffic? It's the exact opposite of your >> intention, but I think that's the result, all the same. >> >> This particular design decision has a big effect on the economics of the >> VW infrastructure. I'd rather the economics to work out such that a region >> provider who wishes to build a region that supports a small population, can >> do so economically. A region that wants to host a *large* population has to >> bear that cost of providing that scalable asset service. >> >> I want the economics of hosting a small asset service to be a non-issue >> (as to best promote creation and creativity). Creating a high bar to provide >> asset services will mean that service will cost money and people shouldn't >> have to pay money just to create or own VW objects (I'm using 'own' here to >> refer to maintaining their existence, I'm not trying to make a >> 'leftist'/'communist' statement about ownership ;) >> >> - Izzy >> >> >> On Apr 2, 2011, at 3:58 PM, Morgaine wrote: >> >> Izzy, when designing for scalability, the model to bear in mind is that of >> seasoned virtual world travelers whose inventories contain assets from many >> different worlds, those assets being served by many different asset >> services. Both worlds and asset services may include commercial, community, >> and personal services, and as the metaverse grows, that set is highly likely >> to become progressively less clustered and more diverse. >> >> When those seasoned travelers click on an advertised VW link and perform >> an inter-world teleport to one particular world's region to share an >> experience, their "worn" assets (the only ones of interest to the region) >> will contain references to asset services spread widely across the >> Internet. The fetches by the travelers' clients occur over many parallel >> paths from clients to asset services, so one can reasonably expect reduced >> network contention and reduced asset server loading because they are both >> spread out over however many asset services are being referenced by the >> overall set of assets in the region. >> >> This is very different to the case of a proxying region, which would get >> slammed for every asset worn by every avatar present. In our current >> architecture, regions run many different CPU-intensive tasks, including >> physics simulation and server-side scripting, and absolutely cannot afford >> to serve assets too unless your scalability requirements are very low >> indeed, ie. just a few dozen avatars of today's kind. We've hit the ceiling >> already on region scalability done that way. There is nowhere to go in that >> direction at all beyond improving the code like Intel demonstrated, and that >> work is subject to a law of diminishing returns. >> >> This is why we have to go parallel, and I think you're wrong that it has >> to cost much money. As we spread the load across more and more asset >> services, we are simply better utilizing all the hardware that's already out >> there on the Internet, at least in respect of community and private >> resources. But add to the community and private resources the commercial >> asset services that are likely to appear to exploit this opportunity, and >> not only will the number of asset services leap, but the power of each one >> will rocket too, because, after all, these businesses will be heavily >> optimized for the job. >> >> As to why a world would want clients to access external asset services >> instead of providing its own implementation, that's an easy question. It >> costs money to host a high performance and scalable asset service and a high >> bandwidth network to handle the traffic. A *lot* of money. In contrast, >> it costs a world nothing to let others serve the assets to clients. And >> that matters to the bottom line. >> >> >> Morgaine. >> >> >> >> >> ====================== >> >> On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis wrote: >> >>> > As always though, it's a trade-off, since the proxied design has very >>> poor scalability compared to the distributed one. >>> >>> I don't agree with that... If a user enters a highly populated region, >>> every other client is going to (could and should be trying to) hit the >>> asset server(s) for the assets that the user is wearing (assuming >>> they're not cached locally). Every asset server has to be scaled up >>> to the point that it can handle that load from all over... >>> >>> If I'm hosting a region that supports 10s of thousands of simultaneous >>> users (thinking of the future), I already have to scale to meet that >>> demand. If the region is proxying the assets, then, yes the region has >>> to be scaled to meet that asset demand too, but it already has to be >>> scaled to meet other demands of being a region server... and why is >>> scaling those asset proxy services hard? It's going to cost $, but is >>> not technically challenging. So, if I want to host a region like >>> that... sure it will cost me, but the simulation will be consistent >>> and users will be able to participate equally, regardless of the >>> capabilities of their individual asset services. >>> >>> >>> >>> >>> On Fri, Apr 1, 2011 at 11:55 PM, Morgaine >>> wrote: >>> > Every design choice results in a trade-off, Vaughn, improving one thing >>> at >>> > the expense of something else. If every time we offered a service we >>> had to >>> > inform its users about the downsides of all the trade-offs we have >>> made, >>> > they would have an awful lot to read. ;-) >>> > >>> > The specific trade-off that you are discussing is no different. A >>> region >>> > that proxies all content has the "benefit" of acquiring control from >>> the >>> > asset servers over the items in the region, so that it can ensure that >>> > everyone in the region not only obtains the items but obtains the same >>> items >>> > as everyone else. That does indeed provide a greater guarantee of >>> > consistency than a deployment in which the region only passes asset >>> URIs to >>> > clients who then fetch the items from asset services separately. As >>> always >>> > though, it's a trade-off, since the proxied design has very poor >>> scalability >>> > compared to the distributed one. >>> > >>> > If we're going to warn users of the potential for inconsistency in the >>> > distributed deployment as you suggest, are we also going to warn them >>> of >>> > non-scalability in the proxied one? I really don't see much merit in >>> the >>> > idea of warning about design choices. Many such choices are technical, >>> and >>> > the issues are quite likely to be of little interest to non-technical >>> users >>> > anyway. In any case, the better services are likely to provide such >>> > information in their online documentation, I would guess. >>> > >>> > You mentioned users "voting with their feet" or choosing to accept the >>> risk >>> > of inconsistency. Well that will happen anyway, when services fail and >>> > users get annoyed. If some asset services refuse to send the requested >>> > items to some users, those services will get a bad reputation and >>> people >>> > will choose different asset services instead. Likewise, if a world >>> service >>> > proxies everything and so it can't handle a large number of assets or >>> of >>> > people, users will get annoyed at the lag and will go elsewhere. This >>> user >>> > evaluation and "voting with their feet" happens already with online >>> services >>> > all over the Internet, and I am sure that this human process will >>> continue >>> > to work when the services are asset and region services. >>> > >>> > Back in September 2010, I wrote this post which proposes that we use in >>> > VWRAP a form of asset addressing that provides massive scalability at >>> the >>> > same time as a very high degree of resilience -- >>> > http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html . It >>> is >>> > based on the concept of the URI containing a host part and a hash part, >>> > where the hash is generated (once, at the time of storage to the asset >>> > service) using a specified digest algorithm over the content of the >>> asset >>> > being referenced. You may wish to note that if this design were used, >>> the >>> > failure of an asset service to deliver a requested item would result in >>> a >>> > failover request for the item to one or more backup services, using the >>> same >>> > hash part but with a different host address. >>> > >>> > This can go some way towards overcoming the problem that you think >>> might >>> > occur when assets are fetched by clients from asset services directly. >>> > Although it won't help when the missing item is available from only a >>> single >>> > asset service, it will help in many other cases, and it will compensate >>> for >>> > service failures and network outages automatically at the same time. >>> > >>> > PS. This design for hash-based asset addressing is already being tested >>> by >>> > Mojito Sorbet in her experimental world and client. It would give >>> > VWRAP-based worlds an improved level of service availability, so I >>> think it >>> > should be a core feature of our protocol. >>> > >>> > >>> > Morgaine. >>> > >>> > >>> > >>> > >>> > =========================== >>> > >>> > On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca < >>> vaughn.deluca@gmail.com> >>> > wrote: >>> >> >>> >> This is a question i discussed with Morgaine off-list a while ago (I >>> >> intended to send it to the list but pushed the wrong button...) I >>> >> think we need to address this problem, and decide how to deal with it. >>> >> >>> >> In Davids deployment draft, section 7.3.1.1 an overview is given van >>> >> ways to deliver content to the region. One way is only passing a >>> >> capability that allows access to (part of) the resource: >>> >> >>> >> 7.3.1.1. Content delivery models >>> >> A range of possible represenations can be passed to a region >>> for >>> >> simulation. [...] The other end of the delivery spectrum >>> >> involves passing >>> >> only a URI or capability used to access the rendering >>> >> information and a >>> >> collision mesh,and related data for physical simulation. >>> >> In such a model, the client is responsible for fetching the >>> >> additional >>> >> information needed to render the item's visual presence from >>> a >>> >> separate >>> >> service. This fetch can be done *under the credentials of >>> the >>> >> end user* >>> >> viewing the material [my emphasis--VD] , and divorces the >>> >> simulation from >>> >> the trust chain needed to manage content. Any automation >>> >> is done on a >>> >> separate host which the content creator or owner trusts, >>> >> interacting with the >>> >> object through remoted interfaces. >>> >> >>> >> I can see the need for such a setup, however, i feel we are >>> >> unpleasantly close to a situation were the coherence of the simulation >>> >> falls apart. >>> >> In this deployment pattern the region advertises the presence of the >>> >> asset, and *some* clients will be able to get it as expected, while >>> >> -based on the arbitrary whims of the asset service- others might not. >>> >> >>> >> My hope would be that after the asset server provides the region with >>> >> the capability to get the asset, it gives up control. That would mean >>> >> that if the client finds the inventory server is unwilling to serve >>> >> the content - in spire of the region saying it is present-, the client >>> >> should be able to turn around ask the *region* for the asset, (and get >>> >> is after all). >>> >> >>> >> If that is not the case, -and there are probably good reasons for the >>> >> deployment pattern as described- shouldn't we *warn* clients that the >>> >> region might be inconsistent, so the users behind the client can vote >>> >> with their feet, (or take the risk)? >>> >> >>> >> --Vaughn >>> >> _______________________________________________ >>> >> 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 >>> > >>> > >>> >> >> >> > --0016368340c0c14b0a04a002161c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I should mention that a Caching Service doesn't have to be a transparen= t cache working behind the scenes within the region.=A0 That kind of cache = can always be introduced without our protocol needing to know about it, and= such caches are in use by regions already I believe.

Instead, it could be a negotiated facility for which the client can que= ry the region to see if it exists, and if it exists then the client has the= choice of using it or not, and the negotiation might also allow a differen= t Caching Service to be nominated.

(Lucy might work for IBM which runs an IBM Employee Caching Service usi= ng 5,000 Blue Gene machines as a perk for employees so that they always ren= der instantly on any world they visit, giving IBM a good name worldwide ...= :P=A0 So of course Lucy would want to tell the region to use her employer&= #39;s Caching Service.)

Also, a world might not necessarily be interested in maintaining a high= quality of service, but very interested in revenue instead, and so request= ing use of its Caching Service could be an extra-cost option at entry.=A0 W= ho knows.=A0 Maybe attending the Musical Furries gig is free, while paying = for the Caching Service is the cost of admission. Nobody really knows where= this is leading. :-)

This is just one possibility out of many possible variations on the the= me.=A0 Even if the Caching Service is hidden within the region and is total= ly transparent to the protocol, it still offers us the means to embrace VW = interop while maintaining a high quality of service as region populations g= row, and that's important.


Morgaine.





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

On Sun,= Apr 3, 2011 at 12:01 PM, Morgaine <morgaine.dinova@googlemail.com> wrote:
On Sun, Apr 3, 2011 at 3:42 AM, Israel Alanis <izzyalanis@gmail.com> wrote:

I think what you're saying is: "It costs a lot of money to build a= =20 scalable asset service, but if assets are spread throughout the internet they don't have to be scalable." But that's not quite right. = You're=20 opening up every asset server to the VW equivalent of being slashdotted, so are you sure you're not forcing *every* asset service to be scalabl= e and handle a lot of bandwith and network traffic? It's the exact=20 opposite of your intention, but I think that's the result, all the same= .



We actually dis= cussed this in the early days of the list, and I was advocating that part o= f the duties of a huge commercial service that supports VW interop needs to= be to temporarily cache assets of new arrivals from other worlds, as an in= dependent service of the large VW, ie. a Caching Service.

The reason why I believe a separate Caching Service (unrelated to any A= sset Service) is needed is because the commercial service will not be able = to maintain a desired quality of service without it for its users.

Imagine a Truly Awesome Commercial World, able to support media crowd event= s of 100,000 avatars.=A0 Lucy The Musical Furries Fan runs a tiny world for= her family with its own midget integrated asset service, and hears that he= r adored Musical Furries are going to play at Truly Awesome Commercial Worl= d, so off she teleports to the venue.=A0 Instantly on arrival, 100,000 fans= of the Musical Furries slashdot her asset service into a smoldering slag h= eap as they all try to fetch her avatar's assets.

Clearly this is not going to work.=A0 Quite apart from Lucy's probl= em, it is the Truly Awesome Commercial World that suffers most, because it = now has 100,000 fans who are faced with a broken simulation.=A0 It's no= longer very awesome.

(Not allowing entry to Lucy is not an option because the huge world rel= ies on 100,000 people like Lucy arriving to support the event, many of whom= are in Lucy's situation.)

Unfortunately I never managed to get = anyone interested in the concept of a Caching Service as an independent ent= ity.=A0 Perhaps it's time to revive the idea.

Note that the Caching Service would be yet another independent service,= conceptually external and not related administratively with any other enti= ty in our picture.=A0 It would be optionally engaged by a region that wants= to open its doors to the metaverse but takes pride in offering a better qu= ality of service than its visitors' asset services can provide by thems= elves.

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



On Sun, Apr 3, 2011 at 3:42 = AM, Israel Alanis <izzyalanis@gmail.com> wrote:

>=A0when designing for scalabil= ity, the model to bear in mind is ...

Well, there are a lot of different models to keep in mi= nd, and many different use cases. One particular use case to keep in mind i= s: "User acquires new outfit, and wants to 'show it off' in a = highly populated region".

>=A0Both worlds and asset services may include = commercial, community, and personal services

Yes, yes and yes. I'm particularly concerned about how the model affec= ts the ability to host personal asset services.

>=A0a proxying region, which would get slammed = for every asset worn by every avatar present.

Granted the collection of services that are provided by the region need t= o be scaled to meet the demands of that region. That's all part of capa= city planning.

>=A0regions run many different CPU-intensive ta= sks, including physics simulation and server-side scripting, and absolutely= cannot afford to serve assets too=A0

Well... who said the same CPU's have to do proxying, physics simul= ation and server-side scripting? Asset proxying is a different service than= physics simulation and can be on separate hardware, could make use of geog= raphically distributed caching, and in certain deployment patterns, the sam= e caching services could be shared by different regions. (Server-side scrip= ting is a discussion for another day).

>=A0This is why we have to go parallel...
=
Totally agree, and a proxying model could and should also ta= ke advantage of parallelism.

>=A0I think y= ou're wrong that it has to cost much money.=A0
?vs?
>=A0It costs money to host a high perform= ance and scalable asset service and a high bandwidth network to handle the = traffic.=A0 A=A0lot=A0of money.=A0

I think what you're saying is: "It costs a lot of money to build a= scalable asset service, but if assets are spread throughout the internet t= hey don't have to be scalable." But that's not quite right. Yo= u're opening up every asset server to the VW equivalent of being slashd= otted, so are you sure you're not forcing *every* asset service to be s= calable and handle a lot of bandwith and network traffic? It's the exac= t opposite of your intention, but I think that's the result, all the sa= me.

This particular design decision has a big effect on the= economics of the VW infrastructure. I'd rather the economics to work o= ut such that a region provider who wishes to build a region that supports a= small population, can do so economically. A region that wants to host a *l= arge* population has to bear that cost of providing that scalable asset ser= vice.=A0

I want the economics of hosting a small asset service t= o be a non-issue (as to best promote creation and creativity). Creating a h= igh bar to provide asset services will mean that service will cost money an= d people shouldn't have to pay money just to create or own VW objects (= I'm using 'own' here to refer to maintaining their existence, I= 'm not trying to make a 'leftist'/'communist' statement= about ownership ;)

- Izzy


On Apr 2, 2011, at 3:58 PM, Morgaine = wrote:

Izzy, when designing for scalabil= ity, the model to bear in mind is that of seasoned virtual world travelers = whose inventories contain assets from many different worlds, those assets b= eing served by many different asset services.=A0 Both worlds and asset serv= ices may include commercial, community, and personal services, and as the m= etaverse grows, that set is highly likely to become progressively less clus= tered and more diverse.

When those seasoned travelers click on an advertised VW link and perfor= m an inter-world teleport to one particular world's region to share an = experience, their "worn" assets (the only ones of interest to the= region) will contain references to asset services spread widely across the= Internet.=A0 The fetches by the travelers' clients occur over many par= allel paths from clients to asset services, so one can reasonably expect re= duced network contention and reduced asset server loading because they are = both spread out over however many asset services are being referenced by th= e overall set of assets in the region.

This is very different to the case of a proxying region, which would ge= t slammed for every asset worn by every avatar present.=A0 In our current a= rchitecture, regions run many different CPU-intensive tasks, including phys= ics simulation and server-side scripting, and absolutely cannot afford to s= erve assets too unless your scalability requirements are very low indeed, i= e. just a few dozen avatars of today's kind.=A0 We've hit the ceili= ng already on region scalability done that way.=A0 There is nowhere to go i= n that direction at all beyond improving the code like Intel demonstrated, = and that work is subject to a law of diminishing returns.

This is why we have to go parallel, and I think you're wrong that i= t has to cost much money.=A0 As we spread the load across more and more ass= et services, we are simply better utilizing all the hardware that's alr= eady out there on the Internet, at least in respect of community and privat= e resources.=A0 But add to the community and private resources the commerci= al asset services that are likely to appear to exploit this opportunity, an= d not only will the number of asset services leap, but the power of each on= e will rocket too, because, after all, these businesses will be heavily opt= imized for the job.

As to why a world would want clients to access external asset services = instead of providing its own implementation, that's an easy question.= =A0 It costs money to host a high performance and scalable asset service an= d a high bandwidth network to handle the traffic.=A0 A lot of money.= =A0 In contrast, it costs a world nothing to let others serve the assets to= clients.=A0 And that matters to the bottom line.


Morgaine.




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

On Sat, Ap= r 2, 2011 at 7:05 PM, Izzy Alanis <izzyalanis@gmail.com> = wrote:
> As always though, it's a trade-off, since the proxied design = has very poor scalability compared to the distributed one.

I don't agree with that... If a user enters a highly populated re= gion,
every other client is going to (could and should be trying to) hit the
asset server(s) for the assets that the user is wearing (assuming
they're not cached locally). =A0Every asset server has to be scaled up<= br> to the point that it can handle that load from all over...

If I'm hosting a region that supports 10s of thousands of simultaneous<= br> users (thinking of the future), I already have to scale to meet that
demand. If the region is proxying the assets, then, yes the region has
to be scaled to meet that asset demand too, but it already has to be
scaled to meet other demands of being a region server... and why is
scaling those asset proxy services hard? =A0It's going to cost $, but i= s
not technically challenging. So, if I want to host a region like
that... sure it will cost me, but the simulation will be consistent
and users will be able to participate equally, regardless of the
capabilities of their individual asset services.




On Fri, Apr 1, 2011 at 11:55 PM, Morgaine
> Every design choice results in a trade-off,= Vaughn, improving one thing at
> the expense of something else.=A0 If every time we offered a service w= e had to
> inform its users about the downsides of all the trade-offs we have mad= e,
> they would have an awful lot to read. ;-)
>
> The specific trade-off that you are discussing is no different.=A0 A r= egion
> that proxies all content has the "benefit" of acquiring cont= rol from the
> asset servers over the items in the region, so that it can ensure that=
> everyone in the region not only obtains the items but obtains the same= items
> as everyone else.=A0 That does indeed provide a greater guarantee of > consistency than a deployment in which the region only passes asset UR= Is to
> clients who then fetch the items from asset services separately.=A0 As= always
> though, it's a trade-off, since the proxied design has very poor s= calability
> compared to the distributed one.
>
> If we're going to warn users of the potential for inconsistency in= the
> distributed deployment as you suggest, are we also going to warn them = of
> non-scalability in the proxied one?=A0 I really don't see much mer= it in the
> idea of warning about design choices.=A0 Many such choices are technic= al, and
> the issues are quite likely to be of little interest to non-technical = users
> anyway.=A0 In any case, the better services are likely to provide such=
> information in their online documentation, I would guess.
>
> You mentioned users "voting with their feet" or choosing to = accept the risk
> of inconsistency.=A0 Well that will happen anyway, when services fail = and
> users get annoyed.=A0 If some asset services refuse to send the reques= ted
> items to some users, those services will get a bad reputation and peop= le
> will choose different asset services instead.=A0 Likewise, if a world = service
> proxies everything and so it can't handle a large number of assets= or of
> people, users will get annoyed at the lag and will go elsewhere.=A0 Th= is user
> evaluation and "voting with their feet" happens already with= online services
> all over the Internet, and I am sure that this human process will cont= inue
> to work when the services are asset and region services.
>
> Back in September 2010, I wrote this post which proposes that we use i= n
> VWRAP a form of asset addressing that provides massive scalability at = the
> same time as a very high degree of resilience --
> http://www.ietf.org/mail-archive/web/vwrap/current= /msg00463.html .=A0 It is
> based on the concept of the URI containing a host part and a hash part= ,
> where the hash is generated (once, at the time of storage to the asset=
> service) using a specified digest algorithm over the content of the as= set
> being referenced.=A0 You may wish to note that if this design were use= d, the
> failure of an asset service to deliver a requested item would result i= n a
> failover request for the item to one or more backup services, using th= e same
> hash part but with a different host address.
>
> This can go some way towards overcoming the problem that you think mig= ht
> occur when assets are fetched by clients from asset services directly.=
> Although it won't help when the missing item is available from onl= y a single
> asset service, it will help in many other cases, and it will compensat= e for
> service failures and network outages automatically at the same time. >
> PS. This design for hash-based asset addressing is already being teste= d by
> Mojito Sorbet in her experimental world and client.=A0 It would give > VWRAP-based worlds an improved level of service availability, so I thi= nk it
> should be a core feature of our protocol.
>
>
> Morgaine.
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
>
> On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca <vaughn.deluca@gmail.com> > wrote:
>>
>> This is a question i discussed with Morgaine off-list a while ago = (I
>> intended to send it to the list but pushed the wrong button...) I<= br> >> think we need to address this problem, and decide how to deal with= it.
>>
>> =A0In Davids deployment draft, section 7.3.1.1 an overview is give= n van
>> ways to deliver content to the region. One way is only passing a >> capability that allows access to (part of) the resource:
>>
>> =A0 =A0 =A0 =A0 =A0 7.3.1.1. =A0Content delivery models
>> =A0 =A0 =A0 =A0 =A0 A range of possible represenations can be pass= ed to a region for
>> =A0 =A0 =A0 =A0 =A0 simulation. [...] The other end of the deliver= y spectrum
>> involves passing
>> =A0 =A0 =A0 =A0 =A0 only a URI or capability used to access the re= ndering
>> information and a
>> =A0 =A0 =A0 =A0 =A0 collision mesh,and related data for physical s= imulation.
>> =A0 =A0 =A0 =A0 =A0 In such a model, the client is responsible for= fetching the
>> additional
>> =A0 =A0 =A0 =A0 =A0 information needed to render the item's vi= sual presence from a
>> separate
>> =A0 =A0 =A0 =A0 =A0 service. =A0This fetch can be done *under the = credentials of the
>> end user*
>> =A0 =A0 =A0 =A0 =A0 viewing the material [my emphasis--VD] , and d= ivorces the
>> simulation from
>> =A0 =A0 =A0 =A0 =A0 the trust chain needed to manage content. =A0A= ny automation
>> is done on a
>> =A0 =A0 =A0 =A0 =A0 separate host which the content creator or own= er trusts,
>> interacting with the
>> =A0 =A0 =A0 =A0 =A0 object through remoted interfaces.
>>
>> =A0I can see the need for such a setup, however, i feel we are
>> unpleasantly close to a situation were the coherence of the simula= tion
>> falls apart.
>> In this deployment pattern the region advertises the presence of t= he
>> asset, and *some* clients will be able to get it as expected, whil= e
>> -based on the arbitrary whims of the asset service- others might n= ot.
>>
>> My hope would be that after the asset server provides the region w= ith
>> the capability to get the asset, it gives up control. That would m= ean
>> that if the client finds the inventory server is unwilling to serv= e
>> the content - in spire of the region saying it is present-, the cl= ient
>> should be able to turn around ask the *region* for the asset, (and= get
>> is after all).
>>
>> =A0If that is not the case, -and there are probably good reasons f= or the
>> deployment pattern as described- =A0shouldn't we *warn* client= s that the
>> region might be inconsistent, so the users behind the client can v= ote
>> with their feet, (or take the risk)?
>>
>> --Vaughn
>> _______________________________________________
>> 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
>
>




--0016368340c0c14b0a04a002161c-- From vaughn.deluca@gmail.com Sun Apr 3 05:23:16 2011 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 642F73A67C1 for ; Sun, 3 Apr 2011 05:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] 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 2ZO9-pVpcHGP for ; Sun, 3 Apr 2011 05:23:10 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 7B9AE3A67DA for ; Sun, 3 Apr 2011 05:23:09 -0700 (PDT) Received: by eye13 with SMTP id 13so1672902eye.31 for ; Sun, 03 Apr 2011 05:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rHAC0MfhDT51csizIls2b3/ClIclxjy5Ey7Jw6BpBR0=; b=QMYumP1oluGAw3OQr/ExjrtxgqZnVB0F5tizxtnCIq+Dwm+Fc9Iv65MvYb4xssNXoF Ia97H0cj3pV58tAC5fXzYOf4F0uwLfJZqkxaF0T0HP2PP+7HI2rShHHTn3YUQLK6Jau3 ZyrpcuCL/AYWCOE1eTNuLLgv2bEdKD+4W6ipM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=esXv87JZT8jmwJD47QSuRQTcvAhek7iNpqGWCkkL3zaaMTAHIN84HwKuLxELB6Ja85 HBg5Uw+IhN+aNBRwjqE5zSjphJKNBf1gBJBeswqM7JigXxriXtR2rWyX8pI5Oe3C7Llp 4gFt/0/v4EbTtzVHkS0y1LZ+C2ZmQqlIYa9F0= MIME-Version: 1.0 Received: by 10.213.34.209 with SMTP id m17mr3124780ebd.3.1301833474444; Sun, 03 Apr 2011 05:24:34 -0700 (PDT) Received: by 10.213.17.17 with HTTP; Sun, 3 Apr 2011 05:24:34 -0700 (PDT) In-Reply-To: References: Date: Sun, 3 Apr 2011 14:24:34 +0200 Message-ID: From: Vaughn Deluca To: Morgaine Content-Type: multipart/alternative; boundary=0015174c177ccd100004a002b99c Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 03 Apr 2011 12:23:16 -0000 --0015174c177ccd100004a002b99c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Morgaine, I will put my comments inline for clarity >The detail is probably a bit different to how you described it, >because region and agent policy scopes are separate, ie. the >agent service doesn't have a role in determining region policy, it >just provides an agent. Hmmm, i certainly did not want to imply that the agent service was determining region policy! All I tried to say was that the agent service requests to place an agent in the region, and informs the region about the assets it wants to bring. >Since asset services are entirely concerned with region functions alone, >this puts them out of scope for the agent service, at least according to >the last set of list discussions we had on the topic. I might have gotten this wrong but in my view the the Agent service handles the all things related to the agent, and that would surely include the *references* to attachments like dresses? If the user wants to visit some region, she asks her agent service to place the avatar in that region? >I expect it's the client that you need to consult for its current list of asset services, > because it keeps tally as it encounters new ones in its travels. Hmm, no, that is not what i had in mind... I expect the agent service keep= s track of the assets currently in use by the agent, i.e. a list of reference= s to data in asset services. >The agent service only supplies a seed cap to kick things off with an initial >asset service and inventory to hold the default avatar. This is legacy stuff >though, dating back from when there was >a single centralized asset store. > It needs reworking now that we've gone beyond that singleton.. We badly need some diagrams to illustrate our thinking. Is there anywhere something that depicts the high level flow of requests and responses? >This whole area of protocol design was never finalized because the Lab withdrew >while we were still discussing how the OGP model was going to support VW interop. > The OGP-based drafts became totally >out of date as soon as the requirements for >interop materialized, and we haven't recovered from that yet. >I agree with your call which echoed Kevin's earlier one, that we need to get on with this! >However, it doesn't start with a doc, but with an agree= d design concept, so that the first doc is >roughly in the right area! It depends on your definition of a doc, even your list below could be a doc if placed on the vwrap wiki. :) >This is a partial list of the requirements which I think need to be met: >Handle a dynamic set of asset services, one being the minimum > (and only usable in a walled garden), while the maximum is unlimited. OK >Never to disallow an agent from using its current agent credentials to travel to >another world (agent registration must not be confused with world policy)= . I do not get this. This is surely the choice of the agent service? If some agent service wants to prevent its agents to connect to some region fine, that their policy! And if i, as a user don't like that, i go and get me a service that fits my needs better. In the end i could use my own agent service running as part of my own client? I am assuming that there will be some mechanism to use an external identity provider if needed. >Let asset services determine asset distribution policy, and provide the means for > regions to query that policy (your consistency requirement). OK >Decide where the user state is held. If it's in the agent service then th= e agent >service must be agnostic to worlds and accept all travel requests. For sure the user state should be held by the agent service, that's what it= s designed for (i think?) and no, you can't control the agent's service policy! That fully and completely up to that service. The only requirement is that the service handles the defined protocol messages, but refusing to send a user to a certain world could be a key requirement for some services= . I am not at all in favour of this, but i am sure some people are; think of = a kids world, were you might want to prevent visits to the big bad virtual universe rife with sex, drugs and rock and roll. >If we cannot agree to make the agent service VW agnostic, then state will >have to be held in the client. Maybe i am naive, but my feeling is that *if* you would hold the agent stat= e in the client, that would be nothing else than integrating an agent service in the client? Or am i totally missing your meaning here? >Once we have a rough model of that in our minds, then we can: >Run through a few iterations of basic top-level pseudocode showing how the agent >service, asset services and clients handle the above split of responsibilities. >Write the first draft document reflecting the above. >Rinse and repeat. Yes! --Vaughn On Sun, Apr 3, 2011 at 12:07 PM, Morgaine w= rote: > Great to hear that we're on the same page, Vaughn! > > The detail is probably a bit different to how you described it, because > region and agent policy scopes are separate, ie. the agent service doesn'= t > have a role in determining region policy, it just provides an agent. Sin= ce > asset services are entirely concerned with region functions alone, this p= uts > them out of scope for the agent service, at least according to the last s= et > of list discussions we had on the topic. > > I expect it's the client that you need to consult for its current list of > asset services, because it keeps tally as it encounters new ones in its > travels. The agent service only supplies a seed cap to kick things off w= ith > an initial asset service and inventory to hold the default avatar. This = is > legacy stuff though, dating back from when there was a single centralized > asset store. It needs reworking now that we've gone beyond that singleto= n.. > > This whole area of protocol design was never finalized because the Lab > withdrew while we were still discussing how the OGP model was going to > support VW interop. The OGP-based drafts became totally out of date as s= oon > as the requirements for interop materialized, and we haven't recovered fr= om > that yet. > > I agree with your call which echoed Kevin's earlier one, that we need to > get on with this! However, it doesn't start with a doc, but with an agre= ed > design concept, so that the first doc is roughly in the right area! > > This is a partial list of the requirements which I think need to be met: > > > - Handle a dynamic set of asset services, one being the minimum (and > only usable in a walled garden), while the maximum is unlimited. > - Never to disallow an agent from using its current agent credentials > to travel to another world (agent registration must not be confused wi= th > world policy). > - Let asset services determine asset distribution policy, and provide > the means for regions to query that policy (your consistency requireme= nt). > - Decide where the user state is held. If it's in the agent service > then the agent service must be agnostic to worlds and accept all trave= l > requests. If we cannot agree to make the agent service VW agnostic, t= hen > state will have to be held in the client. > > > Once we have a rough model of that in our minds, then we can: > > > - Run through a few iterations of basic top-level pseudocode showing > how the agent service, asset services and clients handle the above spl= it of > responsibilities. > - Write the first draft document reflecting the above. > - Rinse and repeat. > > > > Morgaine. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > On Sat, Apr 2, 2011 at 11:26 PM, Vaughn Deluca w= rote: > >> I wrote: >> >The region can now tells the agent service which of the assets agent >> service requested transfer the avatar can bring. >> >> I meant to say: >> >> The region can now tell the agent service which of the assets the agent >> service requested transfer for, can actually be transfered. >> >> (its late here...) >> >> On Sun, Apr 3, 2011 at 12:02 AM, Vaughn Deluca = wrote: >> >>> Morgain, all, >>> >>> Ahha!, i was halfway my reply explaining that i was *not* asking for th= e >>> impossible, and did *not* want to impose my rules on others, but that i= just >>> wanted to be able to know that stuff that i get into my region will be >>> visible to everybody present, and now i see that you got that. Good! >>> We are on the same page again :) >>> >>> The way the draft relating tot the tourist model is now written i can >>> *never* be sure my visitors all get the same data, because i just juggl= e the >>> crude physics representation, and the viewers negotiate about anything = else >>> with the asset service, fully out of my control. >>> >>> You formulated a solution (requesting the transfer rights explicitly). >>> I was originally thinking of a solution where the protocol specifies th= at >>> the capability to get the crude physics representation of the asset in = my >>> region would be *automatically* give me the right to download the full = asset >>> (if I asked for that). After reading your replies i now see that reque= sting >>> the transfer rights, just like like the viewers will do, is a better >>> solution. The same protocol messages could even be used, The region pre= sent >>> its credentials and either gets the capability or not. The region can = now >>> tells the agent service which of the assets agent service requested tra= nsfer >>> the avatar can bring. Its up to the viewer to deal with that informatio= n, it >>> might simply ignore it. In the latter case the avatar will be simulated= by >>> the region without the offending asset. The asset service will subseque= ntly >>> get requests from all viewers connected to the region for the assets in= the >>> region. Some of those might not pass trust checks of the asset service.= Bad >>> luck for the asset service, it has given a capability to the region and= the >>> region will use that to get the asset. If the asset service has second >>> thoughts to often - causing download costs and lag, it will eventually = end >>> up on the black list of the region service, and next time around the re= gion >>> might tell the agent service it can't allow asset Y from servivce X be= casue >>> it does not trust assert service X. >>> It all sounds logical and transparent to me. >>> >>> It also fits what meadhbh said: >>> >my recommendation has always been... "define mechanism, not policy." >>> As far as i can see that is what we do here. >>> >>> Now, this brings me to a point of order. In september Kevin Tweedy made >>> this observation: >>> >>> " >>> Date: Wed, 22 Sep 2010 13:40:15 -0400 >>> May I suggest we stop arbitrarily trying to define things in emails and >>> come up with some kind of process into how to define what the first dra= ft >>> specification should include? Doesn=92t W3C have a process on how this= works? >>> I think this is the fundamental problem of this group; we are mixing >>> vision, requirements, and design in the same email. We are making desi= gn >>> decisions when we haven=92t even defined the requirements." >>> >>> I fully agree. We used to brainstorm in the group and assumed the edito= rs >>> of the drafts would incorporate the generated ideas in new versions of = the >>> draft. At times that worked really well, at other times it did work no= t so >>> well. But currently we have no editors, so we need to do something new.= ... >>> >>> My question to the group is how do we consolidate this bit of >>> discussion? >>> >>> In general it seems to me we have managed to generate new enthusiasm in >>> the group, and we are on -or close to- the point were we have enough >>> critical mass to continue. In my view we would really benefit from a tr= ue >>> editor, and it seems nobody is willing to take that responsibility yet.= Can >>> we really do it collectively on the wiki? It would be a break with the = way i >>> think ietf groups normally work, but i might be kind off fitting for t= his >>> highly diverse group :) >>> >>> So will it work? What alternatives do we have? comments please. >>> >>> --Vaughn >>> >>> On Sat, Apr 2, 2011 at 5:09 PM, Morgaine >> > wrote: >>> >>>> Vaughn, I left your final (and very important) point for the end of my >>>> response, and then I fired off my email without addressing it ... Sor= ry. :P >>>> >>>> >>>> On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca >>> > wrote: >>>> >>>>> So I want methods to prevent breaking my highly emergent world as mu= ch >>>>> as possible. >>>>> >>>> >>>> >>>> Yes indeed!!! >>>> >>>> You have a perfectly reasonable requirement for the service that you >>>> want to operate, and you need some means of meeting it. I agree with = that >>>> wholeheartedly. I only begin to disagree when you hint that your >>>> requirement must be imposed on everyone, whether they want it or not. = That >>>> I cannot support, and I expect that you did not mean it that way anywa= y. >>>> After all, some of my requirements are probably not of interest to you >>>> either, and you would not wish me to impose them on you. It cuts both= ways. >>>> >>>> So, how can we enable you to offer a service with many 9's of simulati= on >>>> consistency, without imposing that requirement on those who prefer a >>>> different trade-off? You hinted at the solution yourself, so I'll mer= ely >>>> elaborate on it. You wrote: >>>> >>>> >>>> >>>> I would like to argue that the region *should* get the capability to >>>>> fetch all details. [...] Note that this does not mean that the regio= n *has* >>>>> to proxy the asset, just that in case the asset service refuses to se= rve a >>>>> client it does not like, the region can insist on delivery based on = the >>>>> capability it originally got. >>>>> >>>> >>>> >>>> >>>> Perfect. All you need then is an optional query in the protocol that >>>> allows a region to ask each asset service referenced by assets carried= by >>>> newly arriving avatars the following question: >>>> >>>> QUERY: "*Do I have your permission to fetch from your asset service th= e >>>> assets normally reserved for client fetches, and to distribute these a= ssets >>>> to clients directly in the (unexpected) event that I want to?*" >>>> >>>> >>>> That easily maps to an optional capability request of course. If the >>>> asset service answers "No" to you, then you can deny the incoming avat= ar >>>> entry to your region, returning a status that indicates >>>> >>>> RESPONSE: "*Asset service X referenced by asset Y does not meet the >>>> re-distribution requirement requested for entry to region Z*". >>>> >>>> >>>> Your requirement is then satisfied (I believe) without imposing that >>>> requirement on a region operator who does not need it because they des= ire a >>>> different trade-off. Those who don't have your requirement simply won= 't >>>> request the capability. >>>> >>>> For example, it would be pointless to even ask an asset service founde= d >>>> entirely around Creative Commons assets that question, since all CC co= ntent >>>> is perpetually and non-revocably redistributable by anyone and to anyo= ne. >>>> By not issuing the query we can save ourselves the round-trip time and= allow >>>> faster entry to the region. >>>> >>>> Would something like that get the nod from you? >>>> >>>> >>>> PS. You need to note that when an asset service answers "Yes" to your >>>> query, this does not mean that it will necessarily honor its promise w= hen >>>> you actually attempt to fetch items. David's very important point abo= ut >>>> independent parties not having control over each other applies here. = You >>>> can at most hope that it will behave well, and perhaps test the promis= e by >>>> fetching something. However, if you truly want as many 9's of consist= ency >>>> as is obtainable then you will have to fetch all the assets yourself p= rior >>>> to allowing entry to the avatar, and that would be a dreadful overhead= . >>>> Most people will probably settle for "*best effort*" approaches, which >>>> are quite likely to succeed. >>>> >>>> >>>> Morgaine. >>>> >>>> >>>> >>>> >>>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> >>>> On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca >>> > wrote: >>>> >>>>> Morgaine, Meadhbh, >>>>> >>>>> Thanks for the answers, but i see that i have not been clear enough. >>>>> I think the protocol should demand certain things to prevent the >>>>> deterioration of the simulation to an unacceptable level. We need to= be >>>>> more precise to prevent problems and i think we can. >>>>> >>>>> I was arguing from the perspecive of a region service without making >>>>> that explicit. Note i was *not* advocating the region proxies everyth= ing, >>>>> just that it lives up to its promises about object presence. Also not= e that >>>>> i do *not* always have the option to pick another high quality asset >>>>> service, since I normally do not own the assets. I will use Prokofy a= s an >>>>> example just for the fun of it. He is highly worried about content t= heft, >>>>> so (in the unlikely case he wants to start selling stuff outside of S= L) he >>>>> might use this deployment pattern. Assume he sells wonderful sexy dr= esses >>>>> to two customers, that can only be fetched from his own asset service= for >>>>> rendering. Both customers go off to "Vaughns highly immersive world" = were a >>>>> party is given. My region receives some physics properties of the dr= esses >>>>> for simulation and an address of Proks asset service for high-res det= ails >>>>> and textures. In this case the region does not even get the capabilit= y to >>>>> fetch the assets, just a link to the asset service and its up to view= er to >>>>> request the details and show credentials to get them. The two girls m= eet, >>>>> both their viewers request the details of the other dress, and Proks = asset >>>>> service grants those requests. They girls admire their dresses and >>>>> compliment each other with their good taste. Now when i arrive and my= viewer >>>>> request the dress details, Prok's asset service recognises me as the >>>>> copyleftists that i am. It refuses to serve the asset details -and de= pending >>>>> on my viewers behaviour i might get to view two girls in sexy underwe= ar -or >>>>> wearing even less- instead of party dresses. From a consistency point= of >>>>> view this is a highly undesirable situation, it breaks immersion, and >>>>> depending on the circumstances might also be embarrassing to the peop= le >>>>> involved. >>>>> >>>>> The key question is if we want to allow this situation to arise withi= n >>>>> VWRAP compliant worlds. >>>>> I would like to argue that the region *should* get the capability to >>>>> fetch all details. In other words, Prokofy would have to give up some >>>>> control over the asset in case he allows it to be used by my region. = Note >>>>> that this does not mean that the region *has* to proxy the asset, jus= t that >>>>> in case the asset service refuses to serve a client it does not like,= the >>>>> region can insist on delivery based on the capability it originally = got. If >>>>> that fails Proks asset service can not be called VWRAP compliant. >>>>> >>>>> If Prokofy does not want to relinquish that level of control, fine, = it >>>>> is his right not to, but in that case the dresses should not be allow= ed to >>>>> get into my region in the first place. If people visit my region and= find >>>>> themselves naked in the eyes of some others *I* will get the blame. = As >>>>> Morgaine says, the technical details of my innocence will not convinc= e the >>>>> general public. So I want methods to prevent breaking my highly emerg= ent >>>>> world as much as possible. >>>>> My proposal would be that the whatever the region gets MUST be >>>>> guaranteed by protocol to be delivered to anybody within the region >>>>> requesting it. If the asset service does not want to serve a cryptoco= munist >>>>> copyleftist, fine, but IF it has given the region a capability, it MU= ST >>>>> serve the full asset to be VWRAP compliant. Its *my* choice as a regi= on >>>>> deployer to download the full asset to be able to guarantee region >>>>> consistency if I want to. I will try to avoid that as much as possibl= e, but >>>>> if my customers complain, i will be forces to start doing this for ce= rtain >>>>> asset services that i know show discriminatory behaviour against for >>>>> instance copyleftist. >>>>> >>>>> Finally Morgaine, you keep hammering on the fact that proxying by the >>>>> region does not scale. (I tend to disagree, but that is beside the po= int >>>>> here). I do agree the asset should not be needlessly transfered, but = i >>>>> strongly feel we must insist in the protocol on transferring the *rig= hts* to >>>>> view the asset. If that leads to to the region not getting the asset = at all, >>>>> so be it, it can warn visitors that their assets will not be visible = and >>>>> even offer to serve simple replacements (1). This in turn will encour= age the >>>>> end users to avoid this type of asset service, and Prokofy will go ou= t of >>>>> business, as should be the case given the behaviour of the service. A= nd if >>>>> he pulls it off, thats fine with me also, as long as i do not have to= suffer >>>>> from it due to lack of rigour in the protocol specs. >>>>> >>>>> So, in summary, I very well see that there is no way to enforce >>>>> consistent serving behaviour but it should at least be clear that it = is >>>>> non-standard and not conform the protocol. The way I am understanding= you >>>>> now, your argument seems to be just one step to far in the direction = of >>>>> anarchy. >>>>> Or am i misreading you? >>>>> >>>>> --Vaughn >>>>> >>>>> >>>>> (1) I just realise that the region might cheat and advertise its own >>>>> asset brands claiming the competitions assets could not be rendered.= .. Oh >>>>> well, one might hope that if there is enough choice in worlds such re= gions >>>>> will be forced out of business as well. >>>>> >>>>> On Sat, Apr 2, 2011 at 7:31 AM, Morgaine < >>>>> morgaine.dinova@googlemail.com> wrote: >>>>> >>>>>> Further to my last post, it's worth noting that if you find that you >>>>>> suffer poor quality behavior from a particular asset service and it = is >>>>>> breaking the consistency of your simulation, with hash-based item ad= dressing >>>>>> you can also automatically use an alternative asset service *in >>>>>> preference* to the one specified in a given URI. >>>>>> >>>>>> Your client could be configured to attempt the item fetch at a known >>>>>> good quality asset service *first* (perhaps one that you paid to use >>>>>> because of its better service), automatically, and maybe even dynami= cally >>>>>> depending on the type of item. >>>>>> >>>>>> The scheme has a long list of benefits, and overcoming (to some >>>>>> extent) poor quality asset services is just one of them. >>>>>> >>>>>> >>>>>> Morgaine. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> >>>>>> >>>>>> On Sat, Apr 2, 2011 at 4:55 AM, Morgaine < >>>>>> morgaine.dinova@googlemail.com> wrote: >>>>>> >>>>>>> Every design choice results in a trade-off, Vaughn, improving one >>>>>>> thing at the expense of something else. If every time we offered a= service >>>>>>> we had to inform its users about the downsides of all the trade-off= s we have >>>>>>> made, they would have an awful lot to read. ;-) >>>>>>> >>>>>>> The specific trade-off that you are discussing is no different. A >>>>>>> region that proxies all content has the "benefit" of acquiring cont= rol from >>>>>>> the asset servers over the items in the region, so that it can ensu= re that >>>>>>> everyone in the region not only obtains the items but obtains the * >>>>>>> same* items as everyone else. That does indeed provide a greater >>>>>>> guarantee of consistency than a deployment in which the region only= passes >>>>>>> asset URIs to clients who then fetch the items from asset services >>>>>>> separately. As always though, it's a trade-off, since the proxied = design >>>>>>> has very poor scalability compared to the distributed one. >>>>>>> >>>>>>> If we're going to warn users of the potential for inconsistency in >>>>>>> the distributed deployment as you suggest, are we also going to war= n them of >>>>>>> non-scalability in the proxied one? I really don't see much merit = in the >>>>>>> idea of warning about design choices. Many such choices are techni= cal, and >>>>>>> the issues are quite likely to be of little interest to non-technic= al users >>>>>>> anyway. In any case, the better services are likely to provide suc= h >>>>>>> information in their online documentation, I would guess. >>>>>>> >>>>>>> You mentioned users "voting with their feet" or choosing to accept >>>>>>> the risk of inconsistency. Well that will happen anyway, when serv= ices fail >>>>>>> and users get annoyed. If some asset services refuse to send the r= equested >>>>>>> items to some users, those services will get a bad reputation and p= eople >>>>>>> will choose different asset services instead. Likewise, if a world= service >>>>>>> proxies everything and so it can't handle a large number of assets = or of >>>>>>> people, users will get annoyed at the lag and will go elsewhere. T= his user >>>>>>> evaluation and "voting with their feet" happens already with online= services >>>>>>> all over the Internet, and I am sure that this human process will c= ontinue >>>>>>> to work when the services are asset and region services. >>>>>>> >>>>>>> Back in September 2010, I wrote this post which proposes that we us= e >>>>>>> in VWRAP a form of asset addressing that provides massive scalabili= ty at the >>>>>>> same time as a very high degree of resilience -- >>>>>>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html . >>>>>>> It is based on the concept of the URI containing a host part and a = hash >>>>>>> part, where the hash is generated (once, at the time of storage to = the asset >>>>>>> service) using a specified digest algorithm over the content of the= asset >>>>>>> being referenced. You may wish to note that if this design were us= ed, the >>>>>>> failure of an asset service to deliver a requested item would resul= t in a >>>>>>> failover request for the item to one or more backup services, using= the same >>>>>>> hash part but with a different host address. >>>>>>> >>>>>>> This can go some way towards overcoming the problem that you think >>>>>>> might occur when assets are fetched by clients from asset services >>>>>>> directly. Although it won't help when the missing item is availabl= e from >>>>>>> only a single asset service, it will help in many other cases, and = it will >>>>>>> compensate for service failures and network outages automatically a= t the >>>>>>> same time. >>>>>>> >>>>>>> PS. This design for hash-based asset addressing is already being >>>>>>> tested by Mojito Sorbet in her experimental world and client. It w= ould give >>>>>>> VWRAP-based worlds an improved level of service availability, so I = think it >>>>>>> should be a core feature of our protocol. >>>>>>> >>>>>>> >>>>>>> Morgaine. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>>>> >>>>>>> >>>>>>> On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca < >>>>>>> vaughn.deluca@gmail.com> wrote: >>>>>>> >>>>>>>> This is a question i discussed with Morgaine off-list a while ago = (I >>>>>>>> intended to send it to the list but pushed the wrong button...) I >>>>>>>> think we need to address this problem, and decide how to deal with >>>>>>>> it. >>>>>>>> >>>>>>>> In Davids deployment draft, section 7.3.1.1 an overview is given >>>>>>>> van >>>>>>>> ways to deliver content to the region. One way is only passing a >>>>>>>> capability that allows access to (part of) the resource: >>>>>>>> >>>>>>>> 7.3.1.1. Content delivery models >>>>>>>> A range of possible represenations can be passed to a >>>>>>>> region for >>>>>>>> simulation. [...] The other end of the delivery spectrum >>>>>>>> involves passing >>>>>>>> only a URI or capability used to access the rendering >>>>>>>> information and a >>>>>>>> collision mesh,and related data for physical simulation. >>>>>>>> In such a model, the client is responsible for fetching >>>>>>>> the additional >>>>>>>> information needed to render the item's visual presence >>>>>>>> from a separate >>>>>>>> service. This fetch can be done *under the credentials = of >>>>>>>> the end user* >>>>>>>> viewing the material [my emphasis--VD] , and divorces th= e >>>>>>>> simulation from >>>>>>>> the trust chain needed to manage content. Any automatio= n >>>>>>>> is done on a >>>>>>>> separate host which the content creator or owner trusts, >>>>>>>> interacting with the >>>>>>>> object through remoted interfaces. >>>>>>>> >>>>>>>> I can see the need for such a setup, however, i feel we are >>>>>>>> unpleasantly close to a situation were the coherence of the >>>>>>>> simulation >>>>>>>> falls apart. >>>>>>>> In this deployment pattern the region advertises the presence of t= he >>>>>>>> asset, and *some* clients will be able to get it as expected, whil= e >>>>>>>> -based on the arbitrary whims of the asset service- others might >>>>>>>> not. >>>>>>>> >>>>>>>> My hope would be that after the asset server provides the region >>>>>>>> with >>>>>>>> the capability to get the asset, it gives up control. That would >>>>>>>> mean >>>>>>>> that if the client finds the inventory server is unwilling to serv= e >>>>>>>> the content - in spire of the region saying it is present-, the >>>>>>>> client >>>>>>>> should be able to turn around ask the *region* for the asset, (and >>>>>>>> get >>>>>>>> is after all). >>>>>>>> >>>>>>>> If that is not the case, -and there are probably good reasons for >>>>>>>> the >>>>>>>> deployment pattern as described- shouldn't we *warn* clients that >>>>>>>> the >>>>>>>> region might be inconsistent, so the users behind the client can >>>>>>>> vote >>>>>>>> with their feet, (or take the risk)? >>>>>>>> >>>>>>>> --Vaughn >>>>>>>> _______________________________________________ >>>>>>>> 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 >> >> > --0015174c177ccd100004a002b99c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Morgaine,

I will put my comments inline for clarity

>The detail is probably a bit different to how= you described it,=A0
>because region and agent policy=A0scope= s are separate, ie. the=A0
>agent=A0service doesn't have a role in determining region poli= cy, it=A0
>just provides an agent. =A0

Hmmm, i certainly did not want to imply that the agent service was determ= ining region policy! All I tried to say was that the agent service requests= to place an agent in the region, and informs the region about the assets i= t wants to bring.

>Since asset services are entirely concerned with re= gion functions alone,=A0
>this puts them out of scope for the = agent service, at least according to=A0
>the last set of list = discussions we had on the topic.

I might have gotten this wrong but in my view the the A= gent service handles the all things related to the agent, and that would = =A0surely include the *references* to attachments like dresses? =A0 If the = user wants to visit some region, she =A0asks her agent service to place the= avatar in that region? =A0

>I expect it's the client that you need to consu= lt for its current list of asset services,=A0
> because it kee= ps tally as it encounters new ones in its travels.

Hmm, no, that is not what i had in =A0mind... I expect the agent service ke= eps track of the assets currently in use by the agent, i.e. a list of refer= ences to data in asset services.

>The agent ser= vice only supplies a seed cap to kick things off with an initial=A0
>asset=A0service and inventory to hold the default avatar. =A0This = is legacy stuff
>though, dating=A0back from when there was >= ;a single centralized asset store.=A0
> It needs reworking now= =A0that we've gone beyond that singleton..

We badly need some diagrams to illustrate our thinking.= Is there anywhere something that depicts the high level flow of requests a= nd responses?

>This whole area of protocol desi= gn was never finalized because the Lab withdrew
>while we were still discussing how the OGP model was going to supp= ort VW interop.
> The OGP-based drafts became totally >out = of date as soon as the requirements for
>interop materiali= zed, and we haven't recovered from that yet.

>I agree with your call which echoed Kevin's ear= lier one, that we need to get on with this! =A0>However, it doesn't = start with a doc, but with an agreed design concept, so that the first doc = is >roughly in the right area!

It depends on your definition of a doc, even your list = below could be a doc if placed on the vwrap wiki. =A0 :)

>This is a partial list of the requirements which I think need to= be met:

>Handle a dynamic set of asset services, one being t= he minimum
> (and only usable in a walled garden), while the m= aximum is unlimited.

OK

>Never to disallow an agent from using its current agent credentials to = travel to=A0
>another world =A0(agent registration must not be= confused with world policy).

I do not get this. T= his is surely the choice of the agent service? If some agent service wants = to prevent its agents to connect to some region fine, that their policy! = =A0And if i, as a user =A0don't like that, i go and get me a service th= at fits my needs better. In the end i could use my own agent service runnin= g as part of my own client? I am assuming that there will be some mechanism= to use an external identity provider if needed.

>Let asset services determine asset distribution pol= icy, and provide the means for
> regions to query that policy = (your consistency requirement).

OK

>Decide where the user state is held. =A0If it's in the a= gent service then the agent=A0
>service must be agnostic to wo= rlds and accept all travel requests.

For sure the = user state should be held by the agent service, that's what its designe= d for (i think?) and no, you can't control the agent's =A0service p= olicy! That fully and completely up to that service. The only requirement i= s that the service handles the defined protocol messages, but refusing to s= end a user to a certain world could be a key requirement for some services.= I am not at all in favour of this, but i am sure some people are; think of= a kids world, were you might want to prevent visits to the big bad virtual= universe rife with sex, drugs and rock and roll.

>If we cannot agree to make the agent service VW agn= ostic, then state will=A0
>have to be held in the client.

Maybe i am naive, but my feeling is that *if* you woul= d hold the agent state in the client, that would be nothing else than integ= rating an agent service in the client? Or am i totally missing your meaning= here?

>Once we have a rough model of that in our minds, th= en we can:

>Run through a few iterations of bas= ic top-level pseudocode showing how the agent=A0
>service, ass= et services and clients handle the above split of responsibilities.
>Write the first draft document reflecting the above.
>Rinse and repeat.

Yes!

--Vaughn



On Sun, Apr 3, 2011 at 12:07 PM, Morgaine <morgaine.dinova@googlemail.com&g= t; wrote:
Great to hear that we're on the same page, Vaughn!

The detail is= probably a bit different to how you described it, because region and agent= policy scopes are separate, ie. the agent service doesn't have a role = in determining region policy, it just provides an agent.=A0 Since asset ser= vices are entirely concerned with region functions alone, this puts them ou= t of scope for the agent service, at least according to the last set of lis= t discussions we had on the topic.

I expect it's the client that you need to consult for its current l= ist of asset services, because it keeps tally as it encounters new ones in = its travels.=A0 The agent service only supplies a seed cap to kick things o= ff with an initial asset service and inventory to hold the default avatar.= =A0 This is legacy stuff though, dating back from when there was a single c= entralized asset store.=A0 It needs reworking now that we've gone beyon= d that singleton..

This whole area of protocol design was never finalized because the Lab = withdrew while we were still discussing how the OGP model was going to supp= ort VW interop.=A0 The OGP-based drafts became totally out of date as soon = as the requirements for interop materialized, and we haven't recovered = from that yet.

I agree with your call which echoed Kevin's earlier one, that we ne= ed to get on with this!=A0 However, it doesn't start with a doc, but wi= th an agreed design concept, so that the first doc is roughly in the right = area!

This is a partial list of the requirements which I think need to be met= :

  • Handle a dynamic set of asset services, one being the mini= mum (and only usable in a walled garden), while the maximum is unlimited.
  • Never to disallow an agent from using its current agent credentials to = travel to another world (agent registration must not be confused with world= policy).
  • Let asset services determine asset distribution polic= y, and provide the means for regions to query that policy (your consistency= requirement).
  • Decide where the user state is held.=A0 If it's in the agent servic= e then the agent service must be agnostic to worlds and accept all travel r= equests.=A0 If we cannot agree to make the agent service VW agnostic, then = state will have to be held in the client.

Once we have a rough model of that in our minds, then we can:=

  • Run through a few iterations of basic top-level pseudocode = showing how the agent service, asset services and clients handle the above = split of responsibilities.
  • Write the first draft document reflecting the above.
  • Rinse and = repeat.


Morgaine.





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


On Sat, Apr 2, 2011 at 11:26 PM, Vaugh= n Deluca <vaughn.deluca@gmail.com> wrote:
I wrote:
>The region c= an now tells the agent service which of the assets agent service requested = transfer the avatar can bring.

I meant to= say:

=
The region can now tell= the agent service which of the assets the agent service requested transfer= for, can actually be transfered.

(its late here...)

<= div class=3D"gmail_quote">On Sun, Apr 3, 2011 at 12:02 AM, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
Morgain, all,

Ahha!, i was halfway my reply explaining that i was *n= ot* asking for the impossible, and did *not* want to impose my rules on oth= ers, but that i just wanted to be able to know that stuff that i get into m= y region will be visible to everybody present, and now i see that you got t= hat. Good!
We are on the same page again :)

The way the = draft relating tot the tourist model is now written i can *never* be sure m= y visitors all get the same data, because i just juggle the crude physics r= epresentation, and the viewers negotiate about anything else with the asset= service, fully out of my control.=A0

You formulated a solution (requesting the transfer righ= ts explicitly). =A0
I was originally thinking of a solution where= the protocol specifies that the capability to get the crude physics repres= entation of the asset in my region would be *automatically* give me the rig= ht to download the full asset (if I asked for that). =A0After reading your = replies i now see that requesting the transfer rights, just like like the v= iewers will do, is a better solution. The same protocol messages could even= be used, The region present its credentials and either gets the capability= or not. =A0The region can now tells the agent service which of the assets = agent service requested transfer the avatar can bring. Its up to the viewer= to deal with that information, it might simply ignore it. In the latter ca= se the avatar will be simulated by the region without the offending asset. = The asset service will subsequently get requests from all viewers connected= to the region for the assets in the region. Some of those might not pass t= rust checks of the asset service. Bad luck for the asset service, it has gi= ven a capability to the region and the region will use that to get the asse= t. If the asset service has second thoughts to often - causing download cos= ts and lag, it will eventually end up on the black list of the region servi= ce, and next time around the region =A0might tell the agent service it can&= #39;t allow asset Y from servivce X becasue it does not trust assert servic= e X. =A0
It all sounds logical and transparent to me.

=
It also fits what meadhbh said:
>my recommendation has al= ways been... "define mechanism, not policy."
As far as i can see that is what we do here.

Now, this brings me to a point of order. In september K= evin Tweedy made this observation:

"<kevin= .tweedy at xrgrid.com&g= t;
Date: Wed, 22 Sep 2010 13:40:15 -0400
May I suggest we stop arbitrarily trying to define things in emails an= d come up with some kind of process into how to define what the first draft= specification should include? =A0Doesn=92t W3C have a process on how this = works? =A0I think this is the fundamental problem of this group; we are mix= ing vision, requirements, and design in the same email. =A0We are making de= sign decisions when we haven=92t even defined the requirements."

I fully agree. We used to brainstorm in the group and a= ssumed the editors of the drafts would incorporate the generated ideas in n= ew versions of the draft. =A0At times that worked really well, at other tim= es it did work not so well. But currently we have no editors, so we need to= do something new....

My question to the group is how do we consolidate this = bit of discussion?=A0

In general it seems to me we= have managed to generate new enthusiasm in the group, and we are on -or cl= ose to- the =A0point were we have enough critical mass to continue. In my v= iew we would really benefit from a true editor, and it seems nobody is will= ing to take that responsibility yet. Can we really do it collectively on th= e wiki? It would be a break with the way i think ietf groups normally work,= but i might be =A0kind off fitting for this highly diverse group =A0:)

So will it work? What alternatives do we have? =A0comme= nts please.

--Vaughn
=

On Sat, Apr 2, 2= 011 at 5:09 PM, Morgaine <morgaine.dinova@googlemail.com&= gt; wrote:
Vaughn, I left your fin= al (and very important) point for the end of my response, and then I fired = off my email without addressing it ...=A0 Sorry. :P


On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca &l= t;vaughn.deluc= a@gmail.com> wrote:
=A0So I want metho= ds=20 to prevent breaking my highly emergent world as much as possible.


Yes indeed!!!

You have a perfectly reaso= nable requirement for the service that you want to operate, and you need so= me means of meeting it.=A0 I agree with that wholeheartedly.=A0 I only begi= n to disagree when you hint that your requirement must be imposed on everyo= ne, whether they want it or not.=A0 That I cannot support, and I expect tha= t you did not mean it that way anyway.=A0 After all, some of my requirement= s are probably not of interest to you either, and you would not wish me to = impose them on you.=A0 It cuts both ways.

So, how can we enable you to offer a service with many 9's of simul= ation consistency, without imposing that requirement on those who prefer a = different trade-off?=A0 You hinted at the solution yourself, so I'll me= rely elaborate on it.=A0 You wrote:



I would like to argue that the region *should* get the capability to=20 fetch all details. [...]=A0=20 Note that this does not mean that the region *has* to proxy the asset,=20 just that in case the asset service refuses to serve a client it does=20 not like, the region can insist on delivery =A0based on the capability it= =20 originally got.



Perfect.=A0 All you need then= is an optional query in the protocol that allows a region to ask each asse= t service referenced by assets carried by newly arriving avatars the follow= ing question:

QUERY: "Do I have your permissi= on to fetch from your asset service the assets normally reserved for client= fetches, and to distribute these assets to clients directly in the (unexpe= cted) event that I want to?"


That easily maps to an optional capability request of course.= =A0 If the asset service answers "No" to you, then you can deny t= he incoming avatar entry to your region, returning a status that indicates<= br>
RESPONSE: "Asset service X refe= renced by asset Y does not meet the re-distribution requirement requested f= or entry to region Z".


Your requirement is then s= atisfied (I believe) without imposing that requirement on a region operator= who does not need it because they desire a different trade-off.=A0 Those w= ho don't have your requirement simply won't request the capability.=

For example, it would be pointless to even ask an asset service founded= entirely around Creative Commons assets that question, since all CC conten= t is perpetually and non-revocably redistributable by anyone and to anyone.= =A0 By not issuing the query we can save ourselves the round-trip time and = allow faster entry to the region.

Would something like that get the nod from you?


PS. You need= to note that when an asset service answers "Yes" to your query, = this does not mean that it will necessarily honor its promise when you actu= ally attempt to fetch items.=A0 David's very important point about inde= pendent parties not having control over each other applies here.=A0 You can= at most hope that it will behave well, and perhaps test the promise by fet= ching something.=A0 However, if you truly want as many 9's of consisten= cy as is obtainable then you will have to fetch all the assets yourself pri= or to allowing entry to the avatar, and that would be a dreadful overhead.= =A0 Most people will probably settle for "best effort" app= roaches, which are quite likely to succeed.


Morgaine.





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


On Sat, Apr 2, 2011 at 11:26 AM, Vaughn Deluca <v= aughn.deluca@gmail.com> wrote:
Morgaine, Meadhbh,=

Thanks for the answers, but i see that i have not= been clear enough.
I think the protocol should demand certain things to prevent the =A0de= terioration of the simulation to an unacceptable level. We need to be more = precise to prevent problems and i think we can.

I was arguing from the perspecive of a region service w= ithout making that explicit. Note i was *not* advocating the region proxies= everything, just that it lives up to its promises about object presence. A= lso note that i do =A0*not* always have the option to pick another high qua= lity asset service, since I normally do not own the assets. I will use Prok= ofy as an example just for the fun of it. =A0He is highly worried about con= tent theft, so (in the unlikely case he wants to start selling stuff outsid= e of SL) he might use this deployment pattern. =A0Assume he sells wonderful= sexy dresses to two customers, that can only be fetched from his own asset= service for rendering. Both customers go off to "Vaughns highly immer= sive world" were a party is given. =A0My region receives some physics = properties of the dresses for simulation and an address of Proks asset serv= ice for high-res details and textures. In this case the region does not eve= n get the capability to fetch the assets, just a link to the asset service = and its up to viewer to request the details and show credentials to get the= m. The two girls meet, both their viewers request the details of the other = dress, and Proks asset service grants those requests. They girls admire the= ir dresses and compliment each other with their good taste. Now when i arri= ve and my viewer request the dress details, Prok's asset service recogn= ises me as the copyleftists that i am. It refuses to serve the asset detail= s -and depending on my viewers behaviour i might get to view two girls in s= exy underwear -or wearing even less- instead of party dresses. From a consi= stency point of view this is a highly undesirable situation, it breaks imme= rsion, and depending on the circumstances might also be embarrassing to the= people involved.=A0

The key question is if we want to allow this situation = to arise within VWRAP compliant worlds.
I would like to argue tha= t the region *should* get the capability to fetch all details. In other wor= ds, Prokofy would have to give up some control over the asset in case he al= lows it to be used by my region. Note that this does not mean that the regi= on *has* to proxy the asset, just that in case the asset service refuses to= serve a client it does not like, the region can insist on delivery =A0base= d on the capability it originally got. If that fails Proks asset service ca= n not be called VWRAP compliant. =A0

If Prokofy does not want to relinquish =A0that level of= control, fine, it is his right not to, but in that case the dresses should= not be allowed to get into my region in the first place. =A0If people visi= t my region and find themselves naked in the eyes of some others *I* will g= et the blame. =A0As Morgaine says, the technical details of my innocence wi= ll not convince the general public. So I want methods to prevent breaking m= y highly emergent world as much as possible.=A0
My proposal would be that the whatever the region gets MUST be guarant= eed by protocol to be delivered to =A0anybody within the region requesting = it. If the asset service does not want to serve a cryptocomunist copyleftis= t, fine, but IF it has given the region a capability, it MUST serve the ful= l asset to be VWRAP compliant. Its *my* choice as a region deployer to down= load the full asset to be able to guarantee region consistency if I want to= . I will try to avoid that as much as possible, but if my customers complai= n, i will be forces to start doing this for certain asset services that i k= now show discriminatory behaviour against for instance copyleftist.=A0

Finally Morgaine, you keep hammering on the fact that p= roxying by the region does not scale. (I tend to disagree, but that is besi= de the point here). I do agree the asset should not be needlessly transfere= d, but i strongly feel we must insist in the protocol on transferring the *= rights* to view the asset. If that leads to to the region not getting the a= sset at all, so be it, it can warn visitors that their assets will not be v= isible and even offer to serve simple replacements (1). This in turn will e= ncourage the end users to avoid this type of asset service, and Prokofy wil= l go out of business, as should be the case given the behaviour of the serv= ice. And if he pulls it off, thats fine with me also, as long as i do not h= ave to suffer from it due to lack of rigour in the protocol specs. =A0

So, in summary, I very well see that there is no way to= enforce consistent serving behaviour but it should at least be clear that = it is non-standard and not conform the protocol. The way I am understanding= you now, your argument seems to be just one step to far in the direction o= f anarchy.
Or am i misreading you?

--Vaughn

(1) I just realise that the region might cheat = and advertise its own asset brands claiming the competitions assets =A0coul= d not be rendered... Oh well, one might hope that if there is enough choice= in worlds such regions will be forced =A0out of business as well.=A0

On Sat, Apr 2, 2011 at 7:31 AM, Morgaine <morgaine.dinova@googlemail.com> wrote:
Further to my last post, it's worth noting that if you find that you su= ffer poor quality behavior from a particular asset service and it is breaki= ng the consistency of your simulation, with hash-based item addressing you = can also automatically use an alternative asset service in preference= to the one specified in a given URI.

Your client could be configured to attempt the item fetch at a known go= od quality asset service first (perhaps one that you paid to use bec= ause of its better service), automatically, and maybe even dynamically depe= nding on the type of item.

The scheme has a long list of benefits, and overcoming (to some extent)= poor quality asset services is just one of them.


Morgaine.





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


On Sat, Apr 2, 2011 at 4:55 AM, Morgaine <morgaine.dinova@goo= glemail.com> wrote:
Every design choice results in a trade-off, Vaughn, improving one thing at = the expense of something else.=A0 If every time we offered a service we had= to inform its users about the downsides of all the trade-offs we have made= , they would have an awful lot to read. ;-)

The specific trade-off that you are discussing is no different.=A0 A re= gion that proxies all content has the "benefit" of acquiring cont= rol from the asset servers over the items in the region, so that it can ens= ure that everyone in the region not only obtains the items but obtains the = same items as everyone else.=A0 That does indeed provide a greater g= uarantee of consistency than a deployment in which the region only passes a= sset URIs to clients who then fetch the items from asset services separatel= y.=A0 As always though, it's a trade-off, since the proxied design has = very poor scalability compared to the distributed one.

If we're going to warn users of the potential for inconsistency in = the distributed deployment as you suggest, are we also going to warn them o= f non-scalability in the proxied one?=A0 I really don't see much merit = in the idea of warning about design choices.=A0 Many such choices are techn= ical, and the issues are quite likely to be of little interest to non-techn= ical users anyway.=A0 In any case, the better services are likely to provid= e such information in their online documentation, I would guess.

You mentioned users "voting with their feet" or choosing to a= ccept the risk of inconsistency.=A0 Well that will happen anyway, when serv= ices fail and users get annoyed.=A0 If some asset services refuse to send t= he requested items to some users, those services will get a bad reputation = and people will choose different asset services instead.=A0 Likewise, if a = world service proxies everything and so it can't handle a large number = of assets or of people, users will get annoyed at the lag and will go elsew= here.=A0 This user evaluation and "voting with their feet" happen= s already with online services all over the Internet, and I am sure that th= is human process will continue to work when the services are asset and regi= on services.

Back in September 2010, I wrote this post which proposes that we use in= VWRAP a form of asset addressing that provides massive scalability at the = same time as a very high degree of resilience -- http:/= /www.ietf.org/mail-archive/web/vwrap/current/msg00463.html .=A0 It is b= ased on the concept of the URI containing a host part and a hash part, wher= e the hash is generated (once, at the time of storage to the asset service)= using a specified digest algorithm over the content of the asset being ref= erenced.=A0 You may wish to note that if this design were used, the failure= of an asset service to deliver a requested item would result in a failover= request for the item to one or more backup services, using the same hash p= art but with a different host address.

This can go some way towards overcoming the problem that you think migh= t occur when assets are fetched by clients from asset services directly.=A0= Although it won't help when the missing item is available from only a = single asset service, it will help in many other cases, and it will compens= ate for service failures and network outages automatically at the same time= .

PS. This design for hash-based asset addressing is already being tested= by Mojito Sorbet in her experimental world and client.=A0 It would give VW= RAP-based worlds an improved level of service availability, so I think it s= hould be a core feature of our protocol.


Morgaine.




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

On Fri, Apr 1, 2011 at 11:17 PM, Vaughn De= luca <vaughn.deluca@gmail.com> wrote:
This is a question i di= scussed with Morgaine off-list a while ago (I
intended to send it to the list but pushed the wrong button...) I
think we need to address this problem, and decide how to deal with it.

=A0In Davids deployment draft, section 7.3.1.1 an overview is given van
ways to deliver content to the region. One way is only passing a
capability that allows access to (part of) the resource:

=A0 =A0 =A0 =A0 =A0 7.3.1.1. =A0Content delivery models
=A0 =A0 =A0 =A0 =A0 A range of possible represenations can be passed to a = region for
=A0 =A0 =A0 =A0 =A0 simulation. [...] The other end of the delivery spectr= um involves passing
=A0 =A0 =A0 =A0 =A0 only a URI or capability used to access the rendering<= br> information and a
=A0 =A0 =A0 =A0 =A0 collision mesh,and related data for physical simulatio= n.
=A0 =A0 =A0 =A0 =A0 In such a model, the client is responsible for fetchin= g the additional
=A0 =A0 =A0 =A0 =A0 information needed to render the item's visual pre= sence from a separate
=A0 =A0 =A0 =A0 =A0 service. =A0This fetch can be done *under the credenti= als of the end user*
=A0 =A0 =A0 =A0 =A0 viewing the material [my emphasis--VD] , and divorces = the
simulation from
=A0 =A0 =A0 =A0 =A0 the trust chain needed to manage content. =A0Any autom= ation
is done on a
=A0 =A0 =A0 =A0 =A0 separate host which the content creator or owner trust= s,
interacting with the
=A0 =A0 =A0 =A0 =A0 object through remoted interfaces.

=A0I can see the need for such a setup, however, i feel we are
unpleasantly close to a situation were the coherence of the simulation
falls apart.
In this deployment pattern the region advertises the presence of the
asset, and *some* clients will be able to get it as expected, while
-based on the arbitrary whims of the asset service- others might not.

My hope would be that after the asset server provides the region with
the capability to get the asset, it gives up control. That would mean
that if the client finds the inventory server is unwilling to serve
the content - in spire of the region saying it is present-, the client
should be able to turn around ask the *region* for the asset, (and get
is after all).

=A0If that is not the case, -and there are probably good reasons for the deployment pattern as described- =A0shouldn't we *warn* clients that th= e
region might be inconsistent, so the users behind the client can vote
with their feet, (or take the risk)?

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







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



--0015174c177ccd100004a002b99c-- From dzonatas@gmail.com Sun Apr 3 10:18:08 2011 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 4689B3A69C4 for ; Sun, 3 Apr 2011 10:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.238 X-Spam-Level: X-Spam-Status: No, score=-3.238 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] 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 UX4sAMTfslSi for ; Sun, 3 Apr 2011 10:18:06 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C5C403A684F for ; Sun, 3 Apr 2011 10:18:05 -0700 (PDT) Received: by iwn39 with SMTP id 39so5929158iwn.31 for ; Sun, 03 Apr 2011 10:19:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LgMvTRBY9kJ+oebyd2qLnp5znTlOMr2uGHLv3X2bSQI=; b=KwZtYw03//Gxzv5+5/KagA3vG73Dytz8BNaw4skDh7gr/RNIQyR56DtQgg7ZWvxahM hDx77sNGe7vciRL0zfhZlBdOWDwatSRzqlbJpm7KlevWnA2MG+MEU7RjdPUs6lyLX82n 6yFM0Tx/qMLdGaid/HF/wq/DlyKfuVBAvoCGI= 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=No1/vcAhC8c+XO3TlX1f9PXeAhfwgeO8/Vry5jb3O24q+KqW3ZKHoEED3QdQ2/qNsK d8dUhop0qplz99wvtRlKqyh1lBdcBhWN7qITsYxY9GTYVWOt8bbPvml/Q5nGqWbiWb8x CUEI2vO2+CRi5O/Wnm2spn+JhcavXF8l4+xL0= Received: by 10.42.149.7 with SMTP id t7mr2871858icv.449.1301851186654; Sun, 03 Apr 2011 10:19:46 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id 13sm3106296ibo.8.2011.04.03.10.19.43 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Apr 2011 10:19:45 -0700 (PDT) Message-ID: <4D98AC5F.70501@gmail.com> Date: Sun, 03 Apr 2011 10:20:31 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Vaughn Deluca References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 03 Apr 2011 17:18:08 -0000 Probably easy as suggested in other terms here on this list, as how the client contacts the asset services now in the regions. The newer issue is to unitize that asset services. Since their is proprietary (legacy) code then we can't expect that to change, and some form of proxy is of need. Whatever works best, I tried to narrow it down to suggestions here. Eventually, the agent domain is ideal to handle the direction of the asset services. This concept, unfortunately, ended support awhile ago with changes in LL. Also see; http://wiki.secondlife.com/wiki/Agent_Domain And: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset (warn: unstructured collaborative notes, dumped on me and I tried to fix) I tried to find previous visuals. I'd imagine the agent domain could grow out of unitized versions of asset services. Despite that, I think that concept helps view where we were at in discussion and what didn't happen. Vaughn Deluca wrote: > Hi�Dzonatas > > Can you expand on that, what would be needed for legacy support in > VWAP terms�?, > If i want to read up on how the�asset server may proxy the simulator, > what would you recommend me to read? > > -- Vaughn > > On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol > wrote: > > Some stated the proxy-to-asset-server is built into the sim; > however, keep in mind possible legacy support where the asset > server may proxy the simulator. > > > Dzonatas Sol wrote: > > Somehow I feel the basic asset server being able to login and > download assets is now priority, yet I also wondered the best > way to patch this into the current mode of viewers. > > Maybe offer (1) by proxy (sim-side) and (2) by patch > (viewer-side) that either of these two are optional and > neither are mandatory for now. Thoughts? > > Israel Alanis wrote: > > > > when designing for scalability, the model to bear in > mind is ... > > Well, there are a lot of different models to keep in mind, > and many different use cases. One particular use case to > keep in mind is: "User acquires new outfit, and wants to > 'show it off' in a highly populated region". > > > Both worlds and asset services may include commercial, > community, and personal services > > Yes, yes and yes. I'm particularly concerned about how the > model affects the ability to host personal asset services. > > > a proxying region, which would get slammed for every > asset worn by every avatar present. > > Granted the collection of services that are provided by > the region need to be scaled to meet the demands of that > region. That's all part of capacity planning. > > > regions run many different CPU-intensive tasks, > including physics simulation and server-side scripting, > and absolutely cannot afford to serve assets too > Well... who said the same CPU's have to do proxying, > physics simulation and server-side scripting? Asset > proxying is a different service than physics simulation > and can be on separate hardware, could make use of > geographically distributed caching, and in certain > deployment patterns, the same caching services could be > shared by different regions. (Server-side scripting is a > discussion for another day). > > > This is why we have to go parallel... > > Totally agree, and a proxying model could and should also > take advantage of parallelism. > > > I think you're wrong that it has to cost much money. ?vs? > > It costs money to host a high performance and scalable > asset service and a high bandwidth network to handle the > traffic. �A *lot* of money. > I think what you're saying is: "It costs a lot of money to > build a scalable asset service, but if assets are spread > throughout the internet they don't have to be scalable." > But that's not quite right. You're opening up every asset > server to the VW equivalent of being slashdotted, so are > you sure you're not forcing *every* asset service to be > scalable and handle a lot of bandwith and network traffic? > It's the exact opposite of your intention, but I think > that's the result, all the same. > > This particular design decision has a big effect on the > economics of the VW infrastructure. I'd rather the > economics to work out such that a region provider who > wishes to build a region that supports a small population, > can do so economically. A region that wants to host a > *large* population has to bear that cost of providing that > scalable asset service. > I want the economics of hosting a small asset service to > be a non-issue (as to best promote creation and > creativity). Creating a high bar to provide asset services > will mean that service will cost money and people > shouldn't have to pay money just to create or own VW > objects (I'm using 'own' here to refer to maintaining > their existence, I'm not trying to make a > 'leftist'/'communist' statement about ownership ;) > > - Izzy > > > On Apr 2, 2011, at 3:58 PM, Morgaine wrote: > > Izzy, when designing for scalability, the model to > bear in mind is that of seasoned virtual world > travelers whose inventories contain assets from many > different worlds, those assets being served by many > different asset services. �Both worlds and asset > services may include commercial, community, and > personal services, and as the metaverse grows, that > set is highly likely to become progressively less > clustered and more diverse. > > When those seasoned travelers click on an advertised > VW link and perform an inter-world teleport to one > particular world's region to share an experience, > their "worn" assets (the only ones of interest to the > region) will contain references to asset services > spread widely across the Internet. �The fetches by the > travelers' clients occur over many parallel paths from > clients to asset services, so one can reasonably > expect reduced network contention and reduced asset > server loading because they are both spread out over > however many asset services are being referenced by > the overall set of assets in the region. > > This is very different to the case of a proxying > region, which would get slammed for every asset worn > by every avatar present. �In our current architecture, > regions run many different CPU-intensive tasks, > including physics simulation and server-side > scripting, and absolutely cannot afford to serve > assets too unless your scalability requirements are > very low indeed, ie. just a few dozen avatars of > today's kind. �We've hit the ceiling already on region > scalability done that way. �There is nowhere to go in > that direction at all beyond improving the code like > Intel demonstrated, and that work is subject to a law > of diminishing returns. > > This is why we have to go parallel, and I think you're > wrong that it has to cost much money. �As we spread > the load across more and more asset services, we are > simply better utilizing all the hardware that's > already out there on the Internet, at least in respect > of community and private resources. �But add to the > community and private resources the commercial asset > services that are likely to appear to exploit this > opportunity, and not only will the number of asset > services leap, but the power of each one will rocket > too, because, after all, these businesses will be > heavily optimized for the job. > > As to why a world would want clients to access > external asset services instead of providing its own > implementation, that's an easy question. �It costs > money to host a high performance and scalable asset > service and a high bandwidth network to handle the > traffic. �A *lot* of money. �In contrast, it costs a > world nothing to let others serve the assets to > clients. �And that matters to the bottom line. > > > Morgaine. > > > > > ====================== > > On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis > > >> wrote: > > � �> As always though, it's a trade-off, since the > proxied design > � �has very poor scalability compared to the > distributed one. > > � �I don't agree with that... If a user enters a > highly populated > � �region, > � �every other client is going to (could and should be > trying to) > � �hit the > � �asset server(s) for the assets that the user is > wearing (assuming > � �they're not cached locally). �Every asset server > has to be scaled up > � �to the point that it can handle that load from all > over... > > � �If I'm hosting a region that supports 10s of > thousands of > � �simultaneous > � �users (thinking of the future), I already have to > scale to meet that > � �demand. If the region is proxying the assets, then, > yes the > � �region has > � �to be scaled to meet that asset demand too, but it > already has to be > � �scaled to meet other demands of being a region > server... and why is > � �scaling those asset proxy services hard? �It's > going to cost $, > � �but is > � �not technically challenging. So, if I want to host > a region like > � �that... sure it will cost me, but the simulation > will be consistent > � �and users will be able to participate equally, > regardless of the > � �capabilities of their individual asset services. > > > > > � �On Fri, Apr 1, 2011 at 11:55 PM, Morgaine > � � > � � >> wrote: > � �> Every design choice results in a trade-off, > Vaughn, improving > � �one thing at > � �> the expense of something else. �If every time we > offered a > � �service we had to > � �> inform its users about the downsides of all the > trade-offs we > � �have made, > � �> they would have an awful lot to read. ;-) > � �> > � �> The specific trade-off that you are discussing is no > � �different. �A region > � �> that proxies all content has the "benefit" of > acquiring control > � �from the > � �> asset servers over the items in the region, so > that it can > � �ensure that > � �> everyone in the region not only obtains the items > but obtains > � �the same items > � �> as everyone else. �That does indeed provide a > greater guarantee of > � �> consistency than a deployment in which the region > only passes > � �asset URIs to > � �> clients who then fetch the items from asset services > � �separately. �As always > � �> though, it's a trade-off, since the proxied > design has very > � �poor scalability > � �> compared to the distributed one. > � �> > � �> If we're going to warn users of the potential for > inconsistency > � �in the > � �> distributed deployment as you suggest, are we > also going to > � �warn them of > � �> non-scalability in the proxied one? �I really > don't see much > � �merit in the > � �> idea of warning about design choices. �Many such > choices are > � �technical, and > � �> the issues are quite likely to be of little > interest to > � �non-technical users > � �> anyway. �In any case, the better services are > likely to provide > � �such > � �> information in their online documentation, I > would guess. > � �> > � �> You mentioned users "voting with their feet" or > choosing to > � �accept the risk > � �> of inconsistency. �Well that will happen anyway, > when services > � �fail and > � �> users get annoyed. �If some asset services refuse > to send the > � �requested > � �> items to some users, those services will get a > bad reputation > � �and people > � �> will choose different asset services instead. > �Likewise, if a > � �world service > � �> proxies everything and so it can't handle a large > number of > � �assets or of > � �> people, users will get annoyed at the lag and will go > � �elsewhere. �This user > � �> evaluation and "voting with their feet" happens > already with > � �online services > � �> all over the Internet, and I am sure that this > human process > � �will continue > � �> to work when the services are asset and region > services. > � �> > � �> Back in September 2010, I wrote this post which > proposes that > � �we use in > � �> VWRAP a form of asset addressing that provides > massive > � �scalability at the > � �> same time as a very high degree of resilience -- > � �> > � > �http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html > � �. �It is > � �> based on the concept of the URI containing a host > part and a > � �hash part, > � �> where the hash is generated (once, at the time of > storage to > � �the asset > � �> service) using a specified digest algorithm over > the content of > � �the asset > � �> being referenced. �You may wish to note that if > this design > � �were used, the > � �> failure of an asset service to deliver a > requested item would > � �result in a > � �> failover request for the item to one or more > backup services, > � �using the same > � �> hash part but with a different host address. > � �> > � �> This can go some way towards overcoming the > problem that you > � �think might > � �> occur when assets are fetched by clients from > asset services > � �directly. > � �> Although it won't help when the missing item is > available from > � �only a single > � �> asset service, it will help in many other cases, > and it will > � �compensate for > � �> service failures and network outages > automatically at the same > � �time. > � �> > � �> PS. This design for hash-based asset addressing > is already > � �being tested by > � �> Mojito Sorbet in her experimental world and > client. �It would give > � �> VWRAP-based worlds an improved level of service > availability, > � �so I think it > � �> should be a core feature of our protocol. > � �> > � �> > � �> Morgaine. > � �> > � �> > � �> > � �> > � �> =========================== > � �> > � �> On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca > � � > >> > � �> wrote: > � �>> > � �>> This is a question i discussed with Morgaine > off-list a while > � �ago (I > � �>> intended to send it to the list but pushed the > wrong button...) I > � �>> think we need to address this problem, and > decide how to deal > � �with it. > � �>> > � �>> �In Davids deployment draft, section 7.3.1.1 an > overview is > � �given van > � �>> ways to deliver content to the region. One way > is only passing a > � �>> capability that allows access to (part of) the > resource: > � �>> > � �>> � � � � � 7.3.1.1. �Content delivery models > � �>> � � � � � A range of possible represenations can > be passed to > � �a region for > � �>> � � � � � simulation. [...] The other end of the > delivery spectrum > � �>> involves passing > � �>> � � � � � only a URI or capability used to > access the rendering > � �>> information and a > � �>> � � � � � collision mesh,and related data for > physical simulation. > � �>> � � � � � In such a model, the client is > responsible for > � �fetching the > � �>> additional > � �>> � � � � � information needed to render the > item's visual > � �presence from a > � �>> separate > � �>> � � � � � service. �This fetch can be done > *under the > � �credentials of the > � �>> end user* > � �>> � � � � � viewing the material [my emphasis--VD] > , and > � �divorces the > � �>> simulation from > � �>> � � � � � the trust chain needed to manage > content. �Any > � �automation > � �>> is done on a > � �>> � � � � � separate host which the content > creator or owner trusts, > � �>> interacting with the > � �>> � � � � � object through remoted interfaces. > � �>> > � �>> �I can see the need for such a setup, however, i > feel we are > � �>> unpleasantly close to a situation were the > coherence of the > � �simulation > � �>> falls apart. > � �>> In this deployment pattern the region advertises > the presence > � �of the > � �>> asset, and *some* clients will be able to get it > as expected, > � �while > � �>> -based on the arbitrary whims of the asset > service- others > � �might not. > � �>> > � �>> My hope would be that after the asset server > provides the > � �region with > � �>> the capability to get the asset, it gives up > control. That > � �would mean > � �>> that if the client finds the inventory server is > unwilling to > � �serve > � �>> the content - in spire of the region saying it > is present-, > � �the client > � �>> should be able to turn around ask the *region* > for the asset, > � �(and get > � �>> is after all). > � �>> > � �>> �If that is not the case, -and there are > probably good reasons > � �for the > � �>> deployment pattern as described- �shouldn't we > *warn* clients > � �that the > � �>> region might be inconsistent, so the users > behind the client > � �can vote > � �>> with their feet, (or take the risk)? > � �>> > � �>> --Vaughn > � �>> _______________________________________________ > � �>> vwrap mailing list > � �>> vwrap@ietf.org > > > � �>> https://www.ietf.org/mailman/listinfo/vwrap > � �> > � �> > � �> _______________________________________________ > � �> vwrap mailing list > � �> vwrap@ietf.org > > > � �> https://www.ietf.org/mailman/listinfo/vwrap > � �> > � �> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > � > > > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Sun Apr 3 10:31:38 2011 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 E61373A6867 for ; Sun, 3 Apr 2011 10:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] 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 QwTovLatMN3Z for ; Sun, 3 Apr 2011 10:31:34 -0700 (PDT) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by core3.amsl.com (Postfix) with ESMTP id B8D6A3A6863 for ; Sun, 3 Apr 2011 10:31:33 -0700 (PDT) Received: by qwc9 with SMTP id 9so4874458qwc.27 for ; Sun, 03 Apr 2011 10:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=dfPRdikmzCSLVPS6eXSa0s/IvTVJ0SVmec9x7S6JkWU=; b=IyVA0/cxBQTKwLZnbg704KbrcCm/l2mWbL6eHmsOfDCAoJuz3AYadzXU/EoKjxAQ8a vB7BJBbsZ9/LMfP2zpw2snsfWWFmRshpF2Mwnc90qY7U80zPyuja422M3WyXJ91i/uW/ xQZt67V35soPJI2SY2RkStpCdFxbFFJBQY4Is= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=D9V84bP3K3WELfZaEpquF05wNNJmSGgv/SZIfLaCUz2zfLqTrzE8qlXEHxmfTB+noK hSs3Q2pwsQ/jF/qDGT/Ij7x2gfTBrX5P6KckXd2pttISudcIZJ+2fGbZNoaLKEd7XSHw nMMI8NLzACvspoM9zCsTbDNPwMDAcrZUeHdyI= MIME-Version: 1.0 Received: by 10.229.78.22 with SMTP id i22mr2531991qck.33.1301851995073; Sun, 03 Apr 2011 10:33:15 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sun, 3 Apr 2011 10:33:14 -0700 (PDT) In-Reply-To: <4D98AC5F.70501@gmail.com> References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> Date: Sun, 3 Apr 2011 18:33:14 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00235429d8f4b76cb804a0070921 Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 03 Apr 2011 17:31:38 -0000 --00235429d8f4b76cb804a0070921 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "Agent Domain" more or less ceased to exist in practice when David pointed out very eloquently that the emperor had no clothes. (Same for "Region Domain".) I think we mostly talk about the Agent Service and Region Service these days. The "domain" was just a fluffy cloud that someone once drew on a whiteboard, but which never actually existed. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Sun, Apr 3, 2011 at 6:20 PM, Dzonatas Sol wrote: > Probably easy as suggested in other terms here on this list, as how the > client contacts the asset services now in the regions. The newer issue is= to > unitize that asset services. Since their is proprietary (legacy) code the= n > we can't expect that to change, and some form of proxy is of need. Whatev= er > works best, I tried to narrow it down to suggestions here. > > Eventually, the agent domain is ideal to handle the direction of the asse= t > services. This concept, unfortunately, ended support awhile ago with chan= ges > in LL. > Also see; http://wiki.secondlife.com/wiki/Agent_Domain > And: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset (warn: > unstructured collaborative notes, dumped on me and I tried to fix) > > I tried to find previous visuals. > > I'd imagine the agent domain could grow out of unitized versions of asset > services. Despite that, I think that concept helps view where we were at = in > discussion and what didn't happen. > > Vaughn Deluca wrote: > >> Hi=EF=BF=BDDzonatas >> >> Can you expand on that, what would be needed for legacy support in VWAP >> terms=EF=BF=BD?, >> If i want to read up on how the=EF=BF=BDasset server may proxy the simul= ator, what >> would you recommend me to read? >> >> -- Vaughn >> >> On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol > dzonatas@gmail.com>> wrote: >> >> Some stated the proxy-to-asset-server is built into the sim; >> however, keep in mind possible legacy support where the asset >> server may proxy the simulator. >> >> >> Dzonatas Sol wrote: >> >> Somehow I feel the basic asset server being able to login and >> download assets is now priority, yet I also wondered the best >> way to patch this into the current mode of viewers. >> >> Maybe offer (1) by proxy (sim-side) and (2) by patch >> (viewer-side) that either of these two are optional and >> neither are mandatory for now. Thoughts? >> >> Israel Alanis wrote: >> >> >> > when designing for scalability, the model to bear in >> mind is ... >> >> Well, there are a lot of different models to keep in mind, >> and many different use cases. One particular use case to >> keep in mind is: "User acquires new outfit, and wants to >> 'show it off' in a highly populated region". >> >> > Both worlds and asset services may include commercial, >> community, and personal services >> >> Yes, yes and yes. I'm particularly concerned about how the >> model affects the ability to host personal asset services. >> >> > a proxying region, which would get slammed for every >> asset worn by every avatar present. >> >> Granted the collection of services that are provided by >> the region need to be scaled to meet the demands of that >> region. That's all part of capacity planning. >> >> > regions run many different CPU-intensive tasks, >> including physics simulation and server-side scripting, >> and absolutely cannot afford to serve assets too >> Well... who said the same CPU's have to do proxying, >> physics simulation and server-side scripting? Asset >> proxying is a different service than physics simulation >> and can be on separate hardware, could make use of >> geographically distributed caching, and in certain >> deployment patterns, the same caching services could be >> shared by different regions. (Server-side scripting is a >> discussion for another day). >> >> > This is why we have to go parallel... >> >> Totally agree, and a proxying model could and should also >> take advantage of parallelism. >> >> > I think you're wrong that it has to cost much money. ?vs? >> > It costs money to host a high performance and scalable >> asset service and a high bandwidth network to handle the >> traffic. =EF=BF=BDA *lot* of money. >> I think what you're saying is: "It costs a lot of money to >> build a scalable asset service, but if assets are spread >> throughout the internet they don't have to be scalable." >> But that's not quite right. You're opening up every asset >> server to the VW equivalent of being slashdotted, so are >> you sure you're not forcing *every* asset service to be >> scalable and handle a lot of bandwith and network traffic? >> It's the exact opposite of your intention, but I think >> that's the result, all the same. >> >> This particular design decision has a big effect on the >> economics of the VW infrastructure. I'd rather the >> economics to work out such that a region provider who >> wishes to build a region that supports a small population, >> can do so economically. A region that wants to host a >> *large* population has to bear that cost of providing that >> scalable asset service. >> I want the economics of hosting a small asset service to >> be a non-issue (as to best promote creation and >> creativity). Creating a high bar to provide asset services >> will mean that service will cost money and people >> shouldn't have to pay money just to create or own VW >> objects (I'm using 'own' here to refer to maintaining >> their existence, I'm not trying to make a >> 'leftist'/'communist' statement about ownership ;) >> >> - Izzy >> >> >> On Apr 2, 2011, at 3:58 PM, Morgaine wrote: >> >> Izzy, when designing for scalability, the model to >> bear in mind is that of seasoned virtual world >> travelers whose inventories contain assets from many >> different worlds, those assets being served by many >> different asset services. =EF=BF=BDBoth worlds and asset >> services may include commercial, community, and >> personal services, and as the metaverse grows, that >> set is highly likely to become progressively less >> clustered and more diverse. >> >> When those seasoned travelers click on an advertised >> VW link and perform an inter-world teleport to one >> particular world's region to share an experience, >> their "worn" assets (the only ones of interest to the >> region) will contain references to asset services >> spread widely across the Internet. =EF=BF=BDThe fetches b= y the >> travelers' clients occur over many parallel paths from >> clients to asset services, so one can reasonably >> expect reduced network contention and reduced asset >> server loading because they are both spread out over >> however many asset services are being referenced by >> the overall set of assets in the region. >> >> This is very different to the case of a proxying >> region, which would get slammed for every asset worn >> by every avatar present. =EF=BF=BDIn our current architec= ture, >> regions run many different CPU-intensive tasks, >> including physics simulation and server-side >> scripting, and absolutely cannot afford to serve >> assets too unless your scalability requirements are >> very low indeed, ie. just a few dozen avatars of >> today's kind. =EF=BF=BDWe've hit the ceiling already on r= egion >> scalability done that way. =EF=BF=BDThere is nowhere to g= o in >> that direction at all beyond improving the code like >> Intel demonstrated, and that work is subject to a law >> of diminishing returns. >> >> This is why we have to go parallel, and I think you're >> wrong that it has to cost much money. =EF=BF=BDAs we spre= ad >> the load across more and more asset services, we are >> simply better utilizing all the hardware that's >> already out there on the Internet, at least in respect >> of community and private resources. =EF=BF=BDBut add to t= he >> community and private resources the commercial asset >> services that are likely to appear to exploit this >> opportunity, and not only will the number of asset >> services leap, but the power of each one will rocket >> too, because, after all, these businesses will be >> heavily optimized for the job. >> >> As to why a world would want clients to access >> external asset services instead of providing its own >> implementation, that's an easy question. =EF=BF=BDIt cost= s >> money to host a high performance and scalable asset >> service and a high bandwidth network to handle the >> traffic. =EF=BF=BDA *lot* of money. =EF=BF=BDIn contrast,= it costs a >> world nothing to let others serve the assets to >> clients. =EF=BF=BDAnd that matters to the bottom line. >> >> >> Morgaine. >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> >> On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis >> >> > >> >> wrote: >> >> =EF=BF=BD =EF=BF=BD> As always though, it's a trade-off, = since the >> proxied design >> =EF=BF=BD =EF=BF=BDhas very poor scalability compared to = the >> distributed one. >> >> =EF=BF=BD =EF=BF=BDI don't agree with that... If a user e= nters a >> highly populated >> =EF=BF=BD =EF=BF=BDregion, >> =EF=BF=BD =EF=BF=BDevery other client is going to (could = and should be >> trying to) >> =EF=BF=BD =EF=BF=BDhit the >> =EF=BF=BD =EF=BF=BDasset server(s) for the assets that th= e user is >> wearing (assuming >> =EF=BF=BD =EF=BF=BDthey're not cached locally). =EF=BF=BD= Every asset server >> has to be scaled up >> =EF=BF=BD =EF=BF=BDto the point that it can handle that l= oad from all >> over... >> >> =EF=BF=BD =EF=BF=BDIf I'm hosting a region that supports = 10s of >> thousands of >> =EF=BF=BD =EF=BF=BDsimultaneous >> =EF=BF=BD =EF=BF=BDusers (thinking of the future), I alre= ady have to >> scale to meet that >> =EF=BF=BD =EF=BF=BDdemand. If the region is proxying the = assets, then, >> yes the >> =EF=BF=BD =EF=BF=BDregion has >> =EF=BF=BD =EF=BF=BDto be scaled to meet that asset demand= too, but it >> already has to be >> =EF=BF=BD =EF=BF=BDscaled to meet other demands of being = a region >> server... and why is >> =EF=BF=BD =EF=BF=BDscaling those asset proxy services har= d? =EF=BF=BDIt's >> going to cost $, >> =EF=BF=BD =EF=BF=BDbut is >> =EF=BF=BD =EF=BF=BDnot technically challenging. So, if I = want to host >> a region like >> =EF=BF=BD =EF=BF=BDthat... sure it will cost me, but the = simulation >> will be consistent >> =EF=BF=BD =EF=BF=BDand users will be able to participate = equally, >> regardless of the >> =EF=BF=BD =EF=BF=BDcapabilities of their individual asset= services. >> >> >> >> >> =EF=BF=BD =EF=BF=BDOn Fri, Apr 1, 2011 at 11:55 PM, Morga= ine >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> >> wrote: >> =EF=BF=BD =EF=BF=BD> Every design choice results in a tra= de-off, >> Vaughn, improving >> =EF=BF=BD =EF=BF=BDone thing at >> =EF=BF=BD =EF=BF=BD> the expense of something else. =EF= =BF=BDIf every time we >> offered a >> =EF=BF=BD =EF=BF=BDservice we had to >> =EF=BF=BD =EF=BF=BD> inform its users about the downsides= of all the >> trade-offs we >> =EF=BF=BD =EF=BF=BDhave made, >> =EF=BF=BD =EF=BF=BD> they would have an awful lot to read= . ;-) >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> The specific trade-off that you are = discussing is no >> =EF=BF=BD =EF=BF=BDdifferent. =EF=BF=BDA region >> =EF=BF=BD =EF=BF=BD> that proxies all content has the "be= nefit" of >> acquiring control >> =EF=BF=BD =EF=BF=BDfrom the >> =EF=BF=BD =EF=BF=BD> asset servers over the items in the = region, so >> that it can >> =EF=BF=BD =EF=BF=BDensure that >> =EF=BF=BD =EF=BF=BD> everyone in the region not only obta= ins the items >> but obtains >> =EF=BF=BD =EF=BF=BDthe same items >> =EF=BF=BD =EF=BF=BD> as everyone else. =EF=BF=BDThat does= indeed provide a >> greater guarantee of >> =EF=BF=BD =EF=BF=BD> consistency than a deployment in whi= ch the region >> only passes >> =EF=BF=BD =EF=BF=BDasset URIs to >> =EF=BF=BD =EF=BF=BD> clients who then fetch the items fro= m asset services >> =EF=BF=BD =EF=BF=BDseparately. =EF=BF=BDAs always >> =EF=BF=BD =EF=BF=BD> though, it's a trade-off, since the = proxied >> design has very >> =EF=BF=BD =EF=BF=BDpoor scalability >> =EF=BF=BD =EF=BF=BD> compared to the distributed one. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> If we're going to warn users of the = potential for >> inconsistency >> =EF=BF=BD =EF=BF=BDin the >> =EF=BF=BD =EF=BF=BD> distributed deployment as you sugges= t, are we >> also going to >> =EF=BF=BD =EF=BF=BDwarn them of >> =EF=BF=BD =EF=BF=BD> non-scalability in the proxied one? = =EF=BF=BDI really >> don't see much >> =EF=BF=BD =EF=BF=BDmerit in the >> =EF=BF=BD =EF=BF=BD> idea of warning about design choices= . =EF=BF=BDMany such >> choices are >> =EF=BF=BD =EF=BF=BDtechnical, and >> =EF=BF=BD =EF=BF=BD> the issues are quite likely to be of= little >> interest to >> =EF=BF=BD =EF=BF=BDnon-technical users >> =EF=BF=BD =EF=BF=BD> anyway. =EF=BF=BDIn any case, the be= tter services are >> likely to provide >> =EF=BF=BD =EF=BF=BDsuch >> =EF=BF=BD =EF=BF=BD> information in their online document= ation, I >> would guess. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> You mentioned users "voting with the= ir feet" or >> choosing to >> =EF=BF=BD =EF=BF=BDaccept the risk >> =EF=BF=BD =EF=BF=BD> of inconsistency. =EF=BF=BDWell that= will happen anyway, >> when services >> =EF=BF=BD =EF=BF=BDfail and >> =EF=BF=BD =EF=BF=BD> users get annoyed. =EF=BF=BDIf some = asset services refuse >> to send the >> =EF=BF=BD =EF=BF=BDrequested >> =EF=BF=BD =EF=BF=BD> items to some users, those services = will get a >> bad reputation >> =EF=BF=BD =EF=BF=BDand people >> =EF=BF=BD =EF=BF=BD> will choose different asset services= instead. >> =EF=BF=BDLikewise, if a >> =EF=BF=BD =EF=BF=BDworld service >> =EF=BF=BD =EF=BF=BD> proxies everything and so it can't h= andle a large >> number of >> =EF=BF=BD =EF=BF=BDassets or of >> =EF=BF=BD =EF=BF=BD> people, users will get annoyed at th= e lag and will go >> =EF=BF=BD =EF=BF=BDelsewhere. =EF=BF=BDThis user >> =EF=BF=BD =EF=BF=BD> evaluation and "voting with their fe= et" happens >> already with >> =EF=BF=BD =EF=BF=BDonline services >> =EF=BF=BD =EF=BF=BD> all over the Internet, and I am sure= that this >> human process >> =EF=BF=BD =EF=BF=BDwill continue >> =EF=BF=BD =EF=BF=BD> to work when the services are asset = and region >> services. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> Back in September 2010, I wrote this= post which >> proposes that >> =EF=BF=BD =EF=BF=BDwe use in >> =EF=BF=BD =EF=BF=BD> VWRAP a form of asset addressing tha= t provides >> massive >> =EF=BF=BD =EF=BF=BDscalability at the >> =EF=BF=BD =EF=BF=BD> same time as a very high degree of r= esilience -- >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD >> =EF=BF=BD >> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >> =EF=BF=BD =EF=BF=BD. =EF=BF=BDIt is >> =EF=BF=BD =EF=BF=BD> based on the concept of the URI cont= aining a host >> part and a >> =EF=BF=BD =EF=BF=BDhash part, >> =EF=BF=BD =EF=BF=BD> where the hash is generated (once, a= t the time of >> storage to >> =EF=BF=BD =EF=BF=BDthe asset >> =EF=BF=BD =EF=BF=BD> service) using a specified digest al= gorithm over >> the content of >> =EF=BF=BD =EF=BF=BDthe asset >> =EF=BF=BD =EF=BF=BD> being referenced. =EF=BF=BDYou may w= ish to note that if >> this design >> =EF=BF=BD =EF=BF=BDwere used, the >> =EF=BF=BD =EF=BF=BD> failure of an asset service to deliv= er a >> requested item would >> =EF=BF=BD =EF=BF=BDresult in a >> =EF=BF=BD =EF=BF=BD> failover request for the item to one= or more >> backup services, >> =EF=BF=BD =EF=BF=BDusing the same >> =EF=BF=BD =EF=BF=BD> hash part but with a different host = address. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> This can go some way towards overcom= ing the >> problem that you >> =EF=BF=BD =EF=BF=BDthink might >> =EF=BF=BD =EF=BF=BD> occur when assets are fetched by cli= ents from >> asset services >> =EF=BF=BD =EF=BF=BDdirectly. >> =EF=BF=BD =EF=BF=BD> Although it won't help when the miss= ing item is >> available from >> =EF=BF=BD =EF=BF=BDonly a single >> =EF=BF=BD =EF=BF=BD> asset service, it will help in many = other cases, >> and it will >> =EF=BF=BD =EF=BF=BDcompensate for >> =EF=BF=BD =EF=BF=BD> service failures and network outages >> automatically at the same >> =EF=BF=BD =EF=BF=BDtime. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> PS. This design for hash-based asset= addressing >> is already >> =EF=BF=BD =EF=BF=BDbeing tested by >> =EF=BF=BD =EF=BF=BD> Mojito Sorbet in her experimental wo= rld and >> client. =EF=BF=BDIt would give >> =EF=BF=BD =EF=BF=BD> VWRAP-based worlds an improved level= of service >> availability, >> =EF=BF=BD =EF=BF=BDso I think it >> =EF=BF=BD =EF=BF=BD> should be a core feature of our prot= ocol. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> Morgaine. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> =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 >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> On Fri, Apr 1, 2011 at 11:17 PM, Vau= ghn Deluca >> =EF=BF=BD =EF=BF=BD> >> > >> >> =EF=BF=BD =EF=BF=BD> wrote: >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> This is a question i discussed with= Morgaine >> off-list a while >> =EF=BF=BD =EF=BF=BDago (I >> =EF=BF=BD =EF=BF=BD>> intended to send it to the list but= pushed the >> wrong button...) I >> =EF=BF=BD =EF=BF=BD>> think we need to address this probl= em, and >> decide how to deal >> =EF=BF=BD =EF=BF=BDwith it. >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDIn Davids deployment draft= , section 7.3.1.1 an >> overview is >> =EF=BF=BD =EF=BF=BDgiven van >> =EF=BF=BD =EF=BF=BD>> ways to deliver content to the regi= on. One way >> is only passing a >> =EF=BF=BD =EF=BF=BD>> capability that allows access to (p= art of) the >> resource: >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD 7.3.1.1. =EF=BF=BDContent delivery models >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD A range of possible represenations can >> be passed to >> =EF=BF=BD =EF=BF=BDa region for >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD simulation. [...] The other end of the >> delivery spectrum >> =EF=BF=BD =EF=BF=BD>> involves passing >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD only a URI or capability used to >> access the rendering >> =EF=BF=BD =EF=BF=BD>> information and a >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD collision mesh,and related data for >> physical simulation. >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD In such a model, the client is >> responsible for >> =EF=BF=BD =EF=BF=BDfetching the >> =EF=BF=BD =EF=BF=BD>> additional >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD information needed to render the >> item's visual >> =EF=BF=BD =EF=BF=BDpresence from a >> =EF=BF=BD =EF=BF=BD>> separate >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD service. =EF=BF=BDThis fetch can be done >> *under the >> =EF=BF=BD =EF=BF=BDcredentials of the >> =EF=BF=BD =EF=BF=BD>> end user* >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD viewing the material [my emphasis--VD] >> , and >> =EF=BF=BD =EF=BF=BDdivorces the >> =EF=BF=BD =EF=BF=BD>> simulation from >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD the trust chain needed to manage >> content. =EF=BF=BDAny >> =EF=BF=BD =EF=BF=BDautomation >> =EF=BF=BD =EF=BF=BD>> is done on a >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD separate host which the content >> creator or owner trusts, >> =EF=BF=BD =EF=BF=BD>> interacting with the >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD object through remoted interfaces. >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDI can see the need for suc= h a setup, however, i >> feel we are >> =EF=BF=BD =EF=BF=BD>> unpleasantly close to a situation w= ere the >> coherence of the >> =EF=BF=BD =EF=BF=BDsimulation >> =EF=BF=BD =EF=BF=BD>> falls apart. >> =EF=BF=BD =EF=BF=BD>> In this deployment pattern the regi= on advertises >> the presence >> =EF=BF=BD =EF=BF=BDof the >> =EF=BF=BD =EF=BF=BD>> asset, and *some* clients will be a= ble to get it >> as expected, >> =EF=BF=BD =EF=BF=BDwhile >> =EF=BF=BD =EF=BF=BD>> -based on the arbitrary whims of th= e asset >> service- others >> =EF=BF=BD =EF=BF=BDmight not. >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> My hope would be that after the ass= et server >> provides the >> =EF=BF=BD =EF=BF=BDregion with >> =EF=BF=BD =EF=BF=BD>> the capability to get the asset, it= gives up >> control. That >> =EF=BF=BD =EF=BF=BDwould mean >> =EF=BF=BD =EF=BF=BD>> that if the client finds the invent= ory server is >> unwilling to >> =EF=BF=BD =EF=BF=BDserve >> =EF=BF=BD =EF=BF=BD>> the content - in spire of the regio= n saying it >> is present-, >> =EF=BF=BD =EF=BF=BDthe client >> =EF=BF=BD =EF=BF=BD>> should be able to turn around ask t= he *region* >> for the asset, >> =EF=BF=BD =EF=BF=BD(and get >> =EF=BF=BD =EF=BF=BD>> is after all). >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDIf that is not the case, -= and there are >> probably good reasons >> =EF=BF=BD =EF=BF=BDfor the >> =EF=BF=BD =EF=BF=BD>> deployment pattern as described- = =EF=BF=BDshouldn't we >> *warn* clients >> =EF=BF=BD =EF=BF=BDthat the >> =EF=BF=BD =EF=BF=BD>> region might be inconsistent, so th= e users >> behind the client >> =EF=BF=BD =EF=BF=BDcan vote >> =EF=BF=BD =EF=BF=BD>> with their feet, (or take the risk)= ? >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> --Vaughn >> =EF=BF=BD =EF=BF=BD>> ___________________________________= ____________ >> =EF=BF=BD =EF=BF=BD>> vwrap mailing list >> =EF=BF=BD =EF=BF=BD>> vwrap@ietf.org >> > >> >> =EF=BF=BD =EF=BF=BD>> https://www.ietf.org/mailman/listin= fo/vwrap >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> ____________________________________= ___________ >> =EF=BF=BD =EF=BF=BD> vwrap mailing list >> =EF=BF=BD =EF=BF=BD> vwrap@ietf.org >> > >> >> =EF=BF=BD =EF=BF=BD> https://www.ietf.org/mailman/listinf= o/vwrap >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> >> >> >> >> -----------------------------------------------------------------------= - >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> =EF=BF=BD >> >> >> >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --00235429d8f4b76cb804a0070921 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 JnF1b3Q7QWdlbnQgRG9tYWluJnF1b3Q7IG1vcmUgb3IgbGVzcyBjZWFzZWQgdG8gZXhpc3QgaW4g cHJhY3RpY2Ugd2hlbiBEYXZpZCBwb2ludGVkIG91dCB2ZXJ5IGVsb3F1ZW50bHkgdGhhdCB0aGUg ZW1wZXJvciBoYWQgbm8gY2xvdGhlcy7CoCAoU2FtZSBmb3IgJnF1b3Q7UmVnaW9uIERvbWFpbiZx dW90Oy4pPGJyPjxicj5JIHRoaW5rIHdlIG1vc3RseSB0YWxrIGFib3V0IHRoZSBBZ2VudCBTZXJ2 aWNlIGFuZCBSZWdpb24gU2VydmljZSB0aGVzZSBkYXlzLsKgIFRoZSAmcXVvdDtkb21haW4mcXVv dDsgd2FzIGp1c3QgYSBmbHVmZnkgY2xvdWQgdGhhdCBzb21lb25lIG9uY2UgZHJldyBvbiBhIHdo aXRlYm9hcmQsIGJ1dCB3aGljaCBuZXZlciBhY3R1YWxseSBleGlzdGVkLjxicj4KPGJyPjxicj5N b3JnYWluZS48YnI+PGJyPjxicj48YnI+PGJyPj09PT09PT09PT09PT09PT09PT09PGJyPjxicj48 ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gU3VuLCBBcHIgMywgMjAxMSBhdCA2OjIwIFBNLCBE em9uYXRhcyBTb2wgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86ZHpvbmF0YXNA Z21haWwuY29tIj5kem9uYXRhc0BnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPgo8 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBwdCAwcHQgMHB0 IDAuOGV4OyBib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgcGFkZGlu Zy1sZWZ0OiAxZXg7Ij5Qcm9iYWJseSBlYXN5IGFzIHN1Z2dlc3RlZCBpbiBvdGhlciB0ZXJtcyBo ZXJlIG9uIHRoaXMgbGlzdCwgYXMgaG93IHRoZSBjbGllbnQgY29udGFjdHMgdGhlIGFzc2V0IHNl cnZpY2VzIG5vdyBpbiB0aGUgcmVnaW9ucy4gVGhlIG5ld2VyIGlzc3VlIGlzIHRvIHVuaXRpemUg dGhhdCBhc3NldCBzZXJ2aWNlcy4gU2luY2UgdGhlaXIgaXMgcHJvcHJpZXRhcnkgKGxlZ2FjeSkg Y29kZSB0aGVuIHdlIGNhbiYjMzk7dCBleHBlY3QgdGhhdCB0byBjaGFuZ2UsIGFuZCBzb21lIGZv cm0gb2YgcHJveHkgaXMgb2YgbmVlZC4gV2hhdGV2ZXIgd29ya3MgYmVzdCwgSSB0cmllZCB0byBu YXJyb3cgaXQgZG93biB0byBzdWdnZXN0aW9ucyBoZXJlLjxicj4KCjxicj4KRXZlbnR1YWxseSwg dGhlIGFnZW50IGRvbWFpbiBpcyBpZGVhbCB0byBoYW5kbGUgdGhlIGRpcmVjdGlvbiBvZiB0aGUg YXNzZXQgc2VydmljZXMuIFRoaXMgY29uY2VwdCwgdW5mb3J0dW5hdGVseSwgZW5kZWQgc3VwcG9y dCBhd2hpbGUgYWdvIHdpdGggY2hhbmdlcyBpbiBMTC48YnI+CkFsc28gc2VlOyA8YSBocmVmPSJo dHRwOi8vd2lraS5zZWNvbmRsaWZlLmNvbS93aWtpL0FnZW50X0RvbWFpbiIgdGFyZ2V0PSJfYmxh bmsiPmh0dHA6Ly93aWtpLnNlY29uZGxpZmUuY29tL3dpa2kvQWdlbnRfRG9tYWluPC9hPjxicj4K QW5kOiA8YSBocmVmPSJodHRwOi8vd2lraS5zZWNvbmRsaWZlLmNvbS93aWtpL1VzZXI6RHpvbmF0 YXNfU29sL0FXR19Bc3NldCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93aWtpLnNlY29uZGxpZmUu Y29tL3dpa2kvVXNlcjpEem9uYXRhc19Tb2wvQVdHX0Fzc2V0PC9hPiAod2FybjogdW5zdHJ1Y3R1 cmVkIGNvbGxhYm9yYXRpdmUgbm90ZXMsIGR1bXBlZCBvbiBtZSBhbmQgSSB0cmllZCB0byBmaXgp PGJyPgoKPGJyPgpJIHRyaWVkIHRvIGZpbmQgcHJldmlvdXMgdmlzdWFscy48YnI+Cjxicj4KSSYj Mzk7ZCBpbWFnaW5lIHRoZSBhZ2VudCBkb21haW4gY291bGQgZ3JvdyBvdXQgb2YgdW5pdGl6ZWQg dmVyc2lvbnMgb2YgYXNzZXQgc2VydmljZXMuIERlc3BpdGUgdGhhdCwgSSB0aGluayB0aGF0IGNv bmNlcHQgaGVscHMgdmlldyB3aGVyZSB3ZSB3ZXJlIGF0IGluIGRpc2N1c3Npb24gYW5kIHdoYXQg ZGlkbiYjMzk7dCBoYXBwZW4uPGJyPgo8YnI+ClZhdWdobiBEZWx1Y2Egd3JvdGU6PGJyPgo8Ymxv Y2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBwdCAwcHQgMHB0IDAu OGV4OyBib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZy1s ZWZ0OiAxZXg7Ij48ZGl2IGNsYXNzPSJpbSI+Ckhp77+9RHpvbmF0YXM8YnI+Cjxicj4KQ2FuIHlv dSBleHBhbmQgb24gdGhhdCwgd2hhdCB3b3VsZCBiZSBuZWVkZWQgZm9yIGxlZ2FjeSBzdXBwb3J0 IGluIFZXQVAgdGVybXPvv70/LDxicj4KSWYgaSB3YW50IHRvIHJlYWQgdXAgb24gaG93IHRoZe+/ vWFzc2V0IHNlcnZlciBtYXkgcHJveHkgdGhlIHNpbXVsYXRvciwgd2hhdCB3b3VsZCB5b3UgcmVj b21tZW5kIG1lIHRvIHJlYWQ/PGJyPgo8YnI+Ci0tIFZhdWdobjxicj4KPGJyPjwvZGl2PjxkaXY+ PGRpdj48L2Rpdj48ZGl2IGNsYXNzPSJoNSI+Ck9uIFN1biwgQXByIDMsIDIwMTEgYXQgNTo1MSBB TSwgRHpvbmF0YXMgU29sICZsdDs8YSBocmVmPSJtYWlsdG86ZHpvbmF0YXNAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+ZHpvbmF0YXNAZ21haWwuY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpkem9uYXRhc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kem9uYXRhc0BnbWFp bC5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPgoKPGJyPgogwqAgwqBTb21lIHN0YXRlZCB0aGUg cHJveHktdG8tYXNzZXQtc2VydmVyIGlzIGJ1aWx0IGludG8gdGhlIHNpbTs8YnI+CiDCoCDCoGhv d2V2ZXIsIGtlZXAgaW4gbWluZCBwb3NzaWJsZSBsZWdhY3kgc3VwcG9ydCB3aGVyZSB0aGUgYXNz ZXQ8YnI+CiDCoCDCoHNlcnZlciBtYXkgcHJveHkgdGhlIHNpbXVsYXRvci48YnI+Cjxicj4KPGJy PgogwqAgwqBEem9uYXRhcyBTb2wgd3JvdGU6PGJyPgo8YnI+CiDCoCDCoCDCoCDCoFNvbWVob3cg SSBmZWVsIHRoZSBiYXNpYyBhc3NldCBzZXJ2ZXIgYmVpbmcgYWJsZSB0byBsb2dpbiBhbmQ8YnI+ CiDCoCDCoCDCoCDCoGRvd25sb2FkIGFzc2V0cyBpcyBub3cgcHJpb3JpdHksIHlldCBJIGFsc28g d29uZGVyZWQgdGhlIGJlc3Q8YnI+CiDCoCDCoCDCoCDCoHdheSB0byBwYXRjaCB0aGlzIGludG8g dGhlIGN1cnJlbnQgbW9kZSBvZiB2aWV3ZXJzLjxicj4KPGJyPgogwqAgwqAgwqAgwqBNYXliZSBv ZmZlciAoMSkgYnkgcHJveHkgKHNpbS1zaWRlKSBhbmQgKDIpIGJ5IHBhdGNoPGJyPgogwqAgwqAg wqAgwqAodmlld2VyLXNpZGUpIHRoYXQgZWl0aGVyIG9mIHRoZXNlIHR3byBhcmUgb3B0aW9uYWwg YW5kPGJyPgogwqAgwqAgwqAgwqBuZWl0aGVyIGFyZSBtYW5kYXRvcnkgZm9yIG5vdy4gVGhvdWdo dHM/PGJyPgo8YnI+CiDCoCDCoCDCoCDCoElzcmFlbCBBbGFuaXMgd3JvdGU6PGJyPgo8YnI+Cjxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyB3aGVuIGRlc2lnbmluZyBmb3Igc2NhbGFiaWxpdHks IHRoZSBtb2RlbCB0byBiZWFyIGluPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBtaW5kIGlzIC4uLjxi cj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBXZWxsLCB0aGVyZSBhcmUgYSBsb3Qgb2YgZGlmZmVy ZW50IG1vZGVscyB0byBrZWVwIGluIG1pbmQsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBhbmQgbWFu eSBkaWZmZXJlbnQgdXNlIGNhc2VzLiBPbmUgcGFydGljdWxhciB1c2UgY2FzZSB0bzxicj4KIMKg IMKgIMKgIMKgIMKgIMKga2VlcCBpbiBtaW5kIGlzOiAmcXVvdDtVc2VyIGFjcXVpcmVzIG5ldyBv dXRmaXQsIGFuZCB3YW50cyB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgJiMzOTtzaG93IGl0IG9m ZiYjMzk7IGluIGEgaGlnaGx5IHBvcHVsYXRlZCByZWdpb24mcXVvdDsuPGJyPgo8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCZndDsgQm90aCB3b3JsZHMgYW5kIGFzc2V0IHNlcnZpY2VzIG1heSBpbmNs dWRlIGNvbW1lcmNpYWwsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBjb21tdW5pdHksIGFuZCBwZXJz b25hbCBzZXJ2aWNlczxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBZZXMsIHllcyBhbmQgeWVz LiBJJiMzOTttIHBhcnRpY3VsYXJseSBjb25jZXJuZWQgYWJvdXQgaG93IHRoZTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgbW9kZWwgYWZmZWN0cyB0aGUgYWJpbGl0eSB0byBob3N0IHBlcnNvbmFsIGFz c2V0IHNlcnZpY2VzLjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7IGEgcHJveHlpbmcg cmVnaW9uLCB3aGljaCB3b3VsZCBnZXQgc2xhbW1lZCBmb3IgZXZlcnk8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoGFzc2V0IHdvcm4gYnkgZXZlcnkgYXZhdGFyIHByZXNlbnQuPGJyPgo8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoEdyYW50ZWQgdGhlIGNvbGxlY3Rpb24gb2Ygc2VydmljZXMgdGhhdCBhcmUg cHJvdmlkZWQgYnk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoHRoZSByZWdpb24gbmVlZCB0byBiZSBz Y2FsZWQgdG8gbWVldCB0aGUgZGVtYW5kcyBvZiB0aGF0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqBy ZWdpb24uIFRoYXQmIzM5O3MgYWxsIHBhcnQgb2YgY2FwYWNpdHkgcGxhbm5pbmcuPGJyPgo8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCZndDsgcmVnaW9ucyBydW4gbWFueSBkaWZmZXJlbnQgQ1BVLWlu dGVuc2l2ZSB0YXNrcyw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoGluY2x1ZGluZyBwaHlzaWNzIHNp bXVsYXRpb24gYW5kIHNlcnZlci1zaWRlIHNjcmlwdGluZyw8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oGFuZCBhYnNvbHV0ZWx5IGNhbm5vdCBhZmZvcmQgdG8gc2VydmUgYXNzZXRzIHRvbzxicj4KIMKg IMKgIMKgIMKgIMKgIMKgV2VsbC4uLiB3aG8gc2FpZCB0aGUgc2FtZSBDUFUmIzM5O3MgaGF2ZSB0 byBkbyBwcm94eWluZyw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoHBoeXNpY3Mgc2ltdWxhdGlvbiBh bmQgc2VydmVyLXNpZGUgc2NyaXB0aW5nPyBBc3NldDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgcHJv eHlpbmcgaXMgYSBkaWZmZXJlbnQgc2VydmljZSB0aGFuIHBoeXNpY3Mgc2ltdWxhdGlvbjxicj4K IMKgIMKgIMKgIMKgIMKgIMKgYW5kIGNhbiBiZSBvbiBzZXBhcmF0ZSBoYXJkd2FyZSwgY291bGQg bWFrZSB1c2Ugb2Y8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoGdlb2dyYXBoaWNhbGx5IGRpc3RyaWJ1 dGVkIGNhY2hpbmcsIGFuZCBpbiBjZXJ0YWluPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBkZXBsb3lt ZW50IHBhdHRlcm5zLCB0aGUgc2FtZSBjYWNoaW5nIHNlcnZpY2VzIGNvdWxkIGJlPGJyPgogwqAg wqAgwqAgwqAgwqAgwqBzaGFyZWQgYnkgZGlmZmVyZW50IHJlZ2lvbnMuIChTZXJ2ZXItc2lkZSBz Y3JpcHRpbmcgaXMgYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgZGlzY3Vzc2lvbiBmb3IgYW5vdGhl ciBkYXkpLjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7IFRoaXMgaXMgd2h5IHdlIGhh dmUgdG8gZ28gcGFyYWxsZWwuLi48YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgVG90YWxseSBh Z3JlZSwgYW5kIGEgcHJveHlpbmcgbW9kZWwgY291bGQgYW5kIHNob3VsZCBhbHNvPGJyPgogwqAg wqAgwqAgwqAgwqAgwqB0YWtlIGFkdmFudGFnZSBvZiBwYXJhbGxlbGlzbS48YnI+Cjxicj4KIMKg IMKgIMKgIMKgIMKgIMKgJmd0OyBJIHRoaW5rIHlvdSYjMzk7cmUgd3JvbmcgdGhhdCBpdCBoYXMg dG8gY29zdCBtdWNoIG1vbmV5LiA/dnM/PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7IEl0IGNv c3RzIG1vbmV5IHRvIGhvc3QgYSBoaWdoIHBlcmZvcm1hbmNlIGFuZCBzY2FsYWJsZTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgYXNzZXQgc2VydmljZSBhbmQgYSBoaWdoIGJhbmR3aWR0aCBuZXR3b3Jr IHRvIGhhbmRsZSB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoHRyYWZmaWMuIO+/vUEgKmxvdCog b2YgbW9uZXkuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBJIHRoaW5rIHdoYXQgeW91JiMzOTtyZSBz YXlpbmcgaXM6ICZxdW90O0l0IGNvc3RzIGEgbG90IG9mIG1vbmV5IHRvPGJyPgogwqAgwqAgwqAg wqAgwqAgwqBidWlsZCBhIHNjYWxhYmxlIGFzc2V0IHNlcnZpY2UsIGJ1dCBpZiBhc3NldHMgYXJl IHNwcmVhZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgdGhyb3VnaG91dCB0aGUgaW50ZXJuZXQgdGhl eSBkb24mIzM5O3QgaGF2ZSB0byBiZSBzY2FsYWJsZS4mcXVvdDs8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoEJ1dCB0aGF0JiMzOTtzIG5vdCBxdWl0ZSByaWdodC4gWW91JiMzOTtyZSBvcGVuaW5nIHVw IGV2ZXJ5IGFzc2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqBzZXJ2ZXIgdG8gdGhlIFZXIGVxdWl2 YWxlbnQgb2YgYmVpbmcgc2xhc2hkb3R0ZWQsIHNvIGFyZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKg eW91IHN1cmUgeW91JiMzOTtyZSBub3QgZm9yY2luZyAqZXZlcnkqIGFzc2V0IHNlcnZpY2UgdG8g YmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoHNjYWxhYmxlIGFuZCBoYW5kbGUgYSBsb3Qgb2YgYmFu ZHdpdGggYW5kIG5ldHdvcmsgdHJhZmZpYz88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoEl0JiMzOTtz IHRoZSBleGFjdCBvcHBvc2l0ZSBvZiB5b3VyIGludGVudGlvbiwgYnV0IEkgdGhpbms8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoHRoYXQmIzM5O3MgdGhlIHJlc3VsdCwgYWxsIHRoZSBzYW1lLjxicj4K PGJyPgogwqAgwqAgwqAgwqAgwqAgwqBUaGlzIHBhcnRpY3VsYXIgZGVzaWduIGRlY2lzaW9uIGhh cyBhIGJpZyBlZmZlY3Qgb24gdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBlY29ub21pY3Mgb2Yg dGhlIFZXIGluZnJhc3RydWN0dXJlLiBJJiMzOTtkIHJhdGhlciB0aGU8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoGVjb25vbWljcyB0byB3b3JrIG91dCBzdWNoIHRoYXQgYSByZWdpb24gcHJvdmlkZXIg d2hvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqB3aXNoZXMgdG8gYnVpbGQgYSByZWdpb24gdGhhdCBz dXBwb3J0cyBhIHNtYWxsIHBvcHVsYXRpb24sPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBjYW4gZG8g c28gZWNvbm9taWNhbGx5LiBBIHJlZ2lvbiB0aGF0IHdhbnRzIHRvIGhvc3QgYTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgKmxhcmdlKiBwb3B1bGF0aW9uIGhhcyB0byBiZWFyIHRoYXQgY29zdCBvZiBw cm92aWRpbmcgdGhhdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgc2NhbGFibGUgYXNzZXQgc2Vydmlj ZS48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoEkgd2FudCB0aGUgZWNvbm9taWNzIG9mIGhvc3Rpbmcg YSBzbWFsbCBhc3NldCBzZXJ2aWNlIHRvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBiZSBhIG5vbi1p c3N1ZSAoYXMgdG8gYmVzdCBwcm9tb3RlIGNyZWF0aW9uIGFuZDxicj4KIMKgIMKgIMKgIMKgIMKg IMKgY3JlYXRpdml0eSkuIENyZWF0aW5nIGEgaGlnaCBiYXIgdG8gcHJvdmlkZSBhc3NldCBzZXJ2 aWNlczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgd2lsbCBtZWFuIHRoYXQgc2VydmljZSB3aWxsIGNv c3QgbW9uZXkgYW5kIHBlb3BsZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgc2hvdWxkbiYjMzk7dCBo YXZlIHRvIHBheSBtb25leSBqdXN0IHRvIGNyZWF0ZSBvciBvd24gVlc8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoG9iamVjdHMgKEkmIzM5O20gdXNpbmcgJiMzOTtvd24mIzM5OyBoZXJlIHRvIHJlZmVy IHRvIG1haW50YWluaW5nPGJyPgogwqAgwqAgwqAgwqAgwqAgwqB0aGVpciBleGlzdGVuY2UsIEkm IzM5O20gbm90IHRyeWluZyB0byBtYWtlIGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCYjMzk7bGVm dGlzdCYjMzk7LyYjMzk7Y29tbXVuaXN0JiMzOTsgc3RhdGVtZW50IGFib3V0IG93bmVyc2hpcCA7 KTxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAtIEl6enk8YnI+Cjxicj4KPGJyPgogwqAgwqAg wqAgwqAgwqAgwqBPbiBBcHIgMiwgMjAxMSwgYXQgMzo1OCBQTSwgTW9yZ2FpbmUgd3JvdGU6PGJy Pgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEl6enksIHdoZW4gZGVzaWduaW5nIGZvciBz Y2FsYWJpbGl0eSwgdGhlIG1vZGVsIHRvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBiZWFy IGluIG1pbmQgaXMgdGhhdCBvZiBzZWFzb25lZCB2aXJ0dWFsIHdvcmxkPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqB0cmF2ZWxlcnMgd2hvc2UgaW52ZW50b3JpZXMgY29udGFpbiBhc3NldHMg ZnJvbSBtYW55PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkaWZmZXJlbnQgd29ybGRzLCB0 aG9zZSBhc3NldHMgYmVpbmcgc2VydmVkIGJ5IG1hbnk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoGRpZmZlcmVudCBhc3NldCBzZXJ2aWNlcy4g77+9Qm90aCB3b3JsZHMgYW5kIGFzc2V0PGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzZXJ2aWNlcyBtYXkgaW5jbHVkZSBjb21tZXJjaWFs LCBjb21tdW5pdHksIGFuZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcGVyc29uYWwgc2Vy dmljZXMsIGFuZCBhcyB0aGUgbWV0YXZlcnNlIGdyb3dzLCB0aGF0PGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBzZXQgaXMgaGlnaGx5IGxpa2VseSB0byBiZWNvbWUgcHJvZ3Jlc3NpdmVseSBs ZXNzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBjbHVzdGVyZWQgYW5kIG1vcmUgZGl2ZXJz ZS48YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgV2hlbiB0aG9zZSBzZWFzb25lZCB0 cmF2ZWxlcnMgY2xpY2sgb24gYW4gYWR2ZXJ0aXNlZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgVlcgbGluayBhbmQgcGVyZm9ybSBhbiBpbnRlci13b3JsZCB0ZWxlcG9ydCB0byBvbmU8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHBhcnRpY3VsYXIgd29ybGQmIzM5O3MgcmVnaW9uIHRv IHNoYXJlIGFuIGV4cGVyaWVuY2UsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGVpciAm cXVvdDt3b3JuJnF1b3Q7IGFzc2V0cyAodGhlIG9ubHkgb25lcyBvZiBpbnRlcmVzdCB0byB0aGU8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHJlZ2lvbikgd2lsbCBjb250YWluIHJlZmVyZW5j ZXMgdG8gYXNzZXQgc2VydmljZXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNwcmVhZCB3 aWRlbHkgYWNyb3NzIHRoZSBJbnRlcm5ldC4g77+9VGhlIGZldGNoZXMgYnkgdGhlPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqB0cmF2ZWxlcnMmIzM5OyBjbGllbnRzIG9jY3VyIG92ZXIgbWFu eSBwYXJhbGxlbCBwYXRocyBmcm9tPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBjbGllbnRz IHRvIGFzc2V0IHNlcnZpY2VzLCBzbyBvbmUgY2FuIHJlYXNvbmFibHk8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoGV4cGVjdCByZWR1Y2VkIG5ldHdvcmsgY29udGVudGlvbiBhbmQgcmVkdWNl ZCBhc3NldDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2VydmVyIGxvYWRpbmcgYmVjYXVz ZSB0aGV5IGFyZSBib3RoIHNwcmVhZCBvdXQgb3Zlcjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgaG93ZXZlciBtYW55IGFzc2V0IHNlcnZpY2VzIGFyZSBiZWluZyByZWZlcmVuY2VkIGJ5PGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGUgb3ZlcmFsbCBzZXQgb2YgYXNzZXRzIGluIHRo ZSByZWdpb24uPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFRoaXMgaXMgdmVyeSBk aWZmZXJlbnQgdG8gdGhlIGNhc2Ugb2YgYSBwcm94eWluZzxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgcmVnaW9uLCB3aGljaCB3b3VsZCBnZXQgc2xhbW1lZCBmb3IgZXZlcnkgYXNzZXQgd29y bjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYnkgZXZlcnkgYXZhdGFyIHByZXNlbnQuIO+/ vUluIG91ciBjdXJyZW50IGFyY2hpdGVjdHVyZSw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oHJlZ2lvbnMgcnVuIG1hbnkgZGlmZmVyZW50IENQVS1pbnRlbnNpdmUgdGFza3MsPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBpbmNsdWRpbmcgcGh5c2ljcyBzaW11bGF0aW9uIGFuZCBzZXJ2 ZXItc2lkZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2NyaXB0aW5nLCBhbmQgYWJzb2x1 dGVseSBjYW5ub3QgYWZmb3JkIHRvIHNlcnZlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBh c3NldHMgdG9vIHVubGVzcyB5b3VyIHNjYWxhYmlsaXR5IHJlcXVpcmVtZW50cyBhcmU8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoHZlcnkgbG93IGluZGVlZCwgaWUuIGp1c3QgYSBmZXcgZG96 ZW4gYXZhdGFycyBvZjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdG9kYXkmIzM5O3Mga2lu ZC4g77+9V2UmIzM5O3ZlIGhpdCB0aGUgY2VpbGluZyBhbHJlYWR5IG9uIHJlZ2lvbjxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgc2NhbGFiaWxpdHkgZG9uZSB0aGF0IHdheS4g77+9VGhlcmUg aXMgbm93aGVyZSB0byBnbyBpbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdGhhdCBkaXJl Y3Rpb24gYXQgYWxsIGJleW9uZCBpbXByb3ZpbmcgdGhlIGNvZGUgbGlrZTxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgSW50ZWwgZGVtb25zdHJhdGVkLCBhbmQgdGhhdCB3b3JrIGlzIHN1Ympl Y3QgdG8gYSBsYXc8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG9mIGRpbWluaXNoaW5nIHJl dHVybnMuPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFRoaXMgaXMgd2h5IHdlIGhh dmUgdG8gZ28gcGFyYWxsZWwsIGFuZCBJIHRoaW5rIHlvdSYjMzk7cmU8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoHdyb25nIHRoYXQgaXQgaGFzIHRvIGNvc3QgbXVjaCBtb25leS4g77+9QXMg d2Ugc3ByZWFkPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGUgbG9hZCBhY3Jvc3MgbW9y ZSBhbmQgbW9yZSBhc3NldCBzZXJ2aWNlcywgd2UgYXJlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqBzaW1wbHkgYmV0dGVyIHV0aWxpemluZyBhbGwgdGhlIGhhcmR3YXJlIHRoYXQmIzM5O3M8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGFscmVhZHkgb3V0IHRoZXJlIG9uIHRoZSBJbnRl cm5ldCwgYXQgbGVhc3QgaW4gcmVzcGVjdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgb2Yg Y29tbXVuaXR5IGFuZCBwcml2YXRlIHJlc291cmNlcy4g77+9QnV0IGFkZCB0byB0aGU8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNvbW11bml0eSBhbmQgcHJpdmF0ZSByZXNvdXJjZXMgdGhl IGNvbW1lcmNpYWwgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNlcnZpY2VzIHRo YXQgYXJlIGxpa2VseSB0byBhcHBlYXIgdG8gZXhwbG9pdCB0aGlzPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBvcHBvcnR1bml0eSwgYW5kIG5vdCBvbmx5IHdpbGwgdGhlIG51bWJlciBvZiBh c3NldDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2VydmljZXMgbGVhcCwgYnV0IHRoZSBw b3dlciBvZiBlYWNoIG9uZSB3aWxsIHJvY2tldDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg dG9vLCBiZWNhdXNlLCBhZnRlciBhbGwsIHRoZXNlIGJ1c2luZXNzZXMgd2lsbCBiZTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgaGVhdmlseSBvcHRpbWl6ZWQgZm9yIHRoZSBqb2IuPGJyPgo8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEFzIHRvIHdoeSBhIHdvcmxkIHdvdWxkIHdhbnQg Y2xpZW50cyB0byBhY2Nlc3M8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGV4dGVybmFsIGFz c2V0IHNlcnZpY2VzIGluc3RlYWQgb2YgcHJvdmlkaW5nIGl0cyBvd248YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoGltcGxlbWVudGF0aW9uLCB0aGF0JiMzOTtzIGFuIGVhc3kgcXVlc3Rpb24u IO+/vUl0IGNvc3RzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBtb25leSB0byBob3N0IGEg aGlnaCBwZXJmb3JtYW5jZSBhbmQgc2NhbGFibGUgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoHNlcnZpY2UgYW5kIGEgaGlnaCBiYW5kd2lkdGggbmV0d29yayB0byBoYW5kbGUgdGhl PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0cmFmZmljLiDvv71BICpsb3QqIG9mIG1vbmV5 LiDvv71JbiBjb250cmFzdCwgaXQgY29zdHMgYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg d29ybGQgbm90aGluZyB0byBsZXQgb3RoZXJzIHNlcnZlIHRoZSBhc3NldHMgdG88YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoGNsaWVudHMuIO+/vUFuZCB0aGF0IG1hdHRlcnMgdG8gdGhlIGJv dHRvbSBsaW5lLjxicj4KPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoE1vcmdhaW5l Ljxicj4KPGJyPgo8YnI+Cjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqA9PT09PT09 PT09PT09PT09PT09PT09PGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoE9uIFNhdCwg QXByIDIsIDIwMTEgYXQgNzowNSBQTSwgSXp6eSBBbGFuaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCZsdDs8YSBocmVmPSJtYWlsdG86aXp6eWFsYW5pc0BnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5penp5YWxhbmlzQGdtYWlsLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86aXp6eWFsYW5pc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5penp5YWxhbmlzQGdtYWls LmNvbTwvYT4mZ3Q7PGJyPjwvZGl2PjwvZGl2PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzppenp5YWxhbmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPml6enlhbGFuaXNAZ21haWwuY29tPC9hPjxkaXY+PGRpdj48L2Rpdj48ZGl2IGNsYXNzPSJo NSI+PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0 bzppenp5YWxhbmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPml6enlhbGFuaXNAZ21haWwu Y29tPC9hPiZndDsmZ3Q7Jmd0OyB3cm90ZTo8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKg77+9IO+/vSZndDsgQXMgYWx3YXlzIHRob3VnaCwgaXQmIzM5O3MgYSB0cmFkZS1vZmYsIHNp bmNlIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcHJveGllZCBkZXNpZ248YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71oYXMgdmVyeSBwb29yIHNjYWxhYmlsaXR5IGNv bXBhcmVkIHRvIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZGlzdHJpYnV0ZWQgb25l Ljxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9SSBkb24mIzM5O3QgYWdy ZWUgd2l0aCB0aGF0Li4uIElmIGEgdXNlciBlbnRlcnMgYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgaGlnaGx5IHBvcHVsYXRlZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vXJlZ2lvbiw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71ldmVyeSBvdGhlciBj bGllbnQgaXMgZ29pbmcgdG8gKGNvdWxkIGFuZCBzaG91bGQgYmU8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHRyeWluZyB0byk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71o aXQgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9YXNzZXQgc2VydmVyKHMp IGZvciB0aGUgYXNzZXRzIHRoYXQgdGhlIHVzZXIgaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHdlYXJpbmcgKGFzc3VtaW5nPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 dGhleSYjMzk7cmUgbm90IGNhY2hlZCBsb2NhbGx5KS4g77+9RXZlcnkgYXNzZXQgc2VydmVyPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBoYXMgdG8gYmUgc2NhbGVkIHVwPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dG8gdGhlIHBvaW50IHRoYXQgaXQgY2FuIGhhbmRsZSB0 aGF0IGxvYWQgZnJvbSBhbGw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG92ZXIuLi48YnI+ Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vUlmIEkmIzM5O20gaG9zdGluZyBh IHJlZ2lvbiB0aGF0IHN1cHBvcnRzIDEwcyBvZjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg dGhvdXNhbmRzIG9mPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c2ltdWx0YW5l b3VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dXNlcnMgKHRoaW5raW5nIG9m IHRoZSBmdXR1cmUpLCBJIGFscmVhZHkgaGF2ZSB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgc2NhbGUgdG8gbWVldCB0aGF0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 ZGVtYW5kLiBJZiB0aGUgcmVnaW9uIGlzIHByb3h5aW5nIHRoZSBhc3NldHMsIHRoZW4sPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB5ZXMgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqDvv70g77+9cmVnaW9uIGhhczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXRv IGJlIHNjYWxlZCB0byBtZWV0IHRoYXQgYXNzZXQgZGVtYW5kIHRvbywgYnV0IGl0PGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBhbHJlYWR5IGhhcyB0byBiZTxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vXNjYWxlZCB0byBtZWV0IG90aGVyIGRlbWFuZHMgb2YgYmVpbmcgYSBy ZWdpb248YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNlcnZlci4uLiBhbmQgd2h5IGlzPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c2NhbGluZyB0aG9zZSBhc3NldCBwcm94 eSBzZXJ2aWNlcyBoYXJkPyDvv71JdCYjMzk7czxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg Z29pbmcgdG8gY29zdCAkLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWJ1dCBp czxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vW5vdCB0ZWNobmljYWxseSBjaGFs bGVuZ2luZy4gU28sIGlmIEkgd2FudCB0byBob3N0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqBhIHJlZ2lvbiBsaWtlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dGhhdC4u LiBzdXJlIGl0IHdpbGwgY29zdCBtZSwgYnV0IHRoZSBzaW11bGF0aW9uPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqB3aWxsIGJlIGNvbnNpc3RlbnQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv71hbmQgdXNlcnMgd2lsbCBiZSBhYmxlIHRvIHBhcnRpY2lwYXRlIGVxdWFsbHks PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqByZWdhcmRsZXNzIG9mIHRoZTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWNhcGFiaWxpdGllcyBvZiB0aGVpciBpbmRpdmlkdWFs IGFzc2V0IHNlcnZpY2VzLjxicj4KPGJyPgo8YnI+Cjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqDvv70g77+9T24gRnJpLCBBcHIgMSwgMjAxMSBhdCAxMTo1NSBQTSwgTW9yZ2FpbmU8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mbHQ7PGEgaHJlZj0ibWFpbHRvOm1v cmdhaW5lLmRpbm92YUBnb29nbGVtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vcmdhaW5lLmRp bm92YUBnb29nbGVtYWlsLmNvbTwvYT48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vcmdhaW5lLmRpbm92YUBnb29nbGVtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPm1vcmdhaW5lLmRpbm92YUBnb29nbGVtYWlsLmNvbTwvYT4mZ3Q7PGJyPjwv ZGl2PjwvZGl2PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tPC9hPjxkaXY+PGRpdj48L2Rpdj48ZGl2 IGNsYXNzPSJoNSI+PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhy ZWY9Im1haWx0bzptb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5tb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb208L2E+Jmd0OyZndDsmZ3Q7IHdyb3RlOjxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgRXZlcnkgZGVzaWduIGNob2lj ZSByZXN1bHRzIGluIGEgdHJhZGUtb2ZmLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgVmF1 Z2huLCBpbXByb3Zpbmc8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71vbmUgdGhp bmcgYXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IHRoZSBleHBlbnNl IG9mIHNvbWV0aGluZyBlbHNlLiDvv71JZiBldmVyeSB0aW1lIHdlPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBvZmZlcmVkIGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71z ZXJ2aWNlIHdlIGhhZCB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsg aW5mb3JtIGl0cyB1c2VycyBhYm91dCB0aGUgZG93bnNpZGVzIG9mIGFsbCB0aGU8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHRyYWRlLW9mZnMgd2U8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv71oYXZlIG1hZGUsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 Jmd0OyB0aGV5IHdvdWxkIGhhdmUgYW4gYXdmdWwgbG90IHRvIHJlYWQuIDstKTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv70mZ3Q7IFRoZSBzcGVjaWZpYyB0cmFkZS1vZmYgdGhhdCB5b3UgYXJlIGRpc2N1c3Np bmcgaXMgbm88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71kaWZmZXJlbnQuIO+/ vUEgcmVnaW9uPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyB0aGF0IHBy b3hpZXMgYWxsIGNvbnRlbnQgaGFzIHRoZSAmcXVvdDtiZW5lZml0JnF1b3Q7IG9mPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBhY3F1aXJpbmcgY29udHJvbDxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vWZyb20gdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9Jmd0OyBhc3NldCBzZXJ2ZXJzIG92ZXIgdGhlIGl0ZW1zIGluIHRoZSByZWdpb24sIHNvPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGF0IGl0IGNhbjxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vWVuc3VyZSB0aGF0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDv v70g77+9Jmd0OyBldmVyeW9uZSBpbiB0aGUgcmVnaW9uIG5vdCBvbmx5IG9idGFpbnMgdGhlIGl0 ZW1zPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBidXQgb2J0YWluczxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKg77+9IO+/vXRoZSBzYW1lIGl0ZW1zPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqDvv70g77+9Jmd0OyBhcyBldmVyeW9uZSBlbHNlLiDvv71UaGF0IGRvZXMgaW5kZWVk IHByb3ZpZGUgYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZ3JlYXRlciBndWFyYW50ZWUg b2Y8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGNvbnNpc3RlbmN5IHRo YW4gYSBkZXBsb3ltZW50IGluIHdoaWNoIHRoZSByZWdpb248YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoG9ubHkgcGFzc2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9YXNz ZXQgVVJJcyB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgY2xpZW50 cyB3aG8gdGhlbiBmZXRjaCB0aGUgaXRlbXMgZnJvbSBhc3NldCBzZXJ2aWNlczxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXNlcGFyYXRlbHkuIO+/vUFzIGFsd2F5czxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgdGhvdWdoLCBpdCYjMzk7cyBhIHRyYWRl LW9mZiwgc2luY2UgdGhlIHByb3hpZWQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGRlc2ln biBoYXMgdmVyeTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXBvb3Igc2NhbGFi aWxpdHk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGNvbXBhcmVkIHRv IHRoZSBkaXN0cmlidXRlZCBvbmUuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgSWYgd2UmIzM5O3Jl IGdvaW5nIHRvIHdhcm4gdXNlcnMgb2YgdGhlIHBvdGVudGlhbCBmb3I8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoGluY29uc2lzdGVuY3k8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv71pbiB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGRpc3Ry aWJ1dGVkIGRlcGxveW1lbnQgYXMgeW91IHN1Z2dlc3QsIGFyZSB3ZTxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgYWxzbyBnb2luZyB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vXdhcm4gdGhlbSBvZjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsg bm9uLXNjYWxhYmlsaXR5IGluIHRoZSBwcm94aWVkIG9uZT8g77+9SSByZWFsbHk8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoGRvbiYjMzk7dCBzZWUgbXVjaDxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vW1lcml0IGluIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vSZndDsgaWRlYSBvZiB3YXJuaW5nIGFib3V0IGRlc2lnbiBjaG9pY2VzLiDvv71NYW55 IHN1Y2g8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNob2ljZXMgYXJlPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dGVjaG5pY2FsLCBhbmQ8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoO+/vSDvv70mZ3Q7IHRoZSBpc3N1ZXMgYXJlIHF1aXRlIGxpa2VseSB0byBiZSBv ZiBsaXR0bGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGludGVyZXN0IHRvPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9bm9uLXRlY2huaWNhbCB1c2Vyczxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgYW55d2F5LiDvv71JbiBhbnkgY2FzZSwgdGhl IGJldHRlciBzZXJ2aWNlcyBhcmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGxpa2VseSB0 byBwcm92aWRlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c3VjaDxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgaW5mb3JtYXRpb24gaW4gdGhlaXIgb25s aW5lIGRvY3VtZW50YXRpb24sIEk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHdvdWxkIGd1 ZXNzLjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IFlvdSBtZW50aW9uZWQgdXNlcnMgJnF1b3Q7dm90 aW5nIHdpdGggdGhlaXIgZmVldCZxdW90OyBvcjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg Y2hvb3NpbmcgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71hY2NlcHQgdGhl IHJpc2s8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IG9mIGluY29uc2lz dGVuY3kuIO+/vVdlbGwgdGhhdCB3aWxsIGhhcHBlbiBhbnl3YXksPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqB3aGVuIHNlcnZpY2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9ZmFpbCBhbmQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IHVzZXJz IGdldCBhbm5veWVkLiDvv71JZiBzb21lIGFzc2V0IHNlcnZpY2VzIHJlZnVzZTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgdG8gc2VuZCB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv71yZXF1ZXN0ZWQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7 IGl0ZW1zIHRvIHNvbWUgdXNlcnMsIHRob3NlIHNlcnZpY2VzIHdpbGwgZ2V0IGE8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoGJhZCByZXB1dGF0aW9uPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9YW5kIHBlb3BsZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vSZndDsgd2lsbCBjaG9vc2UgZGlmZmVyZW50IGFzc2V0IHNlcnZpY2VzIGluc3RlYWQuPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv71MaWtld2lzZSwgaWYgYTxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vXdvcmxkIHNlcnZpY2U8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv70mZ3Q7IHByb3hpZXMgZXZlcnl0aGluZyBhbmQgc28gaXQgY2FuJiMzOTt0IGhh bmRsZSBhIGxhcmdlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBudW1iZXIgb2Y8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71hc3NldHMgb3Igb2Y8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IHBlb3BsZSwgdXNlcnMgd2lsbCBnZXQgYW5ub3llZCBh dCB0aGUgbGFnIGFuZCB3aWxsIGdvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 ZWxzZXdoZXJlLiDvv71UaGlzIHVzZXI8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDv v70mZ3Q7IGV2YWx1YXRpb24gYW5kICZxdW90O3ZvdGluZyB3aXRoIHRoZWlyIGZlZXQmcXVvdDsg aGFwcGVuczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYWxyZWFkeSB3aXRoPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9b25saW5lIHNlcnZpY2VzPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBhbGwgb3ZlciB0aGUgSW50ZXJuZXQsIGFuZCBJIGFt IHN1cmUgdGhhdCB0aGlzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBodW1hbiBwcm9jZXNz PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9d2lsbCBjb250aW51ZTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgdG8gd29yayB3aGVuIHRoZSBzZXJ2aWNl cyBhcmUgYXNzZXQgYW5kIHJlZ2lvbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2Vydmlj ZXMuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgQmFjayBpbiBTZXB0ZW1iZXIgMjAxMCwgSSB3cm90 ZSB0aGlzIHBvc3Qgd2hpY2g8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHByb3Bvc2VzIHRo YXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv713ZSB1c2UgaW48YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IFZXUkFQIGEgZm9ybSBvZiBhc3NldCBhZGRy ZXNzaW5nIHRoYXQgcHJvdmlkZXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG1hc3NpdmU8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71zY2FsYWJpbGl0eSBhdCB0aGU8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IHNhbWUgdGltZSBhcyBhIHZlcnkg aGlnaCBkZWdyZWUgb2YgcmVzaWxpZW5jZSAtLTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vTxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKg77+9PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL3Z3cmFwL2N1cnJlbnQvbXNnMDA0NjMuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi92d3JhcC9jdXJyZW50L21zZzAwNDYzLmh0 bWw8L2E+PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9LiDvv71JdCBpczxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgYmFzZWQgb24gdGhlIGNvbmNlcHQg b2YgdGhlIFVSSSBjb250YWluaW5nIGEgaG9zdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg cGFydCBhbmQgYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWhhc2ggcGFydCw8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IHdoZXJlIHRoZSBoYXNoIGlz IGdlbmVyYXRlZCAob25jZSwgYXQgdGhlIHRpbWUgb2Y8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHN0b3JhZ2UgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv710aGUgYXNz ZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IHNlcnZpY2UpIHVzaW5n IGEgc3BlY2lmaWVkIGRpZ2VzdCBhbGdvcml0aG0gb3Zlcjxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgdGhlIGNvbnRlbnQgb2Y8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv710 aGUgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGJlaW5nIHJl ZmVyZW5jZWQuIO+/vVlvdSBtYXkgd2lzaCB0byBub3RlIHRoYXQgaWY8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoHRoaXMgZGVzaWduPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9d2VyZSB1c2VkLCB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7 IGZhaWx1cmUgb2YgYW4gYXNzZXQgc2VydmljZSB0byBkZWxpdmVyIGE8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoHJlcXVlc3RlZCBpdGVtIHdvdWxkPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9cmVzdWx0IGluIGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDv v70mZ3Q7IGZhaWxvdmVyIHJlcXVlc3QgZm9yIHRoZSBpdGVtIHRvIG9uZSBvciBtb3JlPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBiYWNrdXAgc2VydmljZXMsPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqDvv70g77+9dXNpbmcgdGhlIHNhbWU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv70mZ3Q7IGhhc2ggcGFydCBidXQgd2l0aCBhIGRpZmZlcmVudCBob3N0IGFkZHJl c3MuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgVGhpcyBjYW4gZ28gc29tZSB3YXkgdG93YXJkcyBv dmVyY29taW5nIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcHJvYmxlbSB0aGF0IHlv dTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXRoaW5rIG1pZ2h0PGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBvY2N1ciB3aGVuIGFzc2V0cyBhcmUgZmV0 Y2hlZCBieSBjbGllbnRzIGZyb208YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGFzc2V0IHNl cnZpY2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9ZGlyZWN0bHkuPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBBbHRob3VnaCBpdCB3b24mIzM5O3Qg aGVscCB3aGVuIHRoZSBtaXNzaW5nIGl0ZW0gaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oGF2YWlsYWJsZSBmcm9tPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9b25seSBh IHNpbmdsZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgYXNzZXQgc2Vy dmljZSwgaXQgd2lsbCBoZWxwIGluIG1hbnkgb3RoZXIgY2FzZXMsPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBhbmQgaXQgd2lsbDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vWNvbXBlbnNhdGUgZm9yPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBz ZXJ2aWNlIGZhaWx1cmVzIGFuZCBuZXR3b3JrIG91dGFnZXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoGF1dG9tYXRpY2FsbHkgYXQgdGhlIHNhbWU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv710aW1lLjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IFBTLiBUaGlzIGRlc2lnbiBm b3IgaGFzaC1iYXNlZCBhc3NldCBhZGRyZXNzaW5nPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqBpcyBhbHJlYWR5PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9YmVpbmcgdGVz dGVkIGJ5PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBNb2ppdG8gU29y YmV0IGluIGhlciBleHBlcmltZW50YWwgd29ybGQgYW5kPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqBjbGllbnQuIO+/vUl0IHdvdWxkIGdpdmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv70mZ3Q7IFZXUkFQLWJhc2VkIHdvcmxkcyBhbiBpbXByb3ZlZCBsZXZlbCBvZiBzZXJ2 aWNlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhdmFpbGFiaWxpdHksPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c28gSSB0aGluayBpdDxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vSZndDsgc2hvdWxkIGJlIGEgY29yZSBmZWF0dXJlIG9mIG91ciBwcm90 b2NvbC48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vSZndDsgTW9yZ2FpbmUuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDv v70g77+9Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgPT09PT09 PT09PT09PT09PT09PT09PT09PT09PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgT24gRnJpLCBBcHIg MSwgMjAxMSBhdCAxMToxNyBQTSwgVmF1Z2huIERlbHVjYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vSZsdDs8YSBocmVmPSJtYWlsdG86dmF1Z2huLmRlbHVjYUBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj52YXVnaG4uZGVsdWNhQGdtYWlsLmNvbTwvYT48YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZhdWdobi5kZWx1Y2FA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmF1Z2huLmRlbHVjYUBnbWFpbC5jb208L2E+Jmd0 Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 dmF1Z2huLmRlbHVjYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj52YXVnaG4uZGVsdWNhQGdt YWlsLmNvbTwvYT48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOnZhdWdobi5kZWx1Y2FAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmF1Z2hu LmRlbHVjYUBnbWFpbC5jb208L2E+Jmd0OyZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Jmd0OyB3cm90ZTo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDv v70mZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IFRo aXMgaXMgYSBxdWVzdGlvbiBpIGRpc2N1c3NlZCB3aXRoIE1vcmdhaW5lPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqBvZmYtbGlzdCBhIHdoaWxlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqDvv70g77+9YWdvIChJPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZn dDsgaW50ZW5kZWQgdG8gc2VuZCBpdCB0byB0aGUgbGlzdCBidXQgcHVzaGVkIHRoZTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgd3JvbmcgYnV0dG9uLi4uKSBJPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgdGhpbmsgd2UgbmVlZCB0byBhZGRyZXNzIHRoaXMg cHJvYmxlbSwgYW5kPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkZWNpZGUgaG93IHRvIGRl YWw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv713aXRoIGl0Ljxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Jmd0OyZndDsg77+9SW4gRGF2aWRzIGRlcGxveW1lbnQgZHJhZnQsIHNlY3Rp b24gNy4zLjEuMSBhbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgb3ZlcnZpZXcgaXM8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71naXZlbiB2YW48YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyB3YXlzIHRvIGRlbGl2ZXIgY29udGVudCB0byB0 aGUgcmVnaW9uLiBPbmUgd2F5PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpcyBvbmx5IHBh c3NpbmcgYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IGNhcGFi aWxpdHkgdGhhdCBhbGxvd3MgYWNjZXNzIHRvIChwYXJ0IG9mKSB0aGU8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoHJlc291cmNlOjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vSZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsg77+9 IO+/vSDvv70g77+9IO+/vSA3LjMuMS4xLiDvv71Db250ZW50IGRlbGl2ZXJ5IG1vZGVsczxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/vSDvv70g77+9IO+/vSDv v70gQSByYW5nZSBvZiBwb3NzaWJsZSByZXByZXNlbmF0aW9ucyBjYW48YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoGJlIHBhc3NlZCB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vWEgcmVnaW9uIGZvcjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsm Z3Q7IO+/vSDvv70g77+9IO+/vSDvv70gc2ltdWxhdGlvbi4gWy4uLl0gVGhlIG90aGVyIGVuZCBv ZiB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGRlbGl2ZXJ5IHNwZWN0cnVtPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgaW52b2x2ZXMgcGFzc2luZzxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/vSDvv70g77+9IO+/ vSDvv70gb25seSBhIFVSSSBvciBjYXBhYmlsaXR5IHVzZWQgdG88YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoGFjY2VzcyB0aGUgcmVuZGVyaW5nPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqDvv70g77+9Jmd0OyZndDsgaW5mb3JtYXRpb24gYW5kIGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/vSDvv70g77+9IGNvbGxpc2lvbiBtZXNo LGFuZCByZWxhdGVkIGRhdGEgZm9yPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBwaHlzaWNh bCBzaW11bGF0aW9uLjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7 IO+/vSDvv70g77+9IO+/vSDvv70gSW4gc3VjaCBhIG1vZGVsLCB0aGUgY2xpZW50IGlzPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqByZXNwb25zaWJsZSBmb3I8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoO+/vSDvv71mZXRjaGluZyB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv70mZ3Q7Jmd0OyBhZGRpdGlvbmFsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDv v70g77+9Jmd0OyZndDsg77+9IO+/vSDvv70g77+9IO+/vSBpbmZvcm1hdGlvbiBuZWVkZWQgdG8g cmVuZGVyIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaXRlbSYjMzk7cyB2aXN1YWw8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71wcmVzZW5jZSBmcm9tIGE8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBzZXBhcmF0ZTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/vSDvv70g77+9IO+/vSDvv70gc2Vy dmljZS4g77+9VGhpcyBmZXRjaCBjYW4gYmUgZG9uZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgKnVuZGVyIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWNyZWRlbnRp YWxzIG9mIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IGVu ZCB1c2VyKjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/vSDv v70g77+9IO+/vSDvv70gdmlld2luZyB0aGUgbWF0ZXJpYWwgW215IGVtcGhhc2lzLS1WRF08YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCwgYW5kPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqDvv70g77+9ZGl2b3JjZXMgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 Jmd0OyZndDsgc2ltdWxhdGlvbiBmcm9tPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9Jmd0OyZndDsg77+9IO+/vSDvv70g77+9IO+/vSB0aGUgdHJ1c3QgY2hhaW4gbmVlZGVkIHRv IG1hbmFnZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgY29udGVudC4g77+9QW55PGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9YXV0b21hdGlvbjxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IGlzIGRvbmUgb24gYTxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/vSDvv70g77+9IO+/vSDvv70gc2VwYXJhdGUg aG9zdCB3aGljaCB0aGUgY29udGVudDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgY3JlYXRv ciBvciBvd25lciB0cnVzdHMsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0 OyZndDsgaW50ZXJhY3Rpbmcgd2l0aCB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/vSDvv70g77+9IG9iamVjdCB0aHJvdWdoIHJlbW90ZWQg aW50ZXJmYWNlcy48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0Ozxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/vUkgY2FuIHNlZSB0 aGUgbmVlZCBmb3Igc3VjaCBhIHNldHVwLCBob3dldmVyLCBpPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBmZWVsIHdlIGFyZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZn dDsmZ3Q7IHVucGxlYXNhbnRseSBjbG9zZSB0byBhIHNpdHVhdGlvbiB3ZXJlIHRoZTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgY29oZXJlbmNlIG9mIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vXNpbXVsYXRpb248YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv70mZ3Q7Jmd0OyBmYWxscyBhcGFydC48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv70mZ3Q7Jmd0OyBJbiB0aGlzIGRlcGxveW1lbnQgcGF0dGVybiB0aGUgcmVnaW9uIGFkdmVy dGlzZXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRoZSBwcmVzZW5jZTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vW9mIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKg77+9IO+/vSZndDsmZ3Q7IGFzc2V0LCBhbmQgKnNvbWUqIGNsaWVudHMgd2lsbCBiZSBhYmxl IHRvIGdldCBpdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYXMgZXhwZWN0ZWQsPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9d2hpbGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyAtYmFzZWQgb24gdGhlIGFyYml0cmFyeSB3aGltcyBvZiB0 aGUgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNlcnZpY2UtIG90aGVyczxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vW1pZ2h0IG5vdC48YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vSZndDsmZ3Q7IE15IGhvcGUgd291bGQgYmUgdGhhdCBhZnRlciB0aGUgYXNzZXQgc2Vy dmVyPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBwcm92aWRlcyB0aGU8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv71yZWdpb24gd2l0aDxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vSZndDsmZ3Q7IHRoZSBjYXBhYmlsaXR5IHRvIGdldCB0aGUgYXNzZXQsIGl0 IGdpdmVzIHVwPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBjb250cm9sLiBUaGF0PGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9d291bGQgbWVhbjxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHRoYXQgaWYgdGhlIGNsaWVudCBmaW5kcyB0aGUg aW52ZW50b3J5IHNlcnZlciBpczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdW53aWxsaW5n IHRvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c2VydmU8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyB0aGUgY29udGVudCAtIGluIHNwaXJlIG9m IHRoZSByZWdpb24gc2F5aW5nIGl0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpcyBwcmVz ZW50LSw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv710aGUgY2xpZW50PGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgc2hvdWxkIGJlIGFibGUgdG8g dHVybiBhcm91bmQgYXNrIHRoZSAqcmVnaW9uKjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg Zm9yIHRoZSBhc3NldCw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70oYW5kIGdl dDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IGlzIGFmdGVyIGFs bCkuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDs8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv71JZiB0aGF0IGlzIG5vdCB0aGUg Y2FzZSwgLWFuZCB0aGVyZSBhcmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHByb2JhYmx5 IGdvb2QgcmVhc29uczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWZvciB0aGU8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBkZXBsb3ltZW50IHBh dHRlcm4gYXMgZGVzY3JpYmVkLSDvv71zaG91bGRuJiMzOTt0IHdlPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAqd2FybiogY2xpZW50czxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vXRoYXQgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsg cmVnaW9uIG1pZ2h0IGJlIGluY29uc2lzdGVudCwgc28gdGhlIHVzZXJzPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqBiZWhpbmQgdGhlIGNsaWVudDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKg77+9IO+/vWNhbiB2b3RlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0 OyZndDsgd2l0aCB0aGVpciBmZWV0LCAob3IgdGFrZSB0aGUgcmlzayk/PGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv70mZ3Q7Jmd0OyAtLVZhdWdobjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vSZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgdndyYXAgbWFp bGluZyBsaXN0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgPGEg aHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5v cmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+Jmd0Ozxicj48L2Rpdj48L2Rpdj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4m Z3Q7Jmd0OzxkaXYgY2xhc3M9ImltIj48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDv v70mZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Z3cmFwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby92d3JhcDwvYT48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vSZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IHZ3cmFw IG1haWxpbmcgbGlzdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgPGEg aHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5v cmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+Jmd0Ozxicj48L2Rpdj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7Jmd0 OzxkaXYgY2xhc3M9ImltIj48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdndyYXAiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Z3cmFw PC9hPjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgo8YnI+Cjxicj4KPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+CiDCoCDCoCDCoCDC oCDCoCDCoHZ3cmFwIG1haWxpbmcgbGlzdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgPGEgaHJlZj0i bWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+ ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+dndyYXBAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92d3JhcCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdndyYXA8L2E+PGJyPjwv ZGl2PjxkaXYgY2xhc3M9ImltIj4KIMKgIMKgIMKgIMKgIMKgIMKg77+9PGJyPgo8YnI+Cjxicj4K PGJyPgo8YnI+Cjxicj4KIMKgIMKgLS0gwqAgwqAgLS0tIDxhIGhyZWY9Imh0dHBzOi8vdHdpdHRl ci5jb20vRHpvbmF0YXNfU29sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90d2l0dGVyLmNvbS9E em9uYXRhc19Tb2w8L2E+IC0tLTxicj4KIMKgIMKgV2ViIERldmVsb3BtZW50LCBTb2Z0d2FyZSBF bmdpbmVlcmluZywgVmlydHVhbCBSZWFsaXR5LCBDb25zdWx0YW50PGJyPgo8YnI+CiDCoCDCoF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgogwqAgwqB2 d3JhcCBtYWlsaW5nIGxpc3Q8YnI+PC9kaXY+PGRpdiBjbGFzcz0iaW0iPgogwqAgwqA8YSBocmVm PSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwv YT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj52d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPgogwqAgwqA8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Z3cmFwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92d3JhcDwvYT48YnI+Cjxicj4KPGJyPgo8 L2Rpdj48L2Jsb2NrcXVvdGU+Cjxicj48ZGl2PjxkaXY+PC9kaXY+PGRpdiBjbGFzcz0iaDUiPgo8 YnI+Ci0tIDxicj4KLS0tIDxhIGhyZWY9Imh0dHBzOi8vdHdpdHRlci5jb20vRHpvbmF0YXNfU29s IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90d2l0dGVyLmNvbS9Eem9uYXRhc19Tb2w8L2E+IC0t LTxicj4KV2ViIERldmVsb3BtZW50LCBTb2Z0d2FyZSBFbmdpbmVlcmluZywgVmlydHVhbCBSZWFs aXR5LCBDb25zdWx0YW50PGJyPgo8YnI+Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPgp2d3JhcCBtYWlsaW5nIGxpc3Q8YnI+CjxhIGhyZWY9Im1haWx0 bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPjxicj4K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92d3JhcCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdndyYXA8 L2E+PGJyPgo8L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPgo= --00235429d8f4b76cb804a0070921-- From dzonatas@gmail.com Sun Apr 3 10:35:43 2011 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 53F8E3A6870 for ; Sun, 3 Apr 2011 10:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.231 X-Spam-Level: X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] 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 e0NONP88r4Zm for ; Sun, 3 Apr 2011 10:35:40 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 1C5653A6867 for ; Sun, 3 Apr 2011 10:35:40 -0700 (PDT) Received: by iwn39 with SMTP id 39so5940619iwn.31 for ; Sun, 03 Apr 2011 10:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pMbNAGrMq9+LD8/qyO4FFe/GtuXmEFUrrfBwcVzZB4k=; b=TFF6T/8lYE9mtQqzsBJvWlcqRDZuww76AH8q13yfoqcz4DDGupN1lFYVKmQyLa/xAa 2LSYOYS/fd1lDwEOY8jvVev99znhZ0nIxTAQidHkUmiLb+5ylEfpfTEaAwEKgjHnBX55 c6E1AwsvMtTOzPeOntHpHlyN1A1vjVAZYHU3o= 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=RDmNmDYDEgIgwnmaAPOPZ4MVkjwbsJLimngSgCTbPouXyi2PCQOBLND17EsewchLrl PI26SPdkMQcvrG0ZhNTbAWA2Ar2SsQOV8mtAzT9jArxBRRaqMQpGiZGD3ILU53nI8WMG b/uI87r5u+OSXwFyMeBNz0xm04mlTMYnFXGfM= Received: by 10.42.173.197 with SMTP id s5mr4991597icz.368.1301852241661; Sun, 03 Apr 2011 10:37:21 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id 13sm3114561ibo.25.2011.04.03.10.37.18 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Apr 2011 10:37:20 -0700 (PDT) Message-ID: <4D98B07E.8090601@gmail.com> Date: Sun, 03 Apr 2011 10:38:06 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 03 Apr 2011 17:35:43 -0000 I prefer the visualization of "domains" because those fluffy clouds really help those that don't do well with figure-of-speech "services." Morgaine wrote: > "Agent Domain" more or less ceased to exist in practice when David > pointed out very eloquently that the emperor had no clothes. (Same > for "Region Domain".) > > I think we mostly talk about the Agent Service and Region Service > these days. The "domain" was just a fluffy cloud that someone once > drew on a whiteboard, but which never actually existed. > > > Morgaine. > > > > > ==================== > > On Sun, Apr 3, 2011 at 6:20 PM, Dzonatas Sol > wrote: > > Probably easy as suggested in other terms here on this list, as > how the client contacts the asset services now in the regions. The > newer issue is to unitize that asset services. Since their is > proprietary (legacy) code then we can't expect that to change, and > some form of proxy is of need. Whatever works best, I tried to > narrow it down to suggestions here. > > Eventually, the agent domain is ideal to handle the direction of > the asset services. This concept, unfortunately, ended support > awhile ago with changes in LL. > Also see; http://wiki.secondlife.com/wiki/Agent_Domain > And: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset > (warn: unstructured collaborative notes, dumped on me and I tried > to fix) > > I tried to find previous visuals. > > I'd imagine the agent domain could grow out of unitized versions > of asset services. Despite that, I think that concept helps view > where we were at in discussion and what didn't happen. > > Vaughn Deluca wrote: > > Hi�Dzonatas > > Can you expand on that, what would be needed for legacy > support in VWAP terms�?, > If i want to read up on how the�asset server may proxy the > simulator, what would you recommend me to read? > > -- Vaughn > > On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol > > >> wrote: > > Some stated the proxy-to-asset-server is built into the sim; > however, keep in mind possible legacy support where the asset > server may proxy the simulator. > > > Dzonatas Sol wrote: > > Somehow I feel the basic asset server being able to > login and > download assets is now priority, yet I also wondered > the best > way to patch this into the current mode of viewers. > > Maybe offer (1) by proxy (sim-side) and (2) by patch > (viewer-side) that either of these two are optional and > neither are mandatory for now. Thoughts? > > Israel Alanis wrote: > > > > when designing for scalability, the model to bear in > mind is ... > > Well, there are a lot of different models to keep > in mind, > and many different use cases. One particular use > case to > keep in mind is: "User acquires new outfit, and > wants to > 'show it off' in a highly populated region". > > > Both worlds and asset services may include > commercial, > community, and personal services > > Yes, yes and yes. I'm particularly concerned about > how the > model affects the ability to host personal asset > services. > > > a proxying region, which would get slammed for every > asset worn by every avatar present. > > Granted the collection of services that are provided by > the region need to be scaled to meet the demands of > that > region. That's all part of capacity planning. > > > regions run many different CPU-intensive tasks, > including physics simulation and server-side scripting, > and absolutely cannot afford to serve assets too > Well... who said the same CPU's have to do proxying, > physics simulation and server-side scripting? Asset > proxying is a different service than physics simulation > and can be on separate hardware, could make use of > geographically distributed caching, and in certain > deployment patterns, the same caching services could be > shared by different regions. (Server-side scripting > is a > discussion for another day). > > > This is why we have to go parallel... > > Totally agree, and a proxying model could and > should also > take advantage of parallelism. > > > I think you're wrong that it has to cost much > money. ?vs? > > It costs money to host a high performance and > scalable > asset service and a high bandwidth network to > handle the > traffic. �A *lot* of money. > I think what you're saying is: "It costs a lot of > money to > build a scalable asset service, but if assets are > spread > throughout the internet they don't have to be > scalable." > But that's not quite right. You're opening up every > asset > server to the VW equivalent of being slashdotted, > so are > you sure you're not forcing *every* asset service to be > scalable and handle a lot of bandwith and network > traffic? > It's the exact opposite of your intention, but I think > that's the result, all the same. > > This particular design decision has a big effect on the > economics of the VW infrastructure. I'd rather the > economics to work out such that a region provider who > wishes to build a region that supports a small > population, > can do so economically. A region that wants to host a > *large* population has to bear that cost of > providing that > scalable asset service. > I want the economics of hosting a small asset > service to > be a non-issue (as to best promote creation and > creativity). Creating a high bar to provide asset > services > will mean that service will cost money and people > shouldn't have to pay money just to create or own VW > objects (I'm using 'own' here to refer to maintaining > their existence, I'm not trying to make a > 'leftist'/'communist' statement about ownership ;) > > - Izzy > > > On Apr 2, 2011, at 3:58 PM, Morgaine wrote: > > Izzy, when designing for scalability, the model to > bear in mind is that of seasoned virtual world > travelers whose inventories contain assets from > many > different worlds, those assets being served by many > different asset services. �Both worlds and asset > services may include commercial, community, and > personal services, and as the metaverse grows, that > set is highly likely to become progressively less > clustered and more diverse. > > When those seasoned travelers click on an > advertised > VW link and perform an inter-world teleport to one > particular world's region to share an experience, > their "worn" assets (the only ones of interest > to the > region) will contain references to asset services > spread widely across the Internet. �The fetches > by the > travelers' clients occur over many parallel > paths from > clients to asset services, so one can reasonably > expect reduced network contention and reduced asset > server loading because they are both spread out > over > however many asset services are being referenced by > the overall set of assets in the region. > > This is very different to the case of a proxying > region, which would get slammed for every asset > worn > by every avatar present. �In our current > architecture, > regions run many different CPU-intensive tasks, > including physics simulation and server-side > scripting, and absolutely cannot afford to serve > assets too unless your scalability requirements are > very low indeed, ie. just a few dozen avatars of > today's kind. �We've hit the ceiling already on > region > scalability done that way. �There is nowhere to > go in > that direction at all beyond improving the code > like > Intel demonstrated, and that work is subject to > a law > of diminishing returns. > > This is why we have to go parallel, and I think > you're > wrong that it has to cost much money. �As we spread > the load across more and more asset services, > we are > simply better utilizing all the hardware that's > already out there on the Internet, at least in > respect > of community and private resources. �But add to the > community and private resources the commercial > asset > services that are likely to appear to exploit this > opportunity, and not only will the number of asset > services leap, but the power of each one will > rocket > too, because, after all, these businesses will be > heavily optimized for the job. > > As to why a world would want clients to access > external asset services instead of providing > its own > implementation, that's an easy question. �It costs > money to host a high performance and scalable asset > service and a high bandwidth network to handle the > traffic. �A *lot* of money. �In contrast, it > costs a > world nothing to let others serve the assets to > clients. �And that matters to the bottom line. > > > Morgaine. > > > > > ====================== > > On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis > > > > > >>> wrote: > > � �> As always though, it's a trade-off, since the > proxied design > � �has very poor scalability compared to the > distributed one. > > � �I don't agree with that... If a user enters a > highly populated > � �region, > � �every other client is going to (could and > should be > trying to) > � �hit the > � �asset server(s) for the assets that the user is > wearing (assuming > � �they're not cached locally). �Every asset server > has to be scaled up > � �to the point that it can handle that load > from all > over... > > � �If I'm hosting a region that supports 10s of > thousands of > � �simultaneous > � �users (thinking of the future), I already > have to > scale to meet that > � �demand. If the region is proxying the > assets, then, > yes the > � �region has > � �to be scaled to meet that asset demand too, > but it > already has to be > � �scaled to meet other demands of being a region > server... and why is > � �scaling those asset proxy services hard? �It's > going to cost $, > � �but is > � �not technically challenging. So, if I want > to host > a region like > � �that... sure it will cost me, but the simulation > will be consistent > � �and users will be able to participate equally, > regardless of the > � �capabilities of their individual asset services. > > > > > � �On Fri, Apr 1, 2011 at 11:55 PM, Morgaine > � � > > > � � > > >>> wrote: > � �> Every design choice results in a trade-off, > Vaughn, improving > � �one thing at > � �> the expense of something else. �If every > time we > offered a > � �service we had to > � �> inform its users about the downsides of > all the > trade-offs we > � �have made, > � �> they would have an awful lot to read. ;-) > � �> > � �> The specific trade-off that you are > discussing is no > � �different. �A region > � �> that proxies all content has the "benefit" of > acquiring control > � �from the > � �> asset servers over the items in the region, so > that it can > � �ensure that > � �> everyone in the region not only obtains > the items > but obtains > � �the same items > � �> as everyone else. �That does indeed provide a > greater guarantee of > � �> consistency than a deployment in which the > region > only passes > � �asset URIs to > � �> clients who then fetch the items from > asset services > � �separately. �As always > � �> though, it's a trade-off, since the proxied > design has very > � �poor scalability > � �> compared to the distributed one. > � �> > � �> If we're going to warn users of the > potential for > inconsistency > � �in the > � �> distributed deployment as you suggest, are we > also going to > � �warn them of > � �> non-scalability in the proxied one? �I really > don't see much > � �merit in the > � �> idea of warning about design choices. > �Many such > choices are > � �technical, and > � �> the issues are quite likely to be of little > interest to > � �non-technical users > � �> anyway. �In any case, the better services are > likely to provide > � �such > � �> information in their online documentation, I > would guess. > � �> > � �> You mentioned users "voting with their > feet" or > choosing to > � �accept the risk > � �> of inconsistency. �Well that will happen > anyway, > when services > � �fail and > � �> users get annoyed. �If some asset services > refuse > to send the > � �requested > � �> items to some users, those services will get a > bad reputation > � �and people > � �> will choose different asset services instead. > �Likewise, if a > � �world service > � �> proxies everything and so it can't handle > a large > number of > � �assets or of > � �> people, users will get annoyed at the lag > and will go > � �elsewhere. �This user > � �> evaluation and "voting with their feet" > happens > already with > � �online services > � �> all over the Internet, and I am sure that this > human process > � �will continue > � �> to work when the services are asset and region > services. > � �> > � �> Back in September 2010, I wrote this post > which > proposes that > � �we use in > � �> VWRAP a form of asset addressing that provides > massive > � �scalability at the > � �> same time as a very high degree of > resilience -- > � �> > � > > �http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html > � �. �It is > � �> based on the concept of the URI containing > a host > part and a > � �hash part, > � �> where the hash is generated (once, at the > time of > storage to > � �the asset > � �> service) using a specified digest > algorithm over > the content of > � �the asset > � �> being referenced. �You may wish to note > that if > this design > � �were used, the > � �> failure of an asset service to deliver a > requested item would > � �result in a > � �> failover request for the item to one or more > backup services, > � �using the same > � �> hash part but with a different host address. > � �> > � �> This can go some way towards overcoming the > problem that you > � �think might > � �> occur when assets are fetched by clients from > asset services > � �directly. > � �> Although it won't help when the missing > item is > available from > � �only a single > � �> asset service, it will help in many other > cases, > and it will > � �compensate for > � �> service failures and network outages > automatically at the same > � �time. > � �> > � �> PS. This design for hash-based asset > addressing > is already > � �being tested by > � �> Mojito Sorbet in her experimental world and > client. �It would give > � �> VWRAP-based worlds an improved level of > service > availability, > � �so I think it > � �> should be a core feature of our protocol. > � �> > � �> > � �> Morgaine. > � �> > � �> > � �> > � �> > � �> =========================== > � �> > � �> On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca > � � > > > > >>> > � �> wrote: > � �>> > � �>> This is a question i discussed with Morgaine > off-list a while > � �ago (I > � �>> intended to send it to the list but > pushed the > wrong button...) I > � �>> think we need to address this problem, and > decide how to deal > � �with it. > � �>> > � �>> �In Davids deployment draft, section > 7.3.1.1 an > overview is > � �given van > � �>> ways to deliver content to the region. > One way > is only passing a > � �>> capability that allows access to (part > of) the > resource: > � �>> > � �>> � � � � � 7.3.1.1. �Content delivery models > � �>> � � � � � A range of possible > represenations can > be passed to > � �a region for > � �>> � � � � � simulation. [...] The other end > of the > delivery spectrum > � �>> involves passing > � �>> � � � � � only a URI or capability used to > access the rendering > � �>> information and a > � �>> � � � � � collision mesh,and related data for > physical simulation. > � �>> � � � � � In such a model, the client is > responsible for > � �fetching the > � �>> additional > � �>> � � � � � information needed to render the > item's visual > � �presence from a > � �>> separate > � �>> � � � � � service. �This fetch can be done > *under the > � �credentials of the > � �>> end user* > � �>> � � � � � viewing the material [my > emphasis--VD] > , and > � �divorces the > � �>> simulation from > � �>> � � � � � the trust chain needed to manage > content. �Any > � �automation > � �>> is done on a > � �>> � � � � � separate host which the content > creator or owner trusts, > � �>> interacting with the > � �>> � � � � � object through remoted interfaces. > � �>> > � �>> �I can see the need for such a setup, > however, i > feel we are > � �>> unpleasantly close to a situation were the > coherence of the > � �simulation > � �>> falls apart. > � �>> In this deployment pattern the region > advertises > the presence > � �of the > � �>> asset, and *some* clients will be able to > get it > as expected, > � �while > � �>> -based on the arbitrary whims of the asset > service- others > � �might not. > � �>> > � �>> My hope would be that after the asset server > provides the > � �region with > � �>> the capability to get the asset, it gives up > control. That > � �would mean > � �>> that if the client finds the inventory > server is > unwilling to > � �serve > � �>> the content - in spire of the region > saying it > is present-, > � �the client > � �>> should be able to turn around ask the > *region* > for the asset, > � �(and get > � �>> is after all). > � �>> > � �>> �If that is not the case, -and there are > probably good reasons > � �for the > � �>> deployment pattern as described- > �shouldn't we > *warn* clients > � �that the > � �>> region might be inconsistent, so the users > behind the client > � �can vote > � �>> with their feet, (or take the risk)? > � �>> > � �>> --Vaughn > � �>> > _______________________________________________ > � �>> vwrap mailing list > � �>> vwrap@ietf.org > > > > >> > > � �>> https://www.ietf.org/mailman/listinfo/vwrap > � �> > � �> > � �> > _______________________________________________ > � �> vwrap mailing list > � �> vwrap@ietf.org > > > > >> > > � �> https://www.ietf.org/mailman/listinfo/vwrap > � �> > � �> > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > https://www.ietf.org/mailman/listinfo/vwrap > � > > > > > > -- --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, > Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > https://www.ietf.org/mailman/listinfo/vwrap > > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Sun Apr 3 11:31:47 2011 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 635AF28C0DF for ; Sun, 3 Apr 2011 11:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] 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 k3ifDHJFoTG1 for ; Sun, 3 Apr 2011 11:31:41 -0700 (PDT) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by core3.amsl.com (Postfix) with ESMTP id C47643A6824 for ; Sun, 3 Apr 2011 11:31:40 -0700 (PDT) Received: by qwc9 with SMTP id 9so4899148qwc.27 for ; Sun, 03 Apr 2011 11:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=JAIKvhWerxrVCmFUAQn00rYQ7rA8cvcxqQkNfPbYZVw=; b=JXBL2CrwFIa5TzPNzin0PPPXK+GNjXKX/y06Z7G6Ug7dSTmmOp+PjTimNSESewPLD7 fyagMTuPWnieJ/6av5ew0LtNcmk3z4Wi56T5akAN9DACoXm/xM1wyd2h2VwyzkJ3uWzv 57N8JKB1h5/fMbLHl3+F5hKlhpyX/8zrDIzSw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=O8M0PWl+KmGHiH6mwpIryQdjCGcZMgUXQW8TqbgSTMRUFutzQvBs6Gh5wW46ygplZ9 2AIqkDUHgo3pAUQfqSl5+lYL2Xg3NYomlM64nUi8PbVAahO/b13HJA/n800LV8EecGNz vHyH9qRJeTL4KrW0bE/b9oKy0dqsYllN4VeFU= MIME-Version: 1.0 Received: by 10.229.105.82 with SMTP id s18mr717778qco.109.1301855517941; Sun, 03 Apr 2011 11:31:57 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sun, 3 Apr 2011 11:31:57 -0700 (PDT) In-Reply-To: <4D98B07E.8090601@gmail.com> References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> <4D98B07E.8090601@gmail.com> Date: Sun, 3 Apr 2011 19:31:57 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=002354470e60b21f0904a007dbf0 Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 03 Apr 2011 18:31:47 -0000 --002354470e60b21f0904a007dbf0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We have no "figure-of-speech services" in VWRAP. Our services are running processes, they have network endpoints, and they talk a network protocol. Concepts can be very useful, and I regularly draw fluffy clouds that represent the concept behind something concrete. Where concepts are not useful is when they denote something that doesn't actually exist, like say phlogiston, God, or Agent Domain, because this jus= t makes them a hindrance to further progress. Humanity suffers from this a lot. Philosophy aside, we want our Agent Service to be totally concrete, with a network API and well defined semantics. The domain concept does not get us there. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Sun, Apr 3, 2011 at 6:38 PM, Dzonatas Sol wrote: > I prefer the visualization of "domains" because those fluffy clouds reall= y > help those that don't do well with figure-of-speech "services." > > > Morgaine wrote: > >> "Agent Domain" more or less ceased to exist in practice when David point= ed >> out very eloquently that the emperor had no clothes. (Same for "Region >> Domain".) >> >> I think we mostly talk about the Agent Service and Region Service these >> days. The "domain" was just a fluffy cloud that someone once drew on a >> whiteboard, but which never actually existed. >> >> >> Morgaine. >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> On Sun, Apr 3, 2011 at 6:20 PM, Dzonatas Sol > dzonatas@gmail.com>> wrote: >> >> Probably easy as suggested in other terms here on this list, as >> how the client contacts the asset services now in the regions. The >> newer issue is to unitize that asset services. Since their is >> proprietary (legacy) code then we can't expect that to change, and >> some form of proxy is of need. Whatever works best, I tried to >> narrow it down to suggestions here. >> >> Eventually, the agent domain is ideal to handle the direction of >> the asset services. This concept, unfortunately, ended support >> awhile ago with changes in LL. >> Also see; http://wiki.secondlife.com/wiki/Agent_Domain >> And: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset >> (warn: unstructured collaborative notes, dumped on me and I tried >> to fix) >> >> I tried to find previous visuals. >> >> I'd imagine the agent domain could grow out of unitized versions >> of asset services. Despite that, I think that concept helps view >> where we were at in discussion and what didn't happen. >> >> Vaughn Deluca wrote: >> >> Hi=EF=BF=BDDzonatas >> >> Can you expand on that, what would be needed for legacy >> support in VWAP terms=EF=BF=BD?, >> If i want to read up on how the=EF=BF=BDasset server may proxy th= e >> simulator, what would you recommend me to read? >> >> -- Vaughn >> >> On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol >> >> >> wrote: >> >> Some stated the proxy-to-asset-server is built into the sim; >> however, keep in mind possible legacy support where the asset >> server may proxy the simulator. >> >> >> Dzonatas Sol wrote: >> >> Somehow I feel the basic asset server being able to >> login and >> download assets is now priority, yet I also wondered >> the best >> way to patch this into the current mode of viewers. >> >> Maybe offer (1) by proxy (sim-side) and (2) by patch >> (viewer-side) that either of these two are optional and >> neither are mandatory for now. Thoughts? >> >> Israel Alanis wrote: >> >> >> > when designing for scalability, the model to bear in >> mind is ... >> >> Well, there are a lot of different models to keep >> in mind, >> and many different use cases. One particular use >> case to >> keep in mind is: "User acquires new outfit, and >> wants to >> 'show it off' in a highly populated region". >> >> > Both worlds and asset services may include >> commercial, >> community, and personal services >> >> Yes, yes and yes. I'm particularly concerned about >> how the >> model affects the ability to host personal asset >> services. >> >> > a proxying region, which would get slammed for every >> asset worn by every avatar present. >> >> Granted the collection of services that are provided b= y >> the region need to be scaled to meet the demands of >> that >> region. That's all part of capacity planning. >> >> > regions run many different CPU-intensive tasks, >> including physics simulation and server-side scripting= , >> and absolutely cannot afford to serve assets too >> Well... who said the same CPU's have to do proxying, >> physics simulation and server-side scripting? Asset >> proxying is a different service than physics simulatio= n >> and can be on separate hardware, could make use of >> geographically distributed caching, and in certain >> deployment patterns, the same caching services could b= e >> shared by different regions. (Server-side scripting >> is a >> discussion for another day). >> >> > This is why we have to go parallel... >> >> Totally agree, and a proxying model could and >> should also >> take advantage of parallelism. >> >> > I think you're wrong that it has to cost much >> money. ?vs? >> > It costs money to host a high performance and >> scalable >> asset service and a high bandwidth network to >> handle the >> traffic. =EF=BF=BDA *lot* of money. >> I think what you're saying is: "It costs a lot of >> money to >> build a scalable asset service, but if assets are >> spread >> throughout the internet they don't have to be >> scalable." >> But that's not quite right. You're opening up every >> asset >> server to the VW equivalent of being slashdotted, >> so are >> you sure you're not forcing *every* asset service to b= e >> scalable and handle a lot of bandwith and network >> traffic? >> It's the exact opposite of your intention, but I think >> that's the result, all the same. >> >> This particular design decision has a big effect on th= e >> economics of the VW infrastructure. I'd rather the >> economics to work out such that a region provider who >> wishes to build a region that supports a small >> population, >> can do so economically. A region that wants to host a >> *large* population has to bear that cost of >> providing that >> scalable asset service. >> I want the economics of hosting a small asset >> service to >> be a non-issue (as to best promote creation and >> creativity). Creating a high bar to provide asset >> services >> will mean that service will cost money and people >> shouldn't have to pay money just to create or own VW >> objects (I'm using 'own' here to refer to maintaining >> their existence, I'm not trying to make a >> 'leftist'/'communist' statement about ownership ;) >> >> - Izzy >> >> >> On Apr 2, 2011, at 3:58 PM, Morgaine wrote: >> >> Izzy, when designing for scalability, the model to >> bear in mind is that of seasoned virtual world >> travelers whose inventories contain assets from >> many >> different worlds, those assets being served by man= y >> different asset services. =EF=BF=BDBoth worlds and= asset >> services may include commercial, community, and >> personal services, and as the metaverse grows, tha= t >> set is highly likely to become progressively less >> clustered and more diverse. >> >> When those seasoned travelers click on an >> advertised >> VW link and perform an inter-world teleport to one >> particular world's region to share an experience, >> their "worn" assets (the only ones of interest >> to the >> region) will contain references to asset services >> spread widely across the Internet. =EF=BF=BDThe fe= tches >> by the >> travelers' clients occur over many parallel >> paths from >> clients to asset services, so one can reasonably >> expect reduced network contention and reduced asse= t >> server loading because they are both spread out >> over >> however many asset services are being referenced b= y >> the overall set of assets in the region. >> >> This is very different to the case of a proxying >> region, which would get slammed for every asset >> worn >> by every avatar present. =EF=BF=BDIn our current >> architecture, >> regions run many different CPU-intensive tasks, >> including physics simulation and server-side >> scripting, and absolutely cannot afford to serve >> assets too unless your scalability requirements ar= e >> very low indeed, ie. just a few dozen avatars of >> today's kind. =EF=BF=BDWe've hit the ceiling alrea= dy on >> region >> scalability done that way. =EF=BF=BDThere is nowhe= re to >> go in >> that direction at all beyond improving the code >> like >> Intel demonstrated, and that work is subject to >> a law >> of diminishing returns. >> >> This is why we have to go parallel, and I think >> you're >> wrong that it has to cost much money. =EF=BF=BDAs = we spread >> the load across more and more asset services, >> we are >> simply better utilizing all the hardware that's >> already out there on the Internet, at least in >> respect >> of community and private resources. =EF=BF=BDBut a= dd to the >> community and private resources the commercial >> asset >> services that are likely to appear to exploit this >> opportunity, and not only will the number of asset >> services leap, but the power of each one will >> rocket >> too, because, after all, these businesses will be >> heavily optimized for the job. >> >> As to why a world would want clients to access >> external asset services instead of providing >> its own >> implementation, that's an easy question. =EF=BF=BD= It costs >> money to host a high performance and scalable asse= t >> service and a high bandwidth network to handle the >> traffic. =EF=BF=BDA *lot* of money. =EF=BF=BDIn co= ntrast, it >> costs a >> world nothing to let others serve the assets to >> clients. =EF=BF=BDAnd that matters to the bottom l= ine. >> >> >> Morgaine. >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> >> On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis >> > > > >> > >> >> > >>> wrote: >> >> =EF=BF=BD =EF=BF=BD> As always though, it's a trad= e-off, since the >> proxied design >> =EF=BF=BD =EF=BF=BDhas very poor scalability compa= red to the >> distributed one. >> >> =EF=BF=BD =EF=BF=BDI don't agree with that... If a= user enters a >> highly populated >> =EF=BF=BD =EF=BF=BDregion, >> =EF=BF=BD =EF=BF=BDevery other client is going to = (could and >> should be >> trying to) >> =EF=BF=BD =EF=BF=BDhit the >> =EF=BF=BD =EF=BF=BDasset server(s) for the assets = that the user is >> wearing (assuming >> =EF=BF=BD =EF=BF=BDthey're not cached locally). = =EF=BF=BDEvery asset server >> has to be scaled up >> =EF=BF=BD =EF=BF=BDto the point that it can handle= that load >> from all >> over... >> >> =EF=BF=BD =EF=BF=BDIf I'm hosting a region that su= pports 10s of >> thousands of >> =EF=BF=BD =EF=BF=BDsimultaneous >> =EF=BF=BD =EF=BF=BDusers (thinking of the future),= I already >> have to >> scale to meet that >> =EF=BF=BD =EF=BF=BDdemand. If the region is proxyi= ng the >> assets, then, >> yes the >> =EF=BF=BD =EF=BF=BDregion has >> =EF=BF=BD =EF=BF=BDto be scaled to meet that asset= demand too, >> but it >> already has to be >> =EF=BF=BD =EF=BF=BDscaled to meet other demands of= being a region >> server... and why is >> =EF=BF=BD =EF=BF=BDscaling those asset proxy servi= ces hard? =EF=BF=BDIt's >> going to cost $, >> =EF=BF=BD =EF=BF=BDbut is >> =EF=BF=BD =EF=BF=BDnot technically challenging. So= , if I want >> to host >> a region like >> =EF=BF=BD =EF=BF=BDthat... sure it will cost me, b= ut the simulation >> will be consistent >> =EF=BF=BD =EF=BF=BDand users will be able to parti= cipate equally, >> regardless of the >> =EF=BF=BD =EF=BF=BDcapabilities of their individua= l asset services. >> >> >> >> >> =EF=BF=BD =EF=BF=BDOn Fri, Apr 1, 2011 at 11:55 PM= , Morgaine >> =EF=BF=BD =EF=BF=BD> >> > > >> =EF=BF=BD =EF=BF=BD> >> >> >> > >>> wrote: >> =EF=BF=BD =EF=BF=BD> Every design choice results i= n a trade-off, >> Vaughn, improving >> =EF=BF=BD =EF=BF=BDone thing at >> =EF=BF=BD =EF=BF=BD> the expense of something else= . =EF=BF=BDIf every >> time we >> offered a >> =EF=BF=BD =EF=BF=BDservice we had to >> =EF=BF=BD =EF=BF=BD> inform its users about the do= wnsides of >> all the >> trade-offs we >> =EF=BF=BD =EF=BF=BDhave made, >> =EF=BF=BD =EF=BF=BD> they would have an awful lot = to read. ;-) >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> The specific trade-off that y= ou are >> discussing is no >> =EF=BF=BD =EF=BF=BDdifferent. =EF=BF=BDA region >> =EF=BF=BD =EF=BF=BD> that proxies all content has = the "benefit" of >> acquiring control >> =EF=BF=BD =EF=BF=BDfrom the >> =EF=BF=BD =EF=BF=BD> asset servers over the items = in the region, so >> that it can >> =EF=BF=BD =EF=BF=BDensure that >> =EF=BF=BD =EF=BF=BD> everyone in the region not on= ly obtains >> the items >> but obtains >> =EF=BF=BD =EF=BF=BDthe same items >> =EF=BF=BD =EF=BF=BD> as everyone else. =EF=BF=BDTh= at does indeed provide a >> greater guarantee of >> =EF=BF=BD =EF=BF=BD> consistency than a deployment= in which the >> region >> only passes >> =EF=BF=BD =EF=BF=BDasset URIs to >> =EF=BF=BD =EF=BF=BD> clients who then fetch the it= ems from >> asset services >> =EF=BF=BD =EF=BF=BDseparately. =EF=BF=BDAs always >> =EF=BF=BD =EF=BF=BD> though, it's a trade-off, sin= ce the proxied >> design has very >> =EF=BF=BD =EF=BF=BDpoor scalability >> =EF=BF=BD =EF=BF=BD> compared to the distributed o= ne. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> If we're going to warn users = of the >> potential for >> inconsistency >> =EF=BF=BD =EF=BF=BDin the >> =EF=BF=BD =EF=BF=BD> distributed deployment as you= suggest, are we >> also going to >> =EF=BF=BD =EF=BF=BDwarn them of >> =EF=BF=BD =EF=BF=BD> non-scalability in the proxie= d one? =EF=BF=BDI really >> don't see much >> =EF=BF=BD =EF=BF=BDmerit in the >> =EF=BF=BD =EF=BF=BD> idea of warning about design = choices. >> =EF=BF=BDMany such >> choices are >> =EF=BF=BD =EF=BF=BDtechnical, and >> =EF=BF=BD =EF=BF=BD> the issues are quite likely t= o be of little >> interest to >> =EF=BF=BD =EF=BF=BDnon-technical users >> =EF=BF=BD =EF=BF=BD> anyway. =EF=BF=BDIn any case,= the better services are >> likely to provide >> =EF=BF=BD =EF=BF=BDsuch >> =EF=BF=BD =EF=BF=BD> information in their online d= ocumentation, I >> would guess. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> You mentioned users "voting w= ith their >> feet" or >> choosing to >> =EF=BF=BD =EF=BF=BDaccept the risk >> =EF=BF=BD =EF=BF=BD> of inconsistency. =EF=BF=BDWe= ll that will happen >> anyway, >> when services >> =EF=BF=BD =EF=BF=BDfail and >> =EF=BF=BD =EF=BF=BD> users get annoyed. =EF=BF=BDI= f some asset services >> refuse >> to send the >> =EF=BF=BD =EF=BF=BDrequested >> =EF=BF=BD =EF=BF=BD> items to some users, those se= rvices will get a >> bad reputation >> =EF=BF=BD =EF=BF=BDand people >> =EF=BF=BD =EF=BF=BD> will choose different asset s= ervices instead. >> =EF=BF=BDLikewise, if a >> =EF=BF=BD =EF=BF=BDworld service >> =EF=BF=BD =EF=BF=BD> proxies everything and so it = can't handle >> a large >> number of >> =EF=BF=BD =EF=BF=BDassets or of >> =EF=BF=BD =EF=BF=BD> people, users will get annoye= d at the lag >> and will go >> =EF=BF=BD =EF=BF=BDelsewhere. =EF=BF=BDThis user >> =EF=BF=BD =EF=BF=BD> evaluation and "voting with t= heir feet" >> happens >> already with >> =EF=BF=BD =EF=BF=BDonline services >> =EF=BF=BD =EF=BF=BD> all over the Internet, and I = am sure that this >> human process >> =EF=BF=BD =EF=BF=BDwill continue >> =EF=BF=BD =EF=BF=BD> to work when the services are= asset and region >> services. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> Back in September 2010, I wro= te this post >> which >> proposes that >> =EF=BF=BD =EF=BF=BDwe use in >> =EF=BF=BD =EF=BF=BD> VWRAP a form of asset address= ing that provides >> massive >> =EF=BF=BD =EF=BF=BDscalability at the >> =EF=BF=BD =EF=BF=BD> same time as a very high degr= ee of >> resilience -- >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD >> =EF=BF=BD >> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >> =EF=BF=BD =EF=BF=BD. =EF=BF=BDIt is >> =EF=BF=BD =EF=BF=BD> based on the concept of the U= RI containing >> a host >> part and a >> =EF=BF=BD =EF=BF=BDhash part, >> =EF=BF=BD =EF=BF=BD> where the hash is generated (= once, at the >> time of >> storage to >> =EF=BF=BD =EF=BF=BDthe asset >> =EF=BF=BD =EF=BF=BD> service) using a specified di= gest >> algorithm over >> the content of >> =EF=BF=BD =EF=BF=BDthe asset >> =EF=BF=BD =EF=BF=BD> being referenced. =EF=BF=BDYo= u may wish to note >> that if >> this design >> =EF=BF=BD =EF=BF=BDwere used, the >> =EF=BF=BD =EF=BF=BD> failure of an asset service t= o deliver a >> requested item would >> =EF=BF=BD =EF=BF=BDresult in a >> =EF=BF=BD =EF=BF=BD> failover request for the item= to one or more >> backup services, >> =EF=BF=BD =EF=BF=BDusing the same >> =EF=BF=BD =EF=BF=BD> hash part but with a differen= t host address. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> This can go some way towards = overcoming the >> problem that you >> =EF=BF=BD =EF=BF=BDthink might >> =EF=BF=BD =EF=BF=BD> occur when assets are fetched= by clients from >> asset services >> =EF=BF=BD =EF=BF=BDdirectly. >> =EF=BF=BD =EF=BF=BD> Although it won't help when t= he missing >> item is >> available from >> =EF=BF=BD =EF=BF=BDonly a single >> =EF=BF=BD =EF=BF=BD> asset service, it will help i= n many other >> cases, >> and it will >> =EF=BF=BD =EF=BF=BDcompensate for >> =EF=BF=BD =EF=BF=BD> service failures and network = outages >> automatically at the same >> =EF=BF=BD =EF=BF=BDtime. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> PS. This design for hash-base= d asset >> addressing >> is already >> =EF=BF=BD =EF=BF=BDbeing tested by >> =EF=BF=BD =EF=BF=BD> Mojito Sorbet in her experime= ntal world and >> client. =EF=BF=BDIt would give >> =EF=BF=BD =EF=BF=BD> VWRAP-based worlds an improve= d level of >> service >> availability, >> =EF=BF=BD =EF=BF=BDso I think it >> =EF=BF=BD =EF=BF=BD> should be a core feature of o= ur protocol. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> Morgaine. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> =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 >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> On Fri, Apr 1, 2011 at 11:17 = PM, Vaughn Deluca >> =EF=BF=BD =EF=BF=BD> >> > > >> > >> > >>> >> =EF=BF=BD =EF=BF=BD> wrote: >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> This is a question i discuss= ed with Morgaine >> off-list a while >> =EF=BF=BD =EF=BF=BDago (I >> =EF=BF=BD =EF=BF=BD>> intended to send it to the l= ist but >> pushed the >> wrong button...) I >> =EF=BF=BD =EF=BF=BD>> think we need to address thi= s problem, and >> decide how to deal >> =EF=BF=BD =EF=BF=BDwith it. >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDIn Davids deploymen= t draft, section >> 7.3.1.1 an >> overview is >> =EF=BF=BD =EF=BF=BDgiven van >> =EF=BF=BD =EF=BF=BD>> ways to deliver content to t= he region. >> One way >> is only passing a >> =EF=BF=BD =EF=BF=BD>> capability that allows acces= s to (part >> of) the >> resource: >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF= =BD =EF=BF=BD =EF=BF=BD 7.3.1.1. =EF=BF=BDContent delivery models >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF= =BD =EF=BF=BD =EF=BF=BD A range of possible >> represenations can >> be passed to >> =EF=BF=BD =EF=BF=BDa region for >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF= =BD =EF=BF=BD =EF=BF=BD simulation. [...] The other end >> of the >> delivery spectrum >> =EF=BF=BD =EF=BF=BD>> involves passing >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF= =BD =EF=BF=BD =EF=BF=BD only a URI or capability used to >> access the rendering >> =EF=BF=BD =EF=BF=BD>> information and a >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF= =BD =EF=BF=BD =EF=BF=BD collision mesh,and related data for >> physical simulation. >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF= =BD =EF=BF=BD =EF=BF=BD In such a model, the client is >> responsible for >> =EF=BF=BD =EF=BF=BDfetching the >> =EF=BF=BD =EF=BF=BD>> additional >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF= =BD =EF=BF=BD =EF=BF=BD information needed to render the >> item's visual >> =EF=BF=BD =EF=BF=BDpresence from a >> =EF=BF=BD =EF=BF=BD>> separate >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF= =BD =EF=BF=BD =EF=BF=BD service. =EF=BF=BDThis fetch can be done >> *under the >> =EF=BF=BD =EF=BF=BDcredentials of the >> =EF=BF=BD =EF=BF=BD>> end user* >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF= =BD =EF=BF=BD =EF=BF=BD viewing the material [my >> emphasis--VD] >> , and >> =EF=BF=BD =EF=BF=BDdivorces the >> =EF=BF=BD =EF=BF=BD>> simulation from >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF= =BD =EF=BF=BD =EF=BF=BD the trust chain needed to manage >> content. =EF=BF=BDAny >> =EF=BF=BD =EF=BF=BDautomation >> =EF=BF=BD =EF=BF=BD>> is done on a >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF= =BD =EF=BF=BD =EF=BF=BD separate host which the content >> creator or owner trusts, >> =EF=BF=BD =EF=BF=BD>> interacting with the >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF= =BD =EF=BF=BD =EF=BF=BD object through remoted interfaces. >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDI can see the need = for such a setup, >> however, i >> feel we are >> =EF=BF=BD =EF=BF=BD>> unpleasantly close to a situ= ation were the >> coherence of the >> =EF=BF=BD =EF=BF=BDsimulation >> =EF=BF=BD =EF=BF=BD>> falls apart. >> =EF=BF=BD =EF=BF=BD>> In this deployment pattern t= he region >> advertises >> the presence >> =EF=BF=BD =EF=BF=BDof the >> =EF=BF=BD =EF=BF=BD>> asset, and *some* clients wi= ll be able to >> get it >> as expected, >> =EF=BF=BD =EF=BF=BDwhile >> =EF=BF=BD =EF=BF=BD>> -based on the arbitrary whim= s of the asset >> service- others >> =EF=BF=BD =EF=BF=BDmight not. >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> My hope would be that after = the asset server >> provides the >> =EF=BF=BD =EF=BF=BDregion with >> =EF=BF=BD =EF=BF=BD>> the capability to get the as= set, it gives up >> control. That >> =EF=BF=BD =EF=BF=BDwould mean >> =EF=BF=BD =EF=BF=BD>> that if the client finds the= inventory >> server is >> unwilling to >> =EF=BF=BD =EF=BF=BDserve >> =EF=BF=BD =EF=BF=BD>> the content - in spire of th= e region >> saying it >> is present-, >> =EF=BF=BD =EF=BF=BDthe client >> =EF=BF=BD =EF=BF=BD>> should be able to turn aroun= d ask the >> *region* >> for the asset, >> =EF=BF=BD =EF=BF=BD(and get >> =EF=BF=BD =EF=BF=BD>> is after all). >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDIf that is not the = case, -and there are >> probably good reasons >> =EF=BF=BD =EF=BF=BDfor the >> =EF=BF=BD =EF=BF=BD>> deployment pattern as descri= bed- >> =EF=BF=BDshouldn't we >> *warn* clients >> =EF=BF=BD =EF=BF=BDthat the >> =EF=BF=BD =EF=BF=BD>> region might be inconsistent= , so the users >> behind the client >> =EF=BF=BD =EF=BF=BDcan vote >> =EF=BF=BD =EF=BF=BD>> with their feet, (or take th= e risk)? >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> --Vaughn >> =EF=BF=BD =EF=BF=BD>> >> _______________________________________________ >> =EF=BF=BD =EF=BF=BD>> vwrap mailing list >> =EF=BF=BD =EF=BF=BD>> vwrap@ietf.org >> > >> >> >> >> >> =EF=BF=BD =EF=BF=BD>> https://www.ietf.org/mailman= /listinfo/vwrap >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> _______________________________________________ >> =EF=BF=BD =EF=BF=BD> vwrap mailing list >> =EF=BF=BD =EF=BF=BD> vwrap@ietf.org >> > >> >> >> >> >> =EF=BF=BD =EF=BF=BD> https://www.ietf.org/mailman/= listinfo/vwrap >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> >> >> >> >> -----------------------------------------------------------------------= - >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/vwrap >> =EF=BF=BD >> >> >> >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, >> Consultant >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > --002354470e60b21f0904a007dbf0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 V2UgaGF2ZSBubyAmcXVvdDtmaWd1cmUtb2Ytc3BlZWNoIHNlcnZpY2VzJnF1b3Q7IGluIFZXUkFQ LsKgIE91ciBzZXJ2aWNlcyBhcmUgcnVubmluZyBwcm9jZXNzZXMsIHRoZXkgaGF2ZSBuZXR3b3Jr IGVuZHBvaW50cywgYW5kIHRoZXkgdGFsayBhIG5ldHdvcmsgcHJvdG9jb2wuPGJyPjxicj5Db25j ZXB0cyBjYW4gYmUgdmVyeSB1c2VmdWwsIGFuZCBJIHJlZ3VsYXJseSBkcmF3IGZsdWZmeSBjbG91 ZHMgdGhhdCByZXByZXNlbnQgdGhlIGNvbmNlcHQgYmVoaW5kIHNvbWV0aGluZyBjb25jcmV0ZS48 YnI+Cjxicj5XaGVyZSBjb25jZXB0cyBhcmUgbm90IHVzZWZ1bCBpcyB3aGVuIHRoZXkgZGVub3Rl IHNvbWV0aGluZyB0aGF0IGRvZXNuJiMzOTt0IGFjdHVhbGx5IGV4aXN0LCBsaWtlIHNheSBwaGxv Z2lzdG9uLCBHb2QsIG9yIEFnZW50IERvbWFpbiwgYmVjYXVzZSB0aGlzIGp1c3QgbWFrZXMgdGhl bSBhIGhpbmRyYW5jZSB0byBmdXJ0aGVyIHByb2dyZXNzLsKgIEh1bWFuaXR5IHN1ZmZlcnMgZnJv bSB0aGlzIGEgbG90Ljxicj4KPGJyPlBoaWxvc29waHkgYXNpZGUsIHdlIHdhbnQgb3VyIEFnZW50 IFNlcnZpY2UgdG8gYmUgdG90YWxseSBjb25jcmV0ZSwgd2l0aCBhIG5ldHdvcmsgQVBJIGFuZCB3 ZWxsIGRlZmluZWQgc2VtYW50aWNzLsKgIFRoZSBkb21haW4gY29uY2VwdCBkb2VzIG5vdCBnZXQg dXMgdGhlcmUuPGJyPjxicj48YnI+TW9yZ2FpbmUuPGJyPjxicj48YnI+PGJyPjxicj49PT09PT09 PT09PT09PT09PT08YnI+Cjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gU3VuLCBBcHIg MywgMjAxMSBhdCA2OjM4IFBNLCBEem9uYXRhcyBTb2wgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBo cmVmPSJtYWlsdG86ZHpvbmF0YXNAZ21haWwuY29tIj5kem9uYXRhc0BnbWFpbC5jb208L2E+Jmd0 Ozwvc3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IGJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIw NCwgMjA0LCAyMDQpOyBwYWRkaW5nLWxlZnQ6IDFleDsiPgpJIHByZWZlciB0aGUgdmlzdWFsaXph dGlvbiBvZiAmcXVvdDtkb21haW5zJnF1b3Q7IGJlY2F1c2UgdGhvc2UgZmx1ZmZ5IGNsb3VkcyBy ZWFsbHkgaGVscCB0aG9zZSB0aGF0IGRvbiYjMzk7dCBkbyB3ZWxsIHdpdGggZmlndXJlLW9mLXNw ZWVjaCAmcXVvdDtzZXJ2aWNlcy4mcXVvdDs8YnI+Cjxicj4KPGJyPgpNb3JnYWluZSB3cm90ZTo8 YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB0IDBw dCAwcHQgMC44ZXg7IGJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBw YWRkaW5nLWxlZnQ6IDFleDsiPjxkaXYgY2xhc3M9ImltIj4KJnF1b3Q7QWdlbnQgRG9tYWluJnF1 b3Q7IG1vcmUgb3IgbGVzcyBjZWFzZWQgdG8gZXhpc3QgaW4gcHJhY3RpY2Ugd2hlbiBEYXZpZCBw b2ludGVkIG91dCB2ZXJ5IGVsb3F1ZW50bHkgdGhhdCB0aGUgZW1wZXJvciBoYWQgbm8gY2xvdGhl cy4gwqAoU2FtZSBmb3IgJnF1b3Q7UmVnaW9uIERvbWFpbiZxdW90Oy4pPGJyPgo8YnI+CkkgdGhp bmsgd2UgbW9zdGx5IHRhbGsgYWJvdXQgdGhlIEFnZW50IFNlcnZpY2UgYW5kIFJlZ2lvbiBTZXJ2 aWNlIHRoZXNlIGRheXMuIMKgVGhlICZxdW90O2RvbWFpbiZxdW90OyB3YXMganVzdCBhIGZsdWZm eSBjbG91ZCB0aGF0IHNvbWVvbmUgb25jZSBkcmV3IG9uIGEgd2hpdGVib2FyZCwgYnV0IHdoaWNo IG5ldmVyIGFjdHVhbGx5IGV4aXN0ZWQuPGJyPgo8YnI+Cjxicj4KTW9yZ2FpbmUuPGJyPgo8YnI+ Cjxicj4KPGJyPgo8YnI+Cj09PT09PT09PT09PT09PT09PT09PGJyPgo8YnI+PC9kaXY+PGRpdj48 ZGl2PjwvZGl2PjxkaXYgY2xhc3M9Img1Ij4KT24gU3VuLCBBcHIgMywgMjAxMSBhdCA2OjIwIFBN LCBEem9uYXRhcyBTb2wgJmx0OzxhIGhyZWY9Im1haWx0bzpkem9uYXRhc0BnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5kem9uYXRhc0BnbWFpbC5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmR6b25hdGFzQGdtYWls LmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+Cgo8YnI+CiDCoCDCoFByb2JhYmx5IGVhc3kgYXMg c3VnZ2VzdGVkIGluIG90aGVyIHRlcm1zIGhlcmUgb24gdGhpcyBsaXN0LCBhczxicj4KIMKgIMKg aG93IHRoZSBjbGllbnQgY29udGFjdHMgdGhlIGFzc2V0IHNlcnZpY2VzIG5vdyBpbiB0aGUgcmVn aW9ucy4gVGhlPGJyPgogwqAgwqBuZXdlciBpc3N1ZSBpcyB0byB1bml0aXplIHRoYXQgYXNzZXQg c2VydmljZXMuIFNpbmNlIHRoZWlyIGlzPGJyPgogwqAgwqBwcm9wcmlldGFyeSAobGVnYWN5KSBj b2RlIHRoZW4gd2UgY2FuJiMzOTt0IGV4cGVjdCB0aGF0IHRvIGNoYW5nZSwgYW5kPGJyPgogwqAg wqBzb21lIGZvcm0gb2YgcHJveHkgaXMgb2YgbmVlZC4gV2hhdGV2ZXIgd29ya3MgYmVzdCwgSSB0 cmllZCB0bzxicj4KIMKgIMKgbmFycm93IGl0IGRvd24gdG8gc3VnZ2VzdGlvbnMgaGVyZS48YnI+ Cjxicj4KIMKgIMKgRXZlbnR1YWxseSwgdGhlIGFnZW50IGRvbWFpbiBpcyBpZGVhbCB0byBoYW5k bGUgdGhlIGRpcmVjdGlvbiBvZjxicj4KIMKgIMKgdGhlIGFzc2V0IHNlcnZpY2VzLiBUaGlzIGNv bmNlcHQsIHVuZm9ydHVuYXRlbHksIGVuZGVkIHN1cHBvcnQ8YnI+CiDCoCDCoGF3aGlsZSBhZ28g d2l0aCBjaGFuZ2VzIGluIExMLjxicj4KIMKgIMKgQWxzbyBzZWU7IDxhIGhyZWY9Imh0dHA6Ly93 aWtpLnNlY29uZGxpZmUuY29tL3dpa2kvQWdlbnRfRG9tYWluIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL3dpa2kuc2Vjb25kbGlmZS5jb20vd2lraS9BZ2VudF9Eb21haW48L2E+PGJyPgogwqAgwqBB bmQ6IDxhIGhyZWY9Imh0dHA6Ly93aWtpLnNlY29uZGxpZmUuY29tL3dpa2kvVXNlcjpEem9uYXRh c19Tb2wvQVdHX0Fzc2V0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3dpa2kuc2Vjb25kbGlmZS5j b20vd2lraS9Vc2VyOkR6b25hdGFzX1NvbC9BV0dfQXNzZXQ8L2E+PGJyPgogwqAgwqAod2Fybjog dW5zdHJ1Y3R1cmVkIGNvbGxhYm9yYXRpdmUgbm90ZXMsIGR1bXBlZCBvbiBtZSBhbmQgSSB0cmll ZDxicj4KIMKgIMKgdG8gZml4KTxicj4KPGJyPgogwqAgwqBJIHRyaWVkIHRvIGZpbmQgcHJldmlv dXMgdmlzdWFscy48YnI+Cjxicj4KIMKgIMKgSSYjMzk7ZCBpbWFnaW5lIHRoZSBhZ2VudCBkb21h aW4gY291bGQgZ3JvdyBvdXQgb2YgdW5pdGl6ZWQgdmVyc2lvbnM8YnI+CiDCoCDCoG9mIGFzc2V0 IHNlcnZpY2VzLiBEZXNwaXRlIHRoYXQsIEkgdGhpbmsgdGhhdCBjb25jZXB0IGhlbHBzIHZpZXc8 YnI+CiDCoCDCoHdoZXJlIHdlIHdlcmUgYXQgaW4gZGlzY3Vzc2lvbiBhbmQgd2hhdCBkaWRuJiMz OTt0IGhhcHBlbi48YnI+Cjxicj4KIMKgIMKgVmF1Z2huIERlbHVjYSB3cm90ZTo8YnI+Cjxicj4K IMKgIMKgIMKgIMKgSGnvv71Eem9uYXRhczxicj4KPGJyPgogwqAgwqAgwqAgwqBDYW4geW91IGV4 cGFuZCBvbiB0aGF0LCB3aGF0IHdvdWxkIGJlIG5lZWRlZCBmb3IgbGVnYWN5PGJyPgogwqAgwqAg wqAgwqBzdXBwb3J0IGluIFZXQVAgdGVybXPvv70/LDxicj4KIMKgIMKgIMKgIMKgSWYgaSB3YW50 IHRvIHJlYWQgdXAgb24gaG93IHRoZe+/vWFzc2V0IHNlcnZlciBtYXkgcHJveHkgdGhlPGJyPgog wqAgwqAgwqAgwqBzaW11bGF0b3IsIHdoYXQgd291bGQgeW91IHJlY29tbWVuZCBtZSB0byByZWFk Pzxicj4KPGJyPgogwqAgwqAgwqAgwqAtLSBWYXVnaG48YnI+Cjxicj4KIMKgIMKgIMKgIMKgT24g U3VuLCBBcHIgMywgMjAxMSBhdCA1OjUxIEFNLCBEem9uYXRhcyBTb2w8YnI+CiDCoCDCoCDCoCDC oCZsdDs8YSBocmVmPSJtYWlsdG86ZHpvbmF0YXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ ZHpvbmF0YXNAZ21haWwuY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkem9uYXRh c0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kem9uYXRhc0BnbWFpbC5jb208L2E+Jmd0Ozxi cj48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PC9kaXY+PGRpdiBjbGFzcz0iaDUiPgoKIMKgIMKgIMKg IMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZHpvbmF0YXNAZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+ZHpvbmF0YXNAZ21haWwuY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpkem9uYXRhc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kem9uYXRhc0BnbWFpbC5jb208 L2E+Jmd0OyZndDsmZ3Q7IHdyb3RlOjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgU29tZSBzdGF0 ZWQgdGhlIHByb3h5LXRvLWFzc2V0LXNlcnZlciBpcyBidWlsdCBpbnRvIHRoZSBzaW07PGJyPgog wqAgwqAgwqAgwqAgwqAgaG93ZXZlciwga2VlcCBpbiBtaW5kIHBvc3NpYmxlIGxlZ2FjeSBzdXBw b3J0IHdoZXJlIHRoZSBhc3NldDxicj4KIMKgIMKgIMKgIMKgIMKgIHNlcnZlciBtYXkgcHJveHkg dGhlIHNpbXVsYXRvci48YnI+Cjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgRHpvbmF0YXMgU29s IHdyb3RlOjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgU29tZWhvdyBJIGZlZWwgdGhl IGJhc2ljIGFzc2V0IHNlcnZlciBiZWluZyBhYmxlIHRvPGJyPgogwqAgwqAgwqAgwqBsb2dpbiBh bmQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkb3dubG9hZCBhc3NldHMgaXMgbm93IHByaW9y aXR5LCB5ZXQgSSBhbHNvIHdvbmRlcmVkPGJyPgogwqAgwqAgwqAgwqB0aGUgYmVzdDxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHdheSB0byBwYXRjaCB0aGlzIGludG8gdGhlIGN1cnJlbnQgbW9k ZSBvZiB2aWV3ZXJzLjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgTWF5YmUgb2ZmZXIg KDEpIGJ5IHByb3h5IChzaW0tc2lkZSkgYW5kICgyKSBieSBwYXRjaDxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgICh2aWV3ZXItc2lkZSkgdGhhdCBlaXRoZXIgb2YgdGhlc2UgdHdvIGFyZSBvcHRp b25hbCBhbmQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBuZWl0aGVyIGFyZSBtYW5kYXRvcnkg Zm9yIG5vdy4gVGhvdWdodHM/PGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJc3JhZWwg QWxhbmlzIHdyb3RlOjxicj4KPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAm Z3Q7IHdoZW4gZGVzaWduaW5nIGZvciBzY2FsYWJpbGl0eSwgdGhlIG1vZGVsIHRvIGJlYXIgaW48 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBtaW5kIGlzIC4uLjxicj4KPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgV2VsbCwgdGhlcmUgYXJlIGEgbG90IG9mIGRpZmZlcmVu dCBtb2RlbHMgdG8ga2VlcDxicj4KIMKgIMKgIMKgIMKgaW4gbWluZCw8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBhbmQgbWFueSBkaWZmZXJlbnQgdXNlIGNhc2VzLiBPbmUgcGFydGlj dWxhciB1c2U8YnI+CiDCoCDCoCDCoCDCoGNhc2UgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBrZWVwIGluIG1pbmQgaXM6ICZxdW90O1VzZXIgYWNxdWlyZXMgbmV3IG91dGZpdCwg YW5kPGJyPgogwqAgwqAgwqAgwqB3YW50cyB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgICYjMzk7c2hvdyBpdCBvZmYmIzM5OyBpbiBhIGhpZ2hseSBwb3B1bGF0ZWQgcmVnaW9uJnF1 b3Q7Ljxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmd0OyBCb3RoIHdvcmxk cyBhbmQgYXNzZXQgc2VydmljZXMgbWF5IGluY2x1ZGU8YnI+CiDCoCDCoCDCoCDCoGNvbW1lcmNp YWwsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY29tbXVuaXR5LCBhbmQgcGVyc29u YWwgc2VydmljZXM8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFllcywgeWVz IGFuZCB5ZXMuIEkmIzM5O20gcGFydGljdWxhcmx5IGNvbmNlcm5lZCBhYm91dDxicj4KIMKgIMKg IMKgIMKgaG93IHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG1vZGVsIGFmZmVj dHMgdGhlIGFiaWxpdHkgdG8gaG9zdCBwZXJzb25hbCBhc3NldDxicj4KIMKgIMKgIMKgIMKgc2Vy dmljZXMuPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmZ3Q7IGEgcHJveHlp bmcgcmVnaW9uLCB3aGljaCB3b3VsZCBnZXQgc2xhbW1lZCBmb3IgZXZlcnk8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBhc3NldCB3b3JuIGJ5IGV2ZXJ5IGF2YXRhciBwcmVzZW50Ljxi cj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgR3JhbnRlZCB0aGUgY29sbGVjdGlv biBvZiBzZXJ2aWNlcyB0aGF0IGFyZSBwcm92aWRlZCBieTxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHRoZSByZWdpb24gbmVlZCB0byBiZSBzY2FsZWQgdG8gbWVldCB0aGUgZGVtYW5k cyBvZjxicj4KIMKgIMKgIMKgIMKgdGhhdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHJlZ2lvbi4gVGhhdCYjMzk7cyBhbGwgcGFydCBvZiBjYXBhY2l0eSBwbGFubmluZy48YnI+Cjxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZndDsgcmVnaW9ucyBydW4gbWFueSBkaWZm ZXJlbnQgQ1BVLWludGVuc2l2ZSB0YXNrcyw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBpbmNsdWRpbmcgcGh5c2ljcyBzaW11bGF0aW9uIGFuZCBzZXJ2ZXItc2lkZSBzY3JpcHRpbmcs PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYW5kIGFic29sdXRlbHkgY2Fubm90IGFm Zm9yZCB0byBzZXJ2ZSBhc3NldHMgdG9vPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg V2VsbC4uLiB3aG8gc2FpZCB0aGUgc2FtZSBDUFUmIzM5O3MgaGF2ZSB0byBkbyBwcm94eWluZyw8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwaHlzaWNzIHNpbXVsYXRpb24gYW5kIHNl cnZlci1zaWRlIHNjcmlwdGluZz8gQXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBwcm94eWluZyBpcyBhIGRpZmZlcmVudCBzZXJ2aWNlIHRoYW4gcGh5c2ljcyBzaW11bGF0aW9u PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYW5kIGNhbiBiZSBvbiBzZXBhcmF0ZSBo YXJkd2FyZSwgY291bGQgbWFrZSB1c2Ugb2Y8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBnZW9ncmFwaGljYWxseSBkaXN0cmlidXRlZCBjYWNoaW5nLCBhbmQgaW4gY2VydGFpbjxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRlcGxveW1lbnQgcGF0dGVybnMsIHRoZSBzYW1l IGNhY2hpbmcgc2VydmljZXMgY291bGQgYmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBzaGFyZWQgYnkgZGlmZmVyZW50IHJlZ2lvbnMuIChTZXJ2ZXItc2lkZSBzY3JpcHRpbmc8YnI+ CiDCoCDCoCDCoCDCoGlzIGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkaXNjdXNz aW9uIGZvciBhbm90aGVyIGRheSkuPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCAmZ3Q7IFRoaXMgaXMgd2h5IHdlIGhhdmUgdG8gZ28gcGFyYWxsZWwuLi48YnI+Cjxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRvdGFsbHkgYWdyZWUsIGFuZCBhIHByb3h5aW5nIG1v ZGVsIGNvdWxkIGFuZDxicj4KIMKgIMKgIMKgIMKgc2hvdWxkIGFsc288YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB0YWtlIGFkdmFudGFnZSBvZiBwYXJhbGxlbGlzbS48YnI+Cjxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZndDsgSSB0aGluayB5b3UmIzM5O3JlIHdyb25n IHRoYXQgaXQgaGFzIHRvIGNvc3QgbXVjaDxicj4KIMKgIMKgIMKgIMKgbW9uZXkuID92cz88YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmZ3Q7IEl0IGNvc3RzIG1vbmV5IHRvIGhvc3Qg YSBoaWdoIHBlcmZvcm1hbmNlIGFuZDxicj4KIMKgIMKgIMKgIMKgc2NhbGFibGU8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhc3NldCBzZXJ2aWNlIGFuZCBhIGhpZ2ggYmFuZHdpZHRo IG5ldHdvcmsgdG88YnI+CiDCoCDCoCDCoCDCoGhhbmRsZSB0aGU8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCB0cmFmZmljLiDvv71BICpsb3QqIG9mIG1vbmV5Ljxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIEkgdGhpbmsgd2hhdCB5b3UmIzM5O3JlIHNheWluZyBpczogJnF1 b3Q7SXQgY29zdHMgYSBsb3Qgb2Y8YnI+CiDCoCDCoCDCoCDCoG1vbmV5IHRvPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgYnVpbGQgYSBzY2FsYWJsZSBhc3NldCBzZXJ2aWNlLCBidXQg aWYgYXNzZXRzIGFyZTxicj4KIMKgIMKgIMKgIMKgc3ByZWFkPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgdGhyb3VnaG91dCB0aGUgaW50ZXJuZXQgdGhleSBkb24mIzM5O3QgaGF2ZSB0 byBiZTxicj4KIMKgIMKgIMKgIMKgc2NhbGFibGUuJnF1b3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgQnV0IHRoYXQmIzM5O3Mgbm90IHF1aXRlIHJpZ2h0LiBZb3UmIzM5O3JlIG9w ZW5pbmcgdXAgZXZlcnk8YnI+CiDCoCDCoCDCoCDCoGFzc2V0PGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgc2VydmVyIHRvIHRoZSBWVyBlcXVpdmFsZW50IG9mIGJlaW5nIHNsYXNoZG90 dGVkLDxicj4KIMKgIMKgIMKgIMKgc28gYXJlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgeW91IHN1cmUgeW91JiMzOTtyZSBub3QgZm9yY2luZyAqZXZlcnkqIGFzc2V0IHNlcnZpY2Ug dG8gYmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzY2FsYWJsZSBhbmQgaGFuZGxl IGEgbG90IG9mIGJhbmR3aXRoIGFuZCBuZXR3b3JrPGJyPgogwqAgwqAgwqAgwqB0cmFmZmljPzxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEl0JiMzOTtzIHRoZSBleGFjdCBvcHBvc2l0 ZSBvZiB5b3VyIGludGVudGlvbiwgYnV0IEkgdGhpbms8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCB0aGF0JiMzOTtzIHRoZSByZXN1bHQsIGFsbCB0aGUgc2FtZS48YnI+Cjxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoaXMgcGFydGljdWxhciBkZXNpZ24gZGVjaXNpb24g aGFzIGEgYmlnIGVmZmVjdCBvbiB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBl Y29ub21pY3Mgb2YgdGhlIFZXIGluZnJhc3RydWN0dXJlLiBJJiMzOTtkIHJhdGhlciB0aGU8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBlY29ub21pY3MgdG8gd29yayBvdXQgc3VjaCB0 aGF0IGEgcmVnaW9uIHByb3ZpZGVyIHdobzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHdpc2hlcyB0byBidWlsZCBhIHJlZ2lvbiB0aGF0IHN1cHBvcnRzIGEgc21hbGw8YnI+CiDCoCDC oCDCoCDCoHBvcHVsYXRpb24sPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY2FuIGRv IHNvIGVjb25vbWljYWxseS4gQSByZWdpb24gdGhhdCB3YW50cyB0byBob3N0IGE8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAqbGFyZ2UqIHBvcHVsYXRpb24gaGFzIHRvIGJlYXIgdGhh dCBjb3N0IG9mPGJyPgogwqAgwqAgwqAgwqBwcm92aWRpbmcgdGhhdDxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHNjYWxhYmxlIGFzc2V0IHNlcnZpY2UuPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgSSB3YW50IHRoZSBlY29ub21pY3Mgb2YgaG9zdGluZyBhIHNtYWxsIGFz c2V0PGJyPgogwqAgwqAgwqAgwqBzZXJ2aWNlIHRvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgYmUgYSBub24taXNzdWUgKGFzIHRvIGJlc3QgcHJvbW90ZSBjcmVhdGlvbiBhbmQ8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjcmVhdGl2aXR5KS4gQ3JlYXRpbmcgYSBoaWdo IGJhciB0byBwcm92aWRlIGFzc2V0PGJyPgogwqAgwqAgwqAgwqBzZXJ2aWNlczxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdpbGwgbWVhbiB0aGF0IHNlcnZpY2Ugd2lsbCBjb3N0IG1v bmV5IGFuZCBwZW9wbGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzaG91bGRuJiMz OTt0IGhhdmUgdG8gcGF5IG1vbmV5IGp1c3QgdG8gY3JlYXRlIG9yIG93biBWVzxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIG9iamVjdHMgKEkmIzM5O20gdXNpbmcgJiMzOTtvd24mIzM5 OyBoZXJlIHRvIHJlZmVyIHRvIG1haW50YWluaW5nPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgdGhlaXIgZXhpc3RlbmNlLCBJJiMzOTttIG5vdCB0cnlpbmcgdG8gbWFrZSBhPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJiMzOTtsZWZ0aXN0JiMzOTsvJiMzOTtjb21tdW5p c3QmIzM5OyBzdGF0ZW1lbnQgYWJvdXQgb3duZXJzaGlwIDspPGJyPgo8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCAtIEl6enk8YnI+Cjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgT24gQXByIDIsIDIwMTEsIGF0IDM6NTggUE0sIE1vcmdhaW5lIHdyb3RlOjxicj4K PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSXp6eSwgd2hlbiBkZXNpZ25p bmcgZm9yIHNjYWxhYmlsaXR5LCB0aGUgbW9kZWwgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBiZWFyIGluIG1pbmQgaXMgdGhhdCBvZiBzZWFzb25lZCB2aXJ0dWFsIHdv cmxkPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdHJhdmVsZXJzIHdob3Nl IGludmVudG9yaWVzIGNvbnRhaW4gYXNzZXRzIGZyb208YnI+CiDCoCDCoCDCoCDCoG1hbnk8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkaWZmZXJlbnQgd29ybGRzLCB0aG9z ZSBhc3NldHMgYmVpbmcgc2VydmVkIGJ5IG1hbnk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBkaWZmZXJlbnQgYXNzZXQgc2VydmljZXMuIO+/vUJvdGggd29ybGRzIGFuZCBh c3NldDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNlcnZpY2VzIG1heSBp bmNsdWRlIGNvbW1lcmNpYWwsIGNvbW11bml0eSwgYW5kPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgcGVyc29uYWwgc2VydmljZXMsIGFuZCBhcyB0aGUgbWV0YXZlcnNlIGdy b3dzLCB0aGF0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc2V0IGlzIGhp Z2hseSBsaWtlbHkgdG8gYmVjb21lIHByb2dyZXNzaXZlbHkgbGVzczxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNsdXN0ZXJlZCBhbmQgbW9yZSBkaXZlcnNlLjxicj4KPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgV2hlbiB0aG9zZSBzZWFzb25lZCB0 cmF2ZWxlcnMgY2xpY2sgb24gYW48YnI+CiDCoCDCoCDCoCDCoGFkdmVydGlzZWQ8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBWVyBsaW5rIGFuZCBwZXJmb3JtIGFuIGludGVy LXdvcmxkIHRlbGVwb3J0IHRvIG9uZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHBhcnRpY3VsYXIgd29ybGQmIzM5O3MgcmVnaW9uIHRvIHNoYXJlIGFuIGV4cGVyaWVuY2Us PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhlaXIgJnF1b3Q7d29ybiZx dW90OyBhc3NldHMgKHRoZSBvbmx5IG9uZXMgb2YgaW50ZXJlc3Q8YnI+CiDCoCDCoCDCoCDCoHRv IHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlZ2lvbikgd2lsbCBj b250YWluIHJlZmVyZW5jZXMgdG8gYXNzZXQgc2VydmljZXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBzcHJlYWQgd2lkZWx5IGFjcm9zcyB0aGUgSW50ZXJuZXQuIO+/vVRo ZSBmZXRjaGVzPGJyPgogwqAgwqAgwqAgwqBieSB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCB0cmF2ZWxlcnMmIzM5OyBjbGllbnRzIG9jY3VyIG92ZXIgbWFueSBwYXJh bGxlbDxicj4KIMKgIMKgIMKgIMKgcGF0aHMgZnJvbTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGNsaWVudHMgdG8gYXNzZXQgc2VydmljZXMsIHNvIG9uZSBjYW4gcmVhc29u YWJseTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGV4cGVjdCByZWR1Y2Vk IG5ldHdvcmsgY29udGVudGlvbiBhbmQgcmVkdWNlZCBhc3NldDxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHNlcnZlciBsb2FkaW5nIGJlY2F1c2UgdGhleSBhcmUgYm90aCBz cHJlYWQgb3V0PGJyPgogwqAgwqAgwqAgwqBvdmVyPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgaG93ZXZlciBtYW55IGFzc2V0IHNlcnZpY2VzIGFyZSBiZWluZyByZWZlcmVu Y2VkIGJ5PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhlIG92ZXJhbGwg c2V0IG9mIGFzc2V0cyBpbiB0aGUgcmVnaW9uLjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgVGhpcyBpcyB2ZXJ5IGRpZmZlcmVudCB0byB0aGUgY2FzZSBvZiBhIHBy b3h5aW5nPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVnaW9uLCB3aGlj aCB3b3VsZCBnZXQgc2xhbW1lZCBmb3IgZXZlcnkgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoHdvcm48 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBieSBldmVyeSBhdmF0YXIgcHJl c2VudC4g77+9SW4gb3VyIGN1cnJlbnQ8YnI+CiDCoCDCoCDCoCDCoGFyY2hpdGVjdHVyZSw8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZWdpb25zIHJ1biBtYW55IGRpZmZl cmVudCBDUFUtaW50ZW5zaXZlIHRhc2tzLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGluY2x1ZGluZyBwaHlzaWNzIHNpbXVsYXRpb24gYW5kIHNlcnZlci1zaWRlPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc2NyaXB0aW5nLCBhbmQgYWJzb2x1dGVs eSBjYW5ub3QgYWZmb3JkIHRvIHNlcnZlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgYXNzZXRzIHRvbyB1bmxlc3MgeW91ciBzY2FsYWJpbGl0eSByZXF1aXJlbWVudHMgYXJl PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdmVyeSBsb3cgaW5kZWVkLCBp ZS4ganVzdCBhIGZldyBkb3plbiBhdmF0YXJzIG9mPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgdG9kYXkmIzM5O3Mga2luZC4g77+9V2UmIzM5O3ZlIGhpdCB0aGUgY2VpbGlu ZyBhbHJlYWR5IG9uPGJyPgogwqAgwqAgwqAgwqByZWdpb248YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBzY2FsYWJpbGl0eSBkb25lIHRoYXQgd2F5LiDvv71UaGVyZSBpcyBu b3doZXJlIHRvPGJyPgogwqAgwqAgwqAgwqBnbyBpbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHRoYXQgZGlyZWN0aW9uIGF0IGFsbCBiZXlvbmQgaW1wcm92aW5nIHRoZSBj b2RlPGJyPgogwqAgwqAgwqAgwqBsaWtlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgSW50ZWwgZGVtb25zdHJhdGVkLCBhbmQgdGhhdCB3b3JrIGlzIHN1YmplY3QgdG88YnI+ CiDCoCDCoCDCoCDCoGEgbGF3PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg b2YgZGltaW5pc2hpbmcgcmV0dXJucy48YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIFRoaXMgaXMgd2h5IHdlIGhhdmUgdG8gZ28gcGFyYWxsZWwsIGFuZCBJIHRoaW5r PGJyPgogwqAgwqAgwqAgwqB5b3UmIzM5O3JlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgd3JvbmcgdGhhdCBpdCBoYXMgdG8gY29zdCBtdWNoIG1vbmV5LiDvv71BcyB3ZSBz cHJlYWQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGUgbG9hZCBhY3Jv c3MgbW9yZSBhbmQgbW9yZSBhc3NldCBzZXJ2aWNlcyw8YnI+CiDCoCDCoCDCoCDCoHdlIGFyZTxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNpbXBseSBiZXR0ZXIgdXRpbGl6 aW5nIGFsbCB0aGUgaGFyZHdhcmUgdGhhdCYjMzk7czxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGFscmVhZHkgb3V0IHRoZXJlIG9uIHRoZSBJbnRlcm5ldCwgYXQgbGVhc3Qg aW48YnI+CiDCoCDCoCDCoCDCoHJlc3BlY3Q8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBvZiBjb21tdW5pdHkgYW5kIHByaXZhdGUgcmVzb3VyY2VzLiDvv71CdXQgYWRkIHRv IHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNvbW11bml0eSBhbmQg cHJpdmF0ZSByZXNvdXJjZXMgdGhlIGNvbW1lcmNpYWw8YnI+CiDCoCDCoCDCoCDCoGFzc2V0PGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc2VydmljZXMgdGhhdCBhcmUgbGlr ZWx5IHRvIGFwcGVhciB0byBleHBsb2l0IHRoaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBvcHBvcnR1bml0eSwgYW5kIG5vdCBvbmx5IHdpbGwgdGhlIG51bWJlciBvZiBh c3NldDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNlcnZpY2VzIGxlYXAs IGJ1dCB0aGUgcG93ZXIgb2YgZWFjaCBvbmUgd2lsbDxicj4KIMKgIMKgIMKgIMKgcm9ja2V0PGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdG9vLCBiZWNhdXNlLCBhZnRlciBh bGwsIHRoZXNlIGJ1c2luZXNzZXMgd2lsbCBiZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGhlYXZpbHkgb3B0aW1pemVkIGZvciB0aGUgam9iLjxicj4KPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQXMgdG8gd2h5IGEgd29ybGQgd291bGQgd2FudCBj bGllbnRzIHRvIGFjY2Vzczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGV4 dGVybmFsIGFzc2V0IHNlcnZpY2VzIGluc3RlYWQgb2YgcHJvdmlkaW5nPGJyPgogwqAgwqAgwqAg wqBpdHMgb3duPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW1wbGVtZW50 YXRpb24sIHRoYXQmIzM5O3MgYW4gZWFzeSBxdWVzdGlvbi4g77+9SXQgY29zdHM8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBtb25leSB0byBob3N0IGEgaGlnaCBwZXJmb3Jt YW5jZSBhbmQgc2NhbGFibGUgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBzZXJ2aWNlIGFuZCBhIGhpZ2ggYmFuZHdpZHRoIG5ldHdvcmsgdG8gaGFuZGxlIHRoZTxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRyYWZmaWMuIO+/vUEgKmxvdCog b2YgbW9uZXkuIO+/vUluIGNvbnRyYXN0LCBpdDxicj4KIMKgIMKgIMKgIMKgY29zdHMgYTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdvcmxkIG5vdGhpbmcgdG8gbGV0IG90 aGVycyBzZXJ2ZSB0aGUgYXNzZXRzIHRvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgY2xpZW50cy4g77+9QW5kIHRoYXQgbWF0dGVycyB0byB0aGUgYm90dG9tIGxpbmUuPGJy Pgo8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE1vcmdhaW5lLjxi cj4KPGJyPgo8YnI+Cjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg PT09PT09PT09PT09PT09PT09PT09PTxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgT24gU2F0LCBBcHIgMiwgMjAxMSBhdCA3OjA1IFBNLCBJenp5IEFsYW5pczxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDs8YSBocmVmPSJtYWlsdG86aXp6 eWFsYW5pc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5penp5YWxhbmlzQGdtYWlsLmNvbTwv YT48YnI+CiDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOml6enlhbGFuaXNA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+aXp6eWFsYW5pc0BnbWFpbC5jb208L2E+Jmd0OyAm bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzppenp5YWxhbmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPml6enlhbGFuaXNAZ21haWwuY29tPC9hPjxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86aXp6eWFsYW5pc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5p enp5YWxhbmlzQGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOml6enlhbGFuaXNAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+aXp6eWFsYW5pc0BnbWFpbC5jb208L2E+PGJyPgogwqAgwqAg wqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzppenp5YWxhbmlzQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPml6enlhbGFuaXNAZ21haWwuY29tPC9hPiZndDs8YnI+Cjxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOml6 enlhbGFuaXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+aXp6eWFsYW5pc0BnbWFpbC5jb208 L2E+PGJyPgogwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzppenp5YWxhbmlz QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPml6enlhbGFuaXNAZ21haWwuY29tPC9hPiZndDsm Z3Q7Jmd0OyZndDsgd3JvdGU6PGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDvv70g77+9Jmd0OyBBcyBhbHdheXMgdGhvdWdoLCBpdCYjMzk7cyBhIHRyYWRlLW9mZiwg c2luY2UgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcHJveGllZCBk ZXNpZ248YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9aGFzIHZl cnkgcG9vciBzY2FsYWJpbGl0eSBjb21wYXJlZCB0byB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBkaXN0cmlidXRlZCBvbmUuPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9SSBkb24mIzM5O3QgYWdyZWUgd2l0aCB0aGF0Li4u IElmIGEgdXNlciBlbnRlcnMgYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGhpZ2hseSBwb3B1bGF0ZWQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDv v70g77+9cmVnaW9uLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDv v71ldmVyeSBvdGhlciBjbGllbnQgaXMgZ29pbmcgdG8gKGNvdWxkIGFuZDxicj4KIMKgIMKgIMKg IMKgc2hvdWxkIGJlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdHJ5aW5n IHRvKTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv71oaXQgdGhl PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vWFzc2V0IHNlcnZl cihzKSBmb3IgdGhlIGFzc2V0cyB0aGF0IHRoZSB1c2VyIGlzPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgd2VhcmluZyAoYXNzdW1pbmc8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDvv70g77+9dGhleSYjMzk7cmUgbm90IGNhY2hlZCBsb2NhbGx5KS4g 77+9RXZlcnkgYXNzZXQgc2VydmVyPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgaGFzIHRvIGJlIHNjYWxlZCB1cDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIO+/vSDvv710byB0aGUgcG9pbnQgdGhhdCBpdCBjYW4gaGFuZGxlIHRoYXQgbG9hZDxicj4K IMKgIMKgIMKgIMKgZnJvbSBhbGw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBvdmVyLi4uPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g 77+9SWYgSSYjMzk7bSBob3N0aW5nIGEgcmVnaW9uIHRoYXQgc3VwcG9ydHMgMTBzIG9mPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhvdXNhbmRzIG9mPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vXNpbXVsdGFuZW91czxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv711c2VycyAodGhpbmtpbmcgb2YgdGhl IGZ1dHVyZSksIEkgYWxyZWFkeTxicj4KIMKgIMKgIMKgIMKgaGF2ZSB0bzxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNjYWxlIHRvIG1lZXQgdGhhdDxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv71kZW1hbmQuIElmIHRoZSByZWdpb24gaXMg cHJveHlpbmcgdGhlPGJyPgogwqAgwqAgwqAgwqBhc3NldHMsIHRoZW4sPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgeWVzIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIO+/vSDvv71yZWdpb24gaGFzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAg77+9IO+/vXRvIGJlIHNjYWxlZCB0byBtZWV0IHRoYXQgYXNzZXQgZGVtYW5k IHRvbyw8YnI+CiDCoCDCoCDCoCDCoGJ1dCBpdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGFscmVhZHkgaGFzIHRvIGJlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAg77+9IO+/vXNjYWxlZCB0byBtZWV0IG90aGVyIGRlbWFuZHMgb2YgYmVpbmcgYSBy ZWdpb248YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzZXJ2ZXIuLi4gYW5k IHdoeSBpczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv71zY2Fs aW5nIHRob3NlIGFzc2V0IHByb3h5IHNlcnZpY2VzIGhhcmQ/IO+/vUl0JiMzOTtzPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZ29pbmcgdG8gY29zdCAkLDxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv71idXQgaXM8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9bm90IHRlY2huaWNhbGx5IGNoYWxsZW5naW5n LiBTbywgaWYgSSB3YW50PGJyPgogwqAgwqAgwqAgwqB0byBob3N0PGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgYSByZWdpb24gbGlrZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIO+/vSDvv710aGF0Li4uIHN1cmUgaXQgd2lsbCBjb3N0IG1lLCBidXQg dGhlIHNpbXVsYXRpb248YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3aWxs IGJlIGNvbnNpc3RlbnQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g 77+9YW5kIHVzZXJzIHdpbGwgYmUgYWJsZSB0byBwYXJ0aWNpcGF0ZSBlcXVhbGx5LDxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlZ2FyZGxlc3Mgb2YgdGhlPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vWNhcGFiaWxpdGllcyBvZiB0aGVp ciBpbmRpdmlkdWFsIGFzc2V0IHNlcnZpY2VzLjxicj4KPGJyPgo8YnI+Cjxicj4KPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vU9uIEZyaSwgQXByIDEsIDIwMTEg YXQgMTE6NTUgUE0sIE1vcmdhaW5lPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAg77+9IO+/vSZsdDs8YSBocmVmPSJtYWlsdG86bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tPC9hPjxi cj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9yZ2FpbmUuZGlub3Zh QGdvb2dsZW1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1h aWwuY29tPC9hPiZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5tb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb208L2E+PGJyPgogwqAg wqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb3JnYWluZS5kaW5vdmFAZ29vZ2xl bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb208 L2E+Jmd0OyZndDs8YnI+PC9kaXY+PC9kaXY+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDvv70g77+9Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9yZ2FpbmUuZGlub3ZhQGdv b2dsZW1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwu Y29tPC9hPjxkaXY+PGRpdj48L2Rpdj48ZGl2IGNsYXNzPSJoNSI+PGJyPgogwqAgwqAgwqAgwqAm bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5tb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb208L2E+Jmd0Ozxi cj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tPC9hPjxicj4KIMKgIMKgIMKgIMKgJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tPC9hPiZndDsmZ3Q7 Jmd0OyZndDsgd3JvdGU6PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9 IO+/vSZndDsgRXZlcnkgZGVzaWduIGNob2ljZSByZXN1bHRzIGluIGEgdHJhZGUtb2ZmLDxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFZhdWdobiwgaW1wcm92aW5nPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vW9uZSB0aGluZyBhdDxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7IHRoZSBleHBlbnNl IG9mIHNvbWV0aGluZyBlbHNlLiDvv71JZiBldmVyeTxicj4KIMKgIMKgIMKgIMKgdGltZSB3ZTxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG9mZmVyZWQgYTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv71zZXJ2aWNlIHdlIGhhZCB0bzxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7IGluZm9ybSBpdHMg dXNlcnMgYWJvdXQgdGhlIGRvd25zaWRlcyBvZjxicj4KIMKgIMKgIMKgIMKgYWxsIHRoZTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRyYWRlLW9mZnMgd2U8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9aGF2ZSBtYWRlLDxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7IHRoZXkgd291bGQgaGF2ZSBh biBhd2Z1bCBsb3QgdG8gcmVhZC4gOy0pPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDv v70g77+9Jmd0OyBUaGUgc3BlY2lmaWMgdHJhZGUtb2ZmIHRoYXQgeW91IGFyZTxicj4KIMKgIMKg IMKgIMKgZGlzY3Vzc2luZyBpcyBubzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIO+/vSDvv71kaWZmZXJlbnQuIO+/vUEgcmVnaW9uPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsgdGhhdCBwcm94aWVzIGFsbCBjb250ZW50IGhhcyB0 aGUgJnF1b3Q7YmVuZWZpdCZxdW90OyBvZjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGFjcXVpcmluZyBjb250cm9sPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAg77+9IO+/vWZyb20gdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAg77+9IO+/vSZndDsgYXNzZXQgc2VydmVycyBvdmVyIHRoZSBpdGVtcyBpbiB0aGUgcmVnaW9u LCBzbzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoYXQgaXQgY2FuPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vWVuc3VyZSB0aGF0PGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsgZXZlcnlvbmUg aW4gdGhlIHJlZ2lvbiBub3Qgb25seSBvYnRhaW5zPGJyPgogwqAgwqAgwqAgwqB0aGUgaXRlbXM8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBidXQgb2J0YWluczxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv710aGUgc2FtZSBpdGVtczxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7IGFzIGV2ZXJ5b25l IGVsc2UuIO+/vVRoYXQgZG9lcyBpbmRlZWQgcHJvdmlkZSBhPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgZ3JlYXRlciBndWFyYW50ZWUgb2Y8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0OyBjb25zaXN0ZW5jeSB0aGFuIGEgZGVwbG95 bWVudCBpbiB3aGljaCB0aGU8YnI+CiDCoCDCoCDCoCDCoHJlZ2lvbjxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIG9ubHkgcGFzc2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAg77+9IO+/vWFzc2V0IFVSSXMgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0OyBjbGllbnRzIHdobyB0aGVuIGZldGNoIHRoZSBp dGVtcyBmcm9tPGJyPgogwqAgwqAgwqAgwqBhc3NldCBzZXJ2aWNlczxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv71zZXBhcmF0ZWx5LiDvv71BcyBhbHdheXM8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0OyB0aG91Z2gsIGl0 JiMzOTtzIGEgdHJhZGUtb2ZmLCBzaW5jZSB0aGUgcHJveGllZDxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGRlc2lnbiBoYXMgdmVyeTxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIO+/vSDvv71wb29yIHNjYWxhYmlsaXR5PGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsgY29tcGFyZWQgdG8gdGhlIGRpc3RyaWJ1 dGVkIG9uZS48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0 Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7IElmIHdl JiMzOTtyZSBnb2luZyB0byB3YXJuIHVzZXJzIG9mIHRoZTxicj4KIMKgIMKgIMKgIMKgcG90ZW50 aWFsIGZvcjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGluY29uc2lzdGVu Y3k8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9aW4gdGhlPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsgZGlzdHJpYnV0 ZWQgZGVwbG95bWVudCBhcyB5b3Ugc3VnZ2VzdCwgYXJlIHdlPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgYWxzbyBnb2luZyB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIO+/vSDvv713YXJuIHRoZW0gb2Y8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0OyBub24tc2NhbGFiaWxpdHkgaW4gdGhlIHByb3hpZWQg b25lPyDvv71JIHJlYWxseTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRv biYjMzk7dCBzZWUgbXVjaDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/ vSDvv71tZXJpdCBpbiB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDv v70g77+9Jmd0OyBpZGVhIG9mIHdhcm5pbmcgYWJvdXQgZGVzaWduIGNob2ljZXMuPGJyPgogwqAg wqAgwqAgwqDvv71NYW55IHN1Y2g8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBjaG9pY2VzIGFyZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDv v710ZWNobmljYWwsIGFuZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/ vSDvv70mZ3Q7IHRoZSBpc3N1ZXMgYXJlIHF1aXRlIGxpa2VseSB0byBiZSBvZiBsaXR0bGU8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpbnRlcmVzdCB0bzxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv71ub24tdGVjaG5pY2FsIHVzZXJzPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsgYW55d2F5LiDv v71JbiBhbnkgY2FzZSwgdGhlIGJldHRlciBzZXJ2aWNlcyBhcmU8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBsaWtlbHkgdG8gcHJvdmlkZTxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv71zdWNoPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAg77+9IO+/vSZndDsgaW5mb3JtYXRpb24gaW4gdGhlaXIgb25saW5lIGRvY3Vt ZW50YXRpb24sIEk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3b3VsZCBn dWVzcy48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0Ozxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7IFlvdSBtZW50 aW9uZWQgdXNlcnMgJnF1b3Q7dm90aW5nIHdpdGggdGhlaXI8YnI+CiDCoCDCoCDCoCDCoGZlZXQm cXVvdDsgb3I8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjaG9vc2luZyB0 bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv71hY2NlcHQgdGhl IHJpc2s8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0OyBv ZiBpbmNvbnNpc3RlbmN5LiDvv71XZWxsIHRoYXQgd2lsbCBoYXBwZW48YnI+CiDCoCDCoCDCoCDC oGFueXdheSw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3aGVuIHNlcnZp Y2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vWZhaWwgYW5k PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsgdXNlcnMg Z2V0IGFubm95ZWQuIO+/vUlmIHNvbWUgYXNzZXQgc2VydmljZXM8YnI+CiDCoCDCoCDCoCDCoHJl ZnVzZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRvIHNlbmQgdGhlPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vXJlcXVlc3RlZDxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7IGl0ZW1zIHRvIHNv bWUgdXNlcnMsIHRob3NlIHNlcnZpY2VzIHdpbGwgZ2V0IGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBiYWQgcmVwdXRhdGlvbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIO+/vSDvv71hbmQgcGVvcGxlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAg77+9IO+/vSZndDsgd2lsbCBjaG9vc2UgZGlmZmVyZW50IGFzc2V0IHNlcnZp Y2VzIGluc3RlYWQuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9TGlr ZXdpc2UsIGlmIGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9 d29ybGQgc2VydmljZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDv v70mZ3Q7IHByb3hpZXMgZXZlcnl0aGluZyBhbmQgc28gaXQgY2FuJiMzOTt0IGhhbmRsZTxicj4K IMKgIMKgIMKgIMKgYSBsYXJnZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IG51bWJlciBvZjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv71h c3NldHMgb3Igb2Y8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9 Jmd0OyBwZW9wbGUsIHVzZXJzIHdpbGwgZ2V0IGFubm95ZWQgYXQgdGhlIGxhZzxicj4KIMKgIMKg IMKgIMKgYW5kIHdpbGwgZ288YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDv v70g77+9ZWxzZXdoZXJlLiDvv71UaGlzIHVzZXI8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDvv70g77+9Jmd0OyBldmFsdWF0aW9uIGFuZCAmcXVvdDt2b3Rpbmcgd2l0aCB0 aGVpciBmZWV0JnF1b3Q7PGJyPgogwqAgwqAgwqAgwqBoYXBwZW5zPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgYWxyZWFkeSB3aXRoPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAg77+9IO+/vW9ubGluZSBzZXJ2aWNlczxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7IGFsbCBvdmVyIHRoZSBJbnRlcm5ldCwgYW5k IEkgYW0gc3VyZSB0aGF0IHRoaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBodW1hbiBwcm9jZXNzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9 IO+/vXdpbGwgY29udGludWU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDv v70g77+9Jmd0OyB0byB3b3JrIHdoZW4gdGhlIHNlcnZpY2VzIGFyZSBhc3NldCBhbmQgcmVnaW9u PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc2VydmljZXMuPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0OyBCYWNrIGluIFNlcHRlbWJlciAyMDEw LCBJIHdyb3RlIHRoaXMgcG9zdDxicj4KIMKgIMKgIMKgIMKgd2hpY2g8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwcm9wb3NlcyB0aGF0PGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vXdlIHVzZSBpbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7IFZXUkFQIGEgZm9ybSBvZiBhc3NldCBhZGRyZXNz aW5nIHRoYXQgcHJvdmlkZXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBt YXNzaXZlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vXNjYWxh YmlsaXR5IGF0IHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDv v70mZ3Q7IHNhbWUgdGltZSBhcyBhIHZlcnkgaGlnaCBkZWdyZWUgb2Y8YnI+CiDCoCDCoCDCoCDC oHJlc2lsaWVuY2UgLS08YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g 77+9Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9PGEgaHJlZj0iaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Z3cmFwL2N1cnJlbnQvbXNnMDA0NjMu aHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi92d3JhcC9jdXJyZW50L21zZzAwNDYzLmh0bWw8L2E+PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAg77+9IO+/vS4g77+9SXQgaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0OyBiYXNlZCBvbiB0aGUgY29uY2VwdCBvZiB0aGUgVVJJ IGNvbnRhaW5pbmc8YnI+CiDCoCDCoCDCoCDCoGEgaG9zdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHBhcnQgYW5kIGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDvv70g77+9aGFzaCBwYXJ0LDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIO+/vSDvv70mZ3Q7IHdoZXJlIHRoZSBoYXNoIGlzIGdlbmVyYXRlZCAob25jZSwgYXQg dGhlPGJyPgogwqAgwqAgwqAgwqB0aW1lIG9mPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgc3RvcmFnZSB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IO+/vSDvv710aGUgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDv v70g77+9Jmd0OyBzZXJ2aWNlKSB1c2luZyBhIHNwZWNpZmllZCBkaWdlc3Q8YnI+CiDCoCDCoCDC oCDCoGFsZ29yaXRobSBvdmVyPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg dGhlIGNvbnRlbnQgb2Y8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g 77+9dGhlIGFzc2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/ vSZndDsgYmVpbmcgcmVmZXJlbmNlZC4g77+9WW91IG1heSB3aXNoIHRvIG5vdGU8YnI+CiDCoCDC oCDCoCDCoHRoYXQgaWY8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGlz IGRlc2lnbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv713ZXJl IHVzZWQsIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70m Z3Q7IGZhaWx1cmUgb2YgYW4gYXNzZXQgc2VydmljZSB0byBkZWxpdmVyIGE8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZXF1ZXN0ZWQgaXRlbSB3b3VsZDxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv71yZXN1bHQgaW4gYTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7IGZhaWxvdmVyIHJlcXVlc3Qg Zm9yIHRoZSBpdGVtIHRvIG9uZSBvciBtb3JlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgYmFja3VwIHNlcnZpY2VzLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIO+/vSDvv711c2luZyB0aGUgc2FtZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIO+/vSDvv70mZ3Q7IGhhc2ggcGFydCBidXQgd2l0aCBhIGRpZmZlcmVudCBob3N0 IGFkZHJlc3MuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZn dDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0OyBUaGlz IGNhbiBnbyBzb21lIHdheSB0b3dhcmRzIG92ZXJjb21pbmcgdGhlPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgcHJvYmxlbSB0aGF0IHlvdTxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv710aGluayBtaWdodDxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7IG9jY3VyIHdoZW4gYXNzZXRzIGFyZSBmZXRj aGVkIGJ5IGNsaWVudHMgZnJvbTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGFzc2V0IHNlcnZpY2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9 IO+/vWRpcmVjdGx5Ljxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDv v70mZ3Q7IEFsdGhvdWdoIGl0IHdvbiYjMzk7dCBoZWxwIHdoZW4gdGhlIG1pc3Npbmc8YnI+CiDC oCDCoCDCoCDCoGl0ZW0gaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBh dmFpbGFibGUgZnJvbTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDv v71vbmx5IGEgc2luZ2xlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9 IO+/vSZndDsgYXNzZXQgc2VydmljZSwgaXQgd2lsbCBoZWxwIGluIG1hbnkgb3RoZXI8YnI+CiDC oCDCoCDCoCDCoGNhc2VzLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFu ZCBpdCB3aWxsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vWNv bXBlbnNhdGUgZm9yPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/ vSZndDsgc2VydmljZSBmYWlsdXJlcyBhbmQgbmV0d29yayBvdXRhZ2VzPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYXV0b21hdGljYWxseSBhdCB0aGUgc2FtZTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv710aW1lLjxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsgUFMuIFRoaXMgZGVzaWduIGZvciBoYXNoLWJh c2VkIGFzc2V0PGJyPgogwqAgwqAgwqAgwqBhZGRyZXNzaW5nPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgaXMgYWxyZWFkeTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIO+/vSDvv71iZWluZyB0ZXN0ZWQgYnk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0OyBNb2ppdG8gU29yYmV0IGluIGhlciBleHBlcmltZW50 YWwgd29ybGQgYW5kPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY2xpZW50 LiDvv71JdCB3b3VsZCBnaXZlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg 77+9IO+/vSZndDsgVldSQVAtYmFzZWQgd29ybGRzIGFuIGltcHJvdmVkIGxldmVsIG9mPGJyPgog wqAgwqAgwqAgwqBzZXJ2aWNlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg YXZhaWxhYmlsaXR5LDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDv v71zbyBJIHRoaW5rIGl0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9 IO+/vSZndDsgc2hvdWxkIGJlIGEgY29yZSBmZWF0dXJlIG9mIG91ciBwcm90b2NvbC48YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsgTW9yZ2FpbmUuPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg 77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9 Jmd0OyA9PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIO+/vSDvv70mZ3Q7IE9uIEZyaSwgQXByIDEsIDIwMTEgYXQgMTE6MTcgUE0sIFZhdWdo biBEZWx1Y2E8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Jmx0 OzxhIGhyZWY9Im1haWx0bzp2YXVnaG4uZGVsdWNhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnZhdWdobi5kZWx1Y2FAZ21haWwuY29tPC9hPjxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86dmF1Z2huLmRlbHVjYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj52 YXVnaG4uZGVsdWNhQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dmF1Z2huLmRlbHVjYUBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj52YXVnaG4uZGVsdWNhQGdtYWlsLmNvbTwvYT48YnI+CiDC oCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZhdWdobi5kZWx1Y2FAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+dmF1Z2huLmRlbHVjYUBnbWFpbC5jb208L2E+Jmd0OyZndDs8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9 Im1haWx0bzp2YXVnaG4uZGVsdWNhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZhdWdobi5k ZWx1Y2FAZ21haWwuY29tPC9hPjxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86dmF1Z2huLmRlbHVjYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj52YXVnaG4uZGVs dWNhQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dmF1Z2huLmRlbHVjYUBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj52YXVnaG4uZGVsdWNhQGdtYWlsLmNvbTwvYT48YnI+CiDCoCDCoCDCoCDC oCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZhdWdobi5kZWx1Y2FAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+dmF1Z2huLmRlbHVjYUBnbWFpbC5jb208L2E+Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7IHdyb3RlOjxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7Jmd0Ozxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7Jmd0OyBUaGlzIGlz IGEgcXVlc3Rpb24gaSBkaXNjdXNzZWQgd2l0aCBNb3JnYWluZTxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIG9mZi1saXN0IGEgd2hpbGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDvv70g77+9YWdvIChJPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAg77+9IO+/vSZndDsmZ3Q7IGludGVuZGVkIHRvIHNlbmQgaXQgdG8gdGhlIGxp c3QgYnV0PGJyPgogwqAgwqAgwqAgwqBwdXNoZWQgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgd3JvbmcgYnV0dG9uLi4uKSBJPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsmZ3Q7IHRoaW5rIHdlIG5lZWQgdG8gYWRkcmVzcyB0 aGlzIHByb2JsZW0sIGFuZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRl Y2lkZSBob3cgdG8gZGVhbDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/ vSDvv713aXRoIGl0Ljxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDv v70mZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70m Z3Q7Jmd0OyDvv71JbiBEYXZpZHMgZGVwbG95bWVudCBkcmFmdCwgc2VjdGlvbjxicj4KIMKgIMKg IMKgIMKgNy4zLjEuMSBhbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG92 ZXJ2aWV3IGlzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vWdp dmVuIHZhbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7 Jmd0OyB3YXlzIHRvIGRlbGl2ZXIgY29udGVudCB0byB0aGUgcmVnaW9uLjxicj4KIMKgIMKgIMKg IMKgT25lIHdheTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlzIG9ubHkg cGFzc2luZyBhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZn dDsmZ3Q7IGNhcGFiaWxpdHkgdGhhdCBhbGxvd3MgYWNjZXNzIHRvIChwYXJ0PGJyPgogwqAgwqAg wqAgwqBvZikgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVzb3Vy Y2U6PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsmZ3Q7 PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsmZ3Q7IO+/ vSDvv70g77+9IO+/vSDvv70gNy4zLjEuMS4g77+9Q29udGVudCBkZWxpdmVyeSBtb2RlbHM8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0OyZndDsg77+9IO+/ vSDvv70g77+9IO+/vSBBIHJhbmdlIG9mIHBvc3NpYmxlPGJyPgogwqAgwqAgwqAgwqByZXByZXNl bmF0aW9ucyBjYW48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBiZSBwYXNz ZWQgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9YSByZWdp b24gZm9yPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsm Z3Q7IO+/vSDvv70g77+9IO+/vSDvv70gc2ltdWxhdGlvbi4gWy4uLl0gVGhlIG90aGVyIGVuZDxi cj4KIMKgIMKgIMKgIMKgb2YgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgZGVsaXZlcnkgc3BlY3RydW08YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDvv70g77+9Jmd0OyZndDsgaW52b2x2ZXMgcGFzc2luZzxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/vSDvv70g77+9IG9ubHkg YSBVUkkgb3IgY2FwYWJpbGl0eSB1c2VkIHRvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgYWNjZXNzIHRoZSByZW5kZXJpbmc8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDvv70g77+9Jmd0OyZndDsgaW5mb3JtYXRpb24gYW5kIGE8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0OyZndDsg77+9IO+/vSDvv70g77+9 IO+/vSBjb2xsaXNpb24gbWVzaCxhbmQgcmVsYXRlZCBkYXRhIGZvcjxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHBoeXNpY2FsIHNpbXVsYXRpb24uPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsmZ3Q7IO+/vSDvv70g77+9IO+/vSDv v70gSW4gc3VjaCBhIG1vZGVsLCB0aGUgY2xpZW50IGlzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgcmVzcG9uc2libGUgZm9yPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAg77+9IO+/vWZldGNoaW5nIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7Jmd0OyBhZGRpdGlvbmFsPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsmZ3Q7IO+/vSDvv70g77+9IO+/vSDvv70g aW5mb3JtYXRpb24gbmVlZGVkIHRvIHJlbmRlciB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBpdGVtJiMzOTtzIHZpc3VhbDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIO+/vSDvv71wcmVzZW5jZSBmcm9tIGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0OyZndDsgc2VwYXJhdGU8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0OyZndDsg77+9IO+/vSDvv70g77+9IO+/ vSBzZXJ2aWNlLiDvv71UaGlzIGZldGNoIGNhbiBiZSBkb25lPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgKnVuZGVyIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIO+/vSDvv71jcmVkZW50aWFscyBvZiB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0OyZndDsgZW5kIHVzZXIqPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsmZ3Q7IO+/vSDvv70g77+9IO+/vSDv v70gdmlld2luZyB0aGUgbWF0ZXJpYWwgW215PGJyPgogwqAgwqAgwqAgwqBlbXBoYXNpcy0tVkRd PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLCBhbmQ8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9ZGl2b3JjZXMgdGhlPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsmZ3Q7IHNpbXVsYXRpb24gZnJv bTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7Jmd0OyDv v70g77+9IO+/vSDvv70g77+9IHRoZSB0cnVzdCBjaGFpbiBuZWVkZWQgdG8gbWFuYWdlPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY29udGVudC4g77+9QW55PGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vWF1dG9tYXRpb248YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0OyZndDsgaXMgZG9uZSBvbiBh PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsmZ3Q7IO+/ vSDvv70g77+9IO+/vSDvv70gc2VwYXJhdGUgaG9zdCB3aGljaCB0aGUgY29udGVudDxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNyZWF0b3Igb3Igb3duZXIgdHJ1c3RzLDxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7Jmd0OyBpbnRl cmFjdGluZyB3aXRoIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/ vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/vSDvv70g77+9IG9iamVjdCB0aHJvdWdoIHJlbW90ZWQg aW50ZXJmYWNlcy48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9 Jmd0OyZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0 OyZndDsg77+9SSBjYW4gc2VlIHRoZSBuZWVkIGZvciBzdWNoIGEgc2V0dXAsPGJyPgogwqAgwqAg wqAgwqBob3dldmVyLCBpPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZmVl bCB3ZSBhcmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0 OyZndDsgdW5wbGVhc2FudGx5IGNsb3NlIHRvIGEgc2l0dWF0aW9uIHdlcmUgdGhlPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY29oZXJlbmNlIG9mIHRoZTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv71zaW11bGF0aW9uPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsmZ3Q7IGZhbGxzIGFwYXJ0Ljxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7Jmd0OyBJbiB0 aGlzIGRlcGxveW1lbnQgcGF0dGVybiB0aGUgcmVnaW9uPGJyPgogwqAgwqAgwqAgwqBhZHZlcnRp c2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhlIHByZXNlbmNlPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vW9mIHRoZTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7Jmd0OyBhc3NldCwgYW5k ICpzb21lKiBjbGllbnRzIHdpbGwgYmUgYWJsZSB0bzxicj4KIMKgIMKgIMKgIMKgZ2V0IGl0PGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYXMgZXhwZWN0ZWQsPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vXdoaWxlPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsmZ3Q7IC1iYXNlZCBvbiB0aGUgYXJi aXRyYXJ5IHdoaW1zIG9mIHRoZSBhc3NldDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHNlcnZpY2UtIG90aGVyczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIO+/vSDvv71taWdodCBub3QuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAg77+9IO+/vSZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg 77+9IO+/vSZndDsmZ3Q7IE15IGhvcGUgd291bGQgYmUgdGhhdCBhZnRlciB0aGUgYXNzZXQgc2Vy dmVyPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcHJvdmlkZXMgdGhlPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vXJlZ2lvbiB3aXRoPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsmZ3Q7IHRoZSBj YXBhYmlsaXR5IHRvIGdldCB0aGUgYXNzZXQsIGl0IGdpdmVzIHVwPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgY29udHJvbC4gVGhhdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIO+/vSDvv713b3VsZCBtZWFuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsmZ3Q7IHRoYXQgaWYgdGhlIGNsaWVudCBmaW5kcyB0 aGUgaW52ZW50b3J5PGJyPgogwqAgwqAgwqAgwqBzZXJ2ZXIgaXM8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB1bndpbGxpbmcgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDvv70g77+9c2VydmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDvv70g77+9Jmd0OyZndDsgdGhlIGNvbnRlbnQgLSBpbiBzcGlyZSBvZiB0aGUgcmVn aW9uPGJyPgogwqAgwqAgwqAgwqBzYXlpbmcgaXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBpcyBwcmVzZW50LSw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDvv70g77+9dGhlIGNsaWVudDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIO+/vSDvv70mZ3Q7Jmd0OyBzaG91bGQgYmUgYWJsZSB0byB0dXJuIGFyb3VuZCBhc2sgdGhl PGJyPgogwqAgwqAgwqAgwqAqcmVnaW9uKjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGZvciB0aGUgYXNzZXQsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAg77+9IO+/vShhbmQgZ2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg 77+9IO+/vSZndDsmZ3Q7IGlzIGFmdGVyIGFsbCkuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAg77+9IO+/vSZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAg77+9IO+/vSZndDsmZ3Q7IO+/vUlmIHRoYXQgaXMgbm90IHRoZSBjYXNlLCAtYW5k IHRoZXJlIGFyZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHByb2JhYmx5 IGdvb2QgcmVhc29uczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDv v71mb3IgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZn dDsmZ3Q7IGRlcGxveW1lbnQgcGF0dGVybiBhcyBkZXNjcmliZWQtPGJyPgogwqAgwqAgwqAgwqDv v71zaG91bGRuJiMzOTt0IHdlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg Kndhcm4qIGNsaWVudHM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g 77+9dGhhdCB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9 Jmd0OyZndDsgcmVnaW9uIG1pZ2h0IGJlIGluY29uc2lzdGVudCwgc28gdGhlIHVzZXJzPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYmVoaW5kIHRoZSBjbGllbnQ8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Y2FuIHZvdGU8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0OyZndDsgd2l0aCB0aGVpciBm ZWV0LCAob3IgdGFrZSB0aGUgcmlzayk/PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAg77+9IO+/vSZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAg77+9IO+/vSZndDsmZ3Q7IC0tVmF1Z2huPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAg77+9IO+/vSZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7Jmd0OyB2d3JhcCBtYWlsaW5nIGxpc3Q8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDvv70g77+9Jmd0OyZndDsgPGEgaHJlZj0ibWFp bHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+ICZs dDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ dndyYXBAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVm PSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwv YT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj52d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFp bHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVm PSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwv YT4mZ3Q7Jmd0OyZndDs8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IO+/vSDvv70mZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Z3cmFwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby92d3JhcDwvYT48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDv v70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDs8 YnI+CiDCoCDCoCDCoCDCoF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDsg dndyYXAgbWFpbGluZyBsaXN0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg 77+9IO+/vSZndDsgPGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+dndyYXBAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4KIMKgIMKg IMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndy YXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7Jmd0Ozxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+ ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+dndyYXBAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9y ZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7Jmd0OyZndDs8YnI+Cjxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdndyYXAiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Z3cmFwPC9hPjxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAg77+9IO+/vSZndDs8YnI+Cjxicj4KPGJyPgo8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4KPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB2d3JhcCBtYWls aW5nIGxpc3Q8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8YSBocmVmPSJtYWlsdG86 dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4gJmx0O21h aWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3Jh cEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPgogwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiAm bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnZ3cmFwQGlldGYub3JnPC9hPiZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92d3JhcCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdndy YXA8L2E+PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9PGJyPgo8YnI+Cjxicj4K PGJyPgo8YnI+Cjxicj48L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJpbSI+CiDCoCDCoCDCoCDCoCDC oCAtLSDCoCDCoCAtLS0gPGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9Eem9uYXRhc19Tb2wi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3R3aXR0ZXIuY29tL0R6b25hdGFzX1NvbDwvYT4gLS0t PGJyPgogwqAgwqAgwqAgwqAgwqAgV2ViIERldmVsb3BtZW50LCBTb2Z0d2FyZSBFbmdpbmVlcmlu ZywgVmlydHVhbCBSZWFsaXR5LDxicj4KIMKgIMKgIMKgIMKgQ29uc3VsdGFudDxicj4KPGJyPgog wqAgwqAgwqAgwqAgwqAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+CiDCoCDCoCDCoCDCoCDCoCB2d3JhcCBtYWlsaW5nIGxpc3Q8YnI+CiDCoCDCoCDC oCDCoCDCoCA8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52 d3JhcEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPjwvZGl2PjxkaXYg Y2xhc3M9ImltIj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRm Lm9yZzwvYT4mZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdndyYXAiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Z3cmFwPC9hPjxicj4KPGJyPgo8YnI+Cjxi cj4KPGJyPjwvZGl2PjxkaXYgY2xhc3M9ImltIj4KIMKgIMKgLS0gwqAgwqAgLS0tIDxhIGhyZWY9 Imh0dHBzOi8vdHdpdHRlci5jb20vRHpvbmF0YXNfU29sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly90d2l0dGVyLmNvbS9Eem9uYXRhc19Tb2w8L2E+IC0tLTxicj4KIMKgIMKgV2ViIERldmVsb3Bt ZW50LCBTb2Z0d2FyZSBFbmdpbmVlcmluZywgVmlydHVhbCBSZWFsaXR5LCBDb25zdWx0YW50PGJy Pgo8YnI+CiDCoCDCoF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPgogwqAgwqB2d3JhcCBtYWlsaW5nIGxpc3Q8YnI+CiDCoCDCoDxhIGhyZWY9Im1haWx0 bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiAmbHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3 cmFwQGlldGYub3JnPC9hPiZndDs8YnI+CiDCoCDCoDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdndyYXAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Z3cmFwPC9hPjxicj4KPGJyPgo8YnI+PC9kaXY+Ci0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxkaXYgY2xhc3M9ImltIj48YnI+Cjxicj4KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+CnZ3cmFwIG1haWxpbmcgbGlzdDxicj4K PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0 Zi5vcmc8L2E+PGJyPgo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Z3cmFwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby92d3JhcDwvYT48YnI+CiDCoDxicj4KPC9kaXY+PC9ibG9ja3F1b3RlPgo8YnI+PGRp dj48ZGl2PjwvZGl2PjxkaXYgY2xhc3M9Img1Ij4KPGJyPgotLSA8YnI+Ci0tLSA8YSBocmVmPSJo dHRwczovL3R3aXR0ZXIuY29tL0R6b25hdGFzX1NvbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v dHdpdHRlci5jb20vRHpvbmF0YXNfU29sPC9hPiAtLS08YnI+CldlYiBEZXZlbG9wbWVudCwgU29m dHdhcmUgRW5naW5lZXJpbmcsIFZpcnR1YWwgUmVhbGl0eSwgQ29uc3VsdGFudDxicj4KPGJyPgo8 L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPgo= --002354470e60b21f0904a007dbf0-- From vaughn.deluca@gmail.com Sun Apr 3 11:36:41 2011 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 9A2F928C0EA for ; Sun, 3 Apr 2011 11:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.133 X-Spam-Level: X-Spam-Status: No, score=-3.133 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] 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 ZHTk9xUjnEt8 for ; Sun, 3 Apr 2011 11:36:36 -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 B602628C0E0 for ; Sun, 3 Apr 2011 11:36:35 -0700 (PDT) Received: by ewy19 with SMTP id 19so1734803ewy.31 for ; Sun, 03 Apr 2011 11:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9vA0v2ITwo5CXLm/w4PPIPI4M+PqodWGBhpS5bOO1hw=; b=lhCDHuU9XvKcONYkjBfdLmfKm0KqkHYqTqI5piE0Ig+qpJRoKfuFenfZd3n8Zl+t0m T1RpCZVRISJMpvhs6EhK5YI4oyQlsKd2MGA9sjW2OPeWAxQyqn+eAjBT8roPNQvstLV+ mqXbThOQGHRG3LdGHkPUNFVrKsy7eL9Tyvq1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pfhkMN/lzUMja2lA50aWDgXrIZjBFkqtAVLpedp8SHMcieuhRtTI3YIQT6tBzXNEi/ rXnd6FlZsFiLYFIAqDuYpidVETSmLLQYOHSCF4tZeBx/KnJ0khdog6LGBrZF+0ah5Rsp ow/mCpeHh/Sw9rDVcEsPM9rJEbD5HgPO0MqEU= MIME-Version: 1.0 Received: by 10.213.25.79 with SMTP id y15mr3213832ebb.41.1301855896943; Sun, 03 Apr 2011 11:38:16 -0700 (PDT) Received: by 10.213.17.17 with HTTP; Sun, 3 Apr 2011 11:38:16 -0700 (PDT) In-Reply-To: <4D98AC5F.70501@gmail.com> References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> Date: Sun, 3 Apr 2011 20:38:16 +0200 Message-ID: From: Vaughn Deluca To: Dzonatas Sol Content-Type: multipart/alternative; boundary=000e0ce0b726493f1804a007f2c5 Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 03 Apr 2011 18:36:41 -0000 --000e0ce0b726493f1804a007f2c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the pointers. I have a busy week in RL in front of me, so i wont have to much time to respond the next few days, however, i intend to start doing the following things: - Produce a visual that reflects my thinking, i.e. an illustration of my response to Morgaine's itemlist above. - Read up on the older notes, as well as more reading in the list archive - Try to make a summary for the wiki Regarding the use of domain, I think services are eventually what counts, but its all terminology. The way I read the AWG diagrams is that the agent domain is actually a cluster of tightly integrated services. When the functionality of each sub-service is described properly and with uniform interfaces the domain will slowly dissolve. But let not get ahead of out selfs. We should put up some clear descriptions on the wiki for our views o= n this, and *after* that we can decide what we need and what can go. Its been a very useful and illuminating weekend for me, and i am a lot more optimistic about the future of vwrap than two weeks ago. -- Vaughn On Sun, Apr 3, 2011 at 7:20 PM, Dzonatas Sol wrote: > Probably easy as suggested in other terms here on this list, as how the > client contacts the asset services now in the regions. The newer issue is= to > unitize that asset services. Since their is proprietary (legacy) code the= n > we can't expect that to change, and some form of proxy is of need. Whatev= er > works best, I tried to narrow it down to suggestions here. > > Eventually, the agent domain is ideal to handle the direction of the asse= t > services. This concept, unfortunately, ended support awhile ago with chan= ges > in LL. > Also see; http://wiki.secondlife.com/wiki/Agent_Domain > And: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset (warn: > unstructured collaborative notes, dumped on me and I tried to fix) > > I tried to find previous visuals. > > I'd imagine the agent domain could grow out of unitized versions of asset > services. Despite that, I think that concept helps view where we were at = in > discussion and what didn't happen. > > Vaughn Deluca wrote: > >> Hi=EF=BF=BDDzonatas >> >> Can you expand on that, what would be needed for legacy support in VWAP >> terms=EF=BF=BD?, >> If i want to read up on how the=EF=BF=BDasset server may proxy the simul= ator, what >> would you recommend me to read? >> >> -- Vaughn >> >> On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol > dzonatas@gmail.com>> wrote: >> >> Some stated the proxy-to-asset-server is built into the sim; >> however, keep in mind possible legacy support where the asset >> server may proxy the simulator. >> >> >> Dzonatas Sol wrote: >> >> Somehow I feel the basic asset server being able to login and >> download assets is now priority, yet I also wondered the best >> way to patch this into the current mode of viewers. >> >> Maybe offer (1) by proxy (sim-side) and (2) by patch >> (viewer-side) that either of these two are optional and >> neither are mandatory for now. Thoughts? >> >> Israel Alanis wrote: >> >> >> > when designing for scalability, the model to bear in >> mind is ... >> >> Well, there are a lot of different models to keep in mind, >> and many different use cases. One particular use case to >> keep in mind is: "User acquires new outfit, and wants to >> 'show it off' in a highly populated region". >> >> > Both worlds and asset services may include commercial, >> community, and personal services >> >> Yes, yes and yes. I'm particularly concerned about how the >> model affects the ability to host personal asset services. >> >> > a proxying region, which would get slammed for every >> asset worn by every avatar present. >> >> Granted the collection of services that are provided by >> the region need to be scaled to meet the demands of that >> region. That's all part of capacity planning. >> >> > regions run many different CPU-intensive tasks, >> including physics simulation and server-side scripting, >> and absolutely cannot afford to serve assets too >> Well... who said the same CPU's have to do proxying, >> physics simulation and server-side scripting? Asset >> proxying is a different service than physics simulation >> and can be on separate hardware, could make use of >> geographically distributed caching, and in certain >> deployment patterns, the same caching services could be >> shared by different regions. (Server-side scripting is a >> discussion for another day). >> >> > This is why we have to go parallel... >> >> Totally agree, and a proxying model could and should also >> take advantage of parallelism. >> >> > I think you're wrong that it has to cost much money. ?vs? >> > It costs money to host a high performance and scalable >> asset service and a high bandwidth network to handle the >> traffic. =EF=BF=BDA *lot* of money. >> I think what you're saying is: "It costs a lot of money to >> build a scalable asset service, but if assets are spread >> throughout the internet they don't have to be scalable." >> But that's not quite right. You're opening up every asset >> server to the VW equivalent of being slashdotted, so are >> you sure you're not forcing *every* asset service to be >> scalable and handle a lot of bandwith and network traffic? >> It's the exact opposite of your intention, but I think >> that's the result, all the same. >> >> This particular design decision has a big effect on the >> economics of the VW infrastructure. I'd rather the >> economics to work out such that a region provider who >> wishes to build a region that supports a small population, >> can do so economically. A region that wants to host a >> *large* population has to bear that cost of providing that >> scalable asset service. >> I want the economics of hosting a small asset service to >> be a non-issue (as to best promote creation and >> creativity). Creating a high bar to provide asset services >> will mean that service will cost money and people >> shouldn't have to pay money just to create or own VW >> objects (I'm using 'own' here to refer to maintaining >> their existence, I'm not trying to make a >> 'leftist'/'communist' statement about ownership ;) >> >> - Izzy >> >> >> On Apr 2, 2011, at 3:58 PM, Morgaine wrote: >> >> Izzy, when designing for scalability, the model to >> bear in mind is that of seasoned virtual world >> travelers whose inventories contain assets from many >> different worlds, those assets being served by many >> different asset services. =EF=BF=BDBoth worlds and asset >> services may include commercial, community, and >> personal services, and as the metaverse grows, that >> set is highly likely to become progressively less >> clustered and more diverse. >> >> When those seasoned travelers click on an advertised >> VW link and perform an inter-world teleport to one >> particular world's region to share an experience, >> their "worn" assets (the only ones of interest to the >> region) will contain references to asset services >> spread widely across the Internet. =EF=BF=BDThe fetches b= y the >> travelers' clients occur over many parallel paths from >> clients to asset services, so one can reasonably >> expect reduced network contention and reduced asset >> server loading because they are both spread out over >> however many asset services are being referenced by >> the overall set of assets in the region. >> >> This is very different to the case of a proxying >> region, which would get slammed for every asset worn >> by every avatar present. =EF=BF=BDIn our current architec= ture, >> regions run many different CPU-intensive tasks, >> including physics simulation and server-side >> scripting, and absolutely cannot afford to serve >> assets too unless your scalability requirements are >> very low indeed, ie. just a few dozen avatars of >> today's kind. =EF=BF=BDWe've hit the ceiling already on r= egion >> scalability done that way. =EF=BF=BDThere is nowhere to g= o in >> that direction at all beyond improving the code like >> Intel demonstrated, and that work is subject to a law >> of diminishing returns. >> >> This is why we have to go parallel, and I think you're >> wrong that it has to cost much money. =EF=BF=BDAs we spre= ad >> the load across more and more asset services, we are >> simply better utilizing all the hardware that's >> already out there on the Internet, at least in respect >> of community and private resources. =EF=BF=BDBut add to t= he >> community and private resources the commercial asset >> services that are likely to appear to exploit this >> opportunity, and not only will the number of asset >> services leap, but the power of each one will rocket >> too, because, after all, these businesses will be >> heavily optimized for the job. >> >> As to why a world would want clients to access >> external asset services instead of providing its own >> implementation, that's an easy question. =EF=BF=BDIt cost= s >> money to host a high performance and scalable asset >> service and a high bandwidth network to handle the >> traffic. =EF=BF=BDA *lot* of money. =EF=BF=BDIn contrast,= it costs a >> world nothing to let others serve the assets to >> clients. =EF=BF=BDAnd that matters to the bottom line. >> >> >> Morgaine. >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> >> On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis >> >> > >> >> wrote: >> >> =EF=BF=BD =EF=BF=BD> As always though, it's a trade-off, = since the >> proxied design >> =EF=BF=BD =EF=BF=BDhas very poor scalability compared to = the >> distributed one. >> >> =EF=BF=BD =EF=BF=BDI don't agree with that... If a user e= nters a >> highly populated >> =EF=BF=BD =EF=BF=BDregion, >> =EF=BF=BD =EF=BF=BDevery other client is going to (could = and should be >> trying to) >> =EF=BF=BD =EF=BF=BDhit the >> =EF=BF=BD =EF=BF=BDasset server(s) for the assets that th= e user is >> wearing (assuming >> =EF=BF=BD =EF=BF=BDthey're not cached locally). =EF=BF=BD= Every asset server >> has to be scaled up >> =EF=BF=BD =EF=BF=BDto the point that it can handle that l= oad from all >> over... >> >> =EF=BF=BD =EF=BF=BDIf I'm hosting a region that supports = 10s of >> thousands of >> =EF=BF=BD =EF=BF=BDsimultaneous >> =EF=BF=BD =EF=BF=BDusers (thinking of the future), I alre= ady have to >> scale to meet that >> =EF=BF=BD =EF=BF=BDdemand. If the region is proxying the = assets, then, >> yes the >> =EF=BF=BD =EF=BF=BDregion has >> =EF=BF=BD =EF=BF=BDto be scaled to meet that asset demand= too, but it >> already has to be >> =EF=BF=BD =EF=BF=BDscaled to meet other demands of being = a region >> server... and why is >> =EF=BF=BD =EF=BF=BDscaling those asset proxy services har= d? =EF=BF=BDIt's >> going to cost $, >> =EF=BF=BD =EF=BF=BDbut is >> =EF=BF=BD =EF=BF=BDnot technically challenging. So, if I = want to host >> a region like >> =EF=BF=BD =EF=BF=BDthat... sure it will cost me, but the = simulation >> will be consistent >> =EF=BF=BD =EF=BF=BDand users will be able to participate = equally, >> regardless of the >> =EF=BF=BD =EF=BF=BDcapabilities of their individual asset= services. >> >> >> >> >> =EF=BF=BD =EF=BF=BDOn Fri, Apr 1, 2011 at 11:55 PM, Morga= ine >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> >> wrote: >> =EF=BF=BD =EF=BF=BD> Every design choice results in a tra= de-off, >> Vaughn, improving >> =EF=BF=BD =EF=BF=BDone thing at >> =EF=BF=BD =EF=BF=BD> the expense of something else. =EF= =BF=BDIf every time we >> offered a >> =EF=BF=BD =EF=BF=BDservice we had to >> =EF=BF=BD =EF=BF=BD> inform its users about the downsides= of all the >> trade-offs we >> =EF=BF=BD =EF=BF=BDhave made, >> =EF=BF=BD =EF=BF=BD> they would have an awful lot to read= . ;-) >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> The specific trade-off that you are = discussing is no >> =EF=BF=BD =EF=BF=BDdifferent. =EF=BF=BDA region >> =EF=BF=BD =EF=BF=BD> that proxies all content has the "be= nefit" of >> acquiring control >> =EF=BF=BD =EF=BF=BDfrom the >> =EF=BF=BD =EF=BF=BD> asset servers over the items in the = region, so >> that it can >> =EF=BF=BD =EF=BF=BDensure that >> =EF=BF=BD =EF=BF=BD> everyone in the region not only obta= ins the items >> but obtains >> =EF=BF=BD =EF=BF=BDthe same items >> =EF=BF=BD =EF=BF=BD> as everyone else. =EF=BF=BDThat does= indeed provide a >> greater guarantee of >> =EF=BF=BD =EF=BF=BD> consistency than a deployment in whi= ch the region >> only passes >> =EF=BF=BD =EF=BF=BDasset URIs to >> =EF=BF=BD =EF=BF=BD> clients who then fetch the items fro= m asset services >> =EF=BF=BD =EF=BF=BDseparately. =EF=BF=BDAs always >> =EF=BF=BD =EF=BF=BD> though, it's a trade-off, since the = proxied >> design has very >> =EF=BF=BD =EF=BF=BDpoor scalability >> =EF=BF=BD =EF=BF=BD> compared to the distributed one. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> If we're going to warn users of the = potential for >> inconsistency >> =EF=BF=BD =EF=BF=BDin the >> =EF=BF=BD =EF=BF=BD> distributed deployment as you sugges= t, are we >> also going to >> =EF=BF=BD =EF=BF=BDwarn them of >> =EF=BF=BD =EF=BF=BD> non-scalability in the proxied one? = =EF=BF=BDI really >> don't see much >> =EF=BF=BD =EF=BF=BDmerit in the >> =EF=BF=BD =EF=BF=BD> idea of warning about design choices= . =EF=BF=BDMany such >> choices are >> =EF=BF=BD =EF=BF=BDtechnical, and >> =EF=BF=BD =EF=BF=BD> the issues are quite likely to be of= little >> interest to >> =EF=BF=BD =EF=BF=BDnon-technical users >> =EF=BF=BD =EF=BF=BD> anyway. =EF=BF=BDIn any case, the be= tter services are >> likely to provide >> =EF=BF=BD =EF=BF=BDsuch >> =EF=BF=BD =EF=BF=BD> information in their online document= ation, I >> would guess. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> You mentioned users "voting with the= ir feet" or >> choosing to >> =EF=BF=BD =EF=BF=BDaccept the risk >> =EF=BF=BD =EF=BF=BD> of inconsistency. =EF=BF=BDWell that= will happen anyway, >> when services >> =EF=BF=BD =EF=BF=BDfail and >> =EF=BF=BD =EF=BF=BD> users get annoyed. =EF=BF=BDIf some = asset services refuse >> to send the >> =EF=BF=BD =EF=BF=BDrequested >> =EF=BF=BD =EF=BF=BD> items to some users, those services = will get a >> bad reputation >> =EF=BF=BD =EF=BF=BDand people >> =EF=BF=BD =EF=BF=BD> will choose different asset services= instead. >> =EF=BF=BDLikewise, if a >> =EF=BF=BD =EF=BF=BDworld service >> =EF=BF=BD =EF=BF=BD> proxies everything and so it can't h= andle a large >> number of >> =EF=BF=BD =EF=BF=BDassets or of >> =EF=BF=BD =EF=BF=BD> people, users will get annoyed at th= e lag and will go >> =EF=BF=BD =EF=BF=BDelsewhere. =EF=BF=BDThis user >> =EF=BF=BD =EF=BF=BD> evaluation and "voting with their fe= et" happens >> already with >> =EF=BF=BD =EF=BF=BDonline services >> =EF=BF=BD =EF=BF=BD> all over the Internet, and I am sure= that this >> human process >> =EF=BF=BD =EF=BF=BDwill continue >> =EF=BF=BD =EF=BF=BD> to work when the services are asset = and region >> services. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> Back in September 2010, I wrote this= post which >> proposes that >> =EF=BF=BD =EF=BF=BDwe use in >> =EF=BF=BD =EF=BF=BD> VWRAP a form of asset addressing tha= t provides >> massive >> =EF=BF=BD =EF=BF=BDscalability at the >> =EF=BF=BD =EF=BF=BD> same time as a very high degree of r= esilience -- >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD >> =EF=BF=BD >> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >> =EF=BF=BD =EF=BF=BD. =EF=BF=BDIt is >> =EF=BF=BD =EF=BF=BD> based on the concept of the URI cont= aining a host >> part and a >> =EF=BF=BD =EF=BF=BDhash part, >> =EF=BF=BD =EF=BF=BD> where the hash is generated (once, a= t the time of >> storage to >> =EF=BF=BD =EF=BF=BDthe asset >> =EF=BF=BD =EF=BF=BD> service) using a specified digest al= gorithm over >> the content of >> =EF=BF=BD =EF=BF=BDthe asset >> =EF=BF=BD =EF=BF=BD> being referenced. =EF=BF=BDYou may w= ish to note that if >> this design >> =EF=BF=BD =EF=BF=BDwere used, the >> =EF=BF=BD =EF=BF=BD> failure of an asset service to deliv= er a >> requested item would >> =EF=BF=BD =EF=BF=BDresult in a >> =EF=BF=BD =EF=BF=BD> failover request for the item to one= or more >> backup services, >> =EF=BF=BD =EF=BF=BDusing the same >> =EF=BF=BD =EF=BF=BD> hash part but with a different host = address. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> This can go some way towards overcom= ing the >> problem that you >> =EF=BF=BD =EF=BF=BDthink might >> =EF=BF=BD =EF=BF=BD> occur when assets are fetched by cli= ents from >> asset services >> =EF=BF=BD =EF=BF=BDdirectly. >> =EF=BF=BD =EF=BF=BD> Although it won't help when the miss= ing item is >> available from >> =EF=BF=BD =EF=BF=BDonly a single >> =EF=BF=BD =EF=BF=BD> asset service, it will help in many = other cases, >> and it will >> =EF=BF=BD =EF=BF=BDcompensate for >> =EF=BF=BD =EF=BF=BD> service failures and network outages >> automatically at the same >> =EF=BF=BD =EF=BF=BDtime. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> PS. This design for hash-based asset= addressing >> is already >> =EF=BF=BD =EF=BF=BDbeing tested by >> =EF=BF=BD =EF=BF=BD> Mojito Sorbet in her experimental wo= rld and >> client. =EF=BF=BDIt would give >> =EF=BF=BD =EF=BF=BD> VWRAP-based worlds an improved level= of service >> availability, >> =EF=BF=BD =EF=BF=BDso I think it >> =EF=BF=BD =EF=BF=BD> should be a core feature of our prot= ocol. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> Morgaine. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> =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 >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> On Fri, Apr 1, 2011 at 11:17 PM, Vau= ghn Deluca >> =EF=BF=BD =EF=BF=BD> >> > >> >> =EF=BF=BD =EF=BF=BD> wrote: >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> This is a question i discussed with= Morgaine >> off-list a while >> =EF=BF=BD =EF=BF=BDago (I >> =EF=BF=BD =EF=BF=BD>> intended to send it to the list but= pushed the >> wrong button...) I >> =EF=BF=BD =EF=BF=BD>> think we need to address this probl= em, and >> decide how to deal >> =EF=BF=BD =EF=BF=BDwith it. >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDIn Davids deployment draft= , section 7.3.1.1 an >> overview is >> =EF=BF=BD =EF=BF=BDgiven van >> =EF=BF=BD =EF=BF=BD>> ways to deliver content to the regi= on. One way >> is only passing a >> =EF=BF=BD =EF=BF=BD>> capability that allows access to (p= art of) the >> resource: >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD 7.3.1.1. =EF=BF=BDContent delivery models >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD A range of possible represenations can >> be passed to >> =EF=BF=BD =EF=BF=BDa region for >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD simulation. [...] The other end of the >> delivery spectrum >> =EF=BF=BD =EF=BF=BD>> involves passing >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD only a URI or capability used to >> access the rendering >> =EF=BF=BD =EF=BF=BD>> information and a >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD collision mesh,and related data for >> physical simulation. >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD In such a model, the client is >> responsible for >> =EF=BF=BD =EF=BF=BDfetching the >> =EF=BF=BD =EF=BF=BD>> additional >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD information needed to render the >> item's visual >> =EF=BF=BD =EF=BF=BDpresence from a >> =EF=BF=BD =EF=BF=BD>> separate >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD service. =EF=BF=BDThis fetch can be done >> *under the >> =EF=BF=BD =EF=BF=BDcredentials of the >> =EF=BF=BD =EF=BF=BD>> end user* >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD viewing the material [my emphasis--VD] >> , and >> =EF=BF=BD =EF=BF=BDdivorces the >> =EF=BF=BD =EF=BF=BD>> simulation from >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD the trust chain needed to manage >> content. =EF=BF=BDAny >> =EF=BF=BD =EF=BF=BDautomation >> =EF=BF=BD =EF=BF=BD>> is done on a >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD separate host which the content >> creator or owner trusts, >> =EF=BF=BD =EF=BF=BD>> interacting with the >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD object through remoted interfaces. >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDI can see the need for suc= h a setup, however, i >> feel we are >> =EF=BF=BD =EF=BF=BD>> unpleasantly close to a situation w= ere the >> coherence of the >> =EF=BF=BD =EF=BF=BDsimulation >> =EF=BF=BD =EF=BF=BD>> falls apart. >> =EF=BF=BD =EF=BF=BD>> In this deployment pattern the regi= on advertises >> the presence >> =EF=BF=BD =EF=BF=BDof the >> =EF=BF=BD =EF=BF=BD>> asset, and *some* clients will be a= ble to get it >> as expected, >> =EF=BF=BD =EF=BF=BDwhile >> =EF=BF=BD =EF=BF=BD>> -based on the arbitrary whims of th= e asset >> service- others >> =EF=BF=BD =EF=BF=BDmight not. >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> My hope would be that after the ass= et server >> provides the >> =EF=BF=BD =EF=BF=BDregion with >> =EF=BF=BD =EF=BF=BD>> the capability to get the asset, it= gives up >> control. That >> =EF=BF=BD =EF=BF=BDwould mean >> =EF=BF=BD =EF=BF=BD>> that if the client finds the invent= ory server is >> unwilling to >> =EF=BF=BD =EF=BF=BDserve >> =EF=BF=BD =EF=BF=BD>> the content - in spire of the regio= n saying it >> is present-, >> =EF=BF=BD =EF=BF=BDthe client >> =EF=BF=BD =EF=BF=BD>> should be able to turn around ask t= he *region* >> for the asset, >> =EF=BF=BD =EF=BF=BD(and get >> =EF=BF=BD =EF=BF=BD>> is after all). >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDIf that is not the case, -= and there are >> probably good reasons >> =EF=BF=BD =EF=BF=BDfor the >> =EF=BF=BD =EF=BF=BD>> deployment pattern as described- = =EF=BF=BDshouldn't we >> *warn* clients >> =EF=BF=BD =EF=BF=BDthat the >> =EF=BF=BD =EF=BF=BD>> region might be inconsistent, so th= e users >> behind the client >> =EF=BF=BD =EF=BF=BDcan vote >> =EF=BF=BD =EF=BF=BD>> with their feet, (or take the risk)= ? >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> --Vaughn >> =EF=BF=BD =EF=BF=BD>> ___________________________________= ____________ >> =EF=BF=BD =EF=BF=BD>> vwrap mailing list >> =EF=BF=BD =EF=BF=BD>> vwrap@ietf.org >> > >> >> =EF=BF=BD =EF=BF=BD>> https://www.ietf.org/mailman/listin= fo/vwrap >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> ____________________________________= ___________ >> =EF=BF=BD =EF=BF=BD> vwrap mailing list >> =EF=BF=BD =EF=BF=BD> vwrap@ietf.org >> > >> >> =EF=BF=BD =EF=BF=BD> https://www.ietf.org/mailman/listinf= o/vwrap >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> >> >> >> >> -----------------------------------------------------------------------= - >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> =EF=BF=BD >> >> >> >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > --000e0ce0b726493f1804a007f2c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgcG9pbnRlcnMuIMKgSSBoYXZlIGEgwqBidXN5IHdlZWsgaW4gUkwgaW4g ZnJvbnQgb2YgbWUsIHNvIGkgd29udCBoYXZlIHRvIG11Y2ggdGltZSB0byByZXNwb25kIHRoZSBu ZXh0IGZldyBkYXlzLCBob3dldmVyLCBpIGludGVuZCB0byBzdGFydCBkb2luZyB0aGUgZm9sbG93 aW5nIHRoaW5nczo8ZGl2Pjxicj48L2Rpdj48ZGl2Pi0gUHJvZHVjZSBhIHZpc3VhbCB0aGF0IHJl ZmxlY3RzIG15IHRoaW5raW5nLCBpLmUuIGFuIGlsbHVzdHJhdGlvbiBvZiBteSByZXNwb25zZSB0 byBNb3JnYWluZSYjMzk7cyBpdGVtbGlzdCDCoGFib3ZlLjxicj4KPC9kaXY+PGRpdj48ZGl2Pi0g UmVhZCB1cCBvbiB0aGUgb2xkZXIgbm90ZXMsIGFzIHdlbGwgYXMgwqBtb3JlIHJlYWRpbmcgaW4g dGhlIGxpc3QgYXJjaGl2ZTwvZGl2PjxkaXY+LSBUcnkgdG8gbWFrZSBhIHN1bW1hcnkgZm9yIHRo ZSB3aWtpPC9kaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+PGRpdj5SZWdhcmRpbmcgdGhlIHVzZSBv ZiBkb21haW4sIEkgdGhpbmsgc2VydmljZXMgYXJlIGV2ZW50dWFsbHkgd2hhdCBjb3VudHMsIGJ1 dCBpdHMgYWxsIHRlcm1pbm9sb2d5LiBUaGUgd2F5IEkgcmVhZCB0aGUgQVdHIGRpYWdyYW1zIGlz IHRoYXQgdGhlIGFnZW50IGRvbWFpbiBpcyBhY3R1YWxseSBhIGNsdXN0ZXIgb2YgdGlnaHRseSBp bnRlZ3JhdGVkIHNlcnZpY2VzLiBXaGVuIHRoZSBmdW5jdGlvbmFsaXR5IG9mIGVhY2ggc3ViLXNl cnZpY2UgaXMgZGVzY3JpYmVkIHByb3Blcmx5IGFuZCB3aXRoIHVuaWZvcm0gaW50ZXJmYWNlcyB0 aGUgZG9tYWluIHdpbGwgc2xvd2x5IGRpc3NvbHZlLiBCdXQgbGV0IG5vdCBnZXQgYWhlYWQgb2Yg b3V0IHNlbGZzLiBXZSBzaG91bGQgcHV0IHVwIHNvbWUgY2xlYXIgZGVzY3JpcHRpb25zIG9uIHRo ZSB3aWtpIGZvciBvdXIgdmlld3Mgb24gdGhpcywgYW5kICphZnRlciogdGhhdCB3ZSBjYW4gZGVj aWRlIHdoYXQgd2UgbmVlZCBhbmQgd2hhdCBjYW4gZ28uPC9kaXY+CjxkaXY+PGJyPjwvZGl2Pjxk aXY+SXRzIGJlZW4gYSB2ZXJ5IHVzZWZ1bCBhbmQgaWxsdW1pbmF0aW5nIHdlZWtlbmQgZm9yIG1l LCBhbmQgaSBhbSBhIGxvdCBtb3JlIG9wdGltaXN0aWMgYWJvdXQgdGhlIGZ1dHVyZSBvZiB2d3Jh cCB0aGFuIHR3byB3ZWVrcyBhZ28uPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4tLSBWYXVnaG48 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj4KPGRpdj48YnI+PC9kaXY+PGRpdj48 ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gU3VuLCBBcHIgMywgMjAxMSBhdCA3OjIwIFBNLCBE em9uYXRhcyBTb2wgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86ZHpvbmF0YXNA Z21haWwuY29tIj5kem9uYXRhc0BnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2Jv cmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXg7Ij4KUHJvYmFibHkgZWFz eSBhcyBzdWdnZXN0ZWQgaW4gb3RoZXIgdGVybXMgaGVyZSBvbiB0aGlzIGxpc3QsIGFzIGhvdyB0 aGUgY2xpZW50IGNvbnRhY3RzIHRoZSBhc3NldCBzZXJ2aWNlcyBub3cgaW4gdGhlIHJlZ2lvbnMu IFRoZSBuZXdlciBpc3N1ZSBpcyB0byB1bml0aXplIHRoYXQgYXNzZXQgc2VydmljZXMuIFNpbmNl IHRoZWlyIGlzIHByb3ByaWV0YXJ5IChsZWdhY3kpIGNvZGUgdGhlbiB3ZSBjYW4mIzM5O3QgZXhw ZWN0IHRoYXQgdG8gY2hhbmdlLCBhbmQgc29tZSBmb3JtIG9mIHByb3h5IGlzIG9mIG5lZWQuIFdo YXRldmVyIHdvcmtzIGJlc3QsIEkgdHJpZWQgdG8gbmFycm93IGl0IGRvd24gdG8gc3VnZ2VzdGlv bnMgaGVyZS48YnI+Cgo8YnI+CkV2ZW50dWFsbHksIHRoZSBhZ2VudCBkb21haW4gaXMgaWRlYWwg dG8gaGFuZGxlIHRoZSBkaXJlY3Rpb24gb2YgdGhlIGFzc2V0IHNlcnZpY2VzLiBUaGlzIGNvbmNl cHQsIHVuZm9ydHVuYXRlbHksIGVuZGVkIHN1cHBvcnQgYXdoaWxlIGFnbyB3aXRoIGNoYW5nZXMg aW4gTEwuPGJyPgpBbHNvIHNlZTsgPGEgaHJlZj0iaHR0cDovL3dpa2kuc2Vjb25kbGlmZS5jb20v d2lraS9BZ2VudF9Eb21haW4iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd2lraS5zZWNvbmRsaWZl LmNvbS93aWtpL0FnZW50X0RvbWFpbjwvYT48YnI+CkFuZDogPGEgaHJlZj0iaHR0cDovL3dpa2ku c2Vjb25kbGlmZS5jb20vd2lraS9Vc2VyOkR6b25hdGFzX1NvbC9BV0dfQXNzZXQiIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vd2lraS5zZWNvbmRsaWZlLmNvbS93aWtpL1VzZXI6RHpvbmF0YXNfU29s L0FXR19Bc3NldDwvYT4gKHdhcm46IHVuc3RydWN0dXJlZCBjb2xsYWJvcmF0aXZlIG5vdGVzLCBk dW1wZWQgb24gbWUgYW5kIEkgdHJpZWQgdG8gZml4KTxicj4KCjxicj4KSSB0cmllZCB0byBmaW5k IHByZXZpb3VzIHZpc3VhbHMuPGJyPgo8YnI+CkkmIzM5O2QgaW1hZ2luZSB0aGUgYWdlbnQgZG9t YWluIGNvdWxkIGdyb3cgb3V0IG9mIHVuaXRpemVkIHZlcnNpb25zIG9mIGFzc2V0IHNlcnZpY2Vz LiBEZXNwaXRlIHRoYXQsIEkgdGhpbmsgdGhhdCBjb25jZXB0IGhlbHBzIHZpZXcgd2hlcmUgd2Ug d2VyZSBhdCBpbiBkaXNjdXNzaW9uIGFuZCB3aGF0IGRpZG4mIzM5O3QgaGFwcGVuLjxicj4KPGJy PgpWYXVnaG4gRGVsdWNhIHdyb3RlOjxicj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFk ZGluZy1sZWZ0OjFleCI+PGRpdiBjbGFzcz0iaW0iPgpIae+/vUR6b25hdGFzPGJyPgo8YnI+CkNh biB5b3UgZXhwYW5kIG9uIHRoYXQsIHdoYXQgd291bGQgYmUgbmVlZGVkIGZvciBsZWdhY3kgc3Vw cG9ydCBpbiBWV0FQIHRlcm1z77+9Pyw8YnI+CklmIGkgd2FudCB0byByZWFkIHVwIG9uIGhvdyB0 aGXvv71hc3NldCBzZXJ2ZXIgbWF5IHByb3h5IHRoZSBzaW11bGF0b3IsIHdoYXQgd291bGQgeW91 IHJlY29tbWVuZCBtZSB0byByZWFkPzxicj4KPGJyPgotLSBWYXVnaG48YnI+Cjxicj48L2Rpdj48 ZGl2PjxkaXY+PC9kaXY+PGRpdiBjbGFzcz0iaDUiPgpPbiBTdW4sIEFwciAzLCAyMDExIGF0IDU6 NTEgQU0sIER6b25hdGFzIFNvbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmR6b25hdGFzQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmR6b25hdGFzQGdtYWlsLmNvbTwvYT4gJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86ZHpvbmF0YXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHpvbmF0YXNA Z21haWwuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4KCjxicj4KIMKgIMKgU29tZSBzdGF0ZWQg dGhlIHByb3h5LXRvLWFzc2V0LXNlcnZlciBpcyBidWlsdCBpbnRvIHRoZSBzaW07PGJyPgogwqAg wqBob3dldmVyLCBrZWVwIGluIG1pbmQgcG9zc2libGUgbGVnYWN5IHN1cHBvcnQgd2hlcmUgdGhl IGFzc2V0PGJyPgogwqAgwqBzZXJ2ZXIgbWF5IHByb3h5IHRoZSBzaW11bGF0b3IuPGJyPgo8YnI+ Cjxicj4KIMKgIMKgRHpvbmF0YXMgU29sIHdyb3RlOjxicj4KPGJyPgogwqAgwqAgwqAgwqBTb21l aG93IEkgZmVlbCB0aGUgYmFzaWMgYXNzZXQgc2VydmVyIGJlaW5nIGFibGUgdG8gbG9naW4gYW5k PGJyPgogwqAgwqAgwqAgwqBkb3dubG9hZCBhc3NldHMgaXMgbm93IHByaW9yaXR5LCB5ZXQgSSBh bHNvIHdvbmRlcmVkIHRoZSBiZXN0PGJyPgogwqAgwqAgwqAgwqB3YXkgdG8gcGF0Y2ggdGhpcyBp bnRvIHRoZSBjdXJyZW50IG1vZGUgb2Ygdmlld2Vycy48YnI+Cjxicj4KIMKgIMKgIMKgIMKgTWF5 YmUgb2ZmZXIgKDEpIGJ5IHByb3h5IChzaW0tc2lkZSkgYW5kICgyKSBieSBwYXRjaDxicj4KIMKg IMKgIMKgIMKgKHZpZXdlci1zaWRlKSB0aGF0IGVpdGhlciBvZiB0aGVzZSB0d28gYXJlIG9wdGlv bmFsIGFuZDxicj4KIMKgIMKgIMKgIMKgbmVpdGhlciBhcmUgbWFuZGF0b3J5IGZvciBub3cuIFRo b3VnaHRzPzxicj4KPGJyPgogwqAgwqAgwqAgwqBJc3JhZWwgQWxhbmlzIHdyb3RlOjxicj4KPGJy Pgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCZndDsgd2hlbiBkZXNpZ25pbmcgZm9yIHNjYWxhYmls aXR5LCB0aGUgbW9kZWwgdG8gYmVhciBpbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgbWluZCBpcyAu Li48YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgV2VsbCwgdGhlcmUgYXJlIGEgbG90IG9mIGRp ZmZlcmVudCBtb2RlbHMgdG8ga2VlcCBpbiBtaW5kLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgYW5k IG1hbnkgZGlmZmVyZW50IHVzZSBjYXNlcy4gT25lIHBhcnRpY3VsYXIgdXNlIGNhc2UgdG88YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoGtlZXAgaW4gbWluZCBpczogJnF1b3Q7VXNlciBhY3F1aXJlcyBu ZXcgb3V0Zml0LCBhbmQgd2FudHMgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCYjMzk7c2hvdyBp dCBvZmYmIzM5OyBpbiBhIGhpZ2hseSBwb3B1bGF0ZWQgcmVnaW9uJnF1b3Q7Ljxicj4KPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAmZ3Q7IEJvdGggd29ybGRzIGFuZCBhc3NldCBzZXJ2aWNlcyBtYXkg aW5jbHVkZSBjb21tZXJjaWFsLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgY29tbXVuaXR5LCBhbmQg cGVyc29uYWwgc2VydmljZXM8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgWWVzLCB5ZXMgYW5k IHllcy4gSSYjMzk7bSBwYXJ0aWN1bGFybHkgY29uY2VybmVkIGFib3V0IGhvdyB0aGU8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoG1vZGVsIGFmZmVjdHMgdGhlIGFiaWxpdHkgdG8gaG9zdCBwZXJzb25h bCBhc3NldCBzZXJ2aWNlcy48YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyBhIHByb3h5 aW5nIHJlZ2lvbiwgd2hpY2ggd291bGQgZ2V0IHNsYW1tZWQgZm9yIGV2ZXJ5PGJyPgogwqAgwqAg wqAgwqAgwqAgwqBhc3NldCB3b3JuIGJ5IGV2ZXJ5IGF2YXRhciBwcmVzZW50Ljxicj4KPGJyPgog wqAgwqAgwqAgwqAgwqAgwqBHcmFudGVkIHRoZSBjb2xsZWN0aW9uIG9mIHNlcnZpY2VzIHRoYXQg YXJlIHByb3ZpZGVkIGJ5PGJyPgogwqAgwqAgwqAgwqAgwqAgwqB0aGUgcmVnaW9uIG5lZWQgdG8g YmUgc2NhbGVkIHRvIG1lZXQgdGhlIGRlbWFuZHMgb2YgdGhhdDxicj4KIMKgIMKgIMKgIMKgIMKg IMKgcmVnaW9uLiBUaGF0JiMzOTtzIGFsbCBwYXJ0IG9mIGNhcGFjaXR5IHBsYW5uaW5nLjxicj4K PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7IHJlZ2lvbnMgcnVuIG1hbnkgZGlmZmVyZW50IENQ VS1pbnRlbnNpdmUgdGFza3MsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBpbmNsdWRpbmcgcGh5c2lj cyBzaW11bGF0aW9uIGFuZCBzZXJ2ZXItc2lkZSBzY3JpcHRpbmcsPGJyPgogwqAgwqAgwqAgwqAg wqAgwqBhbmQgYWJzb2x1dGVseSBjYW5ub3QgYWZmb3JkIHRvIHNlcnZlIGFzc2V0cyB0b288YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoFdlbGwuLi4gd2hvIHNhaWQgdGhlIHNhbWUgQ1BVJiMzOTtzIGhh dmUgdG8gZG8gcHJveHlpbmcsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBwaHlzaWNzIHNpbXVsYXRp b24gYW5kIHNlcnZlci1zaWRlIHNjcmlwdGluZz8gQXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oHByb3h5aW5nIGlzIGEgZGlmZmVyZW50IHNlcnZpY2UgdGhhbiBwaHlzaWNzIHNpbXVsYXRpb248 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoGFuZCBjYW4gYmUgb24gc2VwYXJhdGUgaGFyZHdhcmUsIGNv dWxkIG1ha2UgdXNlIG9mPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBnZW9ncmFwaGljYWxseSBkaXN0 cmlidXRlZCBjYWNoaW5nLCBhbmQgaW4gY2VydGFpbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgZGVw bG95bWVudCBwYXR0ZXJucywgdGhlIHNhbWUgY2FjaGluZyBzZXJ2aWNlcyBjb3VsZCBiZTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgc2hhcmVkIGJ5IGRpZmZlcmVudCByZWdpb25zLiAoU2VydmVyLXNp ZGUgc2NyaXB0aW5nIGlzIGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoGRpc2N1c3Npb24gZm9yIGFu b3RoZXIgZGF5KS48YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyBUaGlzIGlzIHdoeSB3 ZSBoYXZlIHRvIGdvIHBhcmFsbGVsLi4uPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoFRvdGFs bHkgYWdyZWUsIGFuZCBhIHByb3h5aW5nIG1vZGVsIGNvdWxkIGFuZCBzaG91bGQgYWxzbzxicj4K IMKgIMKgIMKgIMKgIMKgIMKgdGFrZSBhZHZhbnRhZ2Ugb2YgcGFyYWxsZWxpc20uPGJyPgo8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCZndDsgSSB0aGluayB5b3UmIzM5O3JlIHdyb25nIHRoYXQgaXQg aGFzIHRvIGNvc3QgbXVjaCBtb25leS4gP3ZzPzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyBJ dCBjb3N0cyBtb25leSB0byBob3N0IGEgaGlnaCBwZXJmb3JtYW5jZSBhbmQgc2NhbGFibGU8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoGFzc2V0IHNlcnZpY2UgYW5kIGEgaGlnaCBiYW5kd2lkdGggbmV0 d29yayB0byBoYW5kbGUgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqB0cmFmZmljLiDvv71BICps b3QqIG9mIG1vbmV5Ljxicj4KIMKgIMKgIMKgIMKgIMKgIMKgSSB0aGluayB3aGF0IHlvdSYjMzk7 cmUgc2F5aW5nIGlzOiAmcXVvdDtJdCBjb3N0cyBhIGxvdCBvZiBtb25leSB0bzxicj4KIMKgIMKg IMKgIMKgIMKgIMKgYnVpbGQgYSBzY2FsYWJsZSBhc3NldCBzZXJ2aWNlLCBidXQgaWYgYXNzZXRz IGFyZSBzcHJlYWQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoHRocm91Z2hvdXQgdGhlIGludGVybmV0 IHRoZXkgZG9uJiMzOTt0IGhhdmUgdG8gYmUgc2NhbGFibGUuJnF1b3Q7PGJyPgogwqAgwqAgwqAg wqAgwqAgwqBCdXQgdGhhdCYjMzk7cyBub3QgcXVpdGUgcmlnaHQuIFlvdSYjMzk7cmUgb3Blbmlu ZyB1cCBldmVyeSBhc3NldDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgc2VydmVyIHRvIHRoZSBWVyBl cXVpdmFsZW50IG9mIGJlaW5nIHNsYXNoZG90dGVkLCBzbyBhcmU8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoHlvdSBzdXJlIHlvdSYjMzk7cmUgbm90IGZvcmNpbmcgKmV2ZXJ5KiBhc3NldCBzZXJ2aWNl IHRvIGJlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBzY2FsYWJsZSBhbmQgaGFuZGxlIGEgbG90IG9m IGJhbmR3aXRoIGFuZCBuZXR3b3JrIHRyYWZmaWM/PGJyPgogwqAgwqAgwqAgwqAgwqAgwqBJdCYj Mzk7cyB0aGUgZXhhY3Qgb3Bwb3NpdGUgb2YgeW91ciBpbnRlbnRpb24sIGJ1dCBJIHRoaW5rPGJy PgogwqAgwqAgwqAgwqAgwqAgwqB0aGF0JiMzOTtzIHRoZSByZXN1bHQsIGFsbCB0aGUgc2FtZS48 YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgVGhpcyBwYXJ0aWN1bGFyIGRlc2lnbiBkZWNpc2lv biBoYXMgYSBiaWcgZWZmZWN0IG9uIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgZWNvbm9taWNz IG9mIHRoZSBWVyBpbmZyYXN0cnVjdHVyZS4gSSYjMzk7ZCByYXRoZXIgdGhlPGJyPgogwqAgwqAg wqAgwqAgwqAgwqBlY29ub21pY3MgdG8gd29yayBvdXQgc3VjaCB0aGF0IGEgcmVnaW9uIHByb3Zp ZGVyIHdobzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgd2lzaGVzIHRvIGJ1aWxkIGEgcmVnaW9uIHRo YXQgc3VwcG9ydHMgYSBzbWFsbCBwb3B1bGF0aW9uLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgY2Fu IGRvIHNvIGVjb25vbWljYWxseS4gQSByZWdpb24gdGhhdCB3YW50cyB0byBob3N0IGE8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCpsYXJnZSogcG9wdWxhdGlvbiBoYXMgdG8gYmVhciB0aGF0IGNvc3Qg b2YgcHJvdmlkaW5nIHRoYXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoHNjYWxhYmxlIGFzc2V0IHNl cnZpY2UuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBJIHdhbnQgdGhlIGVjb25vbWljcyBvZiBob3N0 aW5nIGEgc21hbGwgYXNzZXQgc2VydmljZSB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgYmUgYSBu b24taXNzdWUgKGFzIHRvIGJlc3QgcHJvbW90ZSBjcmVhdGlvbiBhbmQ8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoGNyZWF0aXZpdHkpLiBDcmVhdGluZyBhIGhpZ2ggYmFyIHRvIHByb3ZpZGUgYXNzZXQg c2VydmljZXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoHdpbGwgbWVhbiB0aGF0IHNlcnZpY2Ugd2ls bCBjb3N0IG1vbmV5IGFuZCBwZW9wbGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoHNob3VsZG4mIzM5 O3QgaGF2ZSB0byBwYXkgbW9uZXkganVzdCB0byBjcmVhdGUgb3Igb3duIFZXPGJyPgogwqAgwqAg wqAgwqAgwqAgwqBvYmplY3RzIChJJiMzOTttIHVzaW5nICYjMzk7b3duJiMzOTsgaGVyZSB0byBy ZWZlciB0byBtYWludGFpbmluZzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgdGhlaXIgZXhpc3RlbmNl LCBJJiMzOTttIG5vdCB0cnlpbmcgdG8gbWFrZSBhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAmIzM5 O2xlZnRpc3QmIzM5Oy8mIzM5O2NvbW11bmlzdCYjMzk7IHN0YXRlbWVudCBhYm91dCBvd25lcnNo aXAgOyk8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgLSBJenp5PGJyPgo8YnI+Cjxicj4KIMKg IMKgIMKgIMKgIMKgIMKgT24gQXByIDIsIDIwMTEsIGF0IDM6NTggUE0sIE1vcmdhaW5lIHdyb3Rl Ojxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBJenp5LCB3aGVuIGRlc2lnbmluZyBm b3Igc2NhbGFiaWxpdHksIHRoZSBtb2RlbCB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg YmVhciBpbiBtaW5kIGlzIHRoYXQgb2Ygc2Vhc29uZWQgdmlydHVhbCB3b3JsZDxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgdHJhdmVsZXJzIHdob3NlIGludmVudG9yaWVzIGNvbnRhaW4gYXNz ZXRzIGZyb20gbWFueTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZGlmZmVyZW50IHdvcmxk cywgdGhvc2UgYXNzZXRzIGJlaW5nIHNlcnZlZCBieSBtYW55PGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBkaWZmZXJlbnQgYXNzZXQgc2VydmljZXMuIO+/vUJvdGggd29ybGRzIGFuZCBhc3Nl dDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2VydmljZXMgbWF5IGluY2x1ZGUgY29tbWVy Y2lhbCwgY29tbXVuaXR5LCBhbmQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHBlcnNvbmFs IHNlcnZpY2VzLCBhbmQgYXMgdGhlIG1ldGF2ZXJzZSBncm93cywgdGhhdDxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgc2V0IGlzIGhpZ2hseSBsaWtlbHkgdG8gYmVjb21lIHByb2dyZXNzaXZl bHkgbGVzczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgY2x1c3RlcmVkIGFuZCBtb3JlIGRp dmVyc2UuPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFdoZW4gdGhvc2Ugc2Vhc29u ZWQgdHJhdmVsZXJzIGNsaWNrIG9uIGFuIGFkdmVydGlzZWQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoFZXIGxpbmsgYW5kIHBlcmZvcm0gYW4gaW50ZXItd29ybGQgdGVsZXBvcnQgdG8gb25l PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBwYXJ0aWN1bGFyIHdvcmxkJiMzOTtzIHJlZ2lv biB0byBzaGFyZSBhbiBleHBlcmllbmNlLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdGhl aXIgJnF1b3Q7d29ybiZxdW90OyBhc3NldHMgKHRoZSBvbmx5IG9uZXMgb2YgaW50ZXJlc3QgdG8g dGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqByZWdpb24pIHdpbGwgY29udGFpbiByZWZl cmVuY2VzIHRvIGFzc2V0IHNlcnZpY2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzcHJl YWQgd2lkZWx5IGFjcm9zcyB0aGUgSW50ZXJuZXQuIO+/vVRoZSBmZXRjaGVzIGJ5IHRoZTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdHJhdmVsZXJzJiMzOTsgY2xpZW50cyBvY2N1ciBvdmVy IG1hbnkgcGFyYWxsZWwgcGF0aHMgZnJvbTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgY2xp ZW50cyB0byBhc3NldCBzZXJ2aWNlcywgc28gb25lIGNhbiByZWFzb25hYmx5PGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqBleHBlY3QgcmVkdWNlZCBuZXR3b3JrIGNvbnRlbnRpb24gYW5kIHJl ZHVjZWQgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNlcnZlciBsb2FkaW5nIGJl Y2F1c2UgdGhleSBhcmUgYm90aCBzcHJlYWQgb3V0IG92ZXI8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoGhvd2V2ZXIgbWFueSBhc3NldCBzZXJ2aWNlcyBhcmUgYmVpbmcgcmVmZXJlbmNlZCBi eTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdGhlIG92ZXJhbGwgc2V0IG9mIGFzc2V0cyBp biB0aGUgcmVnaW9uLjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBUaGlzIGlzIHZl cnkgZGlmZmVyZW50IHRvIHRoZSBjYXNlIG9mIGEgcHJveHlpbmc8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHJlZ2lvbiwgd2hpY2ggd291bGQgZ2V0IHNsYW1tZWQgZm9yIGV2ZXJ5IGFzc2V0 IHdvcm48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJ5IGV2ZXJ5IGF2YXRhciBwcmVzZW50 LiDvv71JbiBvdXIgY3VycmVudCBhcmNoaXRlY3R1cmUsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqByZWdpb25zIHJ1biBtYW55IGRpZmZlcmVudCBDUFUtaW50ZW5zaXZlIHRhc2tzLDxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaW5jbHVkaW5nIHBoeXNpY3Mgc2ltdWxhdGlvbiBhbmQg c2VydmVyLXNpZGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNjcmlwdGluZywgYW5kIGFi c29sdXRlbHkgY2Fubm90IGFmZm9yZCB0byBzZXJ2ZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgYXNzZXRzIHRvbyB1bmxlc3MgeW91ciBzY2FsYWJpbGl0eSByZXF1aXJlbWVudHMgYXJlPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB2ZXJ5IGxvdyBpbmRlZWQsIGllLiBqdXN0IGEgZmV3 IGRvemVuIGF2YXRhcnMgb2Y8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRvZGF5JiMzOTtz IGtpbmQuIO+/vVdlJiMzOTt2ZSBoaXQgdGhlIGNlaWxpbmcgYWxyZWFkeSBvbiByZWdpb248YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNjYWxhYmlsaXR5IGRvbmUgdGhhdCB3YXkuIO+/vVRo ZXJlIGlzIG5vd2hlcmUgdG8gZ28gaW48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRoYXQg ZGlyZWN0aW9uIGF0IGFsbCBiZXlvbmQgaW1wcm92aW5nIHRoZSBjb2RlIGxpa2U8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoEludGVsIGRlbW9uc3RyYXRlZCwgYW5kIHRoYXQgd29yayBpcyBz dWJqZWN0IHRvIGEgbGF3PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBvZiBkaW1pbmlzaGlu ZyByZXR1cm5zLjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBUaGlzIGlzIHdoeSB3 ZSBoYXZlIHRvIGdvIHBhcmFsbGVsLCBhbmQgSSB0aGluayB5b3UmIzM5O3JlPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqB3cm9uZyB0aGF0IGl0IGhhcyB0byBjb3N0IG11Y2ggbW9uZXkuIO+/ vUFzIHdlIHNwcmVhZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdGhlIGxvYWQgYWNyb3Nz IG1vcmUgYW5kIG1vcmUgYXNzZXQgc2VydmljZXMsIHdlIGFyZTxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgc2ltcGx5IGJldHRlciB1dGlsaXppbmcgYWxsIHRoZSBoYXJkd2FyZSB0aGF0JiMz OTtzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhbHJlYWR5IG91dCB0aGVyZSBvbiB0aGUg SW50ZXJuZXQsIGF0IGxlYXN0IGluIHJlc3BlY3Q8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oG9mIGNvbW11bml0eSBhbmQgcHJpdmF0ZSByZXNvdXJjZXMuIO+/vUJ1dCBhZGQgdG8gdGhlPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBjb21tdW5pdHkgYW5kIHByaXZhdGUgcmVzb3VyY2Vz IHRoZSBjb21tZXJjaWFsIGFzc2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzZXJ2aWNl cyB0aGF0IGFyZSBsaWtlbHkgdG8gYXBwZWFyIHRvIGV4cGxvaXQgdGhpczxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgb3Bwb3J0dW5pdHksIGFuZCBub3Qgb25seSB3aWxsIHRoZSBudW1iZXIg b2YgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNlcnZpY2VzIGxlYXAsIGJ1dCB0 aGUgcG93ZXIgb2YgZWFjaCBvbmUgd2lsbCByb2NrZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHRvbywgYmVjYXVzZSwgYWZ0ZXIgYWxsLCB0aGVzZSBidXNpbmVzc2VzIHdpbGwgYmU8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGhlYXZpbHkgb3B0aW1pemVkIGZvciB0aGUgam9iLjxi cj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBBcyB0byB3aHkgYSB3b3JsZCB3b3VsZCB3 YW50IGNsaWVudHMgdG8gYWNjZXNzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBleHRlcm5h bCBhc3NldCBzZXJ2aWNlcyBpbnN0ZWFkIG9mIHByb3ZpZGluZyBpdHMgb3duPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqBpbXBsZW1lbnRhdGlvbiwgdGhhdCYjMzk7cyBhbiBlYXN5IHF1ZXN0 aW9uLiDvv71JdCBjb3N0czxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbW9uZXkgdG8gaG9z dCBhIGhpZ2ggcGVyZm9ybWFuY2UgYW5kIHNjYWxhYmxlIGFzc2V0PGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBzZXJ2aWNlIGFuZCBhIGhpZ2ggYmFuZHdpZHRoIG5ldHdvcmsgdG8gaGFuZGxl IHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdHJhZmZpYy4g77+9QSAqbG90KiBvZiBt b25leS4g77+9SW4gY29udHJhc3QsIGl0IGNvc3RzIGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHdvcmxkIG5vdGhpbmcgdG8gbGV0IG90aGVycyBzZXJ2ZSB0aGUgYXNzZXRzIHRvPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBjbGllbnRzLiDvv71BbmQgdGhhdCBtYXR0ZXJzIHRvIHRo ZSBib3R0b20gbGluZS48YnI+Cjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBNb3Jn YWluZS48YnI+Cjxicj4KPGJyPgo8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgPT09 PT09PT09PT09PT09PT09PT09PTxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBPbiBT YXQsIEFwciAyLCAyMDExIGF0IDc6MDUgUE0sIEl6enkgQWxhbmlzPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAmbHQ7PGEgaHJlZj0ibWFpbHRvOml6enlhbGFuaXNAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+aXp6eWFsYW5pc0BnbWFpbC5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOml6enlhbGFuaXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+aXp6eWFsYW5pc0Bn bWFpbC5jb208L2E+Jmd0Ozxicj48L2Rpdj48L2Rpdj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86aXp6eWFsYW5pc0BnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5penp5YWxhbmlzQGdtYWlsLmNvbTwvYT48ZGl2PjxkaXY+PC9kaXY+PGRpdiBjbGFz cz0iaDUiPjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86aXp6eWFsYW5pc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5penp5YWxhbmlzQGdt YWlsLmNvbTwvYT4mZ3Q7Jmd0OyZndDsgd3JvdGU6PGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoO+/vSDvv70mZ3Q7IEFzIGFsd2F5cyB0aG91Z2gsIGl0JiMzOTtzIGEgdHJhZGUtb2Zm LCBzaW5jZSB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHByb3hpZWQgZGVzaWduPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9aGFzIHZlcnkgcG9vciBzY2FsYWJpbGl0 eSBjb21wYXJlZCB0byB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGRpc3RyaWJ1dGVk IG9uZS48YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vUkgZG9uJiMzOTt0 IGFncmVlIHdpdGggdGhhdC4uLiBJZiBhIHVzZXIgZW50ZXJzIGE8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoGhpZ2hseSBwb3B1bGF0ZWQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv71yZWdpb24sPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9ZXZlcnkgb3Ro ZXIgY2xpZW50IGlzIGdvaW5nIHRvIChjb3VsZCBhbmQgc2hvdWxkIGJlPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqB0cnlpbmcgdG8pPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9aGl0IHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWFzc2V0IHNlcnZl cihzKSBmb3IgdGhlIGFzc2V0cyB0aGF0IHRoZSB1c2VyIGlzPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqB3ZWFyaW5nIChhc3N1bWluZzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vXRoZXkmIzM5O3JlIG5vdCBjYWNoZWQgbG9jYWxseSkuIO+/vUV2ZXJ5IGFzc2V0IHNlcnZl cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaGFzIHRvIGJlIHNjYWxlZCB1cDxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXRvIHRoZSBwb2ludCB0aGF0IGl0IGNhbiBoYW5k bGUgdGhhdCBsb2FkIGZyb20gYWxsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBvdmVyLi4u PGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71JZiBJJiMzOTttIGhvc3Rp bmcgYSByZWdpb24gdGhhdCBzdXBwb3J0cyAxMHMgb2Y8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHRob3VzYW5kcyBvZjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXNpbXVs dGFuZW91czxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXVzZXJzICh0aGlua2lu ZyBvZiB0aGUgZnV0dXJlKSwgSSBhbHJlYWR5IGhhdmUgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoHNjYWxlIHRvIG1lZXQgdGhhdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vWRlbWFuZC4gSWYgdGhlIHJlZ2lvbiBpcyBwcm94eWluZyB0aGUgYXNzZXRzLCB0aGVuLDxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgeWVzIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vXJlZ2lvbiBoYXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDv v710byBiZSBzY2FsZWQgdG8gbWVldCB0aGF0IGFzc2V0IGRlbWFuZCB0b28sIGJ1dCBpdDxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYWxyZWFkeSBoYXMgdG8gYmU8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv71zY2FsZWQgdG8gbWVldCBvdGhlciBkZW1hbmRzIG9mIGJlaW5n IGEgcmVnaW9uPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzZXJ2ZXIuLi4gYW5kIHdoeSBp czxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXNjYWxpbmcgdGhvc2UgYXNzZXQg cHJveHkgc2VydmljZXMgaGFyZD8g77+9SXQmIzM5O3M8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoGdvaW5nIHRvIGNvc3QgJCw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71i dXQgaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71ub3QgdGVjaG5pY2FsbHkg Y2hhbGxlbmdpbmcuIFNvLCBpZiBJIHdhbnQgdG8gaG9zdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgYSByZWdpb24gbGlrZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXRo YXQuLi4gc3VyZSBpdCB3aWxsIGNvc3QgbWUsIGJ1dCB0aGUgc2ltdWxhdGlvbjxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgd2lsbCBiZSBjb25zaXN0ZW50PGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqDvv70g77+9YW5kIHVzZXJzIHdpbGwgYmUgYWJsZSB0byBwYXJ0aWNpcGF0ZSBlcXVh bGx5LDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcmVnYXJkbGVzcyBvZiB0aGU8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71jYXBhYmlsaXRpZXMgb2YgdGhlaXIgaW5kaXZp ZHVhbCBhc3NldCBzZXJ2aWNlcy48YnI+Cjxicj4KPGJyPgo8YnI+Cjxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vU9uIEZyaSwgQXByIDEsIDIwMTEgYXQgMTE6NTUgUE0sIE1vcmdh aW5lPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmx0OzxhIGhyZWY9Im1haWx0 bzptb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tb3JnYWlu ZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb208L2E+PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAm bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5tb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb208L2E+Jmd0Ozxi cj48L2Rpdj48L2Rpdj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZsdDttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOm1vcmdhaW5lLmRpbm92YUBnb29nbGVtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPm1vcmdhaW5lLmRpbm92YUBnb29nbGVtYWlsLmNvbTwvYT48ZGl2PjxkaXY+PC9kaXY+ PGRpdiBjbGFzcz0iaDUiPjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tPC9hPiZndDsmZ3Q7Jmd0OyB3cm90 ZTo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IEV2ZXJ5IGRlc2lnbiBj aG9pY2UgcmVzdWx0cyBpbiBhIHRyYWRlLW9mZiw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oFZhdWdobiwgaW1wcm92aW5nPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9b25l IHRoaW5nIGF0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyB0aGUgZXhw ZW5zZSBvZiBzb21ldGhpbmcgZWxzZS4g77+9SWYgZXZlcnkgdGltZSB3ZTxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgb2ZmZXJlZCBhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9c2VydmljZSB3ZSBoYWQgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70m Z3Q7IGluZm9ybSBpdHMgdXNlcnMgYWJvdXQgdGhlIGRvd25zaWRlcyBvZiBhbGwgdGhlPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0cmFkZS1vZmZzIHdlPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqDvv70g77+9aGF2ZSBtYWRlLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vSZndDsgdGhleSB3b3VsZCBoYXZlIGFuIGF3ZnVsIGxvdCB0byByZWFkLiA7LSk8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Jmd0OyBUaGUgc3BlY2lmaWMgdHJhZGUtb2ZmIHRoYXQgeW91IGFyZSBkaXNj dXNzaW5nIGlzIG5vPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9ZGlmZmVyZW50 LiDvv71BIHJlZ2lvbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgdGhh dCBwcm94aWVzIGFsbCBjb250ZW50IGhhcyB0aGUgJnF1b3Q7YmVuZWZpdCZxdW90OyBvZjxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYWNxdWlyaW5nIGNvbnRyb2w8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv71mcm9tIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vSZndDsgYXNzZXQgc2VydmVycyBvdmVyIHRoZSBpdGVtcyBpbiB0aGUgcmVnaW9uLCBz bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdGhhdCBpdCBjYW48YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv71lbnN1cmUgdGhhdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKg77+9IO+/vSZndDsgZXZlcnlvbmUgaW4gdGhlIHJlZ2lvbiBub3Qgb25seSBvYnRhaW5zIHRo ZSBpdGVtczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYnV0IG9idGFpbnM8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv710aGUgc2FtZSBpdGVtczxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vSZndDsgYXMgZXZlcnlvbmUgZWxzZS4g77+9VGhhdCBkb2VzIGlu ZGVlZCBwcm92aWRlIGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGdyZWF0ZXIgZ3VhcmFu dGVlIG9mPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBjb25zaXN0ZW5j eSB0aGFuIGEgZGVwbG95bWVudCBpbiB3aGljaCB0aGUgcmVnaW9uPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBvbmx5IHBhc3Nlczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vWFzc2V0IFVSSXMgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGNs aWVudHMgd2hvIHRoZW4gZmV0Y2ggdGhlIGl0ZW1zIGZyb20gYXNzZXQgc2VydmljZXM8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71zZXBhcmF0ZWx5LiDvv71BcyBhbHdheXM8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IHRob3VnaCwgaXQmIzM5O3MgYSB0 cmFkZS1vZmYsIHNpbmNlIHRoZSBwcm94aWVkPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBk ZXNpZ24gaGFzIHZlcnk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71wb29yIHNj YWxhYmlsaXR5PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBjb21wYXJl ZCB0byB0aGUgZGlzdHJpYnV0ZWQgb25lLjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IElmIHdlJiMz OTtyZSBnb2luZyB0byB3YXJuIHVzZXJzIG9mIHRoZSBwb3RlbnRpYWwgZm9yPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqBpbmNvbnNpc3RlbmN5PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqDvv70g77+9aW4gdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBk aXN0cmlidXRlZCBkZXBsb3ltZW50IGFzIHlvdSBzdWdnZXN0LCBhcmUgd2U8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoGFsc28gZ29pbmcgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv713YXJuIHRoZW0gb2Y8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70m Z3Q7IG5vbi1zY2FsYWJpbGl0eSBpbiB0aGUgcHJveGllZCBvbmU/IO+/vUkgcmVhbGx5PGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkb24mIzM5O3Qgc2VlIG11Y2g8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv71tZXJpdCBpbiB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv70mZ3Q7IGlkZWEgb2Ygd2FybmluZyBhYm91dCBkZXNpZ24gY2hvaWNlcy4g77+9 TWFueSBzdWNoPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBjaG9pY2VzIGFyZTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXRlY2huaWNhbCwgYW5kPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyB0aGUgaXNzdWVzIGFyZSBxdWl0ZSBsaWtlbHkgdG8g YmUgb2YgbGl0dGxlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpbnRlcmVzdCB0bzxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vW5vbi10ZWNobmljYWwgdXNlcnM8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGFueXdheS4g77+9SW4gYW55IGNhc2Us IHRoZSBiZXR0ZXIgc2VydmljZXMgYXJlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBsaWtl bHkgdG8gcHJvdmlkZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXN1Y2g8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGluZm9ybWF0aW9uIGluIHRoZWly IG9ubGluZSBkb2N1bWVudGF0aW9uLCBJPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB3b3Vs ZCBndWVzcy48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBZb3UgbWVudGlvbmVkIHVzZXJzICZxdW90 O3ZvdGluZyB3aXRoIHRoZWlyIGZlZXQmcXVvdDsgb3I8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoGNob29zaW5nIHRvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9YWNjZXB0 IHRoZSByaXNrPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBvZiBpbmNv bnNpc3RlbmN5LiDvv71XZWxsIHRoYXQgd2lsbCBoYXBwZW4gYW55d2F5LDxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgd2hlbiBzZXJ2aWNlczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vWZhaWwgYW5kPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyB1 c2VycyBnZXQgYW5ub3llZC4g77+9SWYgc29tZSBhc3NldCBzZXJ2aWNlcyByZWZ1c2U8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRvIHNlbmQgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9cmVxdWVzdGVkPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 Jmd0OyBpdGVtcyB0byBzb21lIHVzZXJzLCB0aG9zZSBzZXJ2aWNlcyB3aWxsIGdldCBhPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBiYWQgcmVwdXRhdGlvbjxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vWFuZCBwZW9wbGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv70mZ3Q7IHdpbGwgY2hvb3NlIGRpZmZlcmVudCBhc3NldCBzZXJ2aWNlcyBpbnN0ZWFkLjxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9TGlrZXdpc2UsIGlmIGE8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv713b3JsZCBzZXJ2aWNlPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqDvv70g77+9Jmd0OyBwcm94aWVzIGV2ZXJ5dGhpbmcgYW5kIHNvIGl0IGNhbiYjMzk7 dCBoYW5kbGUgYSBsYXJnZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbnVtYmVyIG9mPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9YXNzZXRzIG9yIG9mPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBwZW9wbGUsIHVzZXJzIHdpbGwgZ2V0IGFubm95 ZWQgYXQgdGhlIGxhZyBhbmQgd2lsbCBnbzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vWVsc2V3aGVyZS4g77+9VGhpcyB1c2VyPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDv v70g77+9Jmd0OyBldmFsdWF0aW9uIGFuZCAmcXVvdDt2b3Rpbmcgd2l0aCB0aGVpciBmZWV0JnF1 b3Q7IGhhcHBlbnM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGFscmVhZHkgd2l0aDxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vW9ubGluZSBzZXJ2aWNlczxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgYWxsIG92ZXIgdGhlIEludGVybmV0LCBhbmQg SSBhbSBzdXJlIHRoYXQgdGhpczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaHVtYW4gcHJv Y2Vzczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXdpbGwgY29udGludWU8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IHRvIHdvcmsgd2hlbiB0aGUgc2Vy dmljZXMgYXJlIGFzc2V0IGFuZCByZWdpb248YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNl cnZpY2VzLjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IEJhY2sgaW4gU2VwdGVtYmVyIDIwMTAsIEkg d3JvdGUgdGhpcyBwb3N0IHdoaWNoPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBwcm9wb3Nl cyB0aGF0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9d2UgdXNlIGluPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBWV1JBUCBhIGZvcm0gb2YgYXNzZXQg YWRkcmVzc2luZyB0aGF0IHByb3ZpZGVzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBtYXNz aXZlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c2NhbGFiaWxpdHkgYXQgdGhl PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBzYW1lIHRpbWUgYXMgYSB2 ZXJ5IGhpZ2ggZGVncmVlIG9mIHJlc2lsaWVuY2UgLS08YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv708YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vTxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi92d3JhcC9jdXJyZW50L21zZzAwNDYzLmh0bWwiIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdndyYXAvY3VycmVudC9tc2cwMDQ2 My5odG1sPC9hPjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vS4g77+9SXQgaXM8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGJhc2VkIG9uIHRoZSBjb25j ZXB0IG9mIHRoZSBVUkkgY29udGFpbmluZyBhIGhvc3Q8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHBhcnQgYW5kIGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71oYXNoIHBh cnQsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyB3aGVyZSB0aGUgaGFz aCBpcyBnZW5lcmF0ZWQgKG9uY2UsIGF0IHRoZSB0aW1lIG9mPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBzdG9yYWdlIHRvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dGhl IGFzc2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBzZXJ2aWNlKSB1 c2luZyBhIHNwZWNpZmllZCBkaWdlc3QgYWxnb3JpdGhtIG92ZXI8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHRoZSBjb250ZW50IG9mPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9dGhlIGFzc2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBiZWlu ZyByZWZlcmVuY2VkLiDvv71Zb3UgbWF5IHdpc2ggdG8gbm90ZSB0aGF0IGlmPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqB0aGlzIGRlc2lnbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vXdlcmUgdXNlZCwgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 Jmd0OyBmYWlsdXJlIG9mIGFuIGFzc2V0IHNlcnZpY2UgdG8gZGVsaXZlciBhPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqByZXF1ZXN0ZWQgaXRlbSB3b3VsZDxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vXJlc3VsdCBpbiBhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDv v70g77+9Jmd0OyBmYWlsb3ZlciByZXF1ZXN0IGZvciB0aGUgaXRlbSB0byBvbmUgb3IgbW9yZTxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYmFja3VwIHNlcnZpY2VzLDxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKg77+9IO+/vXVzaW5nIHRoZSBzYW1lPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqDvv70g77+9Jmd0OyBoYXNoIHBhcnQgYnV0IHdpdGggYSBkaWZmZXJlbnQgaG9zdCBh ZGRyZXNzLjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IFRoaXMgY2FuIGdvIHNvbWUgd2F5IHRvd2Fy ZHMgb3ZlcmNvbWluZyB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHByb2JsZW0gdGhh dCB5b3U8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv710aGluayBtaWdodDxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgb2NjdXIgd2hlbiBhc3NldHMgYXJl IGZldGNoZWQgYnkgY2xpZW50cyBmcm9tPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhc3Nl dCBzZXJ2aWNlczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWRpcmVjdGx5Ljxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgQWx0aG91Z2ggaXQgd29uJiMz OTt0IGhlbHAgd2hlbiB0aGUgbWlzc2luZyBpdGVtIGlzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqBhdmFpbGFibGUgZnJvbTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vW9u bHkgYSBzaW5nbGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGFzc2V0 IHNlcnZpY2UsIGl0IHdpbGwgaGVscCBpbiBtYW55IG90aGVyIGNhc2VzLDxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgYW5kIGl0IHdpbGw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv71jb21wZW5zYXRlIGZvcjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZn dDsgc2VydmljZSBmYWlsdXJlcyBhbmQgbmV0d29yayBvdXRhZ2VzPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBhdXRvbWF0aWNhbGx5IGF0IHRoZSBzYW1lPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqDvv70g77+9dGltZS48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70m Z3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBQUy4gVGhpcyBkZXNp Z24gZm9yIGhhc2gtYmFzZWQgYXNzZXQgYWRkcmVzc2luZzxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgaXMgYWxyZWFkeTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWJlaW5n IHRlc3RlZCBieTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgTW9qaXRv IFNvcmJldCBpbiBoZXIgZXhwZXJpbWVudGFsIHdvcmxkIGFuZDxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgY2xpZW50LiDvv71JdCB3b3VsZCBnaXZlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Jmd0OyBWV1JBUC1iYXNlZCB3b3JsZHMgYW4gaW1wcm92ZWQgbGV2ZWwgb2Yg c2VydmljZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYXZhaWxhYmlsaXR5LDxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXNvIEkgdGhpbmsgaXQ8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IHNob3VsZCBiZSBhIGNvcmUgZmVhdHVyZSBvZiBvdXIg cHJvdG9jb2wuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0Ozxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv70mZ3Q7IE1vcmdhaW5lLjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7ID09 PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IE9uIEZyaSwg QXByIDEsIDIwMTEgYXQgMTE6MTcgUE0sIFZhdWdobiBEZWx1Y2E8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoO+/vSDvv70mbHQ7PGEgaHJlZj0ibWFpbHRvOnZhdWdobi5kZWx1Y2FAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+dmF1Z2huLmRlbHVjYUBnbWFpbC5jb208L2E+PGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2YXVnaG4uZGVs dWNhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZhdWdobi5kZWx1Y2FAZ21haWwuY29tPC9h PiZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFp bHRvOnZhdWdobi5kZWx1Y2FAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmF1Z2huLmRlbHVj YUBnbWFpbC5jb208L2E+PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxh IGhyZWY9Im1haWx0bzp2YXVnaG4uZGVsdWNhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZh dWdobi5kZWx1Y2FAZ21haWwuY29tPC9hPiZndDsmZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vSZndDsgd3JvdGU6PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDv v70g77+9Jmd0OyZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0 OyBUaGlzIGlzIGEgcXVlc3Rpb24gaSBkaXNjdXNzZWQgd2l0aCBNb3JnYWluZTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgb2ZmLWxpc3QgYSB3aGlsZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vWFnbyAoSTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZn dDsmZ3Q7IGludGVuZGVkIHRvIHNlbmQgaXQgdG8gdGhlIGxpc3QgYnV0IHB1c2hlZCB0aGU8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHdyb25nIGJ1dHRvbi4uLikgSTxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHRoaW5rIHdlIG5lZWQgdG8gYWRkcmVzcyB0 aGlzIHByb2JsZW0sIGFuZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZGVjaWRlIGhvdyB0 byBkZWFsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9d2l0aCBpdC48YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/vUluIERhdmlkcyBkZXBsb3ltZW50IGRyYWZ0LCBz ZWN0aW9uIDcuMy4xLjEgYW48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG92ZXJ2aWV3IGlz PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Z2l2ZW4gdmFuPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgd2F5cyB0byBkZWxpdmVyIGNvbnRlbnQg dG8gdGhlIHJlZ2lvbi4gT25lIHdheTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaXMgb25s eSBwYXNzaW5nIGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBj YXBhYmlsaXR5IHRoYXQgYWxsb3dzIGFjY2VzcyB0byAocGFydCBvZikgdGhlPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqByZXNvdXJjZTo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv70mZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7 IO+/vSDvv70g77+9IO+/vSDvv70gNy4zLjEuMS4g77+9Q29udGVudCBkZWxpdmVyeSBtb2RlbHM8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/vSDv v70g77+9IEEgcmFuZ2Ugb2YgcG9zc2libGUgcmVwcmVzZW5hdGlvbnMgY2FuPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqBiZSBwYXNzZWQgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv71hIHJlZ2lvbiBmb3I8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70m Z3Q7Jmd0OyDvv70g77+9IO+/vSDvv70g77+9IHNpbXVsYXRpb24uIFsuLi5dIFRoZSBvdGhlciBl bmQgb2YgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkZWxpdmVyeSBzcGVjdHJ1bTxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IGludm9sdmVzIHBhc3Np bmc8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/ vSDvv70g77+9IG9ubHkgYSBVUkkgb3IgY2FwYWJpbGl0eSB1c2VkIHRvPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqBhY2Nlc3MgdGhlIHJlbmRlcmluZzxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vSZndDsmZ3Q7IGluZm9ybWF0aW9uIGFuZCBhPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsg77+9IO+/vSDvv70g77+9IO+/vSBjb2xsaXNpb24g bWVzaCxhbmQgcmVsYXRlZCBkYXRhIGZvcjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcGh5 c2ljYWwgc2ltdWxhdGlvbi48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7 Jmd0OyDvv70g77+9IO+/vSDvv70g77+9IEluIHN1Y2ggYSBtb2RlbCwgdGhlIGNsaWVudCBpczxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcmVzcG9uc2libGUgZm9yPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqDvv70g77+9ZmV0Y2hpbmcgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Jmd0OyZndDsgYWRkaXRpb25hbDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKg77+9IO+/vSZndDsmZ3Q7IO+/vSDvv70g77+9IO+/vSDvv70gaW5mb3JtYXRpb24gbmVlZGVk IHRvIHJlbmRlciB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGl0ZW0mIzM5O3Mgdmlz dWFsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9cHJlc2VuY2UgZnJvbSBhPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgc2VwYXJhdGU8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/vSDvv70g77+9 IHNlcnZpY2UuIO+/vVRoaXMgZmV0Y2ggY2FuIGJlIGRvbmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCp1bmRlciB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71jcmVk ZW50aWFscyBvZiB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0 OyBlbmQgdXNlcio8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDv v70g77+9IO+/vSDvv70g77+9IHZpZXdpbmcgdGhlIG1hdGVyaWFsIFtteSBlbXBoYXNpcy0tVkRd PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAsIGFuZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vWRpdm9yY2VzIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vSZndDsmZ3Q7IHNpbXVsYXRpb24gZnJvbTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vSZndDsmZ3Q7IO+/vSDvv70g77+9IO+/vSDvv70gdGhlIHRydXN0IGNoYWluIG5lZWRl ZCB0byBtYW5hZ2U8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNvbnRlbnQuIO+/vUFueTxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWF1dG9tYXRpb248YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBpcyBkb25lIG9uIGE8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/vSDvv70g77+9IHNlcGFy YXRlIGhvc3Qgd2hpY2ggdGhlIGNvbnRlbnQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNy ZWF0b3Igb3Igb3duZXIgdHJ1c3RzLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vSZndDsmZ3Q7IGludGVyYWN0aW5nIHdpdGggdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqDvv70g77+9Jmd0OyZndDsg77+9IO+/vSDvv70g77+9IO+/vSBvYmplY3QgdGhyb3VnaCByZW1v dGVkIGludGVyZmFjZXMuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZn dDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv71JIGNhbiBz ZWUgdGhlIG5lZWQgZm9yIHN1Y2ggYSBzZXR1cCwgaG93ZXZlciwgaTxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgZmVlbCB3ZSBhcmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDv v70mZ3Q7Jmd0OyB1bnBsZWFzYW50bHkgY2xvc2UgdG8gYSBzaXR1YXRpb24gd2VyZSB0aGU8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNvaGVyZW5jZSBvZiB0aGU8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv71zaW11bGF0aW9uPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqDvv70g77+9Jmd0OyZndDsgZmFsbHMgYXBhcnQuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqDvv70g77+9Jmd0OyZndDsgSW4gdGhpcyBkZXBsb3ltZW50IHBhdHRlcm4gdGhlIHJlZ2lvbiBh ZHZlcnRpc2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGUgcHJlc2VuY2U8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71vZiB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBhc3NldCwgYW5kICpzb21lKiBjbGllbnRzIHdpbGwgYmUg YWJsZSB0byBnZXQgaXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGFzIGV4cGVjdGVkLDxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXdoaWxlPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgLWJhc2VkIG9uIHRoZSBhcmJpdHJhcnkgd2hpbXMg b2YgdGhlIGFzc2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzZXJ2aWNlLSBvdGhlcnM8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71taWdodCBub3QuPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv70mZ3Q7Jmd0OyBNeSBob3BlIHdvdWxkIGJlIHRoYXQgYWZ0ZXIgdGhlIGFzc2V0 IHNlcnZlcjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcHJvdmlkZXMgdGhlPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9cmVnaW9uIHdpdGg8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyB0aGUgY2FwYWJpbGl0eSB0byBnZXQgdGhlIGFzc2V0 LCBpdCBnaXZlcyB1cDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgY29udHJvbC4gVGhhdDxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXdvdWxkIG1lYW48YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyB0aGF0IGlmIHRoZSBjbGllbnQgZmluZHMg dGhlIGludmVudG9yeSBzZXJ2ZXIgaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHVud2ls bGluZyB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXNlcnZlPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgdGhlIGNvbnRlbnQgLSBpbiBzcGly ZSBvZiB0aGUgcmVnaW9uIHNheWluZyBpdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaXMg cHJlc2VudC0sPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dGhlIGNsaWVudDxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHNob3VsZCBiZSBhYmxl IHRvIHR1cm4gYXJvdW5kIGFzayB0aGUgKnJlZ2lvbio8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoGZvciB0aGUgYXNzZXQsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9KGFu ZCBnZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBpcyBhZnRl ciBhbGwpLjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7PGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsg77+9SWYgdGhhdCBpcyBub3Qg dGhlIGNhc2UsIC1hbmQgdGhlcmUgYXJlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBwcm9i YWJseSBnb29kIHJlYXNvbnM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71mb3Ig dGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgZGVwbG95bWVu dCBwYXR0ZXJuIGFzIGRlc2NyaWJlZC0g77+9c2hvdWxkbiYjMzk7dCB3ZTxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgKndhcm4qIGNsaWVudHM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv710aGF0IHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsm Z3Q7IHJlZ2lvbiBtaWdodCBiZSBpbmNvbnNpc3RlbnQsIHNvIHRoZSB1c2Vyczxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgYmVoaW5kIHRoZSBjbGllbnQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoO+/vSDvv71jYW4gdm90ZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vSZndDsmZ3Q7IHdpdGggdGhlaXIgZmVldCwgKG9yIHRha2UgdGhlIHJpc2spPzxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Jmd0OyZndDsgLS1WYXVnaG48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv70mZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHZ3cmFw IG1haWxpbmcgbGlzdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7 IDxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGll dGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiZndDs8YnI+PC9kaXY+PC9kaXY+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8 L2E+Jmd0OyZndDs8ZGl2IGNsYXNzPSJpbSI+PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDv v70g77+9Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby92d3JhcCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdndyYXA8L2E+PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0 Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyB2 d3JhcCBtYWlsaW5nIGxpc3Q8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7 IDxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGll dGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiZndDs8YnI+PC9kaXY+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFp bHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+Jmd0 OyZndDs8ZGl2IGNsYXNzPSJpbSI+PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Z3cmFw IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92 d3JhcDwvYT48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0Ozxicj4KPGJyPgo8YnI+Cjxicj4KIMKgIMKg IMKgIMKgIMKgIMKgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgogwqAgwqAg wqAgwqAgwqAgwqB2d3JhcCBtYWlsaW5nIGxpc3Q8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoDxhIGhy ZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3Jn PC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoDxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdndyYXAiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Z3cmFwPC9hPjxi cj48L2Rpdj48ZGl2IGNsYXNzPSJpbSI+CiDCoCDCoCDCoCDCoCDCoCDCoO+/vTxicj4KPGJyPgo8 YnI+Cjxicj4KPGJyPgo8YnI+CiDCoCDCoC0tIMKgIMKgIC0tLSA8YSBocmVmPSJodHRwczovL3R3 aXR0ZXIuY29tL0R6b25hdGFzX1NvbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdHdpdHRlci5j b20vRHpvbmF0YXNfU29sPC9hPiAtLS08YnI+CiDCoCDCoFdlYiBEZXZlbG9wbWVudCwgU29mdHdh cmUgRW5naW5lZXJpbmcsIFZpcnR1YWwgUmVhbGl0eSwgQ29uc3VsdGFudDxicj4KPGJyPgogwqAg wqBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KIMKg IMKgdndyYXAgbWFpbGluZyBsaXN0PGJyPjwvZGl2PjxkaXYgY2xhc3M9ImltIj4KIMKgIMKgPGEg aHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5v cmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4KIMKgIMKgPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92d3JhcCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdndyYXA8L2E+PGJyPgo8YnI+Cjxi cj4KPC9kaXY+PC9ibG9ja3F1b3RlPgo8YnI+PGRpdj48ZGl2PjwvZGl2PjxkaXYgY2xhc3M9Img1 Ij4KPGJyPgotLSA8YnI+Ci0tLSA8YSBocmVmPSJodHRwczovL3R3aXR0ZXIuY29tL0R6b25hdGFz X1NvbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdHdpdHRlci5jb20vRHpvbmF0YXNfU29sPC9h PiAtLS08YnI+CldlYiBEZXZlbG9wbWVudCwgU29mdHdhcmUgRW5naW5lZXJpbmcsIFZpcnR1YWwg UmVhbGl0eSwgQ29uc3VsdGFudDxicj4KPGJyPgo8L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9k aXY+PGJyPjwvZGl2Pgo= --000e0ce0b726493f1804a007f2c5-- From dzonatas@gmail.com Sun Apr 3 11:46:37 2011 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 4100B28C0F8 for ; Sun, 3 Apr 2011 11:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.225 X-Spam-Level: X-Spam-Status: No, score=-3.225 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] 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 h-9VeCdxySjU for ; Sun, 3 Apr 2011 11:46:34 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 323F628C0F7 for ; Sun, 3 Apr 2011 11:46:34 -0700 (PDT) Received: by iye19 with SMTP id 19so6171034iye.31 for ; Sun, 03 Apr 2011 11:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xxyfff6mVDoJRohwXp3LeKFqUCA0xI+9OvfxvBr90AY=; b=qp6gsNYBZ3wchkjN8cM7Nbde2S0AL5fCOWPharyGvl6zXRlJ8xyrRXuDBe694ENDbT 3Rq1ySjF8F32ATV64OSAuzp2246XBZWPDgGHTuHF7YMSKL7UJ6heVZbAG2k3fbITnJ1L qBLX06t69mmFurSsQL3c/otVEXBfPfldWM1TI= 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=f+w7wVI4ZnOHVg/2QTZS2AYu1B8OAxUwOb8NQCgVRnoV3vu3FOCpkXJRdLeiwCjagm 2LP5LxEqUfZJ1X/uIYmYx4H/9r+fouhBH5jDRyTzcFMLE57ybTFLb4Zpd4yKaxbw3t7L wSNgXpJt2pEsUg2+n146ZiHTTNZ7yklw1MSEw= Received: by 10.42.229.133 with SMTP id ji5mr3806859icb.311.1301856495932; Sun, 03 Apr 2011 11:48:15 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id jv9sm2914126icb.1.2011.04.03.11.48.13 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Apr 2011 11:48:15 -0700 (PDT) Message-ID: <4D98C11D.5050208@gmail.com> Date: Sun, 03 Apr 2011 11:49:01 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> <4D98B07E.8090601@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 03 Apr 2011 18:46:37 -0000 Visual people don't do well with "figure-of-speech" and such semantics. Those that prefer such semantics usually don't either don't recognize this or treat visual people as in need of accessibilities. We are not dumb. It doesn't get "you" their... it gets "us" there if you acknowledge these differences in people. Don't rely on such semantics, as to visual people that is just nonsense (being not useful). To visual people, every word carries its complete meanings and no less. To those that prefer "figure-of-speech" (auditory and kinetic types) they imply less that means nothing to visual people. Also, do note that your message below seems to mock visual people as "hindrance to further progress". =( I hope you reconsider your approach, Morgaine. Not often do people want to categorize accessibilities and such issues. Morgaine wrote: > We have no "figure-of-speech services" in VWRAP. Our services are > running processes, they have network endpoints, and they talk a > network protocol. > > Concepts can be very useful, and I regularly draw fluffy clouds that > represent the concept behind something concrete. > > Where concepts are not useful is when they denote something that > doesn't actually exist, like say phlogiston, God, or Agent Domain, > because this just makes them a hindrance to further progress. > Humanity suffers from this a lot. > > Philosophy aside, we want our Agent Service to be totally concrete, > with a network API and well defined semantics. The domain concept > does not get us there. > > > Morgaine. > > > > > ================== > > On Sun, Apr 3, 2011 at 6:38 PM, Dzonatas Sol > wrote: > > I prefer the visualization of "domains" because those fluffy > clouds really help those that don't do well with figure-of-speech > "services." > > > Morgaine wrote: > > "Agent Domain" more or less ceased to exist in practice when > David pointed out very eloquently that the emperor had no > clothes. (Same for "Region Domain".) > > I think we mostly talk about the Agent Service and Region > Service these days. The "domain" was just a fluffy cloud that > someone once drew on a whiteboard, but which never actually > existed. > > > Morgaine. > > > > > ==================== > > On Sun, Apr 3, 2011 at 6:20 PM, Dzonatas Sol > > >> wrote: > > Probably easy as suggested in other terms here on this list, as > how the client contacts the asset services now in the > regions. The > newer issue is to unitize that asset services. Since their is > proprietary (legacy) code then we can't expect that to > change, and > some form of proxy is of need. Whatever works best, I tried to > narrow it down to suggestions here. > > Eventually, the agent domain is ideal to handle the > direction of > the asset services. This concept, unfortunately, ended support > awhile ago with changes in LL. > Also see; http://wiki.secondlife.com/wiki/Agent_Domain > And: > http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset > (warn: unstructured collaborative notes, dumped on me and I > tried > to fix) > > I tried to find previous visuals. > > I'd imagine the agent domain could grow out of unitized > versions > of asset services. Despite that, I think that concept helps > view > where we were at in discussion and what didn't happen. > > Vaughn Deluca wrote: > > Hi�Dzonatas > > Can you expand on that, what would be needed for legacy > support in VWAP terms�?, > If i want to read up on how the�asset server may proxy the > simulator, what would you recommend me to read? > > -- Vaughn > > On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol > > > > > >>> wrote: > > Some stated the proxy-to-asset-server is built into > the sim; > however, keep in mind possible legacy support where > the asset > server may proxy the simulator. > > > Dzonatas Sol wrote: > > Somehow I feel the basic asset server being able to > login and > download assets is now priority, yet I also wondered > the best > way to patch this into the current mode of viewers. > > Maybe offer (1) by proxy (sim-side) and (2) by patch > (viewer-side) that either of these two are > optional and > neither are mandatory for now. Thoughts? > > Israel Alanis wrote: > > > > when designing for scalability, the model > to bear in > mind is ... > > Well, there are a lot of different models to > keep > in mind, > and many different use cases. One particular use > case to > keep in mind is: "User acquires new outfit, and > wants to > 'show it off' in a highly populated region". > > > Both worlds and asset services may include > commercial, > community, and personal services > > Yes, yes and yes. I'm particularly concerned > about > how the > model affects the ability to host personal asset > services. > > > a proxying region, which would get slammed > for every > asset worn by every avatar present. > > Granted the collection of services that are > provided by > the region need to be scaled to meet the > demands of > that > region. That's all part of capacity planning. > > > regions run many different CPU-intensive > tasks, > including physics simulation and server-side > scripting, > and absolutely cannot afford to serve assets too > Well... who said the same CPU's have to do > proxying, > physics simulation and server-side > scripting? Asset > proxying is a different service than physics > simulation > and can be on separate hardware, could make > use of > geographically distributed caching, and in > certain > deployment patterns, the same caching > services could be > shared by different regions. (Server-side > scripting > is a > discussion for another day). > > > This is why we have to go parallel... > > Totally agree, and a proxying model could and > should also > take advantage of parallelism. > > > I think you're wrong that it has to cost much > money. ?vs? > > It costs money to host a high performance and > scalable > asset service and a high bandwidth network to > handle the > traffic. �A *lot* of money. > I think what you're saying is: "It costs a > lot of > money to > build a scalable asset service, but if > assets are > spread > throughout the internet they don't have to be > scalable." > But that's not quite right. You're opening > up every > asset > server to the VW equivalent of being > slashdotted, > so are > you sure you're not forcing *every* asset > service to be > scalable and handle a lot of bandwith and > network > traffic? > It's the exact opposite of your intention, > but I think > that's the result, all the same. > > This particular design decision has a big > effect on the > economics of the VW infrastructure. I'd > rather the > economics to work out such that a region > provider who > wishes to build a region that supports a small > population, > can do so economically. A region that wants > to host a > *large* population has to bear that cost of > providing that > scalable asset service. > I want the economics of hosting a small asset > service to > be a non-issue (as to best promote creation and > creativity). Creating a high bar to provide > asset > services > will mean that service will cost money and > people > shouldn't have to pay money just to create > or own VW > objects (I'm using 'own' here to refer to > maintaining > their existence, I'm not trying to make a > 'leftist'/'communist' statement about > ownership ;) > > - Izzy > > > On Apr 2, 2011, at 3:58 PM, Morgaine wrote: > > Izzy, when designing for scalability, > the model to > bear in mind is that of seasoned virtual > world > travelers whose inventories contain > assets from > many > different worlds, those assets being > served by many > different asset services. �Both worlds > and asset > services may include commercial, > community, and > personal services, and as the metaverse > grows, that > set is highly likely to become > progressively less > clustered and more diverse. > > When those seasoned travelers click on an > advertised > VW link and perform an inter-world > teleport to one > particular world's region to share an > experience, > their "worn" assets (the only ones of > interest > to the > region) will contain references to asset > services > spread widely across the Internet. �The > fetches > by the > travelers' clients occur over many parallel > paths from > clients to asset services, so one can > reasonably > expect reduced network contention and > reduced asset > server loading because they are both > spread out > over > however many asset services are being > referenced by > the overall set of assets in the region. > > This is very different to the case of a > proxying > region, which would get slammed for > every asset > worn > by every avatar present. �In our current > architecture, > regions run many different CPU-intensive > tasks, > including physics simulation and server-side > scripting, and absolutely cannot afford > to serve > assets too unless your scalability > requirements are > very low indeed, ie. just a few dozen > avatars of > today's kind. �We've hit the ceiling > already on > region > scalability done that way. �There is > nowhere to > go in > that direction at all beyond improving > the code > like > Intel demonstrated, and that work is > subject to > a law > of diminishing returns. > > This is why we have to go parallel, and > I think > you're > wrong that it has to cost much money. > �As we spread > the load across more and more asset > services, > we are > simply better utilizing all the hardware > that's > already out there on the Internet, at > least in > respect > of community and private resources. �But > add to the > community and private resources the > commercial > asset > services that are likely to appear to > exploit this > opportunity, and not only will the > number of asset > services leap, but the power of each one > will > rocket > too, because, after all, these > businesses will be > heavily optimized for the job. > > As to why a world would want clients to > access > external asset services instead of providing > its own > implementation, that's an easy question. > �It costs > money to host a high performance and > scalable asset > service and a high bandwidth network to > handle the > traffic. �A *lot* of money. �In contrast, it > costs a > world nothing to let others serve the > assets to > clients. �And that matters to the bottom > line. > > > Morgaine. > > > > > ====================== > > On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis > > > > >> > > > > > > >>>> wrote: > > � �> As always though, it's a trade-off, > since the > proxied design > � �has very poor scalability compared to the > distributed one. > > � �I don't agree with that... If a user > enters a > highly populated > � �region, > � �every other client is going to (could and > should be > trying to) > � �hit the > � �asset server(s) for the assets that > the user is > wearing (assuming > � �they're not cached locally). �Every > asset server > has to be scaled up > � �to the point that it can handle that load > from all > over... > > � �If I'm hosting a region that supports > 10s of > thousands of > � �simultaneous > � �users (thinking of the future), I already > have to > scale to meet that > � �demand. If the region is proxying the > assets, then, > yes the > � �region has > � �to be scaled to meet that asset > demand too, > but it > already has to be > � �scaled to meet other demands of being > a region > server... and why is > � �scaling those asset proxy services > hard? �It's > going to cost $, > � �but is > � �not technically challenging. So, if I > want > to host > a region like > � �that... sure it will cost me, but the > simulation > will be consistent > � �and users will be able to participate > equally, > regardless of the > � �capabilities of their individual > asset services. > > > > > � �On Fri, Apr 1, 2011 at 11:55 PM, Morgaine > � � > > > > >> > � > � > > > > > > >>>> wrote: > � �> Every design choice results in a > trade-off, > Vaughn, improving > � �one thing at > � �> the expense of something else. �If > every > time we > offered a > � �service we had to > � �> inform its users about the downsides of > all the > trade-offs we > � �have made, > � �> they would have an awful lot to > read. ;-) > � �> > � �> The specific trade-off that you are > discussing is no > � �different. �A region > � �> that proxies all content has the > "benefit" of > acquiring control > � �from the > � �> asset servers over the items in the > region, so > that it can > � �ensure that > � �> everyone in the region not only obtains > the items > but obtains > � �the same items > � �> as everyone else. �That does indeed > provide a > greater guarantee of > � �> consistency than a deployment in > which the > region > only passes > � �asset URIs to > � �> clients who then fetch the items from > asset services > � �separately. �As always > � �> though, it's a trade-off, since the > proxied > design has very > � �poor scalability > � �> compared to the distributed one. > � �> > � �> If we're going to warn users of the > potential for > inconsistency > � �in the > � �> distributed deployment as you > suggest, are we > also going to > � �warn them of > � �> non-scalability in the proxied one? > �I really > don't see much > � �merit in the > � �> idea of warning about design choices. > �Many such > choices are > � �technical, and > � �> the issues are quite likely to be > of little > interest to > � �non-technical users > � �> anyway. �In any case, the better > services are > likely to provide > � �such > � �> information in their online > documentation, I > would guess. > � �> > � �> You mentioned users "voting with their > feet" or > choosing to > � �accept the risk > � �> of inconsistency. �Well that will > happen > anyway, > when services > � �fail and > � �> users get annoyed. �If some asset > services > refuse > to send the > � �requested > � �> items to some users, those services > will get a > bad reputation > � �and people > � �> will choose different asset > services instead. > �Likewise, if a > � �world service > � �> proxies everything and so it can't > handle > a large > number of > � �assets or of > � �> people, users will get annoyed at > the lag > and will go > � �elsewhere. �This user > � �> evaluation and "voting with their feet" > happens > already with > � �online services > � �> all over the Internet, and I am > sure that this > human process > � �will continue > � �> to work when the services are asset > and region > services. > � �> > � �> Back in September 2010, I wrote > this post > which > proposes that > � �we use in > � �> VWRAP a form of asset addressing > that provides > massive > � �scalability at the > � �> same time as a very high degree of > resilience -- > � �> > � > > �http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html > � �. �It is > � �> based on the concept of the URI > containing > a host > part and a > � �hash part, > � �> where the hash is generated (once, > at the > time of > storage to > � �the asset > � �> service) using a specified digest > algorithm over > the content of > � �the asset > � �> being referenced. �You may wish to note > that if > this design > � �were used, the > � �> failure of an asset service to > deliver a > requested item would > � �result in a > � �> failover request for the item to > one or more > backup services, > � �using the same > � �> hash part but with a different host > address. > � �> > � �> This can go some way towards > overcoming the > problem that you > � �think might > � �> occur when assets are fetched by > clients from > asset services > � �directly. > � �> Although it won't help when the missing > item is > available from > � �only a single > � �> asset service, it will help in many > other > cases, > and it will > � �compensate for > � �> service failures and network outages > automatically at the same > � �time. > � �> > � �> PS. This design for hash-based asset > addressing > is already > � �being tested by > � �> Mojito Sorbet in her experimental > world and > client. �It would give > � �> VWRAP-based worlds an improved level of > service > availability, > � �so I think it > � �> should be a core feature of our > protocol. > � �> > � �> > � �> Morgaine. > � �> > � �> > � �> > � �> > � �> =========================== > � �> > � �> On Fri, Apr 1, 2011 at 11:17 PM, > Vaughn Deluca > � � > > > > >> > > > > > >>>> > � �> wrote: > � �>> > � �>> This is a question i discussed > with Morgaine > off-list a while > � �ago (I > � �>> intended to send it to the list but > pushed the > wrong button...) I > � �>> think we need to address this > problem, and > decide how to deal > � �with it. > � �>> > � �>> �In Davids deployment draft, section > 7.3.1.1 an > overview is > � �given van > � �>> ways to deliver content to the region. > One way > is only passing a > � �>> capability that allows access to (part > of) the > resource: > � �>> > � �>> � � � � � 7.3.1.1. �Content > delivery models > � �>> � � � � � A range of possible > represenations can > be passed to > � �a region for > � �>> � � � � � simulation. [...] The > other end > of the > delivery spectrum > � �>> involves passing > � �>> � � � � � only a URI or capability > used to > access the rendering > � �>> information and a > � �>> � � � � � collision mesh,and > related data for > physical simulation. > � �>> � � � � � In such a model, the > client is > responsible for > � �fetching the > � �>> additional > � �>> � � � � � information needed to > render the > item's visual > � �presence from a > � �>> separate > � �>> � � � � � service. �This fetch can > be done > *under the > � �credentials of the > � �>> end user* > � �>> � � � � � viewing the material [my > emphasis--VD] > , and > � �divorces the > � �>> simulation from > � �>> � � � � � the trust chain needed > to manage > content. �Any > � �automation > � �>> is done on a > � �>> � � � � � separate host which the > content > creator or owner trusts, > � �>> interacting with the > � �>> � � � � � object through remoted > interfaces. > � �>> > � �>> �I can see the need for such a setup, > however, i > feel we are > � �>> unpleasantly close to a situation > were the > coherence of the > � �simulation > � �>> falls apart. > � �>> In this deployment pattern the region > advertises > the presence > � �of the > � �>> asset, and *some* clients will be > able to > get it > as expected, > � �while > � �>> -based on the arbitrary whims of > the asset > service- others > � �might not. > � �>> > � �>> My hope would be that after the > asset server > provides the > � �region with > � �>> the capability to get the asset, > it gives up > control. That > � �would mean > � �>> that if the client finds the inventory > server is > unwilling to > � �serve > � �>> the content - in spire of the region > saying it > is present-, > � �the client > � �>> should be able to turn around ask the > *region* > for the asset, > � �(and get > � �>> is after all). > � �>> > � �>> �If that is not the case, -and > there are > probably good reasons > � �for the > � �>> deployment pattern as described- > �shouldn't we > *warn* clients > � �that the > � �>> region might be inconsistent, so > the users > behind the client > � �can vote > � �>> with their feet, (or take the risk)? > � �>> > � �>> --Vaughn > � �>> > _______________________________________________ > � �>> vwrap mailing list > � �>> vwrap@ietf.org > > > > >> > > > > >>> > > � �>> > https://www.ietf.org/mailman/listinfo/vwrap > � �> > � �> > � �> > _______________________________________________ > � �> vwrap mailing list > � �> vwrap@ietf.org > > > > >> > > > > >>> > > � �> > https://www.ietf.org/mailman/listinfo/vwrap > � �> > � �> > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > > >> > https://www.ietf.org/mailman/listinfo/vwrap > � > > > > > > -- --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, > Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > > >> > https://www.ietf.org/mailman/listinfo/vwrap > > > > > -- --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, > Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > https://www.ietf.org/mailman/listinfo/vwrap > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Sun Apr 3 12:05:50 2011 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 890113A6873 for ; Sun, 3 Apr 2011 12:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] 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 G3IYNeyXY1He for ; Sun, 3 Apr 2011 12:05:47 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 513623A67F3 for ; Sun, 3 Apr 2011 12:05:47 -0700 (PDT) Received: by iwn39 with SMTP id 39so5997718iwn.31 for ; Sun, 03 Apr 2011 12:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=upPrM4CClvC9UaA7xsKJ2aGu2kcJla+pZ9PCTSAgoiQ=; b=Ri6XNw/Q8BP7j1nZk2YDlvnz62FSqThpR/SNYfqYdij+b6W6uh0NCMK7gV8ePNePLV oSrzSf5k5HM33+RYsulEIdueBxA1lUX4v/CqACnXDL++ONj8Smc19R0dydHQbyvhTFa2 gM53oDu9jelR8r9WE3AbG3u5hn56NpmdXNTfU= 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=fe79tqZchQXrgaAawjFYG8hbJnU4Zv3hx4E9aYXTSUwX+rK5BkBuixUWZMuH0IUiEz lgqYXXBp/YDDpH9YpGX+wsc5jj53KhXtNIuBDWU3LcU13wpCn+MJSjJLY4m6+i5C1y7I q6sWNMWDpDx8NI37Bdl/pmeYnLuMoB6q19Q0M= Received: by 10.231.195.95 with SMTP id eb31mr6175875ibb.160.1301857649096; Sun, 03 Apr 2011 12:07:29 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id o3sm3163523ibd.44.2011.04.03.12.07.26 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Apr 2011 12:07:27 -0700 (PDT) Message-ID: <4D98C59D.9060806@gmail.com> Date: Sun, 03 Apr 2011 12:08:13 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> <4D98B07E.8090601@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 03 Apr 2011 19:05:50 -0000 Also, most "figure-of-speech" is conceptual in the way it narrows meanings of words that make sense to auditory people and the semantics they prefer. Visual people prefer complete ideas rather than such conceptual sentients. This is why visual people tend to write with less words and more meanings while auditory people tend to write full length figure of speech and less meaning. It means more to auditory people. Not to get off track here, I did take college classes on that, which corrected my English teachers (despite their philosophy, ugh!) Their ploy to "correct programmer English" backfired with 100% technically correct English and no figure-of-speech written papers. They hated it. I've relaxed since then, and I hope you do, too. Morgaine wrote: > We have no "figure-of-speech services" in VWRAP. Our services are > running processes, they have network endpoints, and they talk a > network protocol. > > Concepts can be very useful, and I regularly draw fluffy clouds that > represent the concept behind something concrete. > > Where concepts are not useful is when they denote something that > doesn't actually exist, like say phlogiston, God, or Agent Domain, > because this just makes them a hindrance to further progress. > Humanity suffers from this a lot. > > Philosophy aside, we want our Agent Service to be totally concrete, > with a network API and well defined semantics. The domain concept > does not get us there. > > > Morgaine. > > > > > ================== > > On Sun, Apr 3, 2011 at 6:38 PM, Dzonatas Sol > wrote: > > I prefer the visualization of "domains" because those fluffy > clouds really help those that don't do well with figure-of-speech > "services." > > > Morgaine wrote: > > "Agent Domain" more or less ceased to exist in practice when > David pointed out very eloquently that the emperor had no > clothes. (Same for "Region Domain".) > > I think we mostly talk about the Agent Service and Region > Service these days. The "domain" was just a fluffy cloud that > someone once drew on a whiteboard, but which never actually > existed. > > > Morgaine. > > > > > ==================== > > On Sun, Apr 3, 2011 at 6:20 PM, Dzonatas Sol > > >> wrote: > > Probably easy as suggested in other terms here on this list, as > how the client contacts the asset services now in the > regions. The > newer issue is to unitize that asset services. Since their is > proprietary (legacy) code then we can't expect that to > change, and > some form of proxy is of need. Whatever works best, I tried to > narrow it down to suggestions here. > > Eventually, the agent domain is ideal to handle the > direction of > the asset services. This concept, unfortunately, ended support > awhile ago with changes in LL. > Also see; http://wiki.secondlife.com/wiki/Agent_Domain > And: > http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset > (warn: unstructured collaborative notes, dumped on me and I > tried > to fix) > > I tried to find previous visuals. > > I'd imagine the agent domain could grow out of unitized > versions > of asset services. Despite that, I think that concept helps > view > where we were at in discussion and what didn't happen. > > Vaughn Deluca wrote: > > Hi�Dzonatas > > Can you expand on that, what would be needed for legacy > support in VWAP terms�?, > If i want to read up on how the�asset server may proxy the > simulator, what would you recommend me to read? > > -- Vaughn > > On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol > > > > > >>> wrote: > > Some stated the proxy-to-asset-server is built into > the sim; > however, keep in mind possible legacy support where > the asset > server may proxy the simulator. > > > Dzonatas Sol wrote: > > Somehow I feel the basic asset server being able to > login and > download assets is now priority, yet I also wondered > the best > way to patch this into the current mode of viewers. > > Maybe offer (1) by proxy (sim-side) and (2) by patch > (viewer-side) that either of these two are > optional and > neither are mandatory for now. Thoughts? > > Israel Alanis wrote: > > > > when designing for scalability, the model > to bear in > mind is ... > > Well, there are a lot of different models to > keep > in mind, > and many different use cases. One particular use > case to > keep in mind is: "User acquires new outfit, and > wants to > 'show it off' in a highly populated region". > > > Both worlds and asset services may include > commercial, > community, and personal services > > Yes, yes and yes. I'm particularly concerned > about > how the > model affects the ability to host personal asset > services. > > > a proxying region, which would get slammed > for every > asset worn by every avatar present. > > Granted the collection of services that are > provided by > the region need to be scaled to meet the > demands of > that > region. That's all part of capacity planning. > > > regions run many different CPU-intensive > tasks, > including physics simulation and server-side > scripting, > and absolutely cannot afford to serve assets too > Well... who said the same CPU's have to do > proxying, > physics simulation and server-side > scripting? Asset > proxying is a different service than physics > simulation > and can be on separate hardware, could make > use of > geographically distributed caching, and in > certain > deployment patterns, the same caching > services could be > shared by different regions. (Server-side > scripting > is a > discussion for another day). > > > This is why we have to go parallel... > > Totally agree, and a proxying model could and > should also > take advantage of parallelism. > > > I think you're wrong that it has to cost much > money. ?vs? > > It costs money to host a high performance and > scalable > asset service and a high bandwidth network to > handle the > traffic. �A *lot* of money. > I think what you're saying is: "It costs a > lot of > money to > build a scalable asset service, but if > assets are > spread > throughout the internet they don't have to be > scalable." > But that's not quite right. You're opening > up every > asset > server to the VW equivalent of being > slashdotted, > so are > you sure you're not forcing *every* asset > service to be > scalable and handle a lot of bandwith and > network > traffic? > It's the exact opposite of your intention, > but I think > that's the result, all the same. > > This particular design decision has a big > effect on the > economics of the VW infrastructure. I'd > rather the > economics to work out such that a region > provider who > wishes to build a region that supports a small > population, > can do so economically. A region that wants > to host a > *large* population has to bear that cost of > providing that > scalable asset service. > I want the economics of hosting a small asset > service to > be a non-issue (as to best promote creation and > creativity). Creating a high bar to provide > asset > services > will mean that service will cost money and > people > shouldn't have to pay money just to create > or own VW > objects (I'm using 'own' here to refer to > maintaining > their existence, I'm not trying to make a > 'leftist'/'communist' statement about > ownership ;) > > - Izzy > > > On Apr 2, 2011, at 3:58 PM, Morgaine wrote: > > Izzy, when designing for scalability, > the model to > bear in mind is that of seasoned virtual > world > travelers whose inventories contain > assets from > many > different worlds, those assets being > served by many > different asset services. �Both worlds > and asset > services may include commercial, > community, and > personal services, and as the metaverse > grows, that > set is highly likely to become > progressively less > clustered and more diverse. > > When those seasoned travelers click on an > advertised > VW link and perform an inter-world > teleport to one > particular world's region to share an > experience, > their "worn" assets (the only ones of > interest > to the > region) will contain references to asset > services > spread widely across the Internet. �The > fetches > by the > travelers' clients occur over many parallel > paths from > clients to asset services, so one can > reasonably > expect reduced network contention and > reduced asset > server loading because they are both > spread out > over > however many asset services are being > referenced by > the overall set of assets in the region. > > This is very different to the case of a > proxying > region, which would get slammed for > every asset > worn > by every avatar present. �In our current > architecture, > regions run many different CPU-intensive > tasks, > including physics simulation and server-side > scripting, and absolutely cannot afford > to serve > assets too unless your scalability > requirements are > very low indeed, ie. just a few dozen > avatars of > today's kind. �We've hit the ceiling > already on > region > scalability done that way. �There is > nowhere to > go in > that direction at all beyond improving > the code > like > Intel demonstrated, and that work is > subject to > a law > of diminishing returns. > > This is why we have to go parallel, and > I think > you're > wrong that it has to cost much money. > �As we spread > the load across more and more asset > services, > we are > simply better utilizing all the hardware > that's > already out there on the Internet, at > least in > respect > of community and private resources. �But > add to the > community and private resources the > commercial > asset > services that are likely to appear to > exploit this > opportunity, and not only will the > number of asset > services leap, but the power of each one > will > rocket > too, because, after all, these > businesses will be > heavily optimized for the job. > > As to why a world would want clients to > access > external asset services instead of providing > its own > implementation, that's an easy question. > �It costs > money to host a high performance and > scalable asset > service and a high bandwidth network to > handle the > traffic. �A *lot* of money. �In contrast, it > costs a > world nothing to let others serve the > assets to > clients. �And that matters to the bottom > line. > > > Morgaine. > > > > > ====================== > > On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis > > > > >> > > > > > > >>>> wrote: > > � �> As always though, it's a trade-off, > since the > proxied design > � �has very poor scalability compared to the > distributed one. > > � �I don't agree with that... If a user > enters a > highly populated > � �region, > � �every other client is going to (could and > should be > trying to) > � �hit the > � �asset server(s) for the assets that > the user is > wearing (assuming > � �they're not cached locally). �Every > asset server > has to be scaled up > � �to the point that it can handle that load > from all > over... > > � �If I'm hosting a region that supports > 10s of > thousands of > � �simultaneous > � �users (thinking of the future), I already > have to > scale to meet that > � �demand. If the region is proxying the > assets, then, > yes the > � �region has > � �to be scaled to meet that asset > demand too, > but it > already has to be > � �scaled to meet other demands of being > a region > server... and why is > � �scaling those asset proxy services > hard? �It's > going to cost $, > � �but is > � �not technically challenging. So, if I > want > to host > a region like > � �that... sure it will cost me, but the > simulation > will be consistent > � �and users will be able to participate > equally, > regardless of the > � �capabilities of their individual > asset services. > > > > > � �On Fri, Apr 1, 2011 at 11:55 PM, Morgaine > � � > > > > >> > � > � > > > > > > >>>> wrote: > � �> Every design choice results in a > trade-off, > Vaughn, improving > � �one thing at > � �> the expense of something else. �If > every > time we > offered a > � �service we had to > � �> inform its users about the downsides of > all the > trade-offs we > � �have made, > � �> they would have an awful lot to > read. ;-) > � �> > � �> The specific trade-off that you are > discussing is no > � �different. �A region > � �> that proxies all content has the > "benefit" of > acquiring control > � �from the > � �> asset servers over the items in the > region, so > that it can > � �ensure that > � �> everyone in the region not only obtains > the items > but obtains > � �the same items > � �> as everyone else. �That does indeed > provide a > greater guarantee of > � �> consistency than a deployment in > which the > region > only passes > � �asset URIs to > � �> clients who then fetch the items from > asset services > � �separately. �As always > � �> though, it's a trade-off, since the > proxied > design has very > � �poor scalability > � �> compared to the distributed one. > � �> > � �> If we're going to warn users of the > potential for > inconsistency > � �in the > � �> distributed deployment as you > suggest, are we > also going to > � �warn them of > � �> non-scalability in the proxied one? > �I really > don't see much > � �merit in the > � �> idea of warning about design choices. > �Many such > choices are > � �technical, and > � �> the issues are quite likely to be > of little > interest to > � �non-technical users > � �> anyway. �In any case, the better > services are > likely to provide > � �such > � �> information in their online > documentation, I > would guess. > � �> > � �> You mentioned users "voting with their > feet" or > choosing to > � �accept the risk > � �> of inconsistency. �Well that will > happen > anyway, > when services > � �fail and > � �> users get annoyed. �If some asset > services > refuse > to send the > � �requested > � �> items to some users, those services > will get a > bad reputation > � �and people > � �> will choose different asset > services instead. > �Likewise, if a > � �world service > � �> proxies everything and so it can't > handle > a large > number of > � �assets or of > � �> people, users will get annoyed at > the lag > and will go > � �elsewhere. �This user > � �> evaluation and "voting with their feet" > happens > already with > � �online services > � �> all over the Internet, and I am > sure that this > human process > � �will continue > � �> to work when the services are asset > and region > services. > � �> > � �> Back in September 2010, I wrote > this post > which > proposes that > � �we use in > � �> VWRAP a form of asset addressing > that provides > massive > � �scalability at the > � �> same time as a very high degree of > resilience -- > � �> > � > > �http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html > � �. �It is > � �> based on the concept of the URI > containing > a host > part and a > � �hash part, > � �> where the hash is generated (once, > at the > time of > storage to > � �the asset > � �> service) using a specified digest > algorithm over > the content of > � �the asset > � �> being referenced. �You may wish to note > that if > this design > � �were used, the > � �> failure of an asset service to > deliver a > requested item would > � �result in a > � �> failover request for the item to > one or more > backup services, > � �using the same > � �> hash part but with a different host > address. > � �> > � �> This can go some way towards > overcoming the > problem that you > � �think might > � �> occur when assets are fetched by > clients from > asset services > � �directly. > � �> Although it won't help when the missing > item is > available from > � �only a single > � �> asset service, it will help in many > other > cases, > and it will > � �compensate for > � �> service failures and network outages > automatically at the same > � �time. > � �> > � �> PS. This design for hash-based asset > addressing > is already > � �being tested by > � �> Mojito Sorbet in her experimental > world and > client. �It would give > � �> VWRAP-based worlds an improved level of > service > availability, > � �so I think it > � �> should be a core feature of our > protocol. > � �> > � �> > � �> Morgaine. > � �> > � �> > � �> > � �> > � �> =========================== > � �> > � �> On Fri, Apr 1, 2011 at 11:17 PM, > Vaughn Deluca > � � > > > > >> > > > > > >>>> > � �> wrote: > � �>> > � �>> This is a question i discussed > with Morgaine > off-list a while > � �ago (I > � �>> intended to send it to the list but > pushed the > wrong button...) I > � �>> think we need to address this > problem, and > decide how to deal > � �with it. > � �>> > � �>> �In Davids deployment draft, section > 7.3.1.1 an > overview is > � �given van > � �>> ways to deliver content to the region. > One way > is only passing a > � �>> capability that allows access to (part > of) the > resource: > � �>> > � �>> � � � � � 7.3.1.1. �Content > delivery models > � �>> � � � � � A range of possible > represenations can > be passed to > � �a region for > � �>> � � � � � simulation. [...] The > other end > of the > delivery spectrum > � �>> involves passing > � �>> � � � � � only a URI or capability > used to > access the rendering > � �>> information and a > � �>> � � � � � collision mesh,and > related data for > physical simulation. > � �>> � � � � � In such a model, the > client is > responsible for > � �fetching the > � �>> additional > � �>> � � � � � information needed to > render the > item's visual > � �presence from a > � �>> separate > � �>> � � � � � service. �This fetch can > be done > *under the > � �credentials of the > � �>> end user* > � �>> � � � � � viewing the material [my > emphasis--VD] > , and > � �divorces the > � �>> simulation from > � �>> � � � � � the trust chain needed > to manage > content. �Any > � �automation > � �>> is done on a > � �>> � � � � � separate host which the > content > creator or owner trusts, > � �>> interacting with the > � �>> � � � � � object through remoted > interfaces. > � �>> > � �>> �I can see the need for such a setup, > however, i > feel we are > � �>> unpleasantly close to a situation > were the > coherence of the > � �simulation > � �>> falls apart. > � �>> In this deployment pattern the region > advertises > the presence > � �of the > � �>> asset, and *some* clients will be > able to > get it > as expected, > � �while > � �>> -based on the arbitrary whims of > the asset > service- others > � �might not. > � �>> > � �>> My hope would be that after the > asset server > provides the > � �region with > � �>> the capability to get the asset, > it gives up > control. That > � �would mean > � �>> that if the client finds the inventory > server is > unwilling to > � �serve > � �>> the content - in spire of the region > saying it > is present-, > � �the client > � �>> should be able to turn around ask the > *region* > for the asset, > � �(and get > � �>> is after all). > � �>> > � �>> �If that is not the case, -and > there are > probably good reasons > � �for the > � �>> deployment pattern as described- > �shouldn't we > *warn* clients > � �that the > � �>> region might be inconsistent, so > the users > behind the client > � �can vote > � �>> with their feet, (or take the risk)? > � �>> > � �>> --Vaughn > � �>> > _______________________________________________ > � �>> vwrap mailing list > � �>> vwrap@ietf.org > > > > >> > > > > >>> > > � �>> > https://www.ietf.org/mailman/listinfo/vwrap > � �> > � �> > � �> > _______________________________________________ > � �> vwrap mailing list > � �> vwrap@ietf.org > > > > >> > > > > >>> > > � �> > https://www.ietf.org/mailman/listinfo/vwrap > � �> > � �> > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > > >> > https://www.ietf.org/mailman/listinfo/vwrap > � > > > > > > -- --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, > Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > > >> > https://www.ietf.org/mailman/listinfo/vwrap > > > > > -- --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, > Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > https://www.ietf.org/mailman/listinfo/vwrap > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From ohmeadhbh@gmail.com Sun Apr 3 12:35:01 2011 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 303EA28C0F3 for ; Sun, 3 Apr 2011 12:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4m8gNs-FWNF for ; Sun, 3 Apr 2011 12:34:58 -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 60D353A679F for ; Sun, 3 Apr 2011 12:34:58 -0700 (PDT) Received: by pvh1 with SMTP id 1so441354pvh.31 for ; Sun, 03 Apr 2011 12:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=M5YpgDUvoASBzwrMxXQCTnWd37uEtZ+3MYI8AL61xQ4=; b=QhBLNiGSiGrsGv69NYjP+GDGif8b6Bn0BAN9kGEYMh0N2SqaQk6YtLfP4lAnwLCnAl 8ptNTHfN+iMtQicUJ05f6pTbSnRjCKZltO0pkiPZhWjUL+KTDXQmuaWd/cX3WYg3dFlR CyTLsxXsCbd0lycVrKIZ4fOpuH/fn3kTl7XvY= 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=BCeHzZ6yLhb6KQG9IuGSvSGoE1W6cxWG9Yb3e0N2YNf6DyZTXmszbNL4RF/sI3/o/W 25xGsjCLb5GoZCiofm1WR9lo8dTCT5CQ/dulfbvmbKr/A0DZqdaRY0d9AZj3hx/DNd7l GsMc8fGhywDg/wow7Ac3BqKMxsrv2t9U8epLM= Received: by 10.142.180.6 with SMTP id c6mr5445644wff.433.1301859400101; Sun, 03 Apr 2011 12:36:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.60.164 with HTTP; Sun, 3 Apr 2011 12:36:20 -0700 (PDT) In-Reply-To: <20110402194853.20da8238@hikaru.localdomain> References: <20110402.101259.14412.0@webmail09.vgs.untd.com> <20110402171923.13176462@hikaru.localdomain> <20110402194853.20da8238@hikaru.localdomain> From: Meadhbh Hamrick Date: Sun, 3 Apr 2011 12:36:20 -0700 Message-ID: To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Simulation consistency 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: Sun, 03 Apr 2011 19:35:01 -0000 there is no way for a protocol to enforce the processing behavior on either end of a connection unless you want to mandate the use of MAC or DRM. the reason you "trust" someone is that you can't complete a transaction without trusting them. in the original VWRAP model, we assumed assets were bits of data and meta-data that could be securely moved around. "license" was just another bit of meta-data, as was "distribution." the protocol didn't require you to add either of these fields. neither did the protocol require you to honor them. that's because there's no way a protocol can REQUIRE a consumer of information do anything with that info. instead, we provided a mechanism to communicate structured information and described the processing expectations. but ultimately, if a "bad actor" that wants to steal digital content participates in a protocol transaction, it won't matter that the protocol will say "honor permissions metadata." there is nothing magical about protocols that require adherence to specified processing expectations. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Sat, Apr 2, 2011 at 10:48 AM, Carlo Wood wrote: > On Sat, 2 Apr 2011 10:01:43 -0700 > Meadhbh Hamrick wrote: > > This is not exactly what I was refering too :p > What I meant is that it should be possible to tag > a creation as "GPL-ed" or "Common Creations" etc, > and that the result is that that thing stays that > way. That it is not possible to accidently break > such free licenses by making it 'no mod' because > someone forgot to check a box. > > Although this seems to be a client-side issue, > and thus something internally to grid (and thus > not related to VWRAP), it DOES mean that such > information has to be supported at all levels: > the fact that something IS explicitely allowed > to be copied etc, has to be stored in asset > servers and be transported to others who obtain > a copy if it. > > If everyone is willing to work as hard on guaranteeing > support for such free product as on the use case > for proprietary products, then I'm willing to think > hard of ways to support the latter. > >> yes. there is something missing in the protocol. it's trust. you don't >> put "trust" in a protocol, you put "security" in a protocol. at the >> end of the day, the people using this protocol will need to decide >> whom they trust. this is why there was a security model and the >> ability of the protocol to "securely carry trust." >> >> the idea is that the protocol would carry cryptographically >> unforgeable attestations of an endpoint's identity. this identity >> would then be evaluated by protocol participants to see if it is >> "trusted." >> >> there's no place in the protocol that says "you must trust a specific >> entity," but rather a mechanism deployers can use to carry the >> identity of people wishing to be trusted. >> >> at the end of the day, an asset service should only barf up assets to >> trusted simulation services. simulators SHOULD only allow people on >> the grid they trust (for some definition of the word "trust.") >> >> if you're a company like Linden that needs to respond to DMCA takedown >> requests, you're likely to require the client trust knob turned up a >> bit. if you're an enterprise, you're going to want that trust knob >> turned all the way up. if you're the pirate bay, you're going to >> intentionally want that trust knob turned all the way down. >> >> as protocol developers, it's our duty to create a protocol that meets >> everyone's use cases. so... i mean... feel free to try to define a >> protocol that mandates the use of DRM or blesses a particular trust >> point, but the likelihood of it being widely supported is.. >> approximately nil. >> >> my recommendation has always been... "define mechanism, not policy." >> >> -cheers >> -meadhbh >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> On Sat, Apr 2, 2011 at 8:19 AM, Carlo Wood wrote: >> > On Sat, 2 Apr 2011 14:12:59 GMT >> > "dyerbrookme@juno.com" wrote: >> > >> >> BTW, the Red Zone statistics of 9 million =A0scans with only 78,000 >> >> rogue viewers captured lets us know that this =A0problem is >> >> exaggerated -- and usually by engineers who claim there is no >> >> =A0technical solution. >> > >> > Just for the record, from a hacker/engineer: there is no technical >> > solution. It is possible to copy everything (and without being >> > detected by a "Red Zone" which can only detect rogue viewers that >> > were released to the public and explicitly make a point of being >> > detectable in the first place (call that bragging: no fun in >> > releasing a "k3wl" viewer if others (or even the coder himself) >> > can't see that it is being used.) So, there is a psychological >> > advantage for the detectors, but not really a technical one. >> > >> > Lets concentrate on textures for the moment to explain this. >> > >> > In order to see an object, or clothing, with the appropriate >> > textures, those textures have to be downloadable for the viewer. >> > There is nothing you can do about that short of running the whole >> > viewer server-side and providing a video. But even in that case it >> > would technically be possible to rip the textures: they are still >> > visible (ie, you could make a screenshot of the surface of a wall). >> > I don't consider the video-broadcast to even be remotely >> > interesting, certainly not from the viewpoint of VWRAP so lets >> > forget that for the moment and just accept that it is possible for >> > anyone to store whatever they SEE to their harddisk. >> > >> > Secondly, if the first creator could upload this texture then so can >> > the ripper. And don't tell me software exists that can detect if >> > an uploaded texture "looks like" one of the already existing billion >> > textures that were uploaded before. If the texture is converted >> > twice, ie from jpeg2000 to jpg to tga and then uploaded, then you'd >> > need a human to look at the original and the newly uploaded texture >> > at the same time to judge that it is MAYBE a copy - which then can >> > only be proved in court if the original creator can prove that his >> > original textures are 100% his own and not, for example, downloaded >> > from the internet somewhere (because in that case the other >> > uploader could have used the same source). >> > >> > A real problem, currently in SL, is imho the complete lack of >> > support for FREE things. The amount of restriction (for people with >> > honest viewers) is tremendous: if you're not an expert or do not pay >> > attention for a second, then your creation is not truely free >> > anymore. Everything defaults to very copyleft unfriendly settings. >> > I'm trying to get my friends, who are very willing in that regard, >> > to only create full permission stuff, but it's simply near >> > impossible to keep something full permission and often we're stuck >> > with something nobody else can change or edit because the creator >> > forgot to set the bit of the contents of an object after changing >> > the group etc blah blah... >> > >> > For example, last a good friend of me wanted my help with making a >> > large amount of changes on his sim: hunderds of objects had to be >> > adjusted... He was willing to: >> > 1) Add me to any group necessary. >> > 2) Give me his build rights >> > 3) Transfer any object to me (temporary ownership transfer) >> > 4) Make any adjustments to the objects and the objects contents >> > =A0 needed to allow me to access what I needed to access. >> > etc etc >> > >> > The end result: He had to do it all by himself. It was impossible to >> > give me enough access to help him (for those who don't believe that, >> > one of things involved changing the "anyone can move" bit of an >> > object in the contents of objects: it is not possible to take >> > anything out of the contents (ie copy it to your inventory) when >> > it's no transfer, and therefore you can't edit it, even though it's >> > modify and you get all the rights that the owner can give you). >> > >> > Sorry, but that is unacceptable; and it CLEARLY shows that >> > something is missing from the protocol. >> > >> > Now the above example doesn't show that a free object is not >> > supported, it only make clear that non-free objects can be very >> > annoying even in situations where the owner has all the rights to >> > do what he wants to do. There are many other such examples. Hence, >> > it shows that it is very annoying that an object is non-free by >> > default at so many levels that you need an IQ of over 140 to create >> > one and those permissions erode quickly to non-free. Even the so >> > called "freebies" are non-free by the way: they are almost always >> > no transfer. Hell, even the default shape that you can when you >> > create a new account is no transfer, what kind of insanity is that?! >> > >> > I think you might find a lot of people, like myself, a lot more >> > willing to help out with thinking of ways on how to protect >> > property in virtual worlds when first it is assured that those who >> > want to create things that are FREE are equally supported as the >> > commercial guys out there. >> > >> > -- >> > Carlo Wood >> > _______________________________________________ >> > vwrap mailing list >> > vwrap@ietf.org >> > https://www.ietf.org/mailman/listinfo/vwrap >> > > > > > -- > Carlo Wood > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From morgaine.dinova@googlemail.com Sun Apr 3 12:41:12 2011 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 5283A3A6824 for ; Sun, 3 Apr 2011 12:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] 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 sy7U9haz6goe for ; Sun, 3 Apr 2011 12:41:07 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 69D043A67D7 for ; Sun, 3 Apr 2011 12:41:06 -0700 (PDT) Received: by qyk29 with SMTP id 29so600436qyk.10 for ; Sun, 03 Apr 2011 12:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=WkLfmgWY8ww3oPNk3jsHZON3KLUIc2zTdIDJq5ZRKuE=; b=aW5JlFaPuo0B5Hi3Blfsh2agPnBPwMpkBi6AMeojn+C0NZ5vu4iwrhLLztA+tugUzc A53GQ30jkkcaKmohO9OzRA7YgpZnUyBq6ykY4kXipr8OCMMr0QMmeu8iQ1L0Pb/ccAXD faTSewJfAS0ugsztmuJ1r1RU3vnPQwHmhowMU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=dtQqp15Zo3KxbG1rhRqtvNNc0ZPGRLthbm8K16Zyd7x17jjda5WpF3lk5lWfx6Tb9H gjpUXPWRX7Fh7UlviNWOrnW7UQ8VA3DOruR8Ws7KueZkI1q5mFo/JURVLZW8cv0+x85P DHMMMyqfOQ+v2Z2dOFxBmWxm4T0f1QvVn9C+s= MIME-Version: 1.0 Received: by 10.229.124.145 with SMTP id u17mr5184474qcr.71.1301859767896; Sun, 03 Apr 2011 12:42:47 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sun, 3 Apr 2011 12:42:47 -0700 (PDT) In-Reply-To: <4D98C11D.5050208@gmail.com> References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> <4D98B07E.8090601@gmail.com> <4D98C11D.5050208@gmail.com> Date: Sun, 3 Apr 2011 20:42:47 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd25cae034e9204a008d947 Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 03 Apr 2011 19:41:12 -0000 --000e0cd25cae034e9204a008d947 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm afraid you misunderstand the issue, Dzonatas. I'll add a bit of background. This has nothing to do with visual versus graphical presentation. I'm a bi= g fan of both, and like yourself I think spatially most of the time about architectures, which is a graphic form. Likewise, it has nothing to do wit= h accessibility whatsoever, of which I've been a very enthusiastic proponent in Second Life for many years. The only thing with which the "domain" argument is concerned is whether the concept reflects something useful in VWRAP that we can observe, query, interact with, or design a protocol around. The answer is "No" on all thes= e counts for "Agent Domain" in VWRAP, because it refers to a concept in OGP that denied interop, and it does not apply to us. As a result, far from helping anyone to understand the VWRAP architecture, all it does is increase the amount of confusion surrounding VWRAP, because it does not reflect anything useful about what we are trying to implement. The nearest we get in VWRAP to something that might have been conceived originally as the "Agent Domain" in OGP is roughly "The set of places and items and resources that this world will permit an agent to visit or interact with ", which is approximately the same thing as saying "the close= d walled garden". It is a singularly counter-productive concept for a group that has the important goal of achieving interop between worlds. So no, it's not helpful, either visually or otherwise. The term is just another obstacle on the road to VW interop. That OGP whiteboard never had other fluffy clouds on it labeled "Virtual world B", "Virtual world C", and so on. The concept of interop between worlds was denied, because Agent Domain controlled access to Region Domains, and so nothing outside AD+RD existed in OGP. But we are not designing OGP, we are designing VWRAP, a set of protocols that embraces interoperation between worlds as well. That is why the Agent Domain does not exist as a useful concept in this work. It elevates world closure, negates interoperation, and does not even admit other worlds into the picture, because Agent Domain is defined to exclude them. It's a very bad idea, both in text and as fluffy clouds. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Sun, Apr 3, 2011 at 7:49 PM, Dzonatas Sol wrote: > Visual people don't do well with "figure-of-speech" and such semantics. > Those that prefer such semantics usually don't either don't recognize thi= s > or treat visual people as in need of accessibilities. We are not dumb. It > doesn't get "you" their... it gets "us" there if you acknowledge these > differences in people. Don't rely on such semantics, as to visual people > that is just nonsense (being not useful). To visual people, every word > carries its complete meanings and no less. To those that prefer > "figure-of-speech" (auditory and kinetic types) they imply less that mean= s > nothing to visual people. > > Also, do note that your message below seems to mock visual people as > "hindrance to further progress". =3D( > > I hope you reconsider your approach, Morgaine. Not often do people want t= o > categorize accessibilities and such issues. > > Morgaine wrote: > >> We have no "figure-of-speech services" in VWRAP. Our services are runni= ng >> processes, they have network endpoints, and they talk a network protocol= . >> >> Concepts can be very useful, and I regularly draw fluffy clouds that >> represent the concept behind something concrete. >> >> Where concepts are not useful is when they denote something that doesn't >> actually exist, like say phlogiston, God, or Agent Domain, because this = just >> makes them a hindrance to further progress. Humanity suffers from this = a >> lot. >> >> Philosophy aside, we want our Agent Service to be totally concrete, with= a >> network API and well defined semantics. The domain concept does not get= us >> there. >> >> >> Morgaine. >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> On Sun, Apr 3, 2011 at 6:38 PM, Dzonatas Sol > dzonatas@gmail.com>> wrote: >> >> I prefer the visualization of "domains" because those fluffy >> clouds really help those that don't do well with figure-of-speech >> "services." >> >> >> Morgaine wrote: >> >> "Agent Domain" more or less ceased to exist in practice when >> David pointed out very eloquently that the emperor had no >> clothes. (Same for "Region Domain".) >> >> I think we mostly talk about the Agent Service and Region >> Service these days. The "domain" was just a fluffy cloud that >> someone once drew on a whiteboard, but which never actually >> existed. >> >> >> Morgaine. >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> On Sun, Apr 3, 2011 at 6:20 PM, Dzonatas Sol >> >> >> wrote: >> >> Probably easy as suggested in other terms here on this list, a= s >> how the client contacts the asset services now in the >> regions. The >> newer issue is to unitize that asset services. Since their is >> proprietary (legacy) code then we can't expect that to >> change, and >> some form of proxy is of need. Whatever works best, I tried to >> narrow it down to suggestions here. >> >> Eventually, the agent domain is ideal to handle the >> direction of >> the asset services. This concept, unfortunately, ended support >> awhile ago with changes in LL. >> Also see; http://wiki.secondlife.com/wiki/Agent_Domain >> And: >> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset >> (warn: unstructured collaborative notes, dumped on me and I >> tried >> to fix) >> >> I tried to find previous visuals. >> >> I'd imagine the agent domain could grow out of unitized >> versions >> of asset services. Despite that, I think that concept helps >> view >> where we were at in discussion and what didn't happen. >> >> Vaughn Deluca wrote: >> >> Hi=EF=BF=BDDzonatas >> >> Can you expand on that, what would be needed for legacy >> support in VWAP terms=EF=BF=BD?, >> If i want to read up on how the=EF=BF=BDasset server may p= roxy the >> simulator, what would you recommend me to read? >> >> -- Vaughn >> >> On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol >> >> > >> >> >>> wrote: >> >> Some stated the proxy-to-asset-server is built into >> the sim; >> however, keep in mind possible legacy support where >> the asset >> server may proxy the simulator. >> >> >> Dzonatas Sol wrote: >> >> Somehow I feel the basic asset server being able to >> login and >> download assets is now priority, yet I also wondere= d >> the best >> way to patch this into the current mode of viewers. >> >> Maybe offer (1) by proxy (sim-side) and (2) by patc= h >> (viewer-side) that either of these two are >> optional and >> neither are mandatory for now. Thoughts? >> >> Israel Alanis wrote: >> >> >> > when designing for scalability, the model >> to bear in >> mind is ... >> >> Well, there are a lot of different models to >> keep >> in mind, >> and many different use cases. One particular us= e >> case to >> keep in mind is: "User acquires new outfit, and >> wants to >> 'show it off' in a highly populated region". >> >> > Both worlds and asset services may include >> commercial, >> community, and personal services >> >> Yes, yes and yes. I'm particularly concerned >> about >> how the >> model affects the ability to host personal asse= t >> services. >> >> > a proxying region, which would get slammed >> for every >> asset worn by every avatar present. >> >> Granted the collection of services that are >> provided by >> the region need to be scaled to meet the >> demands of >> that >> region. That's all part of capacity planning. >> >> > regions run many different CPU-intensive >> tasks, >> including physics simulation and server-side >> scripting, >> and absolutely cannot afford to serve assets to= o >> Well... who said the same CPU's have to do >> proxying, >> physics simulation and server-side >> scripting? Asset >> proxying is a different service than physics >> simulation >> and can be on separate hardware, could make >> use of >> geographically distributed caching, and in >> certain >> deployment patterns, the same caching >> services could be >> shared by different regions. (Server-side >> scripting >> is a >> discussion for another day). >> >> > This is why we have to go parallel... >> >> Totally agree, and a proxying model could and >> should also >> take advantage of parallelism. >> >> > I think you're wrong that it has to cost much >> money. ?vs? >> > It costs money to host a high performance and >> scalable >> asset service and a high bandwidth network to >> handle the >> traffic. =EF=BF=BDA *lot* of money. >> I think what you're saying is: "It costs a >> lot of >> money to >> build a scalable asset service, but if >> assets are >> spread >> throughout the internet they don't have to be >> scalable." >> But that's not quite right. You're opening >> up every >> asset >> server to the VW equivalent of being >> slashdotted, >> so are >> you sure you're not forcing *every* asset >> service to be >> scalable and handle a lot of bandwith and >> network >> traffic? >> It's the exact opposite of your intention, >> but I think >> that's the result, all the same. >> >> This particular design decision has a big >> effect on the >> economics of the VW infrastructure. I'd >> rather the >> economics to work out such that a region >> provider who >> wishes to build a region that supports a small >> population, >> can do so economically. A region that wants >> to host a >> *large* population has to bear that cost of >> providing that >> scalable asset service. >> I want the economics of hosting a small asset >> service to >> be a non-issue (as to best promote creation and >> creativity). Creating a high bar to provide >> asset >> services >> will mean that service will cost money and >> people >> shouldn't have to pay money just to create >> or own VW >> objects (I'm using 'own' here to refer to >> maintaining >> their existence, I'm not trying to make a >> 'leftist'/'communist' statement about >> ownership ;) >> >> - Izzy >> >> >> On Apr 2, 2011, at 3:58 PM, Morgaine wrote: >> >> Izzy, when designing for scalability, >> the model to >> bear in mind is that of seasoned virtual >> world >> travelers whose inventories contain >> assets from >> many >> different worlds, those assets being >> served by many >> different asset services. =EF=BF=BDBoth wor= lds >> and asset >> services may include commercial, >> community, and >> personal services, and as the metaverse >> grows, that >> set is highly likely to become >> progressively less >> clustered and more diverse. >> >> When those seasoned travelers click on an >> advertised >> VW link and perform an inter-world >> teleport to one >> particular world's region to share an >> experience, >> their "worn" assets (the only ones of >> interest >> to the >> region) will contain references to asset >> services >> spread widely across the Internet. =EF=BF= =BDThe >> fetches >> by the >> travelers' clients occur over many parallel >> paths from >> clients to asset services, so one can >> reasonably >> expect reduced network contention and >> reduced asset >> server loading because they are both >> spread out >> over >> however many asset services are being >> referenced by >> the overall set of assets in the region. >> >> This is very different to the case of a >> proxying >> region, which would get slammed for >> every asset >> worn >> by every avatar present. =EF=BF=BDIn our cu= rrent >> architecture, >> regions run many different CPU-intensive >> tasks, >> including physics simulation and server-sid= e >> scripting, and absolutely cannot afford >> to serve >> assets too unless your scalability >> requirements are >> very low indeed, ie. just a few dozen >> avatars of >> today's kind. =EF=BF=BDWe've hit the ceilin= g >> already on >> region >> scalability done that way. =EF=BF=BDThere i= s >> nowhere to >> go in >> that direction at all beyond improving >> the code >> like >> Intel demonstrated, and that work is >> subject to >> a law >> of diminishing returns. >> >> This is why we have to go parallel, and >> I think >> you're >> wrong that it has to cost much money. >> =EF=BF=BDAs we spread >> the load across more and more asset >> services, >> we are >> simply better utilizing all the hardware >> that's >> already out there on the Internet, at >> least in >> respect >> of community and private resources. =EF=BF= =BDBut >> add to the >> community and private resources the >> commercial >> asset >> services that are likely to appear to >> exploit this >> opportunity, and not only will the >> number of asset >> services leap, but the power of each one >> will >> rocket >> too, because, after all, these >> businesses will be >> heavily optimized for the job. >> >> As to why a world would want clients to >> access >> external asset services instead of providin= g >> its own >> implementation, that's an easy question. >> =EF=BF=BDIt costs >> money to host a high performance and >> scalable asset >> service and a high bandwidth network to >> handle the >> traffic. =EF=BF=BDA *lot* of money. =EF=BF= =BDIn contrast, it >> costs a >> world nothing to let others serve the >> assets to >> clients. =EF=BF=BDAnd that matters to the b= ottom >> line. >> >> >> Morgaine. >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >> >> On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis >> > >> > > > >> > >> >> > >> = > >> >> > >> > >>>> wrote: >> >> =EF=BF=BD =EF=BF=BD> As always though, it's= a trade-off, >> since the >> proxied design >> =EF=BF=BD =EF=BF=BDhas very poor scalabilit= y compared to the >> distributed one. >> >> =EF=BF=BD =EF=BF=BDI don't agree with that.= .. If a user >> enters a >> highly populated >> =EF=BF=BD =EF=BF=BDregion, >> =EF=BF=BD =EF=BF=BDevery other client is go= ing to (could and >> should be >> trying to) >> =EF=BF=BD =EF=BF=BDhit the >> =EF=BF=BD =EF=BF=BDasset server(s) for the = assets that >> the user is >> wearing (assuming >> =EF=BF=BD =EF=BF=BDthey're not cached local= ly). =EF=BF=BDEvery >> asset server >> has to be scaled up >> =EF=BF=BD =EF=BF=BDto the point that it can= handle that load >> from all >> over... >> >> =EF=BF=BD =EF=BF=BDIf I'm hosting a region = that supports >> 10s of >> thousands of >> =EF=BF=BD =EF=BF=BDsimultaneous >> =EF=BF=BD =EF=BF=BDusers (thinking of the f= uture), I already >> have to >> scale to meet that >> =EF=BF=BD =EF=BF=BDdemand. If the region is= proxying the >> assets, then, >> yes the >> =EF=BF=BD =EF=BF=BDregion has >> =EF=BF=BD =EF=BF=BDto be scaled to meet tha= t asset >> demand too, >> but it >> already has to be >> =EF=BF=BD =EF=BF=BDscaled to meet other dem= ands of being >> a region >> server... and why is >> =EF=BF=BD =EF=BF=BDscaling those asset prox= y services >> hard? =EF=BF=BDIt's >> going to cost $, >> =EF=BF=BD =EF=BF=BDbut is >> =EF=BF=BD =EF=BF=BDnot technically challeng= ing. So, if I >> want >> to host >> a region like >> =EF=BF=BD =EF=BF=BDthat... sure it will cos= t me, but the >> simulation >> will be consistent >> =EF=BF=BD =EF=BF=BDand users will be able t= o participate >> equally, >> regardless of the >> =EF=BF=BD =EF=BF=BDcapabilities of their in= dividual >> asset services. >> >> >> >> >> =EF=BF=BD =EF=BF=BDOn Fri, Apr 1, 2011 at 1= 1:55 PM, Morgaine >> =EF=BF=BD =EF=BF=BD> >> > > >> > >> > >> >> =EF=BF=BD >> =EF=BF=BD> >> >> >> > > >> >> > >> > >>>> wrote: >> =EF=BF=BD =EF=BF=BD> Every design choice re= sults in a >> trade-off, >> Vaughn, improving >> =EF=BF=BD =EF=BF=BDone thing at >> =EF=BF=BD =EF=BF=BD> the expense of somethi= ng else. =EF=BF=BDIf >> every >> time we >> offered a >> =EF=BF=BD =EF=BF=BDservice we had to >> =EF=BF=BD =EF=BF=BD> inform its users about= the downsides of >> all the >> trade-offs we >> =EF=BF=BD =EF=BF=BDhave made, >> =EF=BF=BD =EF=BF=BD> they would have an awf= ul lot to >> read. ;-) >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> The specific trade-off= that you are >> discussing is no >> =EF=BF=BD =EF=BF=BDdifferent. =EF=BF=BDA re= gion >> =EF=BF=BD =EF=BF=BD> that proxies all conte= nt has the >> "benefit" of >> acquiring control >> =EF=BF=BD =EF=BF=BDfrom the >> =EF=BF=BD =EF=BF=BD> asset servers over the= items in the >> region, so >> that it can >> =EF=BF=BD =EF=BF=BDensure that >> =EF=BF=BD =EF=BF=BD> everyone in the region= not only obtains >> the items >> but obtains >> =EF=BF=BD =EF=BF=BDthe same items >> =EF=BF=BD =EF=BF=BD> as everyone else. =EF= =BF=BDThat does indeed >> provide a >> greater guarantee of >> =EF=BF=BD =EF=BF=BD> consistency than a dep= loyment in >> which the >> region >> only passes >> =EF=BF=BD =EF=BF=BDasset URIs to >> =EF=BF=BD =EF=BF=BD> clients who then fetch= the items from >> asset services >> =EF=BF=BD =EF=BF=BDseparately. =EF=BF=BDAs = always >> =EF=BF=BD =EF=BF=BD> though, it's a trade-o= ff, since the >> proxied >> design has very >> =EF=BF=BD =EF=BF=BDpoor scalability >> =EF=BF=BD =EF=BF=BD> compared to the distri= buted one. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> If we're going to warn= users of the >> potential for >> inconsistency >> =EF=BF=BD =EF=BF=BDin the >> =EF=BF=BD =EF=BF=BD> distributed deployment= as you >> suggest, are we >> also going to >> =EF=BF=BD =EF=BF=BDwarn them of >> =EF=BF=BD =EF=BF=BD> non-scalability in the= proxied one? >> =EF=BF=BDI really >> don't see much >> =EF=BF=BD =EF=BF=BDmerit in the >> =EF=BF=BD =EF=BF=BD> idea of warning about = design choices. >> =EF=BF=BDMany such >> choices are >> =EF=BF=BD =EF=BF=BDtechnical, and >> =EF=BF=BD =EF=BF=BD> the issues are quite l= ikely to be >> of little >> interest to >> =EF=BF=BD =EF=BF=BDnon-technical users >> =EF=BF=BD =EF=BF=BD> anyway. =EF=BF=BDIn an= y case, the better >> services are >> likely to provide >> =EF=BF=BD =EF=BF=BDsuch >> =EF=BF=BD =EF=BF=BD> information in their o= nline >> documentation, I >> would guess. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> You mentioned users "v= oting with their >> feet" or >> choosing to >> =EF=BF=BD =EF=BF=BDaccept the risk >> =EF=BF=BD =EF=BF=BD> of inconsistency. =EF= =BF=BDWell that will >> happen >> anyway, >> when services >> =EF=BF=BD =EF=BF=BDfail and >> =EF=BF=BD =EF=BF=BD> users get annoyed. =EF= =BF=BDIf some asset >> services >> refuse >> to send the >> =EF=BF=BD =EF=BF=BDrequested >> =EF=BF=BD =EF=BF=BD> items to some users, t= hose services >> will get a >> bad reputation >> =EF=BF=BD =EF=BF=BDand people >> =EF=BF=BD =EF=BF=BD> will choose different = asset >> services instead. >> =EF=BF=BDLikewise, if a >> =EF=BF=BD =EF=BF=BDworld service >> =EF=BF=BD =EF=BF=BD> proxies everything and= so it can't >> handle >> a large >> number of >> =EF=BF=BD =EF=BF=BDassets or of >> =EF=BF=BD =EF=BF=BD> people, users will get= annoyed at >> the lag >> and will go >> =EF=BF=BD =EF=BF=BDelsewhere. =EF=BF=BDThis= user >> =EF=BF=BD =EF=BF=BD> evaluation and "voting= with their feet" >> happens >> already with >> =EF=BF=BD =EF=BF=BDonline services >> =EF=BF=BD =EF=BF=BD> all over the Internet,= and I am >> sure that this >> human process >> =EF=BF=BD =EF=BF=BDwill continue >> =EF=BF=BD =EF=BF=BD> to work when the servi= ces are asset >> and region >> services. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> Back in September 2010= , I wrote >> this post >> which >> proposes that >> =EF=BF=BD =EF=BF=BDwe use in >> =EF=BF=BD =EF=BF=BD> VWRAP a form of asset = addressing >> that provides >> massive >> =EF=BF=BD =EF=BF=BDscalability at the >> =EF=BF=BD =EF=BF=BD> same time as a very hi= gh degree of >> resilience -- >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD >> =EF=BF=BD >> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >> =EF=BF=BD =EF=BF=BD. =EF=BF=BDIt is >> =EF=BF=BD =EF=BF=BD> based on the concept o= f the URI >> containing >> a host >> part and a >> =EF=BF=BD =EF=BF=BDhash part, >> =EF=BF=BD =EF=BF=BD> where the hash is gene= rated (once, >> at the >> time of >> storage to >> =EF=BF=BD =EF=BF=BDthe asset >> =EF=BF=BD =EF=BF=BD> service) using a speci= fied digest >> algorithm over >> the content of >> =EF=BF=BD =EF=BF=BDthe asset >> =EF=BF=BD =EF=BF=BD> being referenced. =EF= =BF=BDYou may wish to note >> that if >> this design >> =EF=BF=BD =EF=BF=BDwere used, the >> =EF=BF=BD =EF=BF=BD> failure of an asset se= rvice to >> deliver a >> requested item would >> =EF=BF=BD =EF=BF=BDresult in a >> =EF=BF=BD =EF=BF=BD> failover request for t= he item to >> one or more >> backup services, >> =EF=BF=BD =EF=BF=BDusing the same >> =EF=BF=BD =EF=BF=BD> hash part but with a d= ifferent host >> address. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> This can go some way t= owards >> overcoming the >> problem that you >> =EF=BF=BD =EF=BF=BDthink might >> =EF=BF=BD =EF=BF=BD> occur when assets are = fetched by >> clients from >> asset services >> =EF=BF=BD =EF=BF=BDdirectly. >> =EF=BF=BD =EF=BF=BD> Although it won't help= when the missing >> item is >> available from >> =EF=BF=BD =EF=BF=BDonly a single >> =EF=BF=BD =EF=BF=BD> asset service, it will= help in many >> other >> cases, >> and it will >> =EF=BF=BD =EF=BF=BDcompensate for >> =EF=BF=BD =EF=BF=BD> service failures and n= etwork outages >> automatically at the same >> =EF=BF=BD =EF=BF=BDtime. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> PS. This design for ha= sh-based asset >> addressing >> is already >> =EF=BF=BD =EF=BF=BDbeing tested by >> =EF=BF=BD =EF=BF=BD> Mojito Sorbet in her e= xperimental >> world and >> client. =EF=BF=BDIt would give >> =EF=BF=BD =EF=BF=BD> VWRAP-based worlds an = improved level of >> service >> availability, >> =EF=BF=BD =EF=BF=BDso I think it >> =EF=BF=BD =EF=BF=BD> should be a core featu= re of our >> protocol. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> Morgaine. >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> =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 >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> On Fri, Apr 1, 2011 at= 11:17 PM, >> Vaughn Deluca >> =EF=BF=BD =EF=BF=BD> >> > > >> > >> > >> >> > >> > > >> > >> > >>>> >> =EF=BF=BD =EF=BF=BD> wrote: >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> This is a question i = discussed >> with Morgaine >> off-list a while >> =EF=BF=BD =EF=BF=BDago (I >> =EF=BF=BD =EF=BF=BD>> intended to send it t= o the list but >> pushed the >> wrong button...) I >> =EF=BF=BD =EF=BF=BD>> think we need to addr= ess this >> problem, and >> decide how to deal >> =EF=BF=BD =EF=BF=BDwith it. >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDIn Davids de= ployment draft, section >> 7.3.1.1 an >> overview is >> =EF=BF=BD =EF=BF=BDgiven van >> =EF=BF=BD =EF=BF=BD>> ways to deliver conte= nt to the region. >> One way >> is only passing a >> =EF=BF=BD =EF=BF=BD>> capability that allow= s access to (part >> of) the >> resource: >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD =EF=BF=BD 7.3.1.1. =EF=BF=BDContent >> delivery models >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD =EF=BF=BD A range of possible >> represenations can >> be passed to >> =EF=BF=BD =EF=BF=BDa region for >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD =EF=BF=BD simulation. [...] The >> other end >> of the >> delivery spectrum >> =EF=BF=BD =EF=BF=BD>> involves passing >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD =EF=BF=BD only a URI or capability >> used to >> access the rendering >> =EF=BF=BD =EF=BF=BD>> information and a >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD =EF=BF=BD collision mesh,and >> related data for >> physical simulation. >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD =EF=BF=BD In such a model, the >> client is >> responsible for >> =EF=BF=BD =EF=BF=BDfetching the >> =EF=BF=BD =EF=BF=BD>> additional >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD =EF=BF=BD information needed to >> render the >> item's visual >> =EF=BF=BD =EF=BF=BDpresence from a >> =EF=BF=BD =EF=BF=BD>> separate >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD =EF=BF=BD service. =EF=BF=BDThis fetch can >> be done >> *under the >> =EF=BF=BD =EF=BF=BDcredentials of the >> =EF=BF=BD =EF=BF=BD>> end user* >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD =EF=BF=BD viewing the material [my >> emphasis--VD] >> , and >> =EF=BF=BD =EF=BF=BDdivorces the >> =EF=BF=BD =EF=BF=BD>> simulation from >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD =EF=BF=BD the trust chain needed >> to manage >> content. =EF=BF=BDAny >> =EF=BF=BD =EF=BF=BDautomation >> =EF=BF=BD =EF=BF=BD>> is done on a >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD =EF=BF=BD separate host which the >> content >> creator or owner trusts, >> =EF=BF=BD =EF=BF=BD>> interacting with the >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD =EF=BF=BD object through remoted >> interfaces. >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDI can see th= e need for such a setup, >> however, i >> feel we are >> =EF=BF=BD =EF=BF=BD>> unpleasantly close to= a situation >> were the >> coherence of the >> =EF=BF=BD =EF=BF=BDsimulation >> =EF=BF=BD =EF=BF=BD>> falls apart. >> =EF=BF=BD =EF=BF=BD>> In this deployment pa= ttern the region >> advertises >> the presence >> =EF=BF=BD =EF=BF=BDof the >> =EF=BF=BD =EF=BF=BD>> asset, and *some* cli= ents will be >> able to >> get it >> as expected, >> =EF=BF=BD =EF=BF=BDwhile >> =EF=BF=BD =EF=BF=BD>> -based on the arbitra= ry whims of >> the asset >> service- others >> =EF=BF=BD =EF=BF=BDmight not. >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> My hope would be that= after the >> asset server >> provides the >> =EF=BF=BD =EF=BF=BDregion with >> =EF=BF=BD =EF=BF=BD>> the capability to get= the asset, >> it gives up >> control. That >> =EF=BF=BD =EF=BF=BDwould mean >> =EF=BF=BD =EF=BF=BD>> that if the client fi= nds the inventory >> server is >> unwilling to >> =EF=BF=BD =EF=BF=BDserve >> =EF=BF=BD =EF=BF=BD>> the content - in spir= e of the region >> saying it >> is present-, >> =EF=BF=BD =EF=BF=BDthe client >> =EF=BF=BD =EF=BF=BD>> should be able to tur= n around ask the >> *region* >> for the asset, >> =EF=BF=BD =EF=BF=BD(and get >> =EF=BF=BD =EF=BF=BD>> is after all). >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDIf that is n= ot the case, -and >> there are >> probably good reasons >> =EF=BF=BD =EF=BF=BDfor the >> =EF=BF=BD =EF=BF=BD>> deployment pattern as= described- >> =EF=BF=BDshouldn't we >> *warn* clients >> =EF=BF=BD =EF=BF=BDthat the >> =EF=BF=BD =EF=BF=BD>> region might be incon= sistent, so >> the users >> behind the client >> =EF=BF=BD =EF=BF=BDcan vote >> =EF=BF=BD =EF=BF=BD>> with their feet, (or = take the risk)? >> =EF=BF=BD =EF=BF=BD>> >> =EF=BF=BD =EF=BF=BD>> --Vaughn >> =EF=BF=BD =EF=BF=BD>> >> _______________________________________________ >> =EF=BF=BD =EF=BF=BD>> vwrap mailing list >> =EF=BF=BD =EF=BF=BD>> vwrap@ietf.org >> > > >> >> >> >> > > > >> >> >>> >> >> =EF=BF=BD =EF=BF=BD>> >> https://www.ietf.org/mailman/listinfo/vwrap >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> _______________________________________________ >> =EF=BF=BD =EF=BF=BD> vwrap mailing list >> =EF=BF=BD =EF=BF=BD> vwrap@ietf.org >> > > >> >> >> >> > > > >> >> >>> >> >> =EF=BF=BD =EF=BF=BD> >> https://www.ietf.org/mailman/listinfo/vwrap >> =EF=BF=BD =EF=BF=BD> >> =EF=BF=BD =EF=BF=BD> >> >> >> >> >> -----------------------------------------------------------------------= - >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> > >> >> >> >> https://www.ietf.org/mailman/listinfo/vwrap >> =EF=BF=BD >> >> >> >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, >> Consultant >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> > >> >> >> >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, >> Consultant >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> >> -----------------------------------------------------------------------= - >> >> >> >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > --000e0cd25cae034e9204a008d947 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 SSYjMzk7bSBhZnJhaWQgeW91IG1pc3VuZGVyc3RhbmQgdGhlIGlzc3VlLCBEem9uYXRhcy7CoCBJ JiMzOTtsbCBhZGQgYSBiaXQgb2YgYmFja2dyb3VuZC48YnI+PGJyPlRoaXMgaGFzIG5vdGhpbmcg dG8gZG8gd2l0aCB2aXN1YWwgdmVyc3VzIGdyYXBoaWNhbCBwcmVzZW50YXRpb24uwqAgSSYjMzk7 bSBhIGJpZyBmYW4gb2YgYm90aCwgYW5kIGxpa2UgeW91cnNlbGYgSSB0aGluayBzcGF0aWFsbHkg bW9zdCBvZiB0aGUgdGltZSBhYm91dCBhcmNoaXRlY3R1cmVzLCB3aGljaCBpcyBhIGdyYXBoaWMg Zm9ybS7CoCBMaWtld2lzZSwgaXQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBhY2Nlc3NpYmlsaXR5 IHdoYXRzb2V2ZXIsIG9mIHdoaWNoIEkmIzM5O3ZlIGJlZW4gYSB2ZXJ5IGVudGh1c2lhc3RpYyBw cm9wb25lbnQgaW4gU2Vjb25kIExpZmUgZm9yIG1hbnkgeWVhcnMuPGJyPgo8YnI+VGhlIG9ubHkg dGhpbmcgd2l0aCB3aGljaCB0aGUgJnF1b3Q7ZG9tYWluJnF1b3Q7IGFyZ3VtZW50IGlzIGNvbmNl cm5lZCBpcyB3aGV0aGVyIHRoZSBjb25jZXB0IHJlZmxlY3RzIHNvbWV0aGluZyB1c2VmdWwgaW4g VldSQVAgdGhhdCB3ZSBjYW4gb2JzZXJ2ZSwgcXVlcnksIGludGVyYWN0IHdpdGgsIG9yIGRlc2ln biBhIHByb3RvY29sIGFyb3VuZC7CoCBUaGUgYW5zd2VyIGlzICZxdW90O05vJnF1b3Q7IG9uIGFs bCB0aGVzZSBjb3VudHMgZm9yICZxdW90O0FnZW50IERvbWFpbiZxdW90OyBpbiBWV1JBUCwgYmVj YXVzZSBpdCByZWZlcnMgdG8gYSBjb25jZXB0IGluIE9HUCB0aGF0IGRlbmllZCBpbnRlcm9wLCBh bmQgaXQgZG9lcyBub3QgYXBwbHkgdG8gdXMuPGJyPgo8YnI+QXMgYSByZXN1bHQsIGZhciBmcm9t IGhlbHBpbmcgYW55b25lIHRvIHVuZGVyc3RhbmQgdGhlIFZXUkFQIGFyY2hpdGVjdHVyZSwgYWxs IGl0IGRvZXMgaXMgaW5jcmVhc2UgdGhlIGFtb3VudCBvZiBjb25mdXNpb24gc3Vycm91bmRpbmcg VldSQVAsIGJlY2F1c2UgaXQgZG9lcyBub3QgcmVmbGVjdCBhbnl0aGluZyB1c2VmdWwgYWJvdXQg d2hhdCB3ZSBhcmUgdHJ5aW5nIHRvIGltcGxlbWVudC48YnI+Cjxicj5UaGUgbmVhcmVzdCB3ZSBn ZXQgaW4gVldSQVAgdG8gc29tZXRoaW5nIHRoYXQgbWlnaHQgaGF2ZSBiZWVuIGNvbmNlaXZlZCBv cmlnaW5hbGx5IGFzIHRoZSAmcXVvdDtBZ2VudCBEb21haW4mcXVvdDsgaW4gT0dQIGlzIHJvdWdo bHkgJnF1b3Q7VGhlIHNldCBvZiBwbGFjZXMgYW5kIGl0ZW1zIGFuZCByZXNvdXJjZXMgdGhhdCB0 aGlzIHdvcmxkIHdpbGwgcGVybWl0IGFuIGFnZW50IHRvIHZpc2l0IG9yIGludGVyYWN0IHdpdGgg JnF1b3Q7LCB3aGljaCBpcyBhcHByb3hpbWF0ZWx5IHRoZSBzYW1lIHRoaW5nIGFzIHNheWluZyAm cXVvdDt0aGUgY2xvc2VkIHdhbGxlZCBnYXJkZW4mcXVvdDsuwqAgSXQgaXMgYSBzaW5ndWxhcmx5 IGNvdW50ZXItcHJvZHVjdGl2ZSBjb25jZXB0IGZvciBhIGdyb3VwIHRoYXQgaGFzIHRoZSBpbXBv cnRhbnQgZ29hbCBvZiBhY2hpZXZpbmcgaW50ZXJvcCBiZXR3ZWVuIHdvcmxkcy48YnI+Cjxicj5T byBubywgaXQmIzM5O3Mgbm90IGhlbHBmdWwsIGVpdGhlciB2aXN1YWxseSBvciBvdGhlcndpc2Uu wqAgVGhlIHRlcm0gaXMganVzdCBhbm90aGVyIG9ic3RhY2xlIG9uIHRoZSByb2FkIHRvIFZXIGlu dGVyb3AuwqAgVGhhdCBPR1Agd2hpdGVib2FyZCBuZXZlciBoYWQgb3RoZXIgZmx1ZmZ5IGNsb3Vk cyBvbiBpdCBsYWJlbGVkICZxdW90O1ZpcnR1YWwgd29ybGQgQiZxdW90OywgJnF1b3Q7VmlydHVh bCB3b3JsZCBDJnF1b3Q7LCBhbmQgc28gb24uwqAgVGhlIGNvbmNlcHQgb2YgaW50ZXJvcCBiZXR3 ZWVuIHdvcmxkcyB3YXMgZGVuaWVkLCBiZWNhdXNlIEFnZW50IERvbWFpbiBjb250cm9sbGVkIGFj Y2VzcyB0byBSZWdpb24gRG9tYWlucywgYW5kIHNvIG5vdGhpbmcgb3V0c2lkZSBBRCtSRCBleGlz dGVkIGluIE9HUC48YnI+Cjxicj5CdXQgd2UgYXJlIG5vdCBkZXNpZ25pbmcgT0dQLCB3ZSBhcmUg ZGVzaWduaW5nIFZXUkFQLCBhIHNldCBvZiBwcm90b2NvbHMgdGhhdCBlbWJyYWNlcyBpbnRlcm9w ZXJhdGlvbiBiZXR3ZWVuIHdvcmxkcyBhcyB3ZWxsLsKgIFRoYXQgaXMgd2h5IHRoZSBBZ2VudCBE b21haW4gZG9lcyBub3QgZXhpc3QgYXMgYSB1c2VmdWwgY29uY2VwdCBpbiB0aGlzIHdvcmsuwqAg SXQgZWxldmF0ZXMgd29ybGQgY2xvc3VyZSwgbmVnYXRlcyBpbnRlcm9wZXJhdGlvbiwgYW5kIGRv ZXMgbm90IGV2ZW4gYWRtaXQgb3RoZXIgd29ybGRzIGludG8gdGhlIHBpY3R1cmUsIGJlY2F1c2Ug QWdlbnQgRG9tYWluIGlzIGRlZmluZWQgdG8gZXhjbHVkZSB0aGVtLjxicj4KPGJyPkl0JiMzOTtz IGEgdmVyeSBiYWQgaWRlYSwgYm90aCBpbiB0ZXh0IGFuZCBhcyBmbHVmZnkgY2xvdWRzLjxicj48 YnI+PGJyPk1vcmdhaW5lLjxicj48YnI+PGJyPjxicj49PT09PT09PT09PT09PT09PT09PT09PGJy Pjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gU3VuLCBBcHIgMywgMjAxMSBhdCA3OjQ5 IFBNLCBEem9uYXRhcyBTb2wgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86ZHpv bmF0YXNAZ21haWwuY29tIj5kem9uYXRhc0BnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6 PGJyPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBwdCAw cHQgMHB0IDAuOGV4OyBib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsg cGFkZGluZy1sZWZ0OiAxZXg7Ij5WaXN1YWwgcGVvcGxlIGRvbiYjMzk7dCBkbyB3ZWxsIHdpdGgg JnF1b3Q7ZmlndXJlLW9mLXNwZWVjaCZxdW90OyBhbmQgc3VjaCBzZW1hbnRpY3MuIFRob3NlIHRo YXQgcHJlZmVyIHN1Y2ggc2VtYW50aWNzIHVzdWFsbHkgZG9uJiMzOTt0IGVpdGhlciBkb24mIzM5 O3QgcmVjb2duaXplIHRoaXMgb3IgdHJlYXQgdmlzdWFsIHBlb3BsZSBhcyBpbiBuZWVkIG9mIGFj Y2Vzc2liaWxpdGllcy4gV2UgYXJlIG5vdCBkdW1iLiBJdCBkb2VzbiYjMzk7dCBnZXQgJnF1b3Q7 eW91JnF1b3Q7IHRoZWlyLi4uIGl0IGdldHMgJnF1b3Q7dXMmcXVvdDsgdGhlcmUgaWYgeW91IGFj a25vd2xlZGdlIHRoZXNlIGRpZmZlcmVuY2VzIGluIHBlb3BsZS4gRG9uJiMzOTt0IHJlbHkgb24g c3VjaCBzZW1hbnRpY3MsIGFzIHRvIHZpc3VhbCBwZW9wbGUgdGhhdCBpcyBqdXN0IG5vbnNlbnNl IChiZWluZyBub3QgdXNlZnVsKS4gVG8gdmlzdWFsIHBlb3BsZSwgZXZlcnkgd29yZCBjYXJyaWVz IGl0cyBjb21wbGV0ZSBtZWFuaW5ncyBhbmQgbm8gbGVzcy4gVG8gdGhvc2UgdGhhdCBwcmVmZXIg JnF1b3Q7ZmlndXJlLW9mLXNwZWVjaCZxdW90OyAoYXVkaXRvcnkgYW5kIGtpbmV0aWMgdHlwZXMp IHRoZXkgaW1wbHkgbGVzcyB0aGF0IG1lYW5zIG5vdGhpbmcgdG8gdmlzdWFsIHBlb3BsZS48YnI+ Cgo8YnI+CkFsc28sIGRvIG5vdGUgdGhhdCB5b3VyIG1lc3NhZ2UgYmVsb3cgc2VlbXMgdG8gbW9j ayB2aXN1YWwgcGVvcGxlIGFzICZxdW90O2hpbmRyYW5jZSB0byBmdXJ0aGVyIHByb2dyZXNzJnF1 b3Q7LiA9KDxicj4KPGJyPgpJIGhvcGUgeW91IHJlY29uc2lkZXIgeW91ciBhcHByb2FjaCwgTW9y Z2FpbmUuIE5vdCBvZnRlbiBkbyBwZW9wbGUgd2FudCB0byBjYXRlZ29yaXplIGFjY2Vzc2liaWxp dGllcyBhbmQgc3VjaCBpc3N1ZXMuPGJyPgo8YnI+Ck1vcmdhaW5lIHdyb3RlOjxicj4KPGJsb2Nr cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhl eDsgYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRpbmctbGVm dDogMWV4OyI+PGRpdiBjbGFzcz0iaW0iPgpXZSBoYXZlIG5vICZxdW90O2ZpZ3VyZS1vZi1zcGVl Y2ggc2VydmljZXMmcXVvdDsgaW4gVldSQVAuIMKgT3VyIHNlcnZpY2VzIGFyZSBydW5uaW5nIHBy b2Nlc3NlcywgdGhleSBoYXZlIG5ldHdvcmsgZW5kcG9pbnRzLCBhbmQgdGhleSB0YWxrIGEgbmV0 d29yayBwcm90b2NvbC48YnI+Cjxicj4KQ29uY2VwdHMgY2FuIGJlIHZlcnkgdXNlZnVsLCBhbmQg SSByZWd1bGFybHkgZHJhdyBmbHVmZnkgY2xvdWRzIHRoYXQgcmVwcmVzZW50IHRoZSBjb25jZXB0 IGJlaGluZCBzb21ldGhpbmcgY29uY3JldGUuPGJyPgo8YnI+CldoZXJlIGNvbmNlcHRzIGFyZSBu b3QgdXNlZnVsIGlzIHdoZW4gdGhleSBkZW5vdGUgc29tZXRoaW5nIHRoYXQgZG9lc24mIzM5O3Qg YWN0dWFsbHkgZXhpc3QsIGxpa2Ugc2F5IHBobG9naXN0b24sIEdvZCwgb3IgQWdlbnQgRG9tYWlu LCBiZWNhdXNlIHRoaXMganVzdCBtYWtlcyB0aGVtIGEgaGluZHJhbmNlIHRvIGZ1cnRoZXIgcHJv Z3Jlc3MuIMKgSHVtYW5pdHkgc3VmZmVycyBmcm9tIHRoaXMgYSBsb3QuPGJyPgoKPGJyPgpQaGls b3NvcGh5IGFzaWRlLCB3ZSB3YW50IG91ciBBZ2VudCBTZXJ2aWNlIHRvIGJlIHRvdGFsbHkgY29u Y3JldGUsIHdpdGggYSBuZXR3b3JrIEFQSSBhbmQgd2VsbCBkZWZpbmVkIHNlbWFudGljcy4gwqBU aGUgZG9tYWluIGNvbmNlcHQgZG9lcyBub3QgZ2V0IHVzIHRoZXJlLjxicj4KPGJyPgo8YnI+Ck1v cmdhaW5lLjxicj4KPGJyPgo8YnI+Cjxicj4KPGJyPgo9PT09PT09PT09PT09PT09PT08YnI+Cjxi cj48L2Rpdj48ZGl2IGNsYXNzPSJpbSI+Ck9uIFN1biwgQXByIDMsIDIwMTEgYXQgNjozOCBQTSwg RHpvbmF0YXMgU29sICZsdDs8YSBocmVmPSJtYWlsdG86ZHpvbmF0YXNAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+ZHpvbmF0YXNAZ21haWwuY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpkem9uYXRhc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kem9uYXRhc0BnbWFpbC5j b208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPgoKPGJyPgogwqAgwqBJIHByZWZlciB0aGUgdmlzdWFs aXphdGlvbiBvZiAmcXVvdDtkb21haW5zJnF1b3Q7IGJlY2F1c2UgdGhvc2UgZmx1ZmZ5PGJyPgog wqAgwqBjbG91ZHMgcmVhbGx5IGhlbHAgdGhvc2UgdGhhdCBkb24mIzM5O3QgZG8gd2VsbCB3aXRo IGZpZ3VyZS1vZi1zcGVlY2g8YnI+CiDCoCDCoCZxdW90O3NlcnZpY2VzLiZxdW90Ozxicj4KPGJy Pgo8YnI+CiDCoCDCoE1vcmdhaW5lIHdyb3RlOjxicj4KPGJyPgogwqAgwqAgwqAgwqAmcXVvdDtB Z2VudCBEb21haW4mcXVvdDsgbW9yZSBvciBsZXNzIGNlYXNlZCB0byBleGlzdCBpbiBwcmFjdGlj ZSB3aGVuPGJyPgogwqAgwqAgwqAgwqBEYXZpZCBwb2ludGVkIG91dCB2ZXJ5IGVsb3F1ZW50bHkg dGhhdCB0aGUgZW1wZXJvciBoYWQgbm88YnI+CiDCoCDCoCDCoCDCoGNsb3RoZXMuIMKgKFNhbWUg Zm9yICZxdW90O1JlZ2lvbiBEb21haW4mcXVvdDsuKTxicj4KPGJyPgogwqAgwqAgwqAgwqBJIHRo aW5rIHdlIG1vc3RseSB0YWxrIGFib3V0IHRoZSBBZ2VudCBTZXJ2aWNlIGFuZCBSZWdpb248YnI+ CiDCoCDCoCDCoCDCoFNlcnZpY2UgdGhlc2UgZGF5cy4gwqBUaGUgJnF1b3Q7ZG9tYWluJnF1b3Q7 IHdhcyBqdXN0IGEgZmx1ZmZ5IGNsb3VkIHRoYXQ8YnI+CiDCoCDCoCDCoCDCoHNvbWVvbmUgb25j ZSBkcmV3IG9uIGEgd2hpdGVib2FyZCwgYnV0IHdoaWNoIG5ldmVyIGFjdHVhbGx5PGJyPgogwqAg wqAgwqAgwqBleGlzdGVkLjxicj4KPGJyPgo8YnI+CiDCoCDCoCDCoCDCoE1vcmdhaW5lLjxicj4K PGJyPgo8YnI+Cjxicj4KPGJyPgogwqAgwqAgwqAgwqA9PT09PT09PT09PT09PT09PT09PTxicj4K PGJyPgogwqAgwqAgwqAgwqBPbiBTdW4sIEFwciAzLCAyMDExIGF0IDY6MjAgUE0sIER6b25hdGFz IFNvbDxicj4KIMKgIMKgIMKgIMKgJmx0OzxhIGhyZWY9Im1haWx0bzpkem9uYXRhc0BnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5kem9uYXRhc0BnbWFpbC5jb208L2E+ICZsdDttYWlsdG86PGEg aHJlZj0ibWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmR6b25hdGFz QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPjwvZGl2PjxkaXY+PGRpdj48L2Rpdj48ZGl2IGNsYXNzPSJo NSI+CiDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmR6b25hdGFzQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmR6b25hdGFzQGdtYWlsLmNvbTwvYT4gJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86ZHpvbmF0YXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHpvbmF0 YXNAZ21haWwuY29tPC9hPiZndDsmZ3Q7Jmd0OyB3cm90ZTo8YnI+Cjxicj4KIMKgIMKgIMKgIMKg IMKgIFByb2JhYmx5IGVhc3kgYXMgc3VnZ2VzdGVkIGluIG90aGVyIHRlcm1zIGhlcmUgb24gdGhp cyBsaXN0LCBhczxicj4KIMKgIMKgIMKgIMKgIMKgIGhvdyB0aGUgY2xpZW50IGNvbnRhY3RzIHRo ZSBhc3NldCBzZXJ2aWNlcyBub3cgaW4gdGhlPGJyPgogwqAgwqAgwqAgwqByZWdpb25zLiBUaGU8 YnI+CiDCoCDCoCDCoCDCoCDCoCBuZXdlciBpc3N1ZSBpcyB0byB1bml0aXplIHRoYXQgYXNzZXQg c2VydmljZXMuIFNpbmNlIHRoZWlyIGlzPGJyPgogwqAgwqAgwqAgwqAgwqAgcHJvcHJpZXRhcnkg KGxlZ2FjeSkgY29kZSB0aGVuIHdlIGNhbiYjMzk7dCBleHBlY3QgdGhhdCB0bzxicj4KIMKgIMKg IMKgIMKgY2hhbmdlLCBhbmQ8YnI+CiDCoCDCoCDCoCDCoCDCoCBzb21lIGZvcm0gb2YgcHJveHkg aXMgb2YgbmVlZC4gV2hhdGV2ZXIgd29ya3MgYmVzdCwgSSB0cmllZCB0bzxicj4KIMKgIMKgIMKg IMKgIMKgIG5hcnJvdyBpdCBkb3duIHRvIHN1Z2dlc3Rpb25zIGhlcmUuPGJyPgo8YnI+CiDCoCDC oCDCoCDCoCDCoCBFdmVudHVhbGx5LCB0aGUgYWdlbnQgZG9tYWluIGlzIGlkZWFsIHRvIGhhbmRs ZSB0aGU8YnI+CiDCoCDCoCDCoCDCoGRpcmVjdGlvbiBvZjxicj4KIMKgIMKgIMKgIMKgIMKgIHRo ZSBhc3NldCBzZXJ2aWNlcy4gVGhpcyBjb25jZXB0LCB1bmZvcnR1bmF0ZWx5LCBlbmRlZCBzdXBw b3J0PGJyPgogwqAgwqAgwqAgwqAgwqAgYXdoaWxlIGFnbyB3aXRoIGNoYW5nZXMgaW4gTEwuPGJy PgogwqAgwqAgwqAgwqAgwqAgQWxzbyBzZWU7IDxhIGhyZWY9Imh0dHA6Ly93aWtpLnNlY29uZGxp ZmUuY29tL3dpa2kvQWdlbnRfRG9tYWluIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3dpa2kuc2Vj b25kbGlmZS5jb20vd2lraS9BZ2VudF9Eb21haW48L2E+PGJyPgogwqAgwqAgwqAgwqAgwqAgQW5k Ojxicj4KIMKgIMKgIMKgIMKgPGEgaHJlZj0iaHR0cDovL3dpa2kuc2Vjb25kbGlmZS5jb20vd2lr aS9Vc2VyOkR6b25hdGFzX1NvbC9BV0dfQXNzZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd2lr aS5zZWNvbmRsaWZlLmNvbS93aWtpL1VzZXI6RHpvbmF0YXNfU29sL0FXR19Bc3NldDwvYT48YnI+ CiDCoCDCoCDCoCDCoCDCoCAod2FybjogdW5zdHJ1Y3R1cmVkIGNvbGxhYm9yYXRpdmUgbm90ZXMs IGR1bXBlZCBvbiBtZSBhbmQgSTxicj4KIMKgIMKgIMKgIMKgdHJpZWQ8YnI+CiDCoCDCoCDCoCDC oCDCoCB0byBmaXgpPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCBJIHRyaWVkIHRvIGZpbmQgcHJl dmlvdXMgdmlzdWFscy48YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIEkmIzM5O2QgaW1hZ2luZSB0 aGUgYWdlbnQgZG9tYWluIGNvdWxkIGdyb3cgb3V0IG9mIHVuaXRpemVkPGJyPgogwqAgwqAgwqAg wqB2ZXJzaW9uczxicj4KIMKgIMKgIMKgIMKgIMKgIG9mIGFzc2V0IHNlcnZpY2VzLiBEZXNwaXRl IHRoYXQsIEkgdGhpbmsgdGhhdCBjb25jZXB0IGhlbHBzPGJyPgogwqAgwqAgwqAgwqB2aWV3PGJy PgogwqAgwqAgwqAgwqAgwqAgd2hlcmUgd2Ugd2VyZSBhdCBpbiBkaXNjdXNzaW9uIGFuZCB3aGF0 IGRpZG4mIzM5O3QgaGFwcGVuLjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgVmF1Z2huIERlbHVj YSB3cm90ZTo8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEhp77+9RHpvbmF0YXM8YnI+ Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIENhbiB5b3UgZXhwYW5kIG9uIHRoYXQsIHdoYXQg d291bGQgYmUgbmVlZGVkIGZvciBsZWdhY3k8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzdXBw b3J0IGluIFZXQVAgdGVybXPvv70/LDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIElmIGkgd2Fu dCB0byByZWFkIHVwIG9uIGhvdyB0aGXvv71hc3NldCBzZXJ2ZXIgbWF5IHByb3h5IHRoZTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNpbXVsYXRvciwgd2hhdCB3b3VsZCB5b3UgcmVjb21tZW5k IG1lIHRvIHJlYWQ/PGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtLSBWYXVnaG48YnI+ Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE9uIFN1biwgQXByIDMsIDIwMTEgYXQgNTo1MSBB TSwgRHpvbmF0YXMgU29sPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0OzxhIGhyZWY9Im1h aWx0bzpkem9uYXRhc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kem9uYXRhc0BnbWFpbC5j b208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmR6b25hdGFzQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPgogwqAgwqAgwqAgwqAm bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkem9uYXRhc0BnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5kem9uYXRhc0BnbWFpbC5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmR6 b25hdGFzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmR6b25hdGFzQGdtYWlsLmNvbTwvYT4m Z3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFp bHRvOmR6b25hdGFzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmR6b25hdGFzQGdtYWlsLmNv bTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZHpvbmF0YXNAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+ZHpvbmF0YXNAZ21haWwuY29tPC9hPiZndDs8YnI+CiDCoCDCoCDCoCDCoCZs dDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmR6b25hdGFzQGdtYWlsLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZHpv bmF0YXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHpvbmF0YXNAZ21haWwuY29tPC9hPiZn dDsmZ3Q7Jmd0OyZndDsgd3JvdGU6PGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oFNvbWUgc3RhdGVkIHRoZSBwcm94eS10by1hc3NldC1zZXJ2ZXIgaXMgYnVpbHQgaW50bzxicj4K IMKgIMKgIMKgIMKgdGhlIHNpbTs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGhvd2V2 ZXIsIGtlZXAgaW4gbWluZCBwb3NzaWJsZSBsZWdhY3kgc3VwcG9ydCB3aGVyZTxicj4KIMKgIMKg IMKgIMKgdGhlIGFzc2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzZXJ2ZXIgbWF5 IHByb3h5IHRoZSBzaW11bGF0b3IuPGJyPgo8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgRHpvbmF0YXMgU29sIHdyb3RlOjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBTb21laG93IEkgZmVlbCB0aGUgYmFzaWMgYXNzZXQgc2VydmVyIGJlaW5nIGFi bGUgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBsb2dpbiBhbmQ8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoGRvd25sb2FkIGFzc2V0cyBpcyBub3cgcHJpb3JpdHksIHll dCBJIGFsc28gd29uZGVyZWQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGUgYmVzdDxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgd2F5IHRvIHBhdGNoIHRoaXMgaW50byB0 aGUgY3VycmVudCBtb2RlIG9mIHZpZXdlcnMuPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoE1heWJlIG9mZmVyICgxKSBieSBwcm94eSAoc2ltLXNpZGUpIGFuZCAoMikg YnkgcGF0Y2g8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCh2aWV3ZXItc2lk ZSkgdGhhdCBlaXRoZXIgb2YgdGhlc2UgdHdvIGFyZTxicj4KIMKgIMKgIMKgIMKgb3B0aW9uYWwg YW5kPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBuZWl0aGVyIGFyZSBtYW5k YXRvcnkgZm9yIG5vdy4gVGhvdWdodHM/PGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoElzcmFlbCBBbGFuaXMgd3JvdGU6PGJyPgo8YnI+Cjxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyB3aGVuIGRlc2lnbmluZyBmb3Igc2NhbGFi aWxpdHksIHRoZSBtb2RlbDxicj4KIMKgIMKgIMKgIMKgdG8gYmVhciBpbjxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbWluZCBpcyAuLi48YnI+Cjxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgV2VsbCwgdGhlcmUgYXJlIGEgbG90IG9m IGRpZmZlcmVudCBtb2RlbHMgdG88YnI+CiDCoCDCoCDCoCDCoGtlZXA8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCBpbiBtaW5kLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgYW5kIG1hbnkgZGlmZmVyZW50IHVzZSBjYXNlcy4gT25lIHBhcnRpY3VsYXIgdXNlPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgY2FzZSB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKga2VlcCBpbiBtaW5kIGlzOiAmcXVvdDtVc2VyIGFjcXVpcmVzIG5l dyBvdXRmaXQsIGFuZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdhbnRzIHRvPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmIzM5O3Nob3cgaXQgb2ZmJiMzOTsg aW4gYSBoaWdobHkgcG9wdWxhdGVkIHJlZ2lvbiZxdW90Oy48YnI+Cjxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyBCb3RoIHdvcmxkcyBhbmQgYXNzZXQgc2Vy dmljZXMgbWF5IGluY2x1ZGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjb21tZXJjaWFsLDxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgY29tbXVuaXR5LCBhbmQg cGVyc29uYWwgc2VydmljZXM8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgWWVzLCB5ZXMgYW5kIHllcy4gSSYjMzk7bSBwYXJ0aWN1bGFybHkgY29uY2VybmVk PGJyPgogwqAgwqAgwqAgwqBhYm91dDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGhvdyB0aGU8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG1vZGVsIGFmZmVjdHMg dGhlIGFiaWxpdHkgdG8gaG9zdCBwZXJzb25hbCBhc3NldDxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHNlcnZpY2VzLjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAmZ3Q7IGEgcHJveHlpbmcgcmVnaW9uLCB3aGljaCB3b3VsZCBnZXQgc2xhbW1lZDxicj4K IMKgIMKgIMKgIMKgZm9yIGV2ZXJ5PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBhc3NldCB3b3JuIGJ5IGV2ZXJ5IGF2YXRhciBwcmVzZW50Ljxicj4KPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBHcmFudGVkIHRoZSBjb2xsZWN0aW9u IG9mIHNlcnZpY2VzIHRoYXQgYXJlPGJyPgogwqAgwqAgwqAgwqBwcm92aWRlZCBieTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdGhlIHJlZ2lvbiBuZWVkIHRvIGJl IHNjYWxlZCB0byBtZWV0IHRoZTxicj4KIMKgIMKgIMKgIMKgZGVtYW5kcyBvZjxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHRoYXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoHJlZ2lvbi4gVGhhdCYjMzk7cyBhbGwgcGFydCBvZiBjYXBhY2l0eSBwbGFubmluZy48 YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyByZWdp b25zIHJ1biBtYW55IGRpZmZlcmVudCBDUFUtaW50ZW5zaXZlPGJyPgogwqAgwqAgwqAgwqB0YXNr cyw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGluY2x1ZGluZyBw aHlzaWNzIHNpbXVsYXRpb24gYW5kIHNlcnZlci1zaWRlPGJyPgogwqAgwqAgwqAgwqBzY3JpcHRp bmcsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhbmQgYWJzb2x1 dGVseSBjYW5ub3QgYWZmb3JkIHRvIHNlcnZlIGFzc2V0cyB0b288YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFdlbGwuLi4gd2hvIHNhaWQgdGhlIHNhbWUgQ1BVJiMz OTtzIGhhdmUgdG8gZG88YnI+CiDCoCDCoCDCoCDCoHByb3h5aW5nLDxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcGh5c2ljcyBzaW11bGF0aW9uIGFuZCBzZXJ2ZXIt c2lkZTxicj4KIMKgIMKgIMKgIMKgc2NyaXB0aW5nPyBBc3NldDxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcHJveHlpbmcgaXMgYSBkaWZmZXJlbnQgc2VydmljZSB0 aGFuIHBoeXNpY3M8YnI+CiDCoCDCoCDCoCDCoHNpbXVsYXRpb248YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGFuZCBjYW4gYmUgb24gc2VwYXJhdGUgaGFyZHdhcmUs IGNvdWxkIG1ha2U8YnI+CiDCoCDCoCDCoCDCoHVzZSBvZjxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgZ2VvZ3JhcGhpY2FsbHkgZGlzdHJpYnV0ZWQgY2FjaGluZywg YW5kIGluPGJyPgogwqAgwqAgwqAgwqBjZXJ0YWluPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqBkZXBsb3ltZW50IHBhdHRlcm5zLCB0aGUgc2FtZSBjYWNoaW5nPGJy PgogwqAgwqAgwqAgwqBzZXJ2aWNlcyBjb3VsZCBiZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgc2hhcmVkIGJ5IGRpZmZlcmVudCByZWdpb25zLiAoU2VydmVyLXNp ZGU8YnI+CiDCoCDCoCDCoCDCoHNjcmlwdGluZzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlz IGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGRpc2N1c3Npb24g Zm9yIGFub3RoZXIgZGF5KS48YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgJmd0OyBUaGlzIGlzIHdoeSB3ZSBoYXZlIHRvIGdvIHBhcmFsbGVsLi4uPGJyPgo8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFRvdGFsbHkgYWdyZWUs IGFuZCBhIHByb3h5aW5nIG1vZGVsIGNvdWxkIGFuZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHNob3VsZCBhbHNvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0 YWtlIGFkdmFudGFnZSBvZiBwYXJhbGxlbGlzbS48YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyBJIHRoaW5rIHlvdSYjMzk7cmUgd3JvbmcgdGhhdCBp dCBoYXMgdG8gY29zdCBtdWNoPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgbW9uZXkuID92cz88 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZndDsgSXQgY29zdHMg bW9uZXkgdG8gaG9zdCBhIGhpZ2ggcGVyZm9ybWFuY2UgYW5kPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgc2NhbGFibGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oGFzc2V0IHNlcnZpY2UgYW5kIGEgaGlnaCBiYW5kd2lkdGggbmV0d29yayB0bzxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIGhhbmRsZSB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoHRyYWZmaWMuIO+/vUEgKmxvdCogb2YgbW9uZXkuPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBJIHRoaW5rIHdoYXQgeW91JiMzOTtyZSBzYXlp bmcgaXM6ICZxdW90O0l0IGNvc3RzIGE8YnI+CiDCoCDCoCDCoCDCoGxvdCBvZjxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIG1vbmV5IHRvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBidWlsZCBhIHNjYWxhYmxlIGFzc2V0IHNlcnZpY2UsIGJ1dCBpZjxicj4KIMKg IMKgIMKgIMKgYXNzZXRzIGFyZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNwcmVhZDxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdGhyb3VnaG91dCB0aGUgaW50 ZXJuZXQgdGhleSBkb24mIzM5O3QgaGF2ZSB0byBiZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHNjYWxhYmxlLiZxdW90Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgQnV0IHRoYXQmIzM5O3Mgbm90IHF1aXRlIHJpZ2h0LiBZb3UmIzM5O3JlIG9wZW5pbmc8YnI+ CiDCoCDCoCDCoCDCoHVwIGV2ZXJ5PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgYXNzZXQ8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNlcnZlciB0byB0aGUgVlcg ZXF1aXZhbGVudCBvZiBiZWluZzxicj4KIMKgIMKgIMKgIMKgc2xhc2hkb3R0ZWQsPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgc28gYXJlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqB5b3Ugc3VyZSB5b3UmIzM5O3JlIG5vdCBmb3JjaW5nICpldmVyeSogYXNzZXQ8 YnI+CiDCoCDCoCDCoCDCoHNlcnZpY2UgdG8gYmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoHNjYWxhYmxlIGFuZCBoYW5kbGUgYSBsb3Qgb2YgYmFuZHdpdGggYW5k PGJyPgogwqAgwqAgwqAgwqBuZXR3b3JrPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgdHJhZmZp Yz88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEl0JiMzOTtzIHRo ZSBleGFjdCBvcHBvc2l0ZSBvZiB5b3VyIGludGVudGlvbiw8YnI+CiDCoCDCoCDCoCDCoGJ1dCBJ IHRoaW5rPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGF0JiMz OTtzIHRoZSByZXN1bHQsIGFsbCB0aGUgc2FtZS48YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgVGhpcyBwYXJ0aWN1bGFyIGRlc2lnbiBkZWNpc2lvbiBoYXMg YSBiaWc8YnI+CiDCoCDCoCDCoCDCoGVmZmVjdCBvbiB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoGVjb25vbWljcyBvZiB0aGUgVlcgaW5mcmFzdHJ1Y3R1cmUu IEkmIzM5O2Q8YnI+CiDCoCDCoCDCoCDCoHJhdGhlciB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoGVjb25vbWljcyB0byB3b3JrIG91dCBzdWNoIHRoYXQgYSBy ZWdpb248YnI+CiDCoCDCoCDCoCDCoHByb3ZpZGVyIHdobzxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgd2lzaGVzIHRvIGJ1aWxkIGEgcmVnaW9uIHRoYXQgc3VwcG9y dHMgYSBzbWFsbDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHBvcHVsYXRpb24sPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBjYW4gZG8gc28gZWNvbm9taWNhbGx5 LiBBIHJlZ2lvbiB0aGF0IHdhbnRzPGJyPgogwqAgwqAgwqAgwqB0byBob3N0IGE8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCpsYXJnZSogcG9wdWxhdGlvbiBoYXMg dG8gYmVhciB0aGF0IGNvc3Qgb2Y8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwcm92aWRpbmcg dGhhdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2NhbGFibGUg YXNzZXQgc2VydmljZS48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oEkgd2FudCB0aGUgZWNvbm9taWNzIG9mIGhvc3RpbmcgYSBzbWFsbCBhc3NldDxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHNlcnZpY2UgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoGJlIGEgbm9uLWlzc3VlIChhcyB0byBiZXN0IHByb21vdGUgY3JlYXRpb24g YW5kPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBjcmVhdGl2aXR5 KS4gQ3JlYXRpbmcgYSBoaWdoIGJhciB0byBwcm92aWRlPGJyPgogwqAgwqAgwqAgwqBhc3NldDxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNlcnZpY2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqB3aWxsIG1lYW4gdGhhdCBzZXJ2aWNlIHdpbGwgY29zdCBtb25l eSBhbmQ8YnI+CiDCoCDCoCDCoCDCoHBlb3BsZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgc2hvdWxkbiYjMzk7dCBoYXZlIHRvIHBheSBtb25leSBqdXN0IHRvIGNy ZWF0ZTxicj4KIMKgIMKgIMKgIMKgb3Igb3duIFZXPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqBvYmplY3RzIChJJiMzOTttIHVzaW5nICYjMzk7b3duJiMzOTsgaGVy ZSB0byByZWZlciB0bzxicj4KIMKgIMKgIMKgIMKgbWFpbnRhaW5pbmc8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRoZWlyIGV4aXN0ZW5jZSwgSSYjMzk7bSBub3Qg dHJ5aW5nIHRvIG1ha2UgYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgJiMzOTtsZWZ0aXN0JiMzOTsvJiMzOTtjb21tdW5pc3QmIzM5OyBzdGF0ZW1lbnQgYWJvdXQ8 YnI+CiDCoCDCoCDCoCDCoG93bmVyc2hpcCA7KTxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAtIEl6enk8YnI+Cjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBPbiBBcHIgMiwgMjAxMSwgYXQgMzo1OCBQTSwgTW9yZ2Fp bmUgd3JvdGU6PGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoEl6enksIHdoZW4gZGVzaWduaW5nIGZvciBzY2FsYWJpbGl0eSw8YnI+CiDCoCDCoCDC oCDCoHRoZSBtb2RlbCB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgYmVhciBpbiBtaW5kIGlzIHRoYXQgb2Ygc2Vhc29uZWQgdmlydHVhbDxicj4KIMKg IMKgIMKgIMKgd29ybGQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoHRyYXZlbGVycyB3aG9zZSBpbnZlbnRvcmllcyBjb250YWluPGJyPgogwqAgwqAgwqAg wqBhc3NldHMgZnJvbTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG1hbnk8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGRpZmZlcmVudCB3b3JsZHMsIHRo b3NlIGFzc2V0cyBiZWluZzxicj4KIMKgIMKgIMKgIMKgc2VydmVkIGJ5IG1hbnk8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGRpZmZlcmVudCBhc3NldCBz ZXJ2aWNlcy4g77+9Qm90aCB3b3JsZHM8YnI+CiDCoCDCoCDCoCDCoGFuZCBhc3NldDxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2VydmljZXMgbWF5IGlu Y2x1ZGUgY29tbWVyY2lhbCw8YnI+CiDCoCDCoCDCoCDCoGNvbW11bml0eSwgYW5kPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBwZXJzb25hbCBzZXJ2aWNl cywgYW5kIGFzIHRoZSBtZXRhdmVyc2U8YnI+CiDCoCDCoCDCoCDCoGdyb3dzLCB0aGF0PGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzZXQgaXMgaGlnaGx5 IGxpa2VseSB0byBiZWNvbWU8YnI+CiDCoCDCoCDCoCDCoHByb2dyZXNzaXZlbHkgbGVzczxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgY2x1c3RlcmVkIGFu ZCBtb3JlIGRpdmVyc2UuPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoFdoZW4gdGhvc2Ugc2Vhc29uZWQgdHJhdmVsZXJzIGNsaWNrIG9uIGFuPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgYWR2ZXJ0aXNlZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgVlcgbGluayBhbmQgcGVyZm9ybSBhbiBpbnRlci13 b3JsZDxicj4KIMKgIMKgIMKgIMKgdGVsZXBvcnQgdG8gb25lPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBwYXJ0aWN1bGFyIHdvcmxkJiMzOTtzIHJlZ2lv biB0byBzaGFyZSBhbjxicj4KIMKgIMKgIMKgIMKgZXhwZXJpZW5jZSw8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRoZWlyICZxdW90O3dvcm4mcXVvdDsg YXNzZXRzICh0aGUgb25seSBvbmVzIG9mPGJyPgogwqAgwqAgwqAgwqBpbnRlcmVzdDxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHRvIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgcmVnaW9uKSB3aWxsIGNvbnRhaW4gcmVmZXJlbmNlcyB0byBhc3Nl dDxicj4KIMKgIMKgIMKgIMKgc2VydmljZXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHNwcmVhZCB3aWRlbHkgYWNyb3NzIHRoZSBJbnRlcm5ldC4g77+9 VGhlPGJyPgogwqAgwqAgwqAgwqBmZXRjaGVzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgYnkg dGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0cmF2 ZWxlcnMmIzM5OyBjbGllbnRzIG9jY3VyIG92ZXIgbWFueSBwYXJhbGxlbDxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHBhdGhzIGZyb208YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoGNsaWVudHMgdG8gYXNzZXQgc2VydmljZXMsIHNvIG9uZSBjYW48YnI+ CiDCoCDCoCDCoCDCoHJlYXNvbmFibHk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoGV4cGVjdCByZWR1Y2VkIG5ldHdvcmsgY29udGVudGlvbiBhbmQ8YnI+ CiDCoCDCoCDCoCDCoHJlZHVjZWQgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHNlcnZlciBsb2FkaW5nIGJlY2F1c2UgdGhleSBhcmUgYm90aDxi cj4KIMKgIMKgIMKgIMKgc3ByZWFkIG91dDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG92ZXI8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGhvd2V2ZXIg bWFueSBhc3NldCBzZXJ2aWNlcyBhcmUgYmVpbmc8YnI+CiDCoCDCoCDCoCDCoHJlZmVyZW5jZWQg Ynk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRoZSBv dmVyYWxsIHNldCBvZiBhc3NldHMgaW4gdGhlIHJlZ2lvbi48YnI+Cjxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgVGhpcyBpcyB2ZXJ5IGRpZmZlcmVudCB0 byB0aGUgY2FzZSBvZiBhPGJyPgogwqAgwqAgwqAgwqBwcm94eWluZzxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcmVnaW9uLCB3aGljaCB3b3VsZCBnZXQg c2xhbW1lZCBmb3I8YnI+CiDCoCDCoCDCoCDCoGV2ZXJ5IGFzc2V0PGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgd29ybjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgYnkgZXZlcnkgYXZhdGFyIHByZXNlbnQuIO+/vUluIG91ciBjdXJyZW50PGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgYXJjaGl0ZWN0dXJlLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcmVnaW9ucyBydW4gbWFueSBkaWZmZXJlbnQgQ1BVLWlu dGVuc2l2ZTxicj4KIMKgIMKgIMKgIMKgdGFza3MsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpbmNsdWRpbmcgcGh5c2ljcyBzaW11bGF0aW9uIGFuZCBz ZXJ2ZXItc2lkZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgc2NyaXB0aW5nLCBhbmQgYWJzb2x1dGVseSBjYW5ub3QgYWZmb3JkPGJyPgogwqAgwqAgwqAg wqB0byBzZXJ2ZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgYXNzZXRzIHRvbyB1bmxlc3MgeW91ciBzY2FsYWJpbGl0eTxicj4KIMKgIMKgIMKgIMKgcmVx dWlyZW1lbnRzIGFyZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgdmVyeSBsb3cgaW5kZWVkLCBpZS4ganVzdCBhIGZldyBkb3plbjxicj4KIMKgIMKgIMKg IMKgYXZhdGFycyBvZjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgdG9kYXkmIzM5O3Mga2luZC4g77+9V2UmIzM5O3ZlIGhpdCB0aGUgY2VpbGluZzxicj4K IMKgIMKgIMKgIMKgYWxyZWFkeSBvbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlZ2lvbjxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2NhbGFiaWxp dHkgZG9uZSB0aGF0IHdheS4g77+9VGhlcmUgaXM8YnI+CiDCoCDCoCDCoCDCoG5vd2hlcmUgdG88 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBnbyBpbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdGhhdCBkaXJlY3Rpb24gYXQgYWxsIGJleW9uZCBpbXBy b3Zpbmc8YnI+CiDCoCDCoCDCoCDCoHRoZSBjb2RlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg bGlrZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgSW50 ZWwgZGVtb25zdHJhdGVkLCBhbmQgdGhhdCB3b3JrIGlzPGJyPgogwqAgwqAgwqAgwqBzdWJqZWN0 IHRvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgYSBsYXc8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG9mIGRpbWluaXNoaW5nIHJldHVybnMuPGJyPgo8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFRoaXMgaXMg d2h5IHdlIGhhdmUgdG8gZ28gcGFyYWxsZWwsIGFuZDxicj4KIMKgIMKgIMKgIMKgSSB0aGluazxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHlvdSYjMzk7cmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHdyb25nIHRoYXQgaXQgaGFzIHRvIGNvc3QgbXVj aCBtb25leS48YnI+CiDCoCDCoCDCoCDCoO+/vUFzIHdlIHNwcmVhZDxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdGhlIGxvYWQgYWNyb3NzIG1vcmUgYW5k IG1vcmUgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoHNlcnZpY2VzLDxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHdlIGFyZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgc2ltcGx5IGJldHRlciB1dGlsaXppbmcgYWxsIHRoZSBoYXJkd2FyZTxicj4KIMKgIMKg IMKgIMKgdGhhdCYjMzk7czxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgYWxyZWFkeSBvdXQgdGhlcmUgb24gdGhlIEludGVybmV0LCBhdDxicj4KIMKgIMKg IMKgIMKgbGVhc3QgaW48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZXNwZWN0PGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBvZiBjb21tdW5pdHkgYW5k IHByaXZhdGUgcmVzb3VyY2VzLiDvv71CdXQ8YnI+CiDCoCDCoCDCoCDCoGFkZCB0byB0aGU8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNvbW11bml0eSBh bmQgcHJpdmF0ZSByZXNvdXJjZXMgdGhlPGJyPgogwqAgwqAgwqAgwqBjb21tZXJjaWFsPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHNlcnZpY2VzIHRoYXQgYXJlIGxpa2VseSB0byBhcHBlYXIgdG88 YnI+CiDCoCDCoCDCoCDCoGV4cGxvaXQgdGhpczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgb3Bwb3J0dW5pdHksIGFuZCBub3Qgb25seSB3aWxsIHRoZTxi cj4KIMKgIMKgIMKgIMKgbnVtYmVyIG9mIGFzc2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzZXJ2aWNlcyBsZWFwLCBidXQgdGhlIHBvd2VyIG9mIGVh Y2ggb25lPGJyPgogwqAgwqAgwqAgwqB3aWxsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgcm9j a2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0b28s IGJlY2F1c2UsIGFmdGVyIGFsbCwgdGhlc2U8YnI+CiDCoCDCoCDCoCDCoGJ1c2luZXNzZXMgd2ls bCBiZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaGVh dmlseSBvcHRpbWl6ZWQgZm9yIHRoZSBqb2IuPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEFzIHRvIHdoeSBhIHdvcmxkIHdvdWxkIHdhbnQgY2xp ZW50cyB0bzxicj4KIMKgIMKgIMKgIMKgYWNjZXNzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBleHRlcm5hbCBhc3NldCBzZXJ2aWNlcyBpbnN0ZWFkIG9m IHByb3ZpZGluZzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGl0cyBvd248YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGltcGxlbWVudGF0aW9uLCB0aGF0 JiMzOTtzIGFuIGVhc3kgcXVlc3Rpb24uPGJyPgogwqAgwqAgwqAgwqDvv71JdCBjb3N0czxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbW9uZXkgdG8gaG9z dCBhIGhpZ2ggcGVyZm9ybWFuY2UgYW5kPGJyPgogwqAgwqAgwqAgwqBzY2FsYWJsZSBhc3NldDxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2VydmljZSBh bmQgYSBoaWdoIGJhbmR3aWR0aCBuZXR3b3JrIHRvPGJyPgogwqAgwqAgwqAgwqBoYW5kbGUgdGhl PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0cmFmZmlj LiDvv71BICpsb3QqIG9mIG1vbmV5LiDvv71JbiBjb250cmFzdCwgaXQ8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCBjb3N0cyBhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqB3b3JsZCBub3RoaW5nIHRvIGxldCBvdGhlcnMgc2VydmUgdGhlPGJyPgogwqAg wqAgwqAgwqBhc3NldHMgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoGNsaWVudHMuIO+/vUFuZCB0aGF0IG1hdHRlcnMgdG8gdGhlIGJvdHRvbTxicj4K IMKgIMKgIMKgIMKgbGluZS48YnI+Cjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBNb3JnYWluZS48YnI+Cjxicj4KPGJyPgo8YnI+Cjxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgPT09PT09PT09PT09PT09 PT09PT09PTxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqBPbiBTYXQsIEFwciAyLCAyMDExIGF0IDc6MDUgUE0sIEl6enkgQWxhbmlzPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7PGEgaHJlZj0ibWFp bHRvOml6enlhbGFuaXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+aXp6eWFsYW5pc0BnbWFp bC5jb208L2E+PGJyPgogwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzppenp5 YWxhbmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPml6enlhbGFuaXNAZ21haWwuY29tPC9h PiZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0 bzppenp5YWxhbmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPml6enlhbGFuaXNAZ21haWwu Y29tPC9hPjxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86aXp6eWFs YW5pc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5penp5YWxhbmlzQGdtYWlsLmNvbTwvYT4m Z3Q7Jmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzppenp5YWxhbmlzQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPml6enlhbGFuaXNAZ21haWwuY29tPC9hPjxicj4KIMKgIMKgIMKgIMKg Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86aXp6eWFsYW5pc0BnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5penp5YWxhbmlzQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86aXp6eWFsYW5pc0BnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5penp5YWxhbmlzQGdtYWlsLmNvbTwvYT48YnI+CiDCoCDCoCDCoCDCoCZs dDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOml6enlhbGFuaXNAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+aXp6eWFsYW5pc0BnbWFpbC5jb208L2E+Jmd0OyZndDsmZ3Q7PGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzppenp5YWxhbmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPml6enlhbGFuaXNAZ21h aWwuY29tPC9hPjxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86aXp6 eWFsYW5pc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5penp5YWxhbmlzQGdtYWlsLmNvbTwv YT4mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86aXp6eWFsYW5pc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5penp5YWxhbmlzQGdtYWls LmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86aXp6eWFsYW5pc0BnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5penp5YWxhbmlzQGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0Ozxicj4KPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzppenp5YWxhbmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPml6 enlhbGFuaXNAZ21haWwuY29tPC9hPjxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVm PSJtYWlsdG86aXp6eWFsYW5pc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5penp5YWxhbmlz QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86aXp6eWFsYW5pc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5penp5 YWxhbmlzQGdtYWlsLmNvbTwvYT48YnI+CiDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOml6enlhbGFuaXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+aXp6eWFsYW5pc0Bn bWFpbC5jb208L2E+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd3JvdGU6PGJyPgo8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IEFzIGFsd2F5 cyB0aG91Z2gsIGl0JiMzOTtzIGEgdHJhZGUtb2ZmLDxicj4KIMKgIMKgIMKgIMKgc2luY2UgdGhl PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBwcm94aWVk IGRlc2lnbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vWhhcyB2ZXJ5IHBvb3Igc2NhbGFiaWxpdHkgY29tcGFyZWQgdG8gdGhlPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkaXN0cmlidXRlZCBvbmUu PGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv71JIGRvbiYjMzk7dCBhZ3JlZSB3aXRoIHRoYXQuLi4gSWYgYSB1c2VyPGJyPgogwqAgwqAg wqAgwqBlbnRlcnMgYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgaGlnaGx5IHBvcHVsYXRlZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKg77+9IO+/vXJlZ2lvbiw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71ldmVyeSBvdGhlciBjbGllbnQgaXMgZ29pbmcg dG8gKGNvdWxkIGFuZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNob3VsZCBiZTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdHJ5aW5nIHRvKTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWhpdCB0 aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDv v71hc3NldCBzZXJ2ZXIocykgZm9yIHRoZSBhc3NldHMgdGhhdDxicj4KIMKgIMKgIMKgIMKgdGhl IHVzZXIgaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oHdlYXJpbmcgKGFzc3VtaW5nPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqDvv70g77+9dGhleSYjMzk7cmUgbm90IGNhY2hlZCBsb2NhbGx5KS4g77+9RXZl cnk8YnI+CiDCoCDCoCDCoCDCoGFzc2V0IHNlcnZlcjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaGFzIHRvIGJlIHNjYWxlZCB1cDxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXRvIHRoZSBwb2ludCB0 aGF0IGl0IGNhbiBoYW5kbGUgdGhhdCBsb2FkPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgZnJv bSBhbGw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG92 ZXIuLi48YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKg77+9IO+/vUlmIEkmIzM5O20gaG9zdGluZyBhIHJlZ2lvbiB0aGF0IHN1cHBvcnRzPGJyPgog wqAgwqAgwqAgwqAxMHMgb2Y8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHRob3VzYW5kcyBvZjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKg77+9IO+/vXNpbXVsdGFuZW91czxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXVzZXJzICh0aGlua2luZyBvZiB0aGUg ZnV0dXJlKSwgSSBhbHJlYWR5PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgaGF2ZSB0bzxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2NhbGUgdG8gbWVl dCB0aGF0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDv v70g77+9ZGVtYW5kLiBJZiB0aGUgcmVnaW9uIGlzIHByb3h5aW5nIHRoZTxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGFzc2V0cywgdGhlbiw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHllcyB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71yZWdpb24gaGFzPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dG8gYmUgc2NhbGVkIHRvIG1lZXQg dGhhdCBhc3NldDxicj4KIMKgIMKgIMKgIMKgZGVtYW5kIHRvbyw8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCBidXQgaXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoGFscmVhZHkgaGFzIHRvIGJlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c2NhbGVkIHRvIG1lZXQgb3RoZXIgZGVtYW5kcyBvZiBi ZWluZzxicj4KIMKgIMKgIMKgIMKgYSByZWdpb248YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNlcnZlci4uLiBhbmQgd2h5IGlzPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c2NhbGluZyB0aG9zZSBh c3NldCBwcm94eSBzZXJ2aWNlczxicj4KIMKgIMKgIMKgIMKgaGFyZD8g77+9SXQmIzM5O3M8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGdvaW5nIHRvIGNv c3QgJCw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv71idXQgaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv71ub3QgdGVjaG5pY2FsbHkgY2hhbGxlbmdpbmcuIFNvLCBpZiBJPGJyPgogwqAg wqAgwqAgwqB3YW50PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgdG8gaG9zdDxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYSByZWdpb24gbGlrZTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXRoYXQu Li4gc3VyZSBpdCB3aWxsIGNvc3QgbWUsIGJ1dCB0aGU8YnI+CiDCoCDCoCDCoCDCoHNpbXVsYXRp b248YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHdpbGwg YmUgY29uc2lzdGVudDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vWFuZCB1c2VycyB3aWxsIGJlIGFibGUgdG8gcGFydGljaXBhdGU8YnI+CiDC oCDCoCDCoCDCoGVxdWFsbHksPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqByZWdhcmRsZXNzIG9mIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWNhcGFiaWxpdGllcyBvZiB0aGVpciBpbmRpdmlk dWFsPGJyPgogwqAgwqAgwqAgwqBhc3NldCBzZXJ2aWNlcy48YnI+Cjxicj4KPGJyPgo8YnI+Cjxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vU9u IEZyaSwgQXByIDEsIDIwMTEgYXQgMTE6NTUgUE0sIE1vcmdhaW5lPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmx0OzxhIGhyZWY9Im1haWx0 bzptb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tb3JnYWlu ZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb208L2E+PGJyPgogwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxh IGhyZWY9Im1haWx0bzptb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5tb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb208L2E+Jmd0Ozxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vcmdhaW5lLmRpbm92YUBn b29nbGVtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vcmdhaW5lLmRpbm92YUBnb29nbGVtYWls LmNvbTwvYT48YnI+CiDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vcmdh aW5lLmRpbm92YUBnb29nbGVtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vcmdhaW5lLmRpbm92 YUBnb29nbGVtYWlsLmNvbTwvYT4mZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9yZ2FpbmUu ZGlub3ZhQGdvb2dsZW1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9yZ2FpbmUuZGlub3ZhQGdv b2dsZW1haWwuY29tPC9hPjxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9yZ2Fp bmUuZGlub3ZhQGdvb2dsZW1haWwuY29tPC9hPiZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5tb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb208L2E+PGJy PgogwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb3JnYWluZS5kaW5vdmFA Z29vZ2xlbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFp bC5jb208L2E+Jmd0OyZndDsmZ3Q7PGJyPjwvZGl2PjwvZGl2PgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv708YnI+CiDCoCDCoCDCoCDCoO+/vSZsdDttYWls dG86PGEgaHJlZj0ibWFpbHRvOm1vcmdhaW5lLmRpbm92YUBnb29nbGVtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPm1vcmdhaW5lLmRpbm92YUBnb29nbGVtYWlsLmNvbTwvYT48ZGl2PjxkaXY+PC9k aXY+PGRpdiBjbGFzcz0iaDUiPjxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9y Z2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tPC9hPiZndDs8YnI+Cjxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vcmdhaW5lLmRpbm92YUBnb29n bGVtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vcmdhaW5lLmRpbm92YUBnb29nbGVtYWlsLmNv bTwvYT48YnI+CiDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vcmdhaW5l LmRpbm92YUBnb29nbGVtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vcmdhaW5lLmRpbm92YUBn b29nbGVtYWlsLmNvbTwvYT4mZ3Q7Jmd0Ozxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb3JnYWlu ZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tb3JnYWluZS5kaW5vdmFA Z29vZ2xlbWFpbC5jb208L2E+PGJyPgogwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzptb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tb3Jn YWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb208L2E+Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vcmdhaW5lLmRpbm92YUBnb29nbGVtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vcmdhaW5lLmRpbm92YUBnb29nbGVtYWlsLmNvbTwvYT48 YnI+CiDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vcmdhaW5lLmRpbm92 YUBnb29nbGVtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vcmdhaW5lLmRpbm92YUBnb29nbGVt YWlsLmNvbTwvYT4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3cm90ZTo8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IEV2ZXJ5IGRlc2lnbiBj aG9pY2UgcmVzdWx0cyBpbiBhPGJyPgogwqAgwqAgwqAgwqB0cmFkZS1vZmYsPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBWYXVnaG4sIGltcHJvdmluZzxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vW9u ZSB0aGluZyBhdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKg77+9IO+/vSZndDsgdGhlIGV4cGVuc2Ugb2Ygc29tZXRoaW5nIGVsc2UuIO+/vUlmPGJyPgog wqAgwqAgwqAgwqBldmVyeTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRpbWUgd2U8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG9mZmVyZWQgYTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXNlcnZp Y2Ugd2UgaGFkIHRvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Jmd0OyBpbmZvcm0gaXRzIHVzZXJzIGFib3V0IHRoZSBkb3duc2lkZXMgb2Y8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhbGwgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0cmFkZS1vZmZzIHdlPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9aGF2ZSBtYWRlLDxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgdGhl eSB3b3VsZCBoYXZlIGFuIGF3ZnVsIGxvdCB0bzxicj4KIMKgIMKgIMKgIMKgcmVhZC4gOy0pPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0 Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vSZndDsgVGhlIHNwZWNpZmljIHRyYWRlLW9mZiB0aGF0IHlvdSBhcmU8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCBkaXNjdXNzaW5nIGlzIG5vPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9ZGlmZmVyZW50LiDvv71BIHJlZ2lvbjxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgdGhh dCBwcm94aWVzIGFsbCBjb250ZW50IGhhcyB0aGU8YnI+CiDCoCDCoCDCoCDCoCZxdW90O2JlbmVm aXQmcXVvdDsgb2Y8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoGFjcXVpcmluZyBjb250cm9sPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqDvv70g77+9ZnJvbSB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGFzc2V0IHNlcnZlcnMgb3ZlciB0aGUg aXRlbXMgaW4gdGhlPGJyPgogwqAgwqAgwqAgwqByZWdpb24sIHNvPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGF0IGl0IGNhbjxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWVuc3VyZSB0aGF0PGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0 OyBldmVyeW9uZSBpbiB0aGUgcmVnaW9uIG5vdCBvbmx5IG9idGFpbnM8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCB0aGUgaXRlbXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoGJ1dCBvYnRhaW5zPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dGhlIHNhbWUgaXRlbXM8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGFzIGV2ZXJ5b25lIGVs c2UuIO+/vVRoYXQgZG9lcyBpbmRlZWQ8YnI+CiDCoCDCoCDCoCDCoHByb3ZpZGUgYTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZ3JlYXRlciBndWFyYW50 ZWUgb2Y8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv70mZ3Q7IGNvbnNpc3RlbmN5IHRoYW4gYSBkZXBsb3ltZW50IGluPGJyPgogwqAgwqAgwqAg wqB3aGljaCB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZWdpb248YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG9ubHkgcGFzc2VzPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9YXNzZXQgVVJJ cyB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vSZndDsgY2xpZW50cyB3aG8gdGhlbiBmZXRjaCB0aGUgaXRlbXMgZnJvbTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIGFzc2V0IHNlcnZpY2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c2VwYXJhdGVseS4g77+9QXMgYWx3YXlzPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0 OyB0aG91Z2gsIGl0JiMzOTtzIGEgdHJhZGUtb2ZmLCBzaW5jZSB0aGU8YnI+CiDCoCDCoCDCoCDC oHByb3hpZWQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oGRlc2lnbiBoYXMgdmVyeTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vXBvb3Igc2NhbGFiaWxpdHk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGNvbXBhcmVkIHRvIHRoZSBkaXN0 cmlidXRlZCBvbmUuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vSZndDsgSWYgd2UmIzM5O3JlIGdvaW5nIHRvIHdhcm4gdXNlcnMgb2Yg dGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgcG90ZW50aWFsIGZvcjxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaW5jb25zaXN0ZW5jeTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWluIHRoZTxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZn dDsgZGlzdHJpYnV0ZWQgZGVwbG95bWVudCBhcyB5b3U8YnI+CiDCoCDCoCDCoCDCoHN1Z2dlc3Qs IGFyZSB3ZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg YWxzbyBnb2luZyB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vXdhcm4gdGhlbSBvZjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgbm9uLXNjYWxhYmlsaXR5IGluIHRoZSBwcm94 aWVkIG9uZT88YnI+CiDCoCDCoCDCoCDCoO+/vUkgcmVhbGx5PGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkb24mIzM5O3Qgc2VlIG11Y2g8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71tZXJpdCBpbiB0 aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDv v70mZ3Q7IGlkZWEgb2Ygd2FybmluZyBhYm91dCBkZXNpZ24gY2hvaWNlcy48YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDvv71NYW55IHN1Y2g8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoGNob2ljZXMgYXJlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dGVjaG5pY2FsLCBhbmQ8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IHRoZSBpc3N1 ZXMgYXJlIHF1aXRlIGxpa2VseSB0byBiZTxicj4KIMKgIMKgIMKgIMKgb2YgbGl0dGxlPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpbnRlcmVzdCB0bzxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vW5v bi10ZWNobmljYWwgdXNlcnM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGFueXdheS4g77+9SW4gYW55IGNhc2UsIHRoZSBiZXR0ZXI8 YnI+CiDCoCDCoCDCoCDCoHNlcnZpY2VzIGFyZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgbGlrZWx5IHRvIHByb3ZpZGU8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71zdWNoPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBpbmZvcm1hdGlv biBpbiB0aGVpciBvbmxpbmU8YnI+CiDCoCDCoCDCoCDCoGRvY3VtZW50YXRpb24sIEk8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHdvdWxkIGd1ZXNzLjxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZn dDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDv v70mZ3Q7IFlvdSBtZW50aW9uZWQgdXNlcnMgJnF1b3Q7dm90aW5nIHdpdGggdGhlaXI8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCBmZWV0JnF1b3Q7IG9yPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBjaG9vc2luZyB0bzxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWFjY2VwdCB0aGUgcmlzazxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsg b2YgaW5jb25zaXN0ZW5jeS4g77+9V2VsbCB0aGF0IHdpbGw8YnI+CiDCoCDCoCDCoCDCoGhhcHBl bjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFueXdheSw8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHdoZW4gc2VydmljZXM8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71mYWlsIGFuZDxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgdXNl cnMgZ2V0IGFubm95ZWQuIO+/vUlmIHNvbWUgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoHNlcnZpY2Vz PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVmdXNlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0byBzZW5kIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXJlcXVlc3RlZDxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgaXRlbXMg dG8gc29tZSB1c2VycywgdGhvc2Ugc2VydmljZXM8YnI+CiDCoCDCoCDCoCDCoHdpbGwgZ2V0IGE8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJhZCByZXB1 dGF0aW9uPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDv v70g77+9YW5kIHBlb3BsZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vSZndDsgd2lsbCBjaG9vc2UgZGlmZmVyZW50IGFzc2V0PGJyPgogwqAg wqAgwqAgwqBzZXJ2aWNlcyBpbnN0ZWFkLjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9TGlrZXdpc2UsIGlmIGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv713b3JsZCBzZXJ2aWNlPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBwcm94 aWVzIGV2ZXJ5dGhpbmcgYW5kIHNvIGl0IGNhbiYjMzk7dDxicj4KIMKgIMKgIMKgIMKgaGFuZGxl PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgYSBsYXJnZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbnVtYmVyIG9mPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9YXNzZXRzIG9yIG9mPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBwZW9w bGUsIHVzZXJzIHdpbGwgZ2V0IGFubm95ZWQgYXQ8YnI+CiDCoCDCoCDCoCDCoHRoZSBsYWc8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhbmQgd2lsbCBnbzxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWVsc2V3aGVyZS4g77+9VGhpcyB1c2Vy PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 Jmd0OyBldmFsdWF0aW9uIGFuZCAmcXVvdDt2b3Rpbmcgd2l0aCB0aGVpciBmZWV0JnF1b3Q7PGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgaGFwcGVuczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYWxyZWFkeSB3aXRoPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9b25saW5lIHNlcnZpY2VzPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBh bGwgb3ZlciB0aGUgSW50ZXJuZXQsIGFuZCBJIGFtPGJyPgogwqAgwqAgwqAgwqBzdXJlIHRoYXQg dGhpczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaHVt YW4gcHJvY2Vzczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKg77+9IO+/vXdpbGwgY29udGludWU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IHRvIHdvcmsgd2hlbiB0aGUgc2VydmljZXMgYXJl IGFzc2V0PGJyPgogwqAgwqAgwqAgwqBhbmQgcmVnaW9uPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzZXJ2aWNlcy48YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBCYWNrIGluIFNlcHRl bWJlciAyMDEwLCBJIHdyb3RlPGJyPgogwqAgwqAgwqAgwqB0aGlzIHBvc3Q8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCB3aGljaDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgcHJvcG9zZXMgdGhhdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXdlIHVzZSBpbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgVldSQVAgYSBmb3JtIG9mIGFz c2V0IGFkZHJlc3Npbmc8YnI+CiDCoCDCoCDCoCDCoHRoYXQgcHJvdmlkZXM8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG1hc3NpdmU8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71zY2FsYWJpbGl0eSBh dCB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv70mZ3Q7IHNhbWUgdGltZSBhcyBhIHZlcnkgaGlnaCBkZWdyZWUgb2Y8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCByZXNpbGllbmNlIC0tPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv708YSBocmVmPSJodHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdndyYXAvY3VycmVudC9tc2cwMDQ2My5o dG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L3Z3cmFwL2N1cnJlbnQvbXNnMDA0NjMuaHRtbDwvYT48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70uIO+/vUl0IGlzPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBiYXNlZCBvbiB0 aGUgY29uY2VwdCBvZiB0aGUgVVJJPGJyPgogwqAgwqAgwqAgwqBjb250YWluaW5nPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgYSBob3N0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqBwYXJ0IGFuZCBhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9aGFzaCBwYXJ0LDxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgd2hlcmUgdGhlIGhhc2gg aXMgZ2VuZXJhdGVkIChvbmNlLDxicj4KIMKgIMKgIMKgIMKgYXQgdGhlPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgdGltZSBvZjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgc3RvcmFnZSB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKg77+9IO+/vXRoZSBhc3NldDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgc2VydmljZSkgdXNpbmcgYSBzcGVj aWZpZWQgZGlnZXN0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgYWxnb3JpdGhtIG92ZXI8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRoZSBjb250ZW50 IG9mPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9dGhlIGFzc2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Jmd0OyBiZWluZyByZWZlcmVuY2VkLiDvv71Zb3UgbWF5IHdpc2ggdG8gbm90 ZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoYXQgaWY8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRoaXMgZGVzaWduPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9d2VyZSB1c2VkLCB0aGU8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7 IGZhaWx1cmUgb2YgYW4gYXNzZXQgc2VydmljZSB0bzxicj4KIMKgIMKgIMKgIMKgZGVsaXZlciBh PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqByZXF1ZXN0 ZWQgaXRlbSB3b3VsZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vXJlc3VsdCBpbiBhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBmYWlsb3ZlciByZXF1ZXN0IGZvciB0aGUgaXRl bSB0bzxicj4KIMKgIMKgIMKgIMKgb25lIG9yIG1vcmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJhY2t1cCBzZXJ2aWNlcyw8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv711c2luZyB0aGUgc2FtZTxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZn dDsgaGFzaCBwYXJ0IGJ1dCB3aXRoIGEgZGlmZmVyZW50IGhvc3Q8YnI+CiDCoCDCoCDCoCDCoGFk ZHJlc3MuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDv v70g77+9Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKg77+9IO+/vSZndDsgVGhpcyBjYW4gZ28gc29tZSB3YXkgdG93YXJkczxicj4KIMKgIMKgIMKg IMKgb3ZlcmNvbWluZyB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHByb2JsZW0gdGhhdCB5b3U8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv710aGluayBtaWdodDxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgb2NjdXIgd2hlbiBhc3Nl dHMgYXJlIGZldGNoZWQgYnk8YnI+CiDCoCDCoCDCoCDCoGNsaWVudHMgZnJvbTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYXNzZXQgc2VydmljZXM8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71kaXJl Y3RseS48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv70mZ3Q7IEFsdGhvdWdoIGl0IHdvbiYjMzk7dCBoZWxwIHdoZW4gdGhlIG1pc3Npbmc8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpdGVtIGlzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhdmFpbGFibGUgZnJvbTxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vW9ubHkgYSBzaW5nbGU8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGFz c2V0IHNlcnZpY2UsIGl0IHdpbGwgaGVscCBpbiBtYW55PGJyPgogwqAgwqAgwqAgwqBvdGhlcjxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNhc2VzLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYW5kIGl0IHdpbGw8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71jb21wZW5zYXRlIGZvcjxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgc2Vy dmljZSBmYWlsdXJlcyBhbmQgbmV0d29yayBvdXRhZ2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhdXRvbWF0aWNhbGx5IGF0IHRoZSBzYW1lPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dGltZS48 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70m Z3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9Jmd0OyBQUy4gVGhpcyBkZXNpZ24gZm9yIGhhc2gtYmFzZWQgYXNzZXQ8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCBhZGRyZXNzaW5nPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqBpcyBhbHJlYWR5PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9YmVpbmcgdGVzdGVkIGJ5PGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBNb2ppdG8gU29y YmV0IGluIGhlciBleHBlcmltZW50YWw8YnI+CiDCoCDCoCDCoCDCoHdvcmxkIGFuZDxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgY2xpZW50LiDvv71JdCB3 b3VsZCBnaXZlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqDvv70g77+9Jmd0OyBWV1JBUC1iYXNlZCB3b3JsZHMgYW4gaW1wcm92ZWQgbGV2ZWwgb2Y8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzZXJ2aWNlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhdmFpbGFiaWxpdHksPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c28gSSB0aGluayBpdDxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgc2hv dWxkIGJlIGEgY29yZSBmZWF0dXJlIG9mIG91cjxicj4KIMKgIMKgIMKgIMKgcHJvdG9jb2wuPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0 Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv70mZ3Q7IE1vcmdhaW5lLjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7ID09PT09PT09PT09PT09PT09 PT09PT09PT09PTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoO+/vSDvv70mZ3Q7IE9uIEZyaSwgQXByIDEsIDIwMTEgYXQgMTE6MTcgUE0sPGJyPgog wqAgwqAgwqAgwqBWYXVnaG4gRGVsdWNhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmx0OzxhIGhyZWY9Im1haWx0bzp2YXVnaG4uZGVsdWNh QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZhdWdobi5kZWx1Y2FAZ21haWwuY29tPC9hPjxi cj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dmF1Z2huLmRlbHVjYUBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj52YXVnaG4uZGVsdWNhQGdtYWlsLmNvbTwvYT4mZ3Q7 PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dmF1 Z2huLmRlbHVjYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj52YXVnaG4uZGVsdWNhQGdtYWls LmNvbTwvYT48YnI+CiDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZhdWdo bi5kZWx1Y2FAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmF1Z2huLmRlbHVjYUBnbWFpbC5j b208L2E+Jmd0OyZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZhdWdobi5kZWx1Y2FAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+dmF1Z2huLmRlbHVjYUBnbWFpbC5jb208L2E+PGJyPgogwqAgwqAg wqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2YXVnaG4uZGVsdWNhQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnZhdWdobi5kZWx1Y2FAZ21haWwuY29tPC9hPiZndDs8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2YXVnaG4uZGVsdWNh QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZhdWdobi5kZWx1Y2FAZ21haWwuY29tPC9hPjxi cj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dmF1Z2huLmRlbHVjYUBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj52YXVnaG4uZGVsdWNhQGdtYWlsLmNvbTwvYT4mZ3Q7 Jmd0OyZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZhdWdobi5kZWx1Y2FAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+dmF1Z2huLmRlbHVjYUBnbWFpbC5jb208L2E+PGJyPgogwqAgwqAgwqAgwqAm bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2YXVnaG4uZGVsdWNhQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnZhdWdobi5kZWx1Y2FAZ21haWwuY29tPC9hPiZndDs8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2YXVnaG4uZGVsdWNhQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZhdWdobi5kZWx1Y2FAZ21haWwuY29tPC9hPjxicj4KIMKg IMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dmF1Z2huLmRlbHVjYUBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj52YXVnaG4uZGVsdWNhQGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0Ozxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86dmF1Z2huLmRlbHVjYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij52YXVnaG4uZGVsdWNhQGdtYWlsLmNvbTwvYT48YnI+CiDCoCDCoCDCoCDCoCZsdDttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOnZhdWdobi5kZWx1Y2FAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ dmF1Z2huLmRlbHVjYUBnbWFpbC5jb208L2E+Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZhdWdobi5kZWx1Y2FAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+dmF1Z2huLmRlbHVjYUBnbWFpbC5jb208L2E+PGJyPgogwqAgwqAgwqAgwqAm bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2YXVnaG4uZGVsdWNhQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnZhdWdobi5kZWx1Y2FAZ21haWwuY29tPC9hPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 Jmd0OyB3cm90ZTo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv70mZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IFRoaXMgaXMgYSBxdWVzdGlvbiBpIGRpc2N1c3Nl ZDxicj4KIMKgIMKgIMKgIMKgd2l0aCBNb3JnYWluZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgb2ZmLWxpc3QgYSB3aGlsZTxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWFnbyAoSTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IGlu dGVuZGVkIHRvIHNlbmQgaXQgdG8gdGhlIGxpc3QgYnV0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgcHVzaGVkIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgd3JvbmcgYnV0dG9uLi4uKSBJPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgdGhpbmsgd2UgbmVlZCB0byBhZGRyZXNz IHRoaXM8YnI+CiDCoCDCoCDCoCDCoHByb2JsZW0sIGFuZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZGVjaWRlIGhvdyB0byBkZWFsPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9d2l0aCBpdC48YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7 Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vSZndDsmZ3Q7IO+/vUluIERhdmlkcyBkZXBsb3ltZW50IGRyYWZ0LCBzZWN0aW9uPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgNy4zLjEuMSBhbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgb3ZlcnZpZXcgaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71naXZlbiB2YW48YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyB3YXlz IHRvIGRlbGl2ZXIgY29udGVudCB0byB0aGUgcmVnaW9uLjxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIE9uZSB3YXk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoGlzIG9ubHkgcGFzc2luZyBhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgY2FwYWJpbGl0eSB0aGF0IGFsbG93cyBhY2Nl c3MgdG8gKHBhcnQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvZikgdGhlPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqByZXNvdXJjZTo8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0Ozxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZn dDsmZ3Q7IO+/vSDvv70g77+9IO+/vSDvv70gNy4zLjEuMS4g77+9Q29udGVudDxicj4KIMKgIMKg IMKgIMKgZGVsaXZlcnkgbW9kZWxzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsg77+9IO+/vSDvv70g77+9IO+/vSBBIHJhbmdl IG9mIHBvc3NpYmxlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVwcmVzZW5hdGlvbnMgY2Fu PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBiZSBwYXNz ZWQgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv71hIHJlZ2lvbiBmb3I8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/vSDvv70g77+9IHNpbXVsYXRpb24u IFsuLi5dIFRoZTxicj4KIMKgIMKgIMKgIMKgb3RoZXIgZW5kPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgb2YgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqBkZWxpdmVyeSBzcGVjdHJ1bTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IGludm9sdmVzIHBhc3Npbmc8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDv v70g77+9IO+/vSDvv70g77+9IG9ubHkgYSBVUkkgb3IgY2FwYWJpbGl0eTxicj4KIMKgIMKgIMKg IMKgdXNlZCB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgYWNjZXNzIHRoZSByZW5kZXJpbmc8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBpbmZvcm1hdGlvbiBhbmQgYTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7 IO+/vSDvv70g77+9IO+/vSDvv70gY29sbGlzaW9uIG1lc2gsYW5kPGJyPgogwqAgwqAgwqAgwqBy ZWxhdGVkIGRhdGEgZm9yPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBwaHlzaWNhbCBzaW11bGF0aW9uLjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/vSDvv70g77+9IO+/vSDvv70g SW4gc3VjaCBhIG1vZGVsLCB0aGU8YnI+CiDCoCDCoCDCoCDCoGNsaWVudCBpczxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcmVzcG9uc2libGUgZm9yPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9ZmV0 Y2hpbmcgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqDvv70g77+9Jmd0OyZndDsgYWRkaXRpb25hbDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/vSDvv70g77+9IO+/vSDvv70g aW5mb3JtYXRpb24gbmVlZGVkIHRvPGJyPgogwqAgwqAgwqAgwqByZW5kZXIgdGhlPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpdGVtJiMzOTtzIHZpc3Vh bDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vXByZXNlbmNlIGZyb20gYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHNlcGFyYXRlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsg77+9IO+/vSDvv70g77+9 IO+/vSBzZXJ2aWNlLiDvv71UaGlzIGZldGNoIGNhbjxicj4KIMKgIMKgIMKgIMKgYmUgZG9uZTxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKnVuZGVyIHRo ZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vWNyZWRlbnRpYWxzIG9mIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IGVuZCB1c2VyKjxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/vSDvv70g77+9 IO+/vSDvv70gdmlld2luZyB0aGUgbWF0ZXJpYWwgW215PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgZW1waGFzaXMtLVZEXTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgLCBhbmQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoO+/vSDvv71kaXZvcmNlcyB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBzaW11bGF0aW9uIGZyb208YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0 OyDvv70g77+9IO+/vSDvv70g77+9IHRoZSB0cnVzdCBjaGFpbiBuZWVkZWQ8YnI+CiDCoCDCoCDC oCDCoHRvIG1hbmFnZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgY29udGVudC4g77+9QW55PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqDvv70g77+9YXV0b21hdGlvbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IGlzIGRvbmUgb24gYTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsm Z3Q7IO+/vSDvv70g77+9IO+/vSDvv70gc2VwYXJhdGUgaG9zdCB3aGljaCB0aGU8YnI+CiDCoCDC oCDCoCDCoGNvbnRlbnQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoGNyZWF0b3Igb3Igb3duZXIgdHJ1c3RzLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IGludGVyYWN0aW5nIHdpdGgg dGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9Jmd0OyZndDsg77+9IO+/vSDvv70g77+9IO+/vSBvYmplY3QgdGhyb3VnaCByZW1vdGVkPGJy PgogwqAgwqAgwqAgwqBpbnRlcmZhY2VzLjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsg77+9SSBjYW4gc2VlIHRo ZSBuZWVkIGZvciBzdWNoIGEgc2V0dXAsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgaG93ZXZl ciwgaTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZmVl bCB3ZSBhcmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv70mZ3Q7Jmd0OyB1bnBsZWFzYW50bHkgY2xvc2UgdG8gYSBzaXR1YXRpb248YnI+CiDC oCDCoCDCoCDCoHdlcmUgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBjb2hlcmVuY2Ugb2YgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c2ltdWxhdGlvbjxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IGZhbGxzIGFwYXJ0 Ljxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vSZndDsmZ3Q7IEluIHRoaXMgZGVwbG95bWVudCBwYXR0ZXJuIHRoZSByZWdpb248YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCBhZHZlcnRpc2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqB0aGUgcHJlc2VuY2U8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71vZiB0aGU8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBhc3NldCwgYW5k ICpzb21lKiBjbGllbnRzIHdpbGwgYmU8YnI+CiDCoCDCoCDCoCDCoGFibGUgdG88YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCBnZXQgaXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoGFzIGV4cGVjdGVkLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXdoaWxlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgLWJhc2VkIG9uIHRoZSBh cmJpdHJhcnkgd2hpbXMgb2Y8YnI+CiDCoCDCoCDCoCDCoHRoZSBhc3NldDxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2VydmljZS0gb3RoZXJzPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9bWlnaHQg bm90Ljxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vSZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Jmd0OyZndDsgTXkgaG9wZSB3b3VsZCBiZSB0aGF0IGFmdGVyIHRoZTxicj4K IMKgIMKgIMKgIMKgYXNzZXQgc2VydmVyPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqBwcm92aWRlcyB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71yZWdpb24gd2l0aDxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHRoZSBjYXBh YmlsaXR5IHRvIGdldCB0aGUgYXNzZXQsPGJyPgogwqAgwqAgwqAgwqBpdCBnaXZlcyB1cDxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgY29udHJvbC4gVGhh dDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vXdvdWxkIG1lYW48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv70mZ3Q7Jmd0OyB0aGF0IGlmIHRoZSBjbGllbnQgZmluZHMgdGhlIGludmVudG9y eTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNlcnZlciBpczxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdW53aWxsaW5nIHRvPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c2VydmU8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyB0 aGUgY29udGVudCAtIGluIHNwaXJlIG9mIHRoZSByZWdpb248YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCBzYXlpbmcgaXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoGlzIHByZXNlbnQtLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vXRoZSBjbGllbnQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBzaG91bGQgYmUgYWJsZSB0byB0 dXJuIGFyb3VuZCBhc2sgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgKnJlZ2lvbio8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGZvciB0aGUgYXNz ZXQsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9KGFuZCBnZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv70mZ3Q7Jmd0OyBpcyBhZnRlciBhbGwpLjxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7PGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsg77+9SWYg dGhhdCBpcyBub3QgdGhlIGNhc2UsIC1hbmQ8YnI+CiDCoCDCoCDCoCDCoHRoZXJlIGFyZTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcHJvYmFibHkgZ29v ZCByZWFzb25zPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqDvv70g77+9Zm9yIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IGRlcGxveW1lbnQgcGF0dGVybiBhcyBkZXNjcmliZWQt PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9c2hvdWxkbiYjMzk7dCB3ZTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKndhcm4qIGNsaWVudHM8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv710aGF0 IHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vSZndDsmZ3Q7IHJlZ2lvbiBtaWdodCBiZSBpbmNvbnNpc3RlbnQsIHNvPGJyPgogwqAgwqAg wqAgwqB0aGUgdXNlcnM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoGJlaGluZCB0aGUgY2xpZW50PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Y2FuIHZvdGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyB3aXRoIHRoZWlyIGZlZXQs IChvciB0YWtlIHRoZSByaXNrKT88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IC0tVmF1Z2huPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDs8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vSZndDsmZ3Q7IHZ3cmFwIG1haWxpbmcgbGlzdDxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IDxhIGhyZWY9 Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9h Pjxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7ICZsdDttYWlsdG86PGEg aHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5v cmc8L2E+PGJyPgogwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiZndDsmZ3Q7PGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9y ZzwvYT4mZ3Q7PGJyPgogwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3Jh cEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGll dGYub3JnPC9hPiZndDsmZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT48YnI+CiDCoCDCoCDCoCDCoCZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndy YXBAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPjxicj4KIMKgIMKgIMKgIMKg Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij52d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZs dDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ dndyYXBAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4KIMKgIMKgIMKg IMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj52d3JhcEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7Jmd0OyZndDsm Z3Q7PGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv70mZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92d3JhcCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdndyYXA8L2E+PGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv70mZ3Q7IHZ3cmFwIG1haWxpbmcgbGlzdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgPGEgaHJlZj0ibWFpbHRvOnZ3cmFw QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+PGJyPgogwqAgwqAg wqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiZndDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT48YnI+CiDC oCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+Jmd0OyZndDs8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2 d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiZndDs8YnI+ CiDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFp bHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+Jmd0 OyZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnZ3cmFwQGlldGYub3JnPC9hPjxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVm PSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwv YT4mZ3Q7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+PGJyPgogwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxh IGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYu b3JnPC9hPiZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9y ZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPgogwqAgwqAgwqAgwqAmbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGll dGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiZndDsmZ3Q7Jmd0OyZndDs8YnI+Cjxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8 YnI+CiDCoCDCoCDCoCDCoDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdndyYXAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Z3cmFwPC9hPjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgo8YnI+Cjxicj4KPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHZ3cmFwIG1haWxpbmcgbGlzdDxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgPGEgaHJlZj0ibWFpbHRvOnZ3 cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+ICZsdDttYWls dG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4gJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52 d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndy YXBAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4KIMKgIMKgIMKgIMKg Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij52d3JhcEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7Jmd0OyZndDs8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdndyYXAiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Z3cmFwPC9hPjxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9PGJyPgo8YnI+Cjxicj4KPGJyPgo8YnI+ Cjxicj48L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJpbSI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoC0tIMKgIMKgIC0tLSA8YSBocmVmPSJodHRwczovL3R3aXR0ZXIuY29tL0R6b25hdGFzX1Nv bCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdHdpdHRlci5jb20vRHpvbmF0YXNfU29sPC9hPiAt LS08YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFdlYiBEZXZlbG9wbWVudCwgU29mdHdh cmUgRW5naW5lZXJpbmcsIFZpcnR1YWwgUmVhbGl0eSw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCBDb25zdWx0YW50PGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqB2d3JhcCBtYWlsaW5nIGxpc3Q8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoDxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3 cmFwQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiZndDs8YnI+CiDCoCDCoCDCoCDC oCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+dndyYXBAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+Jmd0OyZndDs8YnI+PC9k aXY+PGRpdiBjbGFzcz0iaW0iPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9y ZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPgogwqAgwqAgwqAgwqAmbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGll dGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiZndDsmZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby92d3JhcCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdndyYXA8L2E+PGJyPgo8YnI+Cjxicj4KPGJyPgo8YnI+PC9kaXY+PGRpdiBj bGFzcz0iaW0iPgogwqAgwqAgwqAgwqAgwqAgLS0gwqAgwqAgLS0tIDxhIGhyZWY9Imh0dHBzOi8v dHdpdHRlci5jb20vRHpvbmF0YXNfU29sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90d2l0dGVy LmNvbS9Eem9uYXRhc19Tb2w8L2E+IC0tLTxicj4KIMKgIMKgIMKgIMKgIMKgIFdlYiBEZXZlbG9w bWVudCwgU29mdHdhcmUgRW5naW5lZXJpbmcsIFZpcnR1YWwgUmVhbGl0eSw8YnI+CiDCoCDCoCDC oCDCoENvbnN1bHRhbnQ8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgogwqAgwqAgwqAgwqAgwqAgdndyYXAg bWFpbGluZyBsaXN0PGJyPgogwqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEg aHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndy YXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4gJmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBp ZXRmLm9yZzwvYT4mZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdndyYXAiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Z3cmFwPC9hPjxicj4KPGJyPgo8YnI+ PC9kaXY+CiDCoCDCoCDCoCDCoC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxkaXYgY2xhc3M9ImltIj48YnI+Cjxi cj4KPGJyPgo8YnI+CiDCoCDCoCDCoCDCoF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPgogwqAgwqAgwqAgwqB2d3JhcCBtYWlsaW5nIGxpc3Q8YnI+CiDC oCDCoCDCoCDCoDxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnZ3cmFwQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiZndDs8YnI+CiDCoCDCoCDC oCDCoDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdndyYXAi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Z3 cmFwPC9hPjxicj4KIMKgIMKgIMKgIMKgIDxicj4KPGJyPgo8YnI+PC9kaXY+PGRpdiBjbGFzcz0i aW0iPgogwqAgwqAtLSDCoCDCoCAtLS0gPGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9Eem9u YXRhc19Tb2wiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3R3aXR0ZXIuY29tL0R6b25hdGFzX1Nv bDwvYT4gLS0tPGJyPgogwqAgwqBXZWIgRGV2ZWxvcG1lbnQsIFNvZnR3YXJlIEVuZ2luZWVyaW5n LCBWaXJ0dWFsIFJlYWxpdHksIENvbnN1bHRhbnQ8YnI+Cjxicj4KPGJyPgotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08YnI+Cjxicj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+CnZ3cmFwIG1haWxpbmcgbGlzdDxicj4KPGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+PGJyPgo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Z3cmFwIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92d3JhcDwvYT48YnI+CiDCoDxi cj4KPC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGRpdj48L2Rpdj48ZGl2IGNsYXNzPSJoNSI+Cjxi cj4KPGJyPgotLSA8YnI+Ci0tLSA8YSBocmVmPSJodHRwczovL3R3aXR0ZXIuY29tL0R6b25hdGFz X1NvbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdHdpdHRlci5jb20vRHpvbmF0YXNfU29sPC9h PiAtLS08YnI+CldlYiBEZXZlbG9wbWVudCwgU29mdHdhcmUgRW5naW5lZXJpbmcsIFZpcnR1YWwg UmVhbGl0eSwgQ29uc3VsdGFudDxicj4KPGJyPgo8L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9k aXY+PGJyPgo= --000e0cd25cae034e9204a008d947-- From dzonatas@gmail.com Sun Apr 3 13:06:30 2011 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 682AA3A67E6 for ; Sun, 3 Apr 2011 13:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.214 X-Spam-Level: X-Spam-Status: No, score=-3.214 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] 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 DaOPnxwnp0YG for ; Sun, 3 Apr 2011 13:06:29 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 260FE3A679F for ; Sun, 3 Apr 2011 13:06:29 -0700 (PDT) Received: by iye19 with SMTP id 19so6219140iye.31 for ; Sun, 03 Apr 2011 13:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=x2CCm9BRR2fUBvv1Tjv2m3H5tmCgyJr9wIB1Jf80DQ0=; b=almyhzQ/4emepg4XjuXUEc890mP0jov36uURjp8f9iyCxXc4n3UUgPokh4N3JBEg7Z Tatcz/WICMhJkOJedcR0ys3ucSLzwzpwHlR4iRAS837G7XBcXrl9OiG+Lbs4304ZTkSl dCxKoKRbHYxyvKnIvew/BWx+bLLqnyjgt7edQ= 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=LJP3rWX3BZztKC3Em0Qgk7Ib/T2UxsZ/je7OY02F43P8EmiKZfupRBN/j91CRak3R+ vXss092bVei8fVeEURJNA+bgCGJs/A9k34QJiY/XzfcGHcBuemevKlQq3azC3qS/+pIp waIeVsXSVjMzt/7Upyk5dSQQwnu4p7TGW8cIU= Received: by 10.43.55.73 with SMTP id vx9mr6102228icb.192.1301861291081; Sun, 03 Apr 2011 13:08:11 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id vx7sm2954402icb.14.2011.04.03.13.08.09 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Apr 2011 13:08:10 -0700 (PDT) Message-ID: <4D98D3D9.2060307@gmail.com> Date: Sun, 03 Apr 2011 13:08:57 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> <4D98B07E.8090601@gmail.com> <4D98C11D.5050208@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] [wvrap] Simulation consistency 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: Sun, 03 Apr 2011 20:06:30 -0000 As stated, "it didn't happen." The concepts and ideas are still iconic natured and useful as such. It's iconic usefulness as like that of infinite tense that all English teachers want their students to write in & with figure-of-speech, its the wrong way. That is the nature of English infinite tense. All other tenses are correct, and teachers expect you to "correct" infinite tense, yet they don't teach that. That's the basis of sentience. Infinite tense is logically always in error. Now with that in mind, "we" did not misunderstand the issues. Don't blame others until you look in the mirror more. What makes sense to you doesn't guarantee it makes sense to everybody else. The "graphic form" does not denote sense to visual people! Don't assume this! Like I said, visual people need complete ideas. Visual people don't remember dictionary definitions as much as auditory people don't remember graphic notations. It's because 60% of the people are auditory (they remember active speech) they are at constant battle with themselves in attempts to help the other 40% everywhere they don't need help -- is why there is ANY miscomprehension. Visual people find it completely dumb idea to have dictionaries full words that have any prefixes or suffixes, as that is wasted resources. Only the root words with possible prefixes and suffixes are of need. The reason why they don't exist this way is because of "figure-of-speech" and proof of that 60%. Unless you are somehow smarter than the best and the brightest, I doubt you can solely point out bad ideas such as dictionaries that list every combination of root words with every possible suffix and prefix individually such that basically kills us off slowly with lack of symbiotic flow due to trees used for the numerous pages published as scholarly works. It's a killing. Morgaine wrote: > I'm afraid you misunderstand the issue, Dzonatas. I'll add a bit of > background. > > This has nothing to do with visual versus graphical presentation. I'm > a big fan of both, and like yourself I think spatially most of the > time about architectures, which is a graphic form. Likewise, it has > nothing to do with accessibility whatsoever, of which I've been a very > enthusiastic proponent in Second Life for many years. > > The only thing with which the "domain" argument is concerned is > whether the concept reflects something useful in VWRAP that we can > observe, query, interact with, or design a protocol around. The > answer is "No" on all these counts for "Agent Domain" in VWRAP, > because it refers to a concept in OGP that denied interop, and it does > not apply to us. > > As a result, far from helping anyone to understand the VWRAP > architecture, all it does is increase the amount of confusion > surrounding VWRAP, because it does not reflect anything useful about > what we are trying to implement. > > The nearest we get in VWRAP to something that might have been > conceived originally as the "Agent Domain" in OGP is roughly "The set > of places and items and resources that this world will permit an agent > to visit or interact with ", which is approximately the same thing as > saying "the closed walled garden". It is a singularly > counter-productive concept for a group that has the important goal of > achieving interop between worlds. > > So no, it's not helpful, either visually or otherwise. The term is > just another obstacle on the road to VW interop. That OGP whiteboard > never had other fluffy clouds on it labeled "Virtual world B", > "Virtual world C", and so on. The concept of interop between worlds > was denied, because Agent Domain controlled access to Region Domains, > and so nothing outside AD+RD existed in OGP. > > But we are not designing OGP, we are designing VWRAP, a set of > protocols that embraces interoperation between worlds as well. That > is why the Agent Domain does not exist as a useful concept in this > work. It elevates world closure, negates interoperation, and does not > even admit other worlds into the picture, because Agent Domain is > defined to exclude them. > > It's a very bad idea, both in text and as fluffy clouds. > > > Morgaine. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Sun Apr 3 13:33:31 2011 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 A0C153A679F for ; Sun, 3 Apr 2011 13:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] 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 WqjBIM23W3Ad for ; Sun, 3 Apr 2011 13:33:29 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id DBA4D3A684E for ; Sun, 3 Apr 2011 13:33:28 -0700 (PDT) Received: by iwn39 with SMTP id 39so6049403iwn.31 for ; Sun, 03 Apr 2011 13:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=eoW6P8PkUCyh+tNujMv8rCz2Ubhp5m1CGhLbz/xZIuo=; b=OOCkEdgadDdxp7NPJ6lvGiRLPKZFv90umRxAw7F9wzHcVDT1TWBQrpFZwn1UREALMb b0fVOmWtPtlWPbZaMN/QjG9Vj+OH1pH1uYPA4YJUbVi8sTRoTJZbMnfM82Xjmblh7lnE U3ENqGpEl5HgDQAPDXjPjd1YXyC4nnuZBnoGc= 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=et1s5JSRjpVzTPfko20qGrtrAdP8JxS/qDiwJB2OvXRUVCgyutthmlZFMTVqB9RuI2 gRtmsaJ4qqZvKKdw0fVwaGmQzI/BlN/OpxyOvrKX4e3bwIm1fS2zw/CNcEigodKHJks5 LYS4UPat/jdhtJDbRY8Sb5f7RYyrY186omBkc= Received: by 10.42.141.10 with SMTP id m10mr7324684icu.236.1301862910708; Sun, 03 Apr 2011 13:35:10 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id wo15sm2969091icb.16.2011.04.03.13.35.08 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Apr 2011 13:35:09 -0700 (PDT) Message-ID: <4D98DA2C.2060809@gmail.com> Date: Sun, 03 Apr 2011 13:35:56 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Dzonatas Sol References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> <4D98B07E.8090601@gmail.com> <4D98C11D.5050208@gmail.com> <4D98D3D9.2060307@gmail.com> In-Reply-To: <4D98D3D9.2060307@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 03 Apr 2011 20:33:31 -0000 One more thing, in regards to "It's a killing..."... why do you think automation and virtual worlds exist in the first place? If your answer is anything near virtualization in ways that become turtles upon turtles (or VWs in VWs)... well... readjust your perspective back to "save the environment" and reboot from there. Being able to model and manufacturer without paperwork and without environmental damage has and remains the #1 reason (despite LL's call for "Fast, Fun, S..."). From that perspective, "asset" has wide-range of meanings that often get narrowed carelessly for the "fun of it". Many often go backwards before they know all meaning of assets. Any system that demonstrates single-entry derived bank automation is obviously backwards; it is quick to implement, costs too much in the end to upgrade, and always fails. Dzonatas Sol wrote: > As stated, "it didn't happen." The concepts and ideas are still iconic > natured and useful as such. It's iconic usefulness as like that of > infinite tense that all English teachers want their students to write > in & with figure-of-speech, its the wrong way. That is the nature of > English infinite tense. All other tenses are correct, and teachers > expect you to "correct" infinite tense, yet they don't teach that. > That's the basis of sentience. Infinite tense is logically always in > error. > > Now with that in mind, "we" did not misunderstand the issues. Don't > blame others until you look in the mirror more. What makes sense to > you doesn't guarantee it makes sense to everybody else. The "graphic > form" does not denote sense to visual people! Don't assume this! Like > I said, visual people need complete ideas. Visual people don't > remember dictionary definitions as much as auditory people don't > remember graphic notations. It's because 60% of the people are > auditory (they remember active speech) they are at constant battle > with themselves in attempts to help the other 40% everywhere they > don't need help -- is why there is ANY miscomprehension. > > Visual people find it completely dumb idea to have dictionaries full > words that have any prefixes or suffixes, as that is wasted resources. > Only the root words with possible prefixes and suffixes are of need. > The reason why they don't exist this way is because of > "figure-of-speech" and proof of that 60%. Unless you are somehow > smarter than the best and the brightest, I doubt you can solely point > out bad ideas such as dictionaries that list every combination of root > words with every possible suffix and prefix individually such that > basically kills us off slowly with lack of symbiotic flow due to trees > used for the numerous pages published as scholarly works. It's a killing. > > > Morgaine wrote: >> I'm afraid you misunderstand the issue, Dzonatas. I'll add a bit of >> background. >> >> This has nothing to do with visual versus graphical presentation. >> I'm a big fan of both, and like yourself I think spatially most of >> the time about architectures, which is a graphic form. Likewise, it >> has nothing to do with accessibility whatsoever, of which I've been a >> very enthusiastic proponent in Second Life for many years. >> >> The only thing with which the "domain" argument is concerned is >> whether the concept reflects something useful in VWRAP that we can >> observe, query, interact with, or design a protocol around. The >> answer is "No" on all these counts for "Agent Domain" in VWRAP, >> because it refers to a concept in OGP that denied interop, and it >> does not apply to us. >> >> As a result, far from helping anyone to understand the VWRAP >> architecture, all it does is increase the amount of confusion >> surrounding VWRAP, because it does not reflect anything useful about >> what we are trying to implement. >> >> The nearest we get in VWRAP to something that might have been >> conceived originally as the "Agent Domain" in OGP is roughly "The set >> of places and items and resources that this world will permit an >> agent to visit or interact with ", which is approximately the same >> thing as saying "the closed walled garden". It is a singularly >> counter-productive concept for a group that has the important goal of >> achieving interop between worlds. >> >> So no, it's not helpful, either visually or otherwise. The term is >> just another obstacle on the road to VW interop. That OGP whiteboard >> never had other fluffy clouds on it labeled "Virtual world B", >> "Virtual world C", and so on. The concept of interop between worlds >> was denied, because Agent Domain controlled access to Region Domains, >> and so nothing outside AD+RD existed in OGP. >> >> But we are not designing OGP, we are designing VWRAP, a set of >> protocols that embraces interoperation between worlds as well. That >> is why the Agent Domain does not exist as a useful concept in this >> work. It elevates world closure, negates interoperation, and does >> not even admit other worlds into the picture, because Agent Domain is >> defined to exclude them. >> >> It's a very bad idea, both in text and as fluffy clouds. >> >> >> Morgaine. > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Sun Apr 3 13:44:31 2011 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 D0A963A679F for ; Sun, 3 Apr 2011 13:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.781 X-Spam-Level: X-Spam-Status: No, score=-2.781 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLF6dPoyYOsU for ; Sun, 3 Apr 2011 13:44:28 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 818F73A685B for ; Sun, 3 Apr 2011 13:44:28 -0700 (PDT) Received: by qwc23 with SMTP id 23so19333qwc.31 for ; Sun, 03 Apr 2011 13:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=r9sJxIsPNN7X3Ln5AaQw9if41pX5HlB6+StP/ktcedY=; b=pLVfAn15A6pjo7x/YxdvJsYCaBMDTrGSbTgM5Fi92uy/CbsW4API1snIpNubcumHUj wD4HabgMW1jq9b0bNF+hfLn/8Q1sFc8preVLsdfbVDvae1kDsVB+ftJozYMV9JkVtGeS E7OW1rXkdKsRlhsyJ4e5kWnDoJ8C6YmY3ZRsw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=aTy2XSAC6qNXLFSnWc9wWGowTNIC22L3227h7uQtzhQlE6bypGouCv3FclYDqH2sB0 JvtYfYcwRh0C0YLzUJL0JvVnhMQx3qb8kxEKDfXJKQ+GGjCYtQaf9ulQka1hW7GD/5do KHVtI6XNkdQ0N7pyoFT0v6BK8rhfLTTC4fvHI= MIME-Version: 1.0 Received: by 10.229.78.22 with SMTP id i22mr2620759qck.33.1301863569990; Sun, 03 Apr 2011 13:46:09 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sun, 3 Apr 2011 13:46:09 -0700 (PDT) In-Reply-To: References: <20110402.101259.14412.0@webmail09.vgs.untd.com> <20110402171923.13176462@hikaru.localdomain> <20110402194853.20da8238@hikaru.localdomain> Date: Sun, 3 Apr 2011 21:46:09 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00235429d8f4a2a52404a009bb4d Subject: Re: [vwrap] Simulation consistency 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: Sun, 03 Apr 2011 20:44:31 -0000 --00235429d8f4a2a52404a009bb4d Content-Type: text/plain; charset=ISO-8859-1 Very good points made by Meadhbh, and I agree 100%. It's an unfortunate reality that a puzzlingly large proportion of users have a hard time grasping the total absence of content security in a platform architecture which sends nearly all content types to client machines by design. It was designed that way for very good reasons, and those reasons are as valid today as they were at the time that it was being designed, but it can be hard to get across that this is how it is intended to be and not a fault. Some people's aspirations are destined to be forever unsatisfied because this does not reflect their concept of digital reality. It doesn't matter how much machinery of trust or security or encryption or DRM or VPN or anything else we employ, at the end of the day the client endpoint has open data at its disposal which it needs to get its job done, and no technical barriers against doing with it whatever else it wishes. It's incongruous that we speak of "trust domains" (it's those fluffy clouds again) when all we really have are cryptographically assured endpoint identification and no trust at all. You can't trust someone whom you don't know as a person, and it's a fiction to claim that trust has been obtained. We would be more honest if we exchanged "Trust Placebo Tokens", and then we could at least laugh at our own eclectic joke, while openly admitting that we are not actually providing anything of value beyond knowledge of the endpoint. As you say, there is nothing we can actually do about this, because all we can do is exchange messages containing structured information, and we can't control people. "Trust" about what happens beyond the endpoint is something that our technology cannot convey, and really using terms that suggest otherwise just deludes people who don't have the background to know better. We should avoid doing that, even when a phrase sounds too sexy to give up. Morgaine. ========================= On Sun, Apr 3, 2011 at 8:36 PM, Meadhbh Hamrick wrote: > there is no way for a protocol to enforce the processing behavior on > either end of a connection unless you want to mandate the use of MAC > or DRM. > > the reason you "trust" someone is that you can't complete a > transaction without trusting them. in the original VWRAP model, we > assumed assets were bits of data and meta-data that could be securely > moved around. "license" was just another bit of meta-data, as was > "distribution." the protocol didn't require you to add either of these > fields. neither did the protocol require you to honor them. > > that's because there's no way a protocol can REQUIRE a consumer of > information do anything with that info. > > instead, we provided a mechanism to communicate structured information > and described the processing expectations. but ultimately, if a "bad > actor" that wants to steal digital content participates in a protocol > transaction, it won't matter that the protocol will say "honor > permissions metadata." there is nothing magical about protocols that > require adherence to specified processing expectations. > > -cheers > -meadhbh > > > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Sat, Apr 2, 2011 at 10:48 AM, Carlo Wood wrote: > > On Sat, 2 Apr 2011 10:01:43 -0700 > > Meadhbh Hamrick wrote: > > > > This is not exactly what I was refering too :p > > What I meant is that it should be possible to tag > > a creation as "GPL-ed" or "Common Creations" etc, > > and that the result is that that thing stays that > > way. That it is not possible to accidently break > > such free licenses by making it 'no mod' because > > someone forgot to check a box. > > > > Although this seems to be a client-side issue, > > and thus something internally to grid (and thus > > not related to VWRAP), it DOES mean that such > > information has to be supported at all levels: > > the fact that something IS explicitely allowed > > to be copied etc, has to be stored in asset > > servers and be transported to others who obtain > > a copy if it. > > > > If everyone is willing to work as hard on guaranteeing > > support for such free product as on the use case > > for proprietary products, then I'm willing to think > > hard of ways to support the latter. > > > >> yes. there is something missing in the protocol. it's trust. you don't > >> put "trust" in a protocol, you put "security" in a protocol. at the > >> end of the day, the people using this protocol will need to decide > >> whom they trust. this is why there was a security model and the > >> ability of the protocol to "securely carry trust." > >> > >> the idea is that the protocol would carry cryptographically > >> unforgeable attestations of an endpoint's identity. this identity > >> would then be evaluated by protocol participants to see if it is > >> "trusted." > >> > >> there's no place in the protocol that says "you must trust a specific > >> entity," but rather a mechanism deployers can use to carry the > >> identity of people wishing to be trusted. > >> > >> at the end of the day, an asset service should only barf up assets to > >> trusted simulation services. simulators SHOULD only allow people on > >> the grid they trust (for some definition of the word "trust.") > >> > >> if you're a company like Linden that needs to respond to DMCA takedown > >> requests, you're likely to require the client trust knob turned up a > >> bit. if you're an enterprise, you're going to want that trust knob > >> turned all the way up. if you're the pirate bay, you're going to > >> intentionally want that trust knob turned all the way down. > >> > >> as protocol developers, it's our duty to create a protocol that meets > >> everyone's use cases. so... i mean... feel free to try to define a > >> protocol that mandates the use of DRM or blesses a particular trust > >> point, but the likelihood of it being widely supported is.. > >> approximately nil. > >> > >> my recommendation has always been... "define mechanism, not policy." > >> > >> -cheers > >> -meadhbh > >> -- > >> meadhbh hamrick * it's pronounced "maeve" > >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > >> > >> > >> > >> On Sat, Apr 2, 2011 at 8:19 AM, Carlo Wood wrote: > >> > On Sat, 2 Apr 2011 14:12:59 GMT > >> > "dyerbrookme@juno.com" wrote: > >> > > >> >> BTW, the Red Zone statistics of 9 million scans with only 78,000 > >> >> rogue viewers captured lets us know that this problem is > >> >> exaggerated -- and usually by engineers who claim there is no > >> >> technical solution. > >> > > >> > Just for the record, from a hacker/engineer: there is no technical > >> > solution. It is possible to copy everything (and without being > >> > detected by a "Red Zone" which can only detect rogue viewers that > >> > were released to the public and explicitly make a point of being > >> > detectable in the first place (call that bragging: no fun in > >> > releasing a "k3wl" viewer if others (or even the coder himself) > >> > can't see that it is being used.) So, there is a psychological > >> > advantage for the detectors, but not really a technical one. > >> > > >> > Lets concentrate on textures for the moment to explain this. > >> > > >> > In order to see an object, or clothing, with the appropriate > >> > textures, those textures have to be downloadable for the viewer. > >> > There is nothing you can do about that short of running the whole > >> > viewer server-side and providing a video. But even in that case it > >> > would technically be possible to rip the textures: they are still > >> > visible (ie, you could make a screenshot of the surface of a wall). > >> > I don't consider the video-broadcast to even be remotely > >> > interesting, certainly not from the viewpoint of VWRAP so lets > >> > forget that for the moment and just accept that it is possible for > >> > anyone to store whatever they SEE to their harddisk. > >> > > >> > Secondly, if the first creator could upload this texture then so can > >> > the ripper. And don't tell me software exists that can detect if > >> > an uploaded texture "looks like" one of the already existing billion > >> > textures that were uploaded before. If the texture is converted > >> > twice, ie from jpeg2000 to jpg to tga and then uploaded, then you'd > >> > need a human to look at the original and the newly uploaded texture > >> > at the same time to judge that it is MAYBE a copy - which then can > >> > only be proved in court if the original creator can prove that his > >> > original textures are 100% his own and not, for example, downloaded > >> > from the internet somewhere (because in that case the other > >> > uploader could have used the same source). > >> > > >> > A real problem, currently in SL, is imho the complete lack of > >> > support for FREE things. The amount of restriction (for people with > >> > honest viewers) is tremendous: if you're not an expert or do not pay > >> > attention for a second, then your creation is not truely free > >> > anymore. Everything defaults to very copyleft unfriendly settings. > >> > I'm trying to get my friends, who are very willing in that regard, > >> > to only create full permission stuff, but it's simply near > >> > impossible to keep something full permission and often we're stuck > >> > with something nobody else can change or edit because the creator > >> > forgot to set the bit of the contents of an object after changing > >> > the group etc blah blah... > >> > > >> > For example, last a good friend of me wanted my help with making a > >> > large amount of changes on his sim: hunderds of objects had to be > >> > adjusted... He was willing to: > >> > 1) Add me to any group necessary. > >> > 2) Give me his build rights > >> > 3) Transfer any object to me (temporary ownership transfer) > >> > 4) Make any adjustments to the objects and the objects contents > >> > needed to allow me to access what I needed to access. > >> > etc etc > >> > > >> > The end result: He had to do it all by himself. It was impossible to > >> > give me enough access to help him (for those who don't believe that, > >> > one of things involved changing the "anyone can move" bit of an > >> > object in the contents of objects: it is not possible to take > >> > anything out of the contents (ie copy it to your inventory) when > >> > it's no transfer, and therefore you can't edit it, even though it's > >> > modify and you get all the rights that the owner can give you). > >> > > >> > Sorry, but that is unacceptable; and it CLEARLY shows that > >> > something is missing from the protocol. > >> > > >> > Now the above example doesn't show that a free object is not > >> > supported, it only make clear that non-free objects can be very > >> > annoying even in situations where the owner has all the rights to > >> > do what he wants to do. There are many other such examples. Hence, > >> > it shows that it is very annoying that an object is non-free by > >> > default at so many levels that you need an IQ of over 140 to create > >> > one and those permissions erode quickly to non-free. Even the so > >> > called "freebies" are non-free by the way: they are almost always > >> > no transfer. Hell, even the default shape that you can when you > >> > create a new account is no transfer, what kind of insanity is that?! > >> > > >> > I think you might find a lot of people, like myself, a lot more > >> > willing to help out with thinking of ways on how to protect > >> > property in virtual worlds when first it is assured that those who > >> > want to create things that are FREE are equally supported as the > >> > commercial guys out there. > >> > > >> > -- > >> > Carlo Wood > >> > _______________________________________________ > >> > vwrap mailing list > >> > vwrap@ietf.org > >> > https://www.ietf.org/mailman/listinfo/vwrap > >> > > > > > > > > > -- > > Carlo Wood > > _______________________________________________ > > 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 > --00235429d8f4a2a52404a009bb4d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Very good points made by Meadhbh, and I agree 100%.

It's an unfo= rtunate reality that a puzzlingly large proportion of users have a hard tim= e grasping the total absence of content security in a platform architecture= which sends nearly all content types to client machines by design.=A0 It w= as designed that way for very good reasons, and those reasons are as valid = today as they were at the time that it was being designed, but it can be ha= rd to get across that this is how it is intended to be and not a fault.=A0 = Some people's aspirations are destined to be forever unsatisfied becaus= e this does not reflect their concept of digital reality.

It doesn't matter how much machinery of trust or security or encryp= tion or DRM or VPN or anything else we employ, at the end of the day the cl= ient endpoint has open data at its disposal which it needs to get its job d= one, and no technical barriers against doing with it whatever else it wishe= s.

It's incongruous that we speak of "trust domains" (it'= ;s those fluffy clouds again) when all we really have are cryptographically= assured endpoint identification and no trust at all.=A0 You can't trus= t someone whom you don't know as a person, and it's a fiction to cl= aim that trust has been obtained.=A0 We would be more honest if we exchange= d "Trust Placebo Tokens", and then we could at least laugh at our= own eclectic joke, while openly admitting that we are not actually providi= ng anything of value beyond knowledge of the endpoint.

As you say, there is nothing we can actually do about this, because all= we can do is exchange messages containing structured information, and we c= an't control people.=A0 "Trust" about what happens beyond the= endpoint is something that our technology cannot convey, and really using = terms that suggest otherwise just deludes people who don't have the bac= kground to know better.

We should avoid doing that, even when a phrase sounds too sexy to give = up.


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

On Sun, Apr 3, 2011 at 8:36 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com= > wrote:
there is no way for a protocol to enforce the processing behavior on
either end of a connection unless you want to mandate the use of MAC
or DRM.

the reason you "trust" someone is that you can't complete a transaction without trusting them. in the original VWRAP model, we
assumed assets were bits of data and meta-data that could be securely
moved around. "license" was just another bit of meta-data, as was=
"distribution." the protocol didn't require you to add either= of these
fields. neither did the protocol require you to honor them.

that's because there's no way a protocol can REQUIRE a consumer of<= br> information do anything with that info.

instead, we provided a mechanism to communicate structured information
and described the processing expectations. but ultimately, if a "bad actor" that wants to steal digital content participates in a protocol<= br> transaction, it won't matter that the protocol will say "honor
permissions metadata." there is nothing magical about protocols that require adherence to specified processing expectations.

-cheers
-meadhbh


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



On Sat, Apr 2, 2011 at 10:48 AM, Carlo Wood <= carlo@alinoe.com&= gt; wrote:
> On Sat, 2 Apr 2011 10:01:43 -0700
> Meadhbh Hamrick <ohmeadhbh@gmail.com> wrote:
>
> This is not exactly what I was refering too :p
> What I meant is that it should be possible to tag
> a creation as "GPL-ed" or "Common Creations" etc,<= br> > and that the result is that that thing stays that
> way. That it is not possible to accidently break
> such free licenses by making it 'no mod' because
> someone forgot to check a box.
>
> Although this seems to be a client-side issue,
> and thus something internally to grid (and thus
> not related to VWRAP), it DOES mean that such
> information has to be supported at all levels:
> the fact that something IS explicitely allowed
> to be copied etc, has to be stored in asset
> servers and be transported to others who obtain
> a copy if it.
>
> If everyone is willing to work as hard on guaranteeing
> support for such free product as on the use case
> for proprietary products, then I'm willing to think
> hard of ways to support the latter.
>
>> yes. there is something missing in the protocol. it's trust. y= ou don't
>> put "trust" in a protocol, you put "security" = in a protocol. at the
>> end of the day, the people using this protocol will need to decide=
>> whom they trust. this is why there was a security model and the >> ability of the protocol to "securely carry trust."
>>
>> the idea is that the protocol would carry cryptographically
>> unforgeable attestations of an endpoint's identity. this ident= ity
>> would then be evaluated by protocol participants to see if it is >> "trusted."
>>
>> there's no place in the protocol that says "you must trus= t a specific
>> entity," but rather a mechanism deployers can use to carry th= e
>> identity of people wishing to be trusted.
>>
>> at the end of the day, an asset service should only barf up assets= to
>> trusted simulation services. simulators SHOULD only allow people o= n
>> the grid they trust (for some definition of the word "trust.&= quot;)
>>
>> if you're a company like Linden that needs to respond to DMCA = takedown
>> requests, you're likely to require the client trust knob turne= d up a
>> bit. if you're an enterprise, you're going to want that tr= ust knob
>> turned all the way up. if you're the pirate bay, you're go= ing to
>> intentionally want that trust knob turned all the way down.
>>
>> as protocol developers, it's our duty to create a protocol tha= t meets
>> everyone's use cases. so... i mean... feel free to try to defi= ne a
>> protocol that mandates the use of DRM or blesses a particular trus= t
>> point, but the likelihood of it being widely supported is..
>> approximately nil.
>>
>> my recommendation has always been... "define mechanism, not p= olicy."
>>
>> -cheers
>> -meadhbh
>> --
>> meadhbh hamrick * it's pronounced "maeve"
>> @OhMeadhbh * htt= p://meadhbh.org/ * OhMeadhbh@gmail.com
>>
>>
>>
>> On Sat, Apr 2, 2011 at 8:19 AM, Carlo Wood <carlo@alinoe.com> wrote:
>> > On Sat, 2 Apr 2011 14:12:59 GMT
>> > "dyerbrookme@juno.com" <dyerbrookme@juno.com> wrote:
>> >
>> >> BTW, the Red Zone statistics of 9 million =A0scans with o= nly 78,000
>> >> rogue viewers captured lets us know that this =A0problem = is
>> >> exaggerated -- and usually by engineers who claim there i= s no
>> >> =A0technical solution.
>> >
>> > Just for the record, from a hacker/engineer: there is no tech= nical
>> > solution. It is possible to copy everything (and without bein= g
>> > detected by a "Red Zone" which can only detect rogu= e viewers that
>> > were released to the public and explicitly make a point of be= ing
>> > detectable in the first place (call that bragging: no fun in<= br> >> > releasing a "k3wl" viewer if others (or even the co= der himself)
>> > can't see that it is being used.) So, there is a psycholo= gical
>> > advantage for the detectors, but not really a technical one.<= br> >> >
>> > Lets concentrate on textures for the moment to explain this.<= br> >> >
>> > In order to see an object, or clothing, with the appropriate<= br> >> > textures, those textures have to be downloadable for the view= er.
>> > There is nothing you can do about that short of running the w= hole
>> > viewer server-side and providing a video. But even in that ca= se it
>> > would technically be possible to rip the textures: they are s= till
>> > visible (ie, you could make a screenshot of the surface of a = wall).
>> > I don't consider the video-broadcast to even be remotely<= br> >> > interesting, certainly not from the viewpoint of VWRAP so let= s
>> > forget that for the moment and just accept that it is possibl= e for
>> > anyone to store whatever they SEE to their harddisk.
>> >
>> > Secondly, if the first creator could upload this texture then= so can
>> > the ripper. And don't tell me software exists that can de= tect if
>> > an uploaded texture "looks like" one of the already= existing billion
>> > textures that were uploaded before. If the texture is convert= ed
>> > twice, ie from jpeg2000 to jpg to tga and then uploaded, then= you'd
>> > need a human to look at the original and the newly uploaded t= exture
>> > at the same time to judge that it is MAYBE a copy - which the= n can
>> > only be proved in court if the original creator can prove tha= t his
>> > original textures are 100% his own and not, for example, down= loaded
>> > from the internet somewhere (because in that case the other >> > uploader could have used the same source).
>> >
>> > A real problem, currently in SL, is imho the complete lack of=
>> > support for FREE things. The amount of restriction (for peopl= e with
>> > honest viewers) is tremendous: if you're not an expert or= do not pay
>> > attention for a second, then your creation is not truely free=
>> > anymore. Everything defaults to very copyleft unfriendly sett= ings.
>> > I'm trying to get my friends, who are very willing in tha= t regard,
>> > to only create full permission stuff, but it's simply nea= r
>> > impossible to keep something full permission and often we'= ;re stuck
>> > with something nobody else can change or edit because the cre= ator
>> > forgot to set the bit of the contents of an object after chan= ging
>> > the group etc blah blah...
>> >
>> > For example, last a good friend of me wanted my help with mak= ing a
>> > large amount of changes on his sim: hunderds of objects had t= o be
>> > adjusted... He was willing to:
>> > 1) Add me to any group necessary.
>> > 2) Give me his build rights
>> > 3) Transfer any object to me (temporary ownership transfer) >> > 4) Make any adjustments to the objects and the objects conten= ts
>> > =A0 needed to allow me to access what I needed to access.
>> > etc etc
>> >
>> > The end result: He had to do it all by himself. It was imposs= ible to
>> > give me enough access to help him (for those who don't be= lieve that,
>> > one of things involved changing the "anyone can move&quo= t; bit of an
>> > object in the contents of objects: it is not possible to take=
>> > anything out of the contents (ie copy it to your inventory) w= hen
>> > it's no transfer, and therefore you can't edit it, ev= en though it's
>> > modify and you get all the rights that the owner can give you= ).
>> >
>> > Sorry, but that is unacceptable; and it CLEARLY shows that >> > something is missing from the protocol.
>> >
>> > Now the above example doesn't show that a free object is = not
>> > supported, it only make clear that non-free objects can be ve= ry
>> > annoying even in situations where the owner has all the right= s to
>> > do what he wants to do. There are many other such examples. H= ence,
>> > it shows that it is very annoying that an object is non-free = by
>> > default at so many levels that you need an IQ of over 140 to = create
>> > one and those permissions erode quickly to non-free. Even the= so
>> > called "freebies" are non-free by the way: they are= almost always
>> > no transfer. Hell, even the default shape that you can when y= ou
>> > create a new account is no transfer, what kind of insanity is= that?!
>> >
>> > I think you might find a lot of people, like myself, a lot mo= re
>> > willing to help out with thinking of ways on how to protect >> > property in virtual worlds when first it is assured that thos= e who
>> > want to create things that are FREE are equally supported as = the
>> > commercial guys out there.
>> >
>> > --
>> > Carlo Wood <carlo@alinoe.com>
>> > _______________________________________________
>> > vwrap mailing list
>> > vwrap@iet= f.org
>> > https://www.ietf.org/mailman/listinfo/vwrap
>> >
>
>
>
> --
> Carlo Wood <c= arlo@alinoe.com>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org=
> https://www.ietf.org/mailman/listinfo/vwrap
>
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--00235429d8f4a2a52404a009bb4d-- From dzonatas@gmail.com Sun Apr 3 14:07:38 2011 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 973F53A689A for ; Sun, 3 Apr 2011 14:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.504 X-Spam-Level: X-Spam-Status: No, score=-3.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 P2qJipPycB3k for ; Sun, 3 Apr 2011 14:07:36 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 7B0B13A6970 for ; Sun, 3 Apr 2011 14:07:36 -0700 (PDT) Received: by iye19 with SMTP id 19so6255958iye.31 for ; Sun, 03 Apr 2011 14:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pdJSbIF9Dk49y62iJhzkWjtVXIdvchj8Ujy5xPU+fO0=; b=FREiG4xjB4k9AyeaSymvGw4/tfO1WxvmB9NF3BW/NmADDj2un4LNmw7GYxlxv8NK4C VD6e0IIjyEr+owqBD+uymt9acSra7vSqwf1+XpihMa2EdvKbyKu2VwHQTmiirssFfXkc oObgGYYsp0QxTvlB4074frp1N+4T9ZTOnd7bY= 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=gUoxW7zUv4Ck8UbxCYEkdkKEdvKmkNIk69tFHv2+M+Uuvh8plirnVzsU9AfMttq41b jcwp0sv8FZuhb9dZABiKxFTsH1HnVe7Ty4wV32cWn9x3tIhWgZjysD5k5mrdGi328GlO emIp1Z4rKYC9kcoYz4NL0aZbbqlLSQizWRcPg= Received: by 10.42.135.2 with SMTP id n2mr9686106ict.251.1301864957839; Sun, 03 Apr 2011 14:09:17 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id i20sm3232006iby.14.2011.04.03.14.09.15 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Apr 2011 14:09:17 -0700 (PDT) Message-ID: <4D98E22B.6090203@gmail.com> Date: Sun, 03 Apr 2011 14:10:03 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: <20110402.101259.14412.0@webmail09.vgs.untd.com> <20110402171923.13176462@hikaru.localdomain> <20110402194853.20da8238@hikaru.localdomain> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Simulation consistency 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: Sun, 03 Apr 2011 21:07:38 -0000 You mock fluffy clouds, yet you wrote "It was designed". To not write even close to formal English, when you made use of subject-less sentences, and complained about meanings and (glossary) usage, is incongruous. Just state you don't like the word "domain". There is no need to mock me or anybody else to win points. Morgaine wrote: > Very good points made by Meadhbh, and I agree 100%. > > It's an unfortunate reality that a puzzlingly large proportion of > users have a hard time grasping the total absence of content security > in a platform architecture which sends nearly all content types to > client machines by design.� It was designed that way for very good > reasons, and those reasons are as valid today as they were at the time > that it was being designed, but it can be hard to get across that this > is how it is intended to be and not a fault.� Some people's > aspirations are destined to be forever unsatisfied because this does > not reflect their concept of digital reality. > > It doesn't matter how much machinery of trust or security or > encryption or DRM or VPN or anything else we employ, at the end of the > day the client endpoint has open data at its disposal which it needs > to get its job done, and no technical barriers against doing with it > whatever else it wishes. > > It's incongruous that we speak of "trust domains" (it's those fluffy > clouds again) when all we really have are cryptographically assured > endpoint identification and no trust at all.� You can't trust someone > whom you don't know as a person, and it's a fiction to claim that > trust has been obtained.� We would be more honest if we exchanged > "Trust Placebo Tokens", and then we could at least laugh at our own > eclectic joke, while openly admitting that we are not actually > providing anything of value beyond knowledge of the endpoint. > > As you say, there is nothing we can actually do about this, because > all we can do is exchange messages containing structured information, > and we can't control people.� "Trust" about what happens beyond the > endpoint is something that our technology cannot convey, and really > using terms that suggest otherwise just deludes people who don't have > the background to know better. > > We should avoid doing that, even when a phrase sounds too sexy to give up. > > > Morgaine. > > > > > > ========================= > > On Sun, Apr 3, 2011 at 8:36 PM, Meadhbh Hamrick > wrote: > > there is no way for a protocol to enforce the processing behavior on > either end of a connection unless you want to mandate the use of MAC > or DRM. > > the reason you "trust" someone is that you can't complete a > transaction without trusting them. in the original VWRAP model, we > assumed assets were bits of data and meta-data that could be securely > moved around. "license" was just another bit of meta-data, as was > "distribution." the protocol didn't require you to add either of these > fields. neither did the protocol require you to honor them. > > that's because there's no way a protocol can REQUIRE a consumer of > information do anything with that info. > > instead, we provided a mechanism to communicate structured information > and described the processing expectations. but ultimately, if a "bad > actor" that wants to steal digital content participates in a protocol > transaction, it won't matter that the protocol will say "honor > permissions metadata." there is nothing magical about protocols that > require adherence to specified processing expectations. > > -cheers > -meadhbh > > > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > > On Sat, Apr 2, 2011 at 10:48 AM, Carlo Wood > wrote: > > On Sat, 2 Apr 2011 10:01:43 -0700 > > Meadhbh Hamrick > wrote: > > > > This is not exactly what I was refering too :p > > What I meant is that it should be possible to tag > > a creation as "GPL-ed" or "Common Creations" etc, > > and that the result is that that thing stays that > > way. That it is not possible to accidently break > > such free licenses by making it 'no mod' because > > someone forgot to check a box. > > > > Although this seems to be a client-side issue, > > and thus something internally to grid (and thus > > not related to VWRAP), it DOES mean that such > > information has to be supported at all levels: > > the fact that something IS explicitely allowed > > to be copied etc, has to be stored in asset > > servers and be transported to others who obtain > > a copy if it. > > > > If everyone is willing to work as hard on guaranteeing > > support for such free product as on the use case > > for proprietary products, then I'm willing to think > > hard of ways to support the latter. > > > >> yes. there is something missing in the protocol. it's trust. > you don't > >> put "trust" in a protocol, you put "security" in a protocol. at the > >> end of the day, the people using this protocol will need to decide > >> whom they trust. this is why there was a security model and the > >> ability of the protocol to "securely carry trust." > >> > >> the idea is that the protocol would carry cryptographically > >> unforgeable attestations of an endpoint's identity. this identity > >> would then be evaluated by protocol participants to see if it is > >> "trusted." > >> > >> there's no place in the protocol that says "you must trust a > specific > >> entity," but rather a mechanism deployers can use to carry the > >> identity of people wishing to be trusted. > >> > >> at the end of the day, an asset service should only barf up > assets to > >> trusted simulation services. simulators SHOULD only allow people on > >> the grid they trust (for some definition of the word "trust.") > >> > >> if you're a company like Linden that needs to respond to DMCA > takedown > >> requests, you're likely to require the client trust knob turned > up a > >> bit. if you're an enterprise, you're going to want that trust knob > >> turned all the way up. if you're the pirate bay, you're going to > >> intentionally want that trust knob turned all the way down. > >> > >> as protocol developers, it's our duty to create a protocol that > meets > >> everyone's use cases. so... i mean... feel free to try to define a > >> protocol that mandates the use of DRM or blesses a particular trust > >> point, but the likelihood of it being widely supported is.. > >> approximately nil. > >> > >> my recommendation has always been... "define mechanism, not > policy." > >> > >> -cheers > >> -meadhbh > >> -- > >> meadhbh hamrick * it's pronounced "maeve" > >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > >> > >> > >> > >> On Sat, Apr 2, 2011 at 8:19 AM, Carlo Wood > wrote: > >> > On Sat, 2 Apr 2011 14:12:59 GMT > >> > "dyerbrookme@juno.com " > > wrote: > >> > > >> >> BTW, the Red Zone statistics of 9 million �scans with only > 78,000 > >> >> rogue viewers captured lets us know that this �problem is > >> >> exaggerated -- and usually by engineers who claim there is no > >> >> �technical solution. > >> > > >> > Just for the record, from a hacker/engineer: there is no > technical > >> > solution. It is possible to copy everything (and without being > >> > detected by a "Red Zone" which can only detect rogue viewers that > >> > were released to the public and explicitly make a point of being > >> > detectable in the first place (call that bragging: no fun in > >> > releasing a "k3wl" viewer if others (or even the coder himself) > >> > can't see that it is being used.) So, there is a psychological > >> > advantage for the detectors, but not really a technical one. > >> > > >> > Lets concentrate on textures for the moment to explain this. > >> > > >> > In order to see an object, or clothing, with the appropriate > >> > textures, those textures have to be downloadable for the viewer. > >> > There is nothing you can do about that short of running the whole > >> > viewer server-side and providing a video. But even in that > case it > >> > would technically be possible to rip the textures: they are still > >> > visible (ie, you could make a screenshot of the surface of a > wall). > >> > I don't consider the video-broadcast to even be remotely > >> > interesting, certainly not from the viewpoint of VWRAP so lets > >> > forget that for the moment and just accept that it is > possible for > >> > anyone to store whatever they SEE to their harddisk. > >> > > >> > Secondly, if the first creator could upload this texture then > so can > >> > the ripper. And don't tell me software exists that can detect if > >> > an uploaded texture "looks like" one of the already existing > billion > >> > textures that were uploaded before. If the texture is converted > >> > twice, ie from jpeg2000 to jpg to tga and then uploaded, then > you'd > >> > need a human to look at the original and the newly uploaded > texture > >> > at the same time to judge that it is MAYBE a copy - which > then can > >> > only be proved in court if the original creator can prove > that his > >> > original textures are 100% his own and not, for example, > downloaded > >> > from the internet somewhere (because in that case the other > >> > uploader could have used the same source). > >> > > >> > A real problem, currently in SL, is imho the complete lack of > >> > support for FREE things. The amount of restriction (for > people with > >> > honest viewers) is tremendous: if you're not an expert or do > not pay > >> > attention for a second, then your creation is not truely free > >> > anymore. Everything defaults to very copyleft unfriendly > settings. > >> > I'm trying to get my friends, who are very willing in that > regard, > >> > to only create full permission stuff, but it's simply near > >> > impossible to keep something full permission and often we're > stuck > >> > with something nobody else can change or edit because the creator > >> > forgot to set the bit of the contents of an object after changing > >> > the group etc blah blah... > >> > > >> > For example, last a good friend of me wanted my help with > making a > >> > large amount of changes on his sim: hunderds of objects had to be > >> > adjusted... He was willing to: > >> > 1) Add me to any group necessary. > >> > 2) Give me his build rights > >> > 3) Transfer any object to me (temporary ownership transfer) > >> > 4) Make any adjustments to the objects and the objects contents > >> > � needed to allow me to access what I needed to access. > >> > etc etc > >> > > >> > The end result: He had to do it all by himself. It was > impossible to > >> > give me enough access to help him (for those who don't > believe that, > >> > one of things involved changing the "anyone can move" bit of an > >> > object in the contents of objects: it is not possible to take > >> > anything out of the contents (ie copy it to your inventory) when > >> > it's no transfer, and therefore you can't edit it, even > though it's > >> > modify and you get all the rights that the owner can give you). > >> > > >> > Sorry, but that is unacceptable; and it CLEARLY shows that > >> > something is missing from the protocol. > >> > > >> > Now the above example doesn't show that a free object is not > >> > supported, it only make clear that non-free objects can be very > >> > annoying even in situations where the owner has all the rights to > >> > do what he wants to do. There are many other such examples. > Hence, > >> > it shows that it is very annoying that an object is non-free by > >> > default at so many levels that you need an IQ of over 140 to > create > >> > one and those permissions erode quickly to non-free. Even the so > >> > called "freebies" are non-free by the way: they are almost always > >> > no transfer. Hell, even the default shape that you can when you > >> > create a new account is no transfer, what kind of insanity is > that?! > >> > > >> > I think you might find a lot of people, like myself, a lot more > >> > willing to help out with thinking of ways on how to protect > >> > property in virtual worlds when first it is assured that > those who > >> > want to create things that are FREE are equally supported as the > >> > commercial guys out there. > >> > > >> > -- > >> > Carlo Wood > > >> > _______________________________________________ > >> > vwrap mailing list > >> > vwrap@ietf.org > >> > https://www.ietf.org/mailman/listinfo/vwrap > >> > > > > > > > > > -- > > Carlo Wood > > > _______________________________________________ > > vwrap mailing list > > vwrap@ietf.org > > https://www.ietf.org/mailman/listinfo/vwrap > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Sun Apr 3 14:20:24 2011 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 5D2C83A6889 for ; Sun, 3 Apr 2011 14:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvrktCcIWqjv for ; Sun, 3 Apr 2011 14:20:21 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 1FAC73A6892 for ; Sun, 3 Apr 2011 14:20:20 -0700 (PDT) Received: by qyk7 with SMTP id 7so3271170qyk.10 for ; Sun, 03 Apr 2011 14:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ETSMsqBNklG91b4yMbfh9akUqw4D3GlHQHPzxlHW5Y4=; b=hhn8zZKMdQZCMOFnJ7y7b5XXakN+a8GkpB1L6vlCuVdG+dYuK15nOYkg0lwWKIw+Zj PH3khykifdvrHkaBxGnK+WZ1Jm+CMB2JmMMwb7n9YiS3M5S1iyVQ7Dt3+tykjC8C9zg/ 7QE2L/wpiVCZB1Ejm3ZHYhGgvjZYA/42X0C5U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=DUQ+3pbI0okq3sP7fiyN6W6H6Se0qw8QKieOVAKv+hELFsJ/rJFd7YQkL4szzOmZ9C DOrm9eRCqonUqQ2XvZTc1faKWGKGtDkhMcoz77PYZQogQwhFSmraAsVZNTZ/Kgfihvc9 EtI3hwzuDICSJXcUeAJTA5hkzN3aHejMgTf0A= MIME-Version: 1.0 Received: by 10.229.37.130 with SMTP id x2mr5176912qcd.147.1301865721216; Sun, 03 Apr 2011 14:22:01 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sun, 3 Apr 2011 14:22:00 -0700 (PDT) In-Reply-To: <4D98E22B.6090203@gmail.com> References: <20110402.101259.14412.0@webmail09.vgs.untd.com> <20110402171923.13176462@hikaru.localdomain> <20110402194853.20da8238@hikaru.localdomain> <4D98E22B.6090203@gmail.com> Date: Sun, 3 Apr 2011 22:22:00 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016368340c0dbcafa04a00a3b5c Subject: Re: [vwrap] Simulation consistency 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: Sun, 03 Apr 2011 21:20:24 -0000 --0016368340c0dbcafa04a00a3b5c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I like domains, Dzonatas. I use them thousands of times daily in the Domai= n Name System, and such domains have very precise definitions, concrete services that implement them, a well defined network protocol and many APIs and bindings. These domains are something concrete, and productive. In contrast, Agent Domain and Trust Domain are neither. I'll leave it at that and let you have the last word, because this discussion is similarly unhelpful. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Sun, Apr 3, 2011 at 10:10 PM, Dzonatas Sol wrote: > You mock fluffy clouds, yet you wrote "It was designed". To not write eve= n > close to formal English, when you made use of subject-less sentences, and > complained about meanings and (glossary) usage, is incongruous. > > Just state you don't like the word "domain". There is no need to mock me = or > anybody else to win points. > > Morgaine wrote: > >> Very good points made by Meadhbh, and I agree 100%. >> >> It's an unfortunate reality that a puzzlingly large proportion of users >> have a hard time grasping the total absence of content security in a >> platform architecture which sends nearly all content types to client >> machines by design.=EF=BF=BD It was designed that way for very good reas= ons, and >> those reasons are as valid today as they were at the time that it was be= ing >> designed, but it can be hard to get across that this is how it is intend= ed >> to be and not a fault.=EF=BF=BD Some people's aspirations are destined t= o be forever >> unsatisfied because this does not reflect their concept of digital reali= ty. >> >> It doesn't matter how much machinery of trust or security or encryption = or >> DRM or VPN or anything else we employ, at the end of the day the client >> endpoint has open data at its disposal which it needs to get its job don= e, >> and no technical barriers against doing with it whatever else it wishes. >> >> It's incongruous that we speak of "trust domains" (it's those fluffy >> clouds again) when all we really have are cryptographically assured endp= oint >> identification and no trust at all.=EF=BF=BD You can't trust someone who= m you don't >> know as a person, and it's a fiction to claim that trust has been obtain= ed.=EF=BF=BD >> We would be more honest if we exchanged "Trust Placebo Tokens", and then= we >> could at least laugh at our own eclectic joke, while openly admitting th= at >> we are not actually providing anything of value beyond knowledge of the >> endpoint. >> >> As you say, there is nothing we can actually do about this, because all = we >> can do is exchange messages containing structured information, and we ca= n't >> control people.=EF=BF=BD "Trust" about what happens beyond the endpoint = is something >> that our technology cannot convey, and really using terms that suggest >> otherwise just deludes people who don't have the background to know bett= er. >> >> We should avoid doing that, even when a phrase sounds too sexy to give u= p. >> >> >> 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 >> >> On Sun, Apr 3, 2011 at 8:36 PM, Meadhbh Hamrick > ohmeadhbh@gmail.com>> wrote: >> >> there is no way for a protocol to enforce the processing behavior on >> either end of a connection unless you want to mandate the use of MAC >> or DRM. >> >> the reason you "trust" someone is that you can't complete a >> transaction without trusting them. in the original VWRAP model, we >> assumed assets were bits of data and meta-data that could be securely >> moved around. "license" was just another bit of meta-data, as was >> "distribution." the protocol didn't require you to add either of thes= e >> fields. neither did the protocol require you to honor them. >> >> that's because there's no way a protocol can REQUIRE a consumer of >> information do anything with that info. >> >> instead, we provided a mechanism to communicate structured informatio= n >> and described the processing expectations. but ultimately, if a "bad >> actor" that wants to steal digital content participates in a protocol >> transaction, it won't matter that the protocol will say "honor >> permissions metadata." there is nothing magical about protocols that >> require adherence to specified processing expectations. >> >> -cheers >> -meadhbh >> >> >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> >> >> On Sat, Apr 2, 2011 at 10:48 AM, Carlo Wood > > wrote: >> > On Sat, 2 Apr 2011 10:01:43 -0700 >> > Meadhbh Hamrick > > wrote: >> > >> > This is not exactly what I was refering too :p >> > What I meant is that it should be possible to tag >> > a creation as "GPL-ed" or "Common Creations" etc, >> > and that the result is that that thing stays that >> > way. That it is not possible to accidently break >> > such free licenses by making it 'no mod' because >> > someone forgot to check a box. >> > >> > Although this seems to be a client-side issue, >> > and thus something internally to grid (and thus >> > not related to VWRAP), it DOES mean that such >> > information has to be supported at all levels: >> > the fact that something IS explicitely allowed >> > to be copied etc, has to be stored in asset >> > servers and be transported to others who obtain >> > a copy if it. >> > >> > If everyone is willing to work as hard on guaranteeing >> > support for such free product as on the use case >> > for proprietary products, then I'm willing to think >> > hard of ways to support the latter. >> > >> >> yes. there is something missing in the protocol. it's trust. >> you don't >> >> put "trust" in a protocol, you put "security" in a protocol. at th= e >> >> end of the day, the people using this protocol will need to decide >> >> whom they trust. this is why there was a security model and the >> >> ability of the protocol to "securely carry trust." >> >> >> >> the idea is that the protocol would carry cryptographically >> >> unforgeable attestations of an endpoint's identity. this identity >> >> would then be evaluated by protocol participants to see if it is >> >> "trusted." >> >> >> >> there's no place in the protocol that says "you must trust a >> specific >> >> entity," but rather a mechanism deployers can use to carry the >> >> identity of people wishing to be trusted. >> >> >> >> at the end of the day, an asset service should only barf up >> assets to >> >> trusted simulation services. simulators SHOULD only allow people o= n >> >> the grid they trust (for some definition of the word "trust.") >> >> >> >> if you're a company like Linden that needs to respond to DMCA >> takedown >> >> requests, you're likely to require the client trust knob turned >> up a >> >> bit. if you're an enterprise, you're going to want that trust knob >> >> turned all the way up. if you're the pirate bay, you're going to >> >> intentionally want that trust knob turned all the way down. >> >> >> >> as protocol developers, it's our duty to create a protocol that >> meets >> >> everyone's use cases. so... i mean... feel free to try to define a >> >> protocol that mandates the use of DRM or blesses a particular trus= t >> >> point, but the likelihood of it being widely supported is.. >> >> approximately nil. >> >> >> >> my recommendation has always been... "define mechanism, not >> policy." >> >> >> >> -cheers >> >> -meadhbh >> >> -- >> >> meadhbh hamrick * it's pronounced "maeve" >> >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> >> >> >> >> >> >> On Sat, Apr 2, 2011 at 8:19 AM, Carlo Wood > > wrote: >> >> > On Sat, 2 Apr 2011 14:12:59 GMT >> >> > "dyerbrookme@juno.com " >> >> > wrote: >> >> > >> >> >> BTW, the Red Zone statistics of 9 million =EF=BF=BDscans with o= nly >> 78,000 >> >> >> rogue viewers captured lets us know that this =EF=BF=BDproblem = is >> >> >> exaggerated -- and usually by engineers who claim there is no >> >> >> =EF=BF=BDtechnical solution. >> >> > >> >> > Just for the record, from a hacker/engineer: there is no >> technical >> >> > solution. It is possible to copy everything (and without being >> >> > detected by a "Red Zone" which can only detect rogue viewers tha= t >> >> > were released to the public and explicitly make a point of being >> >> > detectable in the first place (call that bragging: no fun in >> >> > releasing a "k3wl" viewer if others (or even the coder himself) >> >> > can't see that it is being used.) So, there is a psychological >> >> > advantage for the detectors, but not really a technical one. >> >> > >> >> > Lets concentrate on textures for the moment to explain this. >> >> > >> >> > In order to see an object, or clothing, with the appropriate >> >> > textures, those textures have to be downloadable for the viewer. >> >> > There is nothing you can do about that short of running the whol= e >> >> > viewer server-side and providing a video. But even in that >> case it >> >> > would technically be possible to rip the textures: they are stil= l >> >> > visible (ie, you could make a screenshot of the surface of a >> wall). >> >> > I don't consider the video-broadcast to even be remotely >> >> > interesting, certainly not from the viewpoint of VWRAP so lets >> >> > forget that for the moment and just accept that it is >> possible for >> >> > anyone to store whatever they SEE to their harddisk. >> >> > >> >> > Secondly, if the first creator could upload this texture then >> so can >> >> > the ripper. And don't tell me software exists that can detect if >> >> > an uploaded texture "looks like" one of the already existing >> billion >> >> > textures that were uploaded before. If the texture is converted >> >> > twice, ie from jpeg2000 to jpg to tga and then uploaded, then >> you'd >> >> > need a human to look at the original and the newly uploaded >> texture >> >> > at the same time to judge that it is MAYBE a copy - which >> then can >> >> > only be proved in court if the original creator can prove >> that his >> >> > original textures are 100% his own and not, for example, >> downloaded >> >> > from the internet somewhere (because in that case the other >> >> > uploader could have used the same source). >> >> > >> >> > A real problem, currently in SL, is imho the complete lack of >> >> > support for FREE things. The amount of restriction (for >> people with >> >> > honest viewers) is tremendous: if you're not an expert or do >> not pay >> >> > attention for a second, then your creation is not truely free >> >> > anymore. Everything defaults to very copyleft unfriendly >> settings. >> >> > I'm trying to get my friends, who are very willing in that >> regard, >> >> > to only create full permission stuff, but it's simply near >> >> > impossible to keep something full permission and often we're >> stuck >> >> > with something nobody else can change or edit because the creato= r >> >> > forgot to set the bit of the contents of an object after changin= g >> >> > the group etc blah blah... >> >> > >> >> > For example, last a good friend of me wanted my help with >> making a >> >> > large amount of changes on his sim: hunderds of objects had to b= e >> >> > adjusted... He was willing to: >> >> > 1) Add me to any group necessary. >> >> > 2) Give me his build rights >> >> > 3) Transfer any object to me (temporary ownership transfer) >> >> > 4) Make any adjustments to the objects and the objects contents >> >> > =EF=BF=BD needed to allow me to access what I needed to access. >> >> > etc etc >> >> > >> >> > The end result: He had to do it all by himself. It was >> impossible to >> >> > give me enough access to help him (for those who don't >> believe that, >> >> > one of things involved changing the "anyone can move" bit of an >> >> > object in the contents of objects: it is not possible to take >> >> > anything out of the contents (ie copy it to your inventory) when >> >> > it's no transfer, and therefore you can't edit it, even >> though it's >> >> > modify and you get all the rights that the owner can give you). >> >> > >> >> > Sorry, but that is unacceptable; and it CLEARLY shows that >> >> > something is missing from the protocol. >> >> > >> >> > Now the above example doesn't show that a free object is not >> >> > supported, it only make clear that non-free objects can be very >> >> > annoying even in situations where the owner has all the rights t= o >> >> > do what he wants to do. There are many other such examples. >> Hence, >> >> > it shows that it is very annoying that an object is non-free by >> >> > default at so many levels that you need an IQ of over 140 to >> create >> >> > one and those permissions erode quickly to non-free. Even the so >> >> > called "freebies" are non-free by the way: they are almost alway= s >> >> > no transfer. Hell, even the default shape that you can when you >> >> > create a new account is no transfer, what kind of insanity is >> that?! >> >> > >> >> > I think you might find a lot of people, like myself, a lot more >> >> > willing to help out with thinking of ways on how to protect >> >> > property in virtual worlds when first it is assured that >> those who >> >> > want to create things that are FREE are equally supported as the >> >> > commercial guys out there. >> >> > >> >> > -- >> >> > Carlo Wood > >> >> > _______________________________________________ >> >> > vwrap mailing list >> >> > vwrap@ietf.org >> >> >> > https://www.ietf.org/mailman/listinfo/vwrap >> >> > >> > >> > >> > >> > -- >> > Carlo Wood > >> > _______________________________________________ >> > vwrap mailing list >> > vwrap@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/vwrap >> > >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > --0016368340c0dbcafa04a00a3b5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I like domains, Dzonatas.=C2=A0 I use them thousands of times daily in the = Domain Name System, and such domains have very precise definitions, concret= e services that implement them, a well defined network protocol and many AP= Is and bindings.=C2=A0 These domains are something concrete, and productive= .

In contrast, Agent Domain and Trust Domain are neither.

I'll= leave it at that and let you have the last word, because this discussion i= s similarly unhelpful.


Morgaine.



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

On Sun, Apr 3, 2011 at 10:10 PM, Dzonatas So= l <dzonatas@gmai= l.com> wrote:
You mock fluffy clouds, yet you wrote "It was designed". To not w= rite even close to formal English, when you made use of subject-less senten= ces, and complained about meanings and (glossary) usage, is incongruous.
Just state you don't like the word "domain". There is no need= to mock me or anybody else to win points.

Morgaine wrote:
Very good points made by Meadhbh, and I agree 100%.

It's an unfortunate reality that a puzzlingly large proportion of users= have a hard time grasping the total absence of content security in a platf= orm architecture which sends nearly all content types to client machines by= design.=EF=BF=BD It was designed that way for very good reasons, and those= reasons are as valid today as they were at the time that it was being desi= gned, but it can be hard to get across that this is how it is intended to b= e and not a fault.=EF=BF=BD Some people's aspirations are destined to b= e forever unsatisfied because this does not reflect their concept of digita= l reality.

It doesn't matter how much machinery of trust or security or encryption= or DRM or VPN or anything else we employ, at the end of the day the client= endpoint has open data at its disposal which it needs to get its job done,= and no technical barriers against doing with it whatever else it wishes.
It's incongruous that we speak of "trust domains" (it's t= hose fluffy clouds again) when all we really have are cryptographically ass= ured endpoint identification and no trust at all.=EF=BF=BD You can't tr= ust someone whom you don't know as a person, and it's a fiction to = claim that trust has been obtained.=EF=BF=BD We would be more honest if we = exchanged "Trust Placebo Tokens", and then we could at least laug= h at our own eclectic joke, while openly admitting that we are not actually= providing anything of value beyond knowledge of the endpoint.

As you say, there is nothing we can actually do about this, because all we = can do is exchange messages containing structured information, and we can&#= 39;t control people.=EF=BF=BD "Trust" about what happens beyond t= he endpoint is something that our technology cannot convey, and really usin= g terms that suggest otherwise just deludes people who don't have the b= ackground to know better.

We should avoid doing that, even when a phrase sounds too sexy to give up.<= br>

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=

On Sun, Apr 3, 2011 at 8:36 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com <mailto:ohmeadhbh@gmail.com&= gt;> wrote:

=C2=A0 =C2=A0there is no way for a protocol to enforce the processing beha= vior on
=C2=A0 =C2=A0either end of a connection unless you want to mandate the use= of MAC
=C2=A0 =C2=A0or DRM.

=C2=A0 =C2=A0the reason you "trust" someone is that you can'= t complete a
=C2=A0 =C2=A0transaction without trusting them. in the original VWRAP mode= l, we
=C2=A0 =C2=A0assumed assets were bits of data and meta-data that could be = securely
=C2=A0 =C2=A0moved around. "license" was just another bit of met= a-data, as was
=C2=A0 =C2=A0"distribution." the protocol didn't require you= to add either of these
=C2=A0 =C2=A0fields. neither did the protocol require you to honor them.
=C2=A0 =C2=A0that's because there's no way a protocol can REQUIRE = a consumer of
=C2=A0 =C2=A0information do anything with that info.

=C2=A0 =C2=A0instead, we provided a mechanism to communicate structured in= formation
=C2=A0 =C2=A0and described the processing expectations. but ultimately, if= a "bad
=C2=A0 =C2=A0actor" that wants to steal digital content participates = in a protocol
=C2=A0 =C2=A0transaction, it won't matter that the protocol will say &= quot;honor
=C2=A0 =C2=A0permissions metadata." there is nothing magical about pr= otocols that
=C2=A0 =C2=A0require adherence to specified processing expectations.

=C2=A0 =C2=A0-cheers
=C2=A0 =C2=A0-meadhbh


=C2=A0 =C2=A0--
=C2=A0 =C2=A0meadhbh hamrick * it's pronounced "maeve"
=C2=A0 =C2=A0@OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com
=C2=A0 =C2=A0<mailto:OhMeadhbh@gmail.com>




=C2=A0 =C2=A0On Sat, Apr 2, 2011 at 10:48 AM, Carlo Wood <carlo@alinoe.com
=C2=A0 =C2=A0<mailto:carlo@alinoe.com>> wrote:
=C2=A0 =C2=A0> On Sat, 2 Apr 2011 10:01:43 -0700
=C2=A0 =C2=A0> Meadhbh Hamrick <ohmeadhbh@gmail.com
=C2=A0 =C2=A0<mailto:ohmeadhbh@gmail.com>> wrote:
=C2=A0 =C2=A0>
=C2=A0 =C2=A0> This is not exactly what I was refering too :p
=C2=A0 =C2=A0> What I meant is that it should be possible to tag
=C2=A0 =C2=A0> a creation as "GPL-ed" or "Common Creatio= ns" etc,
=C2=A0 =C2=A0> and that the result is that that thing stays that
=C2=A0 =C2=A0> way. That it is not possible to accidently break
=C2=A0 =C2=A0> such free licenses by making it 'no mod' because=
=C2=A0 =C2=A0> someone forgot to check a box.
=C2=A0 =C2=A0>
=C2=A0 =C2=A0> Although this seems to be a client-side issue,
=C2=A0 =C2=A0> and thus something internally to grid (and thus
=C2=A0 =C2=A0> not related to VWRAP), it DOES mean that such
=C2=A0 =C2=A0> information has to be supported at all levels:
=C2=A0 =C2=A0> the fact that something IS explicitely allowed
=C2=A0 =C2=A0> to be copied etc, has to be stored in asset
=C2=A0 =C2=A0> servers and be transported to others who obtain
=C2=A0 =C2=A0> a copy if it.
=C2=A0 =C2=A0>
=C2=A0 =C2=A0> If everyone is willing to work as hard on guaranteeing =C2=A0 =C2=A0> support for such free product as on the use case
=C2=A0 =C2=A0> for proprietary products, then I'm willing to think<= br> =C2=A0 =C2=A0> hard of ways to support the latter.
=C2=A0 =C2=A0>
=C2=A0 =C2=A0>> yes. there is something missing in the protocol. it&= #39;s trust.
=C2=A0 =C2=A0you don't
=C2=A0 =C2=A0>> put "trust" in a protocol, you put "s= ecurity" in a protocol. at the
=C2=A0 =C2=A0>> end of the day, the people using this protocol will = need to decide
=C2=A0 =C2=A0>> whom they trust. this is why there was a security mo= del and the
=C2=A0 =C2=A0>> ability of the protocol to "securely carry trus= t."
=C2=A0 =C2=A0>>
=C2=A0 =C2=A0>> the idea is that the protocol would carry cryptograp= hically
=C2=A0 =C2=A0>> unforgeable attestations of an endpoint's identi= ty. this identity
=C2=A0 =C2=A0>> would then be evaluated by protocol participants to = see if it is
=C2=A0 =C2=A0>> "trusted."
=C2=A0 =C2=A0>>
=C2=A0 =C2=A0>> there's no place in the protocol that says "= ;you must trust a
=C2=A0 =C2=A0specific
=C2=A0 =C2=A0>> entity," but rather a mechanism deployers can u= se to carry the
=C2=A0 =C2=A0>> identity of people wishing to be trusted.
=C2=A0 =C2=A0>>
=C2=A0 =C2=A0>> at the end of the day, an asset service should only = barf up
=C2=A0 =C2=A0assets to
=C2=A0 =C2=A0>> trusted simulation services. simulators SHOULD only = allow people on
=C2=A0 =C2=A0>> the grid they trust (for some definition of the word= "trust.")
=C2=A0 =C2=A0>>
=C2=A0 =C2=A0>> if you're a company like Linden that needs to re= spond to DMCA
=C2=A0 =C2=A0takedown
=C2=A0 =C2=A0>> requests, you're likely to require the client tr= ust knob turned
=C2=A0 =C2=A0up a
=C2=A0 =C2=A0>> bit. if you're an enterprise, you're going t= o want that trust knob
=C2=A0 =C2=A0>> turned all the way up. if you're the pirate bay,= you're going to
=C2=A0 =C2=A0>> intentionally want that trust knob turned all the wa= y down.
=C2=A0 =C2=A0>>
=C2=A0 =C2=A0>> as protocol developers, it's our duty to create = a protocol that
=C2=A0 =C2=A0meets
=C2=A0 =C2=A0>> everyone's use cases. so... i mean... feel free = to try to define a
=C2=A0 =C2=A0>> protocol that mandates the use of DRM or blesses a p= articular trust
=C2=A0 =C2=A0>> point, but the likelihood of it being widely support= ed is..
=C2=A0 =C2=A0>> approximately nil.
=C2=A0 =C2=A0>>
=C2=A0 =C2=A0>> my recommendation has always been... "define me= chanism, not
=C2=A0 =C2=A0policy."
=C2=A0 =C2=A0>>
=C2=A0 =C2=A0>> -cheers
=C2=A0 =C2=A0>> -meadhbh
=C2=A0 =C2=A0>> --
=C2=A0 =C2=A0>> meadhbh hamrick * it's pronounced "maeve&qu= ot;
=C2=A0 =C2=A0>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com
=C2=A0 =C2=A0<mailto:OhMeadhbh@gmail.com>

=C2=A0 =C2=A0>>
=C2=A0 =C2=A0>>
=C2=A0 =C2=A0>>
=C2=A0 =C2=A0>> On Sat, Apr 2, 2011 at 8:19 AM, Carlo Wood <carlo@alinoe.com
=C2=A0 =C2=A0<mailto:carlo@alinoe.com>> wrote:
=C2=A0 =C2=A0>> > On Sat, 2 Apr 2011 14:12:59 GMT
=C2=A0 =C2=A0>> > "dyerbrookme@juno.com <mailto:dyerbrookme@juno.com>"
=

=C2=A0 =C2=A0<dyerbrookme@juno.com <mailto:dyerbrookme@juno.com>> wrote:
=C2=A0 =C2=A0>> >
=C2=A0 =C2=A0>> >> BTW, the Red Zone statistics of 9 million = =EF=BF=BDscans with only
=C2=A0 =C2=A078,000
=C2=A0 =C2=A0>> >> rogue viewers captured lets us know that th= is =EF=BF=BDproblem is
=C2=A0 =C2=A0>> >> exaggerated -- and usually by engineers who= claim there is no
=C2=A0 =C2=A0>> >> =EF=BF=BDtechnical solution.
=C2=A0 =C2=A0>> >
=C2=A0 =C2=A0>> > Just for the record, from a hacker/engineer: th= ere is no
=C2=A0 =C2=A0technical
=C2=A0 =C2=A0>> > solution. It is possible to copy everything (an= d without being
=C2=A0 =C2=A0>> > detected by a "Red Zone" which can on= ly detect rogue viewers that
=C2=A0 =C2=A0>> > were released to the public and explicitly make= a point of being
=C2=A0 =C2=A0>> > detectable in the first place (call that braggi= ng: no fun in
=C2=A0 =C2=A0>> > releasing a "k3wl" viewer if others (= or even the coder himself)
=C2=A0 =C2=A0>> > can't see that it is being used.) So, there= is a psychological
=C2=A0 =C2=A0>> > advantage for the detectors, but not really a t= echnical one.
=C2=A0 =C2=A0>> >
=C2=A0 =C2=A0>> > Lets concentrate on textures for the moment to = explain this.
=C2=A0 =C2=A0>> >
=C2=A0 =C2=A0>> > In order to see an object, or clothing, with th= e appropriate
=C2=A0 =C2=A0>> > textures, those textures have to be downloadabl= e for the viewer.
=C2=A0 =C2=A0>> > There is nothing you can do about that short of= running the whole
=C2=A0 =C2=A0>> > viewer server-side and providing a video. But e= ven in that
=C2=A0 =C2=A0case it
=C2=A0 =C2=A0>> > would technically be possible to rip the textur= es: they are still
=C2=A0 =C2=A0>> > visible (ie, you could make a screenshot of the= surface of a
=C2=A0 =C2=A0wall).
=C2=A0 =C2=A0>> > I don't consider the video-broadcast to eve= n be remotely
=C2=A0 =C2=A0>> > interesting, certainly not from the viewpoint o= f VWRAP so lets
=C2=A0 =C2=A0>> > forget that for the moment and just accept that= it is
=C2=A0 =C2=A0possible for
=C2=A0 =C2=A0>> > anyone to store whatever they SEE to their hard= disk.
=C2=A0 =C2=A0>> >
=C2=A0 =C2=A0>> > Secondly, if the first creator could upload thi= s texture then
=C2=A0 =C2=A0so can
=C2=A0 =C2=A0>> > the ripper. And don't tell me software exis= ts that can detect if
=C2=A0 =C2=A0>> > an uploaded texture "looks like" one = of the already existing
=C2=A0 =C2=A0billion
=C2=A0 =C2=A0>> > textures that were uploaded before. If the text= ure is converted
=C2=A0 =C2=A0>> > twice, ie from jpeg2000 to jpg to tga and then = uploaded, then
=C2=A0 =C2=A0you'd
=C2=A0 =C2=A0>> > need a human to look at the original and the ne= wly uploaded
=C2=A0 =C2=A0texture
=C2=A0 =C2=A0>> > at the same time to judge that it is MAYBE a co= py - which
=C2=A0 =C2=A0then can
=C2=A0 =C2=A0>> > only be proved in court if the original creator= can prove
=C2=A0 =C2=A0that his
=C2=A0 =C2=A0>> > original textures are 100% his own and not, for= example,
=C2=A0 =C2=A0downloaded
=C2=A0 =C2=A0>> > from the internet somewhere (because in that ca= se the other
=C2=A0 =C2=A0>> > uploader could have used the same source).
=C2=A0 =C2=A0>> >
=C2=A0 =C2=A0>> > A real problem, currently in SL, is imho the co= mplete lack of
=C2=A0 =C2=A0>> > support for FREE things. The amount of restrict= ion (for
=C2=A0 =C2=A0people with
=C2=A0 =C2=A0>> > honest viewers) is tremendous: if you're no= t an expert or do
=C2=A0 =C2=A0not pay
=C2=A0 =C2=A0>> > attention for a second, then your creation is n= ot truely free
=C2=A0 =C2=A0>> > anymore. Everything defaults to very copyleft u= nfriendly
=C2=A0 =C2=A0settings.
=C2=A0 =C2=A0>> > I'm trying to get my friends, who are very = willing in that
=C2=A0 =C2=A0regard,
=C2=A0 =C2=A0>> > to only create full permission stuff, but it= 9;s simply near
=C2=A0 =C2=A0>> > impossible to keep something full permission an= d often we're
=C2=A0 =C2=A0stuck
=C2=A0 =C2=A0>> > with something nobody else can change or edit b= ecause the creator
=C2=A0 =C2=A0>> > forgot to set the bit of the contents of an obj= ect after changing
=C2=A0 =C2=A0>> > the group etc blah blah...
=C2=A0 =C2=A0>> >
=C2=A0 =C2=A0>> > For example, last a good friend of me wanted my= help with
=C2=A0 =C2=A0making a
=C2=A0 =C2=A0>> > large amount of changes on his sim: hunderds of= objects had to be
=C2=A0 =C2=A0>> > adjusted... He was willing to:
=C2=A0 =C2=A0>> > 1) Add me to any group necessary.
=C2=A0 =C2=A0>> > 2) Give me his build rights
=C2=A0 =C2=A0>> > 3) Transfer any object to me (temporary ownersh= ip transfer)
=C2=A0 =C2=A0>> > 4) Make any adjustments to the objects and the = objects contents
=C2=A0 =C2=A0>> > =EF=BF=BD needed to allow me to access what I n= eeded to access.
=C2=A0 =C2=A0>> > etc etc
=C2=A0 =C2=A0>> >
=C2=A0 =C2=A0>> > The end result: He had to do it all by himself.= It was
=C2=A0 =C2=A0impossible to
=C2=A0 =C2=A0>> > give me enough access to help him (for those wh= o don't
=C2=A0 =C2=A0believe that,
=C2=A0 =C2=A0>> > one of things involved changing the "anyon= e can move" bit of an
=C2=A0 =C2=A0>> > object in the contents of objects: it is not po= ssible to take
=C2=A0 =C2=A0>> > anything out of the contents (ie copy it to you= r inventory) when
=C2=A0 =C2=A0>> > it's no transfer, and therefore you can'= ;t edit it, even
=C2=A0 =C2=A0though it's
=C2=A0 =C2=A0>> > modify and you get all the rights that the owne= r can give you).
=C2=A0 =C2=A0>> >
=C2=A0 =C2=A0>> > Sorry, but that is unacceptable; and it CLEARLY= shows that
=C2=A0 =C2=A0>> > something is missing from the protocol.
=C2=A0 =C2=A0>> >
=C2=A0 =C2=A0>> > Now the above example doesn't show that a f= ree object is not
=C2=A0 =C2=A0>> > supported, it only make clear that non-free obj= ects can be very
=C2=A0 =C2=A0>> > annoying even in situations where the owner has= all the rights to
=C2=A0 =C2=A0>> > do what he wants to do. There are many other su= ch examples.
=C2=A0 =C2=A0Hence,
=C2=A0 =C2=A0>> > it shows that it is very annoying that an objec= t is non-free by
=C2=A0 =C2=A0>> > default at so many levels that you need an IQ o= f over 140 to
=C2=A0 =C2=A0create
=C2=A0 =C2=A0>> > one and those permissions erode quickly to non-= free. Even the so
=C2=A0 =C2=A0>> > called "freebies" are non-free by the= way: they are almost always
=C2=A0 =C2=A0>> > no transfer. Hell, even the default shape that = you can when you
=C2=A0 =C2=A0>> > create a new account is no transfer, what kind = of insanity is
=C2=A0 =C2=A0that?!
=C2=A0 =C2=A0>> >
=C2=A0 =C2=A0>> > I think you might find a lot of people, like my= self, a lot more
=C2=A0 =C2=A0>> > willing to help out with thinking of ways on ho= w to protect
=C2=A0 =C2=A0>> > property in virtual worlds when first it is ass= ured that
=C2=A0 =C2=A0those who
=C2=A0 =C2=A0>> > want to create things that are FREE are equally= supported as the
=C2=A0 =C2=A0>> > commercial guys out there.
=C2=A0 =C2=A0>> >
=C2=A0 =C2=A0>> > --
=C2=A0 =C2=A0>> > Carlo Wood <carlo@alinoe.com <mailto:carlo@alinoe.com>>
=C2=A0 =C2=A0>> > _______________________________________________=
=C2=A0 =C2=A0>> > vwrap mailing list
=C2=A0 =C2=A0>> > vwrap@ietf.org <mailto:vwrap@ietf.org>

=C2=A0 =C2=A0>> > https://www.ietf.org/mailman/listinfo/vwrap<= br> =C2=A0 =C2=A0>> >
=C2=A0 =C2=A0>
=C2=A0 =C2=A0>
=C2=A0 =C2=A0>
=C2=A0 =C2=A0> --
=C2=A0 =C2=A0> Carlo Wood <carlo@alinoe.com <mailto:carlo@alinoe.com>>
=C2=A0 =C2=A0> _______________________________________________
=C2=A0 =C2=A0> vwrap mailing list
=C2=A0 =C2=A0> vwra= p@ietf.org <mailto:vwrap@ietf.org>

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

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


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


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


--0016368340c0dbcafa04a00a3b5c-- From dzonatas@gmail.com Sun Apr 3 15:12:55 2011 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 308A33A68BF for ; Sun, 3 Apr 2011 15:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 88rIdoIdvu0G for ; Sun, 3 Apr 2011 15:12:53 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id D81013A68BA for ; Sun, 3 Apr 2011 15:12:52 -0700 (PDT) Received: by iye19 with SMTP id 19so6294211iye.31 for ; Sun, 03 Apr 2011 15:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lpwsAUkYy6qy0/DeYi2WPeshP4bFdE5DoWTJ3WKGEqc=; b=RHkUH+DqZfCWUUBdWFBLxvLn7f2v3NXyyWDdLnH/IksdjgTYS2TK6SFPPhut8ADJ0X BnFSWWxRYxTZJUq+Nep+VA2kSHt+Cjy71UDsTFWjQ02qadEgnY/svK2fVngfz0gLsTeW NHLBhjSYW1bgHTloS1KGOiU/5olGfqFwlaBT8= 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=AEHXUA71Efhikq/pSBvz95DHxYHbxMtKBzb0AtDWbGcJHGHobk+s+uHNXZF5ix/dwC 1bhtC1qmP3eeqm7VgglVcs7lHxudQnoCBJ+4B71WH/X4yVYsT+gFbCfOOLyx3Rq8FiIN DEwiXPu8/Jr4urNIFmIW4Aps3tZb16V5XFtwo= Received: by 10.231.112.231 with SMTP id x39mr4893253ibp.113.1301868874442; Sun, 03 Apr 2011 15:14:34 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id i20sm3267881iby.14.2011.04.03.15.14.32 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Apr 2011 15:14:33 -0700 (PDT) Message-ID: <4D98F177.6090403@gmail.com> Date: Sun, 03 Apr 2011 15:15:19 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: <20110402.101259.14412.0@webmail09.vgs.untd.com> <20110402171923.13176462@hikaru.localdomain> <20110402194853.20da8238@hikaru.localdomain> <4D98E22B.6090203@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Simulation consistency 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: Sun, 03 Apr 2011 22:12:55 -0000 This discussion is very helpful, and this is not about "the last word". Figure-of-speech like ""It was designed" is not anywhere near any complete idea without assumptions. Appeals to common sense are still within the realm of figure-of-speech (and obviously does not meet accessibility needs). Concrete sense needs complete ideas and neither common-sense nor assumptions. Grammatic informal English allows assumptions, yet still does not allow incomplete ideas by subject-less or ill-verb usage. This all is very helpful knowledge (requirements) in documentation that makes sense to everybody. If someone writes totally crazy and "lacking" in abilities to type complete sentences, yet they write anywhere near formal English with complete ideas, that someone is not stupid. That someone might have took all day to write what they day compared to what it takes you to write in minutes. How do you think someone feels even when slightly mocked under such conditions? There is no need to mock people (even non-chaletly) due to their accessibility needs, which you now appear ignorant about where you wrote "because this discussion is similarly unhelpful." Agent Domain and Trust Domain are use-cases, which have been used as-is in past documentation and current glossary entries. If that is the end of your discussion then that proves there was no reason to complain about past usage of those instances (because "you can't change the past"). Those still exist despite the implementations did not happen (...publicly). In contrast, documentation without implementation is not concrete. UNIX is the only system, yet, that still remains purely written in documentation without implementation. All other implementation based on UNIX are derivatives . UNIX proves exactly the depth of documentation that needs to exist before any real implementation can exist. Further, this is the IETF list, and thus not limited to LL/OpenSim only politics of what exists and what doesn't. Morgaine wrote: > I like domains, Dzonatas. I use them thousands of times daily in the > Domain Name System, and such domains have very precise definitions, > concrete services that implement them, a well defined network protocol > and many APIs and bindings. These domains are something concrete, and > productive. > > In contrast, Agent Domain and Trust Domain are neither. > > I'll leave it at that and let you have the last word, because this > discussion is similarly unhelpful. > > > Morgaine. > > > > ======================== > > On Sun, Apr 3, 2011 at 10:10 PM, Dzonatas Sol > wrote: > > You mock fluffy clouds, yet you wrote "It was designed". To not > write even close to formal English, when you made use of > subject-less sentences, and complained about meanings and > (glossary) usage, is incongruous. > > Just state you don't like the word "domain". There is no need to > mock me or anybody else to win points. > > Morgaine wrote: > > Very good points made by Meadhbh, and I agree 100%. > > It's an unfortunate reality that a puzzlingly large proportion > of users have a hard time grasping the total absence of > content security in a platform architecture which sends nearly > all content types to client machines by design.� It was > designed that way for very good reasons, and those reasons are > as valid today as they were at the time that it was being > designed, but it can be hard to get across that this is how it > is intended to be and not a fault.� Some people's aspirations > are destined to be forever unsatisfied because this does not > reflect their concept of digital reality. > > It doesn't matter how much machinery of trust or security or > encryption or DRM or VPN or anything else we employ, at the > end of the day the client endpoint has open data at its > disposal which it needs to get its job done, and no technical > barriers against doing with it whatever else it wishes. > > It's incongruous that we speak of "trust domains" (it's those > fluffy clouds again) when all we really have are > cryptographically assured endpoint identification and no trust > at all.� You can't trust someone whom you don't know as a > person, and it's a fiction to claim that trust has been > obtained.� We would be more honest if we exchanged "Trust > Placebo Tokens", and then we could at least laugh at our own > eclectic joke, while openly admitting that we are not actually > providing anything of value beyond knowledge of the endpoint. > > As you say, there is nothing we can actually do about this, > because all we can do is exchange messages containing > structured information, and we can't control people.� "Trust" > about what happens beyond the endpoint is something that our > technology cannot convey, and really using terms that suggest > otherwise just deludes people who don't have the background to > know better. > > We should avoid doing that, even when a phrase sounds too sexy > to give up. > > > Morgaine. > > > > > > ========================= > > On Sun, Apr 3, 2011 at 8:36 PM, Meadhbh Hamrick > > >> wrote: > > there is no way for a protocol to enforce the processing > behavior on > either end of a connection unless you want to mandate the > use of MAC > or DRM. > > the reason you "trust" someone is that you can't complete a > transaction without trusting them. in the original VWRAP > model, we > assumed assets were bits of data and meta-data that could > be securely > moved around. "license" was just another bit of meta-data, > as was > "distribution." the protocol didn't require you to add > either of these > fields. neither did the protocol require you to honor them. > > that's because there's no way a protocol can REQUIRE a > consumer of > information do anything with that info. > > instead, we provided a mechanism to communicate structured > information > and described the processing expectations. but ultimately, > if a "bad > actor" that wants to steal digital content participates in > a protocol > transaction, it won't matter that the protocol will say "honor > permissions metadata." there is nothing magical about > protocols that > require adherence to specified processing expectations. > > -cheers > -meadhbh > > > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > > > > > On Sat, Apr 2, 2011 at 10:48 AM, Carlo Wood > > >> wrote: > > On Sat, 2 Apr 2011 10:01:43 -0700 > > Meadhbh Hamrick > >> > wrote: > > > > This is not exactly what I was refering too :p > > What I meant is that it should be possible to tag > > a creation as "GPL-ed" or "Common Creations" etc, > > and that the result is that that thing stays that > > way. That it is not possible to accidently break > > such free licenses by making it 'no mod' because > > someone forgot to check a box. > > > > Although this seems to be a client-side issue, > > and thus something internally to grid (and thus > > not related to VWRAP), it DOES mean that such > > information has to be supported at all levels: > > the fact that something IS explicitely allowed > > to be copied etc, has to be stored in asset > > servers and be transported to others who obtain > > a copy if it. > > > > If everyone is willing to work as hard on guaranteeing > > support for such free product as on the use case > > for proprietary products, then I'm willing to think > > hard of ways to support the latter. > > > >> yes. there is something missing in the protocol. it's trust. > you don't > >> put "trust" in a protocol, you put "security" in a > protocol. at the > >> end of the day, the people using this protocol will need > to decide > >> whom they trust. this is why there was a security model > and the > >> ability of the protocol to "securely carry trust." > >> > >> the idea is that the protocol would carry cryptographically > >> unforgeable attestations of an endpoint's identity. this > identity > >> would then be evaluated by protocol participants to see > if it is > >> "trusted." > >> > >> there's no place in the protocol that says "you must trust a > specific > >> entity," but rather a mechanism deployers can use to > carry the > >> identity of people wishing to be trusted. > >> > >> at the end of the day, an asset service should only barf up > assets to > >> trusted simulation services. simulators SHOULD only > allow people on > >> the grid they trust (for some definition of the word > "trust.") > >> > >> if you're a company like Linden that needs to respond to > DMCA > takedown > >> requests, you're likely to require the client trust knob > turned > up a > >> bit. if you're an enterprise, you're going to want that > trust knob > >> turned all the way up. if you're the pirate bay, you're > going to > >> intentionally want that trust knob turned all the way down. > >> > >> as protocol developers, it's our duty to create a > protocol that > meets > >> everyone's use cases. so... i mean... feel free to try > to define a > >> protocol that mandates the use of DRM or blesses a > particular trust > >> point, but the likelihood of it being widely supported is.. > >> approximately nil. > >> > >> my recommendation has always been... "define mechanism, not > policy." > >> > >> -cheers > >> -meadhbh > >> -- > >> meadhbh hamrick * it's pronounced "maeve" > >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > > >> > >> > >> > >> On Sat, Apr 2, 2011 at 8:19 AM, Carlo Wood > > >> wrote: > >> > On Sat, 2 Apr 2011 14:12:59 GMT > >> > "dyerbrookme@juno.com > >" > > > >> > wrote: > >> > > >> >> BTW, the Red Zone statistics of 9 million �scans with > only > 78,000 > >> >> rogue viewers captured lets us know that this �problem is > >> >> exaggerated -- and usually by engineers who claim > there is no > >> >> �technical solution. > >> > > >> > Just for the record, from a hacker/engineer: there is no > technical > >> > solution. It is possible to copy everything (and > without being > >> > detected by a "Red Zone" which can only detect rogue > viewers that > >> > were released to the public and explicitly make a > point of being > >> > detectable in the first place (call that bragging: no > fun in > >> > releasing a "k3wl" viewer if others (or even the coder > himself) > >> > can't see that it is being used.) So, there is a > psychological > >> > advantage for the detectors, but not really a > technical one. > >> > > >> > Lets concentrate on textures for the moment to explain > this. > >> > > >> > In order to see an object, or clothing, with the > appropriate > >> > textures, those textures have to be downloadable for > the viewer. > >> > There is nothing you can do about that short of > running the whole > >> > viewer server-side and providing a video. But even in that > case it > >> > would technically be possible to rip the textures: > they are still > >> > visible (ie, you could make a screenshot of the > surface of a > wall). > >> > I don't consider the video-broadcast to even be remotely > >> > interesting, certainly not from the viewpoint of VWRAP > so lets > >> > forget that for the moment and just accept that it is > possible for > >> > anyone to store whatever they SEE to their harddisk. > >> > > >> > Secondly, if the first creator could upload this > texture then > so can > >> > the ripper. And don't tell me software exists that can > detect if > >> > an uploaded texture "looks like" one of the already > existing > billion > >> > textures that were uploaded before. If the texture is > converted > >> > twice, ie from jpeg2000 to jpg to tga and then > uploaded, then > you'd > >> > need a human to look at the original and the newly > uploaded > texture > >> > at the same time to judge that it is MAYBE a copy - which > then can > >> > only be proved in court if the original creator can prove > that his > >> > original textures are 100% his own and not, for example, > downloaded > >> > from the internet somewhere (because in that case the > other > >> > uploader could have used the same source). > >> > > >> > A real problem, currently in SL, is imho the complete > lack of > >> > support for FREE things. The amount of restriction (for > people with > >> > honest viewers) is tremendous: if you're not an expert > or do > not pay > >> > attention for a second, then your creation is not > truely free > >> > anymore. Everything defaults to very copyleft unfriendly > settings. > >> > I'm trying to get my friends, who are very willing in that > regard, > >> > to only create full permission stuff, but it's simply near > >> > impossible to keep something full permission and often > we're > stuck > >> > with something nobody else can change or edit because > the creator > >> > forgot to set the bit of the contents of an object > after changing > >> > the group etc blah blah... > >> > > >> > For example, last a good friend of me wanted my help with > making a > >> > large amount of changes on his sim: hunderds of > objects had to be > >> > adjusted... He was willing to: > >> > 1) Add me to any group necessary. > >> > 2) Give me his build rights > >> > 3) Transfer any object to me (temporary ownership > transfer) > >> > 4) Make any adjustments to the objects and the objects > contents > >> > � needed to allow me to access what I needed to access. > >> > etc etc > >> > > >> > The end result: He had to do it all by himself. It was > impossible to > >> > give me enough access to help him (for those who don't > believe that, > >> > one of things involved changing the "anyone can move" > bit of an > >> > object in the contents of objects: it is not possible > to take > >> > anything out of the contents (ie copy it to your > inventory) when > >> > it's no transfer, and therefore you can't edit it, even > though it's > >> > modify and you get all the rights that the owner can > give you). > >> > > >> > Sorry, but that is unacceptable; and it CLEARLY shows that > >> > something is missing from the protocol. > >> > > >> > Now the above example doesn't show that a free object > is not > >> > supported, it only make clear that non-free objects > can be very > >> > annoying even in situations where the owner has all > the rights to > >> > do what he wants to do. There are many other such > examples. > Hence, > >> > it shows that it is very annoying that an object is > non-free by > >> > default at so many levels that you need an IQ of over > 140 to > create > >> > one and those permissions erode quickly to non-free. > Even the so > >> > called "freebies" are non-free by the way: they are > almost always > >> > no transfer. Hell, even the default shape that you can > when you > >> > create a new account is no transfer, what kind of > insanity is > that?! > >> > > >> > I think you might find a lot of people, like myself, a > lot more > >> > willing to help out with thinking of ways on how to > protect > >> > property in virtual worlds when first it is assured that > those who > >> > want to create things that are FREE are equally > supported as the > >> > commercial guys out there. > >> > > >> > -- > >> > Carlo Wood > >> > >> > _______________________________________________ > >> > vwrap mailing list > >> > vwrap@ietf.org > > > > >> > https://www.ietf.org/mailman/listinfo/vwrap > >> > > > > > > > > > -- > > Carlo Wood > >> > > _______________________________________________ > > vwrap mailing list > > vwrap@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/vwrap > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > > https://www.ietf.org/mailman/listinfo/vwrap > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From fleep513@gmail.com Sun Apr 3 17:00:38 2011 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 2A95B3A68D7 for ; Sun, 3 Apr 2011 17:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] 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 s77S-D9OHLwa for ; Sun, 3 Apr 2011 17:00:36 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id BFD5B3A68DE for ; Sun, 3 Apr 2011 17:00:35 -0700 (PDT) Received: by gxk19 with SMTP id 19so2338280gxk.31 for ; Sun, 03 Apr 2011 17:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=usCDFnm2BhLy1tRp1c8y3kfbFzezFW+Gb7V69nRU+tw=; b=YRSQNJoMDyTZ+aCOFFR4FXfMd24FouzldmQZ/Y0ljw7MNi0AqttfdlwBcKk4sHY4at odXvjal5eB1WNIB959H+xTAnkd9RqxCKi44CBeLYJk8G5eTa/W2L8Vj9Xb5PORQktjMB nEMG/TNtY9u+13weixG2wLBefmXAt0ysSvWTU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=qmLw4gjBggNsFVAMFdWRpB5rMeGl/RcvCczpIldHOgI+yKYDuG6NC82yihdIaNJ8Zi kCsyhYdgAA815ZNHeOT42hq4PNL2HIPz48aY71g3OmjV3delCPl63c01P9eDq1oqQIrA 8kXj9QcDR+SsrB11th25qwqGVCoW0Y4OxRLk8= MIME-Version: 1.0 Received: by 10.90.195.11 with SMTP id s11mr4481064agf.160.1301875337545; Sun, 03 Apr 2011 17:02:17 -0700 (PDT) Received: by 10.90.79.19 with HTTP; Sun, 3 Apr 2011 17:02:17 -0700 (PDT) In-Reply-To: <4D98D3D9.2060307@gmail.com> References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> <4D98B07E.8090601@gmail.com> <4D98C11D.5050208@gmail.com> <4D98D3D9.2060307@gmail.com> Date: Sun, 3 Apr 2011 20:02:17 -0400 Message-ID: From: Fleep Tuque To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016362848b409508904a00c790b Subject: Re: [vwrap] [wvrap] Simulation consistency 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, 04 Apr 2011 00:00:38 -0000 --0016362848b409508904a00c790b Content-Type: text/plain; charset=ISO-8859-1 On a purely academic side note, the theory of "learning styles" has been disputed and some would even say debunked. Current research shows that depending upon the context and activity we're involved with and our specific physical abilities, people generally all learn in visual, auditory, kinesthetic, etc. ways. Unfortunately the website for the primary journal article I wanted to reference appears to be down at the moment, but see http://chronicle.com/article/Matching-Teaching-Style-to-/49497/ for a pretty good explanation. I admit that I don't know enough VWRAP history to fully understand the crux of this debate, but I'm having a hard time drawing the connection between criticism of how a term term like "Agent Domain" has been/is being used and how that relates to accessibility issues. I hope moving forward we're all careful about being critical of ideas versus criticizing a person's abilities and perhaps we can dial back the rhetoric a bit to keep the discussion focused and positive. Sincerely, - Chris/Fleep Chris M. Collins (SL: Fleep Tuque) Project Manager, UC Second Life Second Life Ambassador, Ohio Learning Network UCit Instructional & Research Computing University of Cincinnati 406E Zimmer Hall PO Box 210088 Cincinnati, OH 45221-0088 (513)556-3018 chris.collins@uc.edu UC Second Life: http://homepages.uc.edu/secondlife OLN Second Life: http://www.oln.org/emerging_technologies/emtech.php On Sun, Apr 3, 2011 at 4:08 PM, Dzonatas Sol wrote: > As stated, "it didn't happen." The concepts and ideas are still iconic > natured and useful as such. It's iconic usefulness as like that of infinite > tense that all English teachers want their students to write in & with > figure-of-speech, its the wrong way. That is the nature of English infinite > tense. All other tenses are correct, and teachers expect you to "correct" > infinite tense, yet they don't teach that. That's the basis of sentience. > Infinite tense is logically always in error. > > Now with that in mind, "we" did not misunderstand the issues. Don't blame > others until you look in the mirror more. What makes sense to you doesn't > guarantee it makes sense to everybody else. The "graphic form" does not > denote sense to visual people! Don't assume this! Like I said, visual people > need complete ideas. Visual people don't remember dictionary definitions as > much as auditory people don't remember graphic notations. It's because 60% > of the people are auditory (they remember active speech) they are at > constant battle with themselves in attempts to help the other 40% everywhere > they don't need help -- is why there is ANY miscomprehension. > > Visual people find it completely dumb idea to have dictionaries full words > that have any prefixes or suffixes, as that is wasted resources. Only the > root words with possible prefixes and suffixes are of need. The reason why > they don't exist this way is because of "figure-of-speech" and proof of that > 60%. Unless you are somehow smarter than the best and the brightest, I doubt > you can solely point out bad ideas such as dictionaries that list every > combination of root words with every possible suffix and prefix individually > such that basically kills us off slowly with lack of symbiotic flow due to > trees used for the numerous pages published as scholarly works. It's a > killing. > > > > Morgaine wrote: > >> I'm afraid you misunderstand the issue, Dzonatas. I'll add a bit of >> background. >> >> This has nothing to do with visual versus graphical presentation. I'm a >> big fan of both, and like yourself I think spatially most of the time about >> architectures, which is a graphic form. Likewise, it has nothing to do with >> accessibility whatsoever, of which I've been a very enthusiastic proponent >> in Second Life for many years. >> >> The only thing with which the "domain" argument is concerned is whether >> the concept reflects something useful in VWRAP that we can observe, query, >> interact with, or design a protocol around. The answer is "No" on all these >> counts for "Agent Domain" in VWRAP, because it refers to a concept in OGP >> that denied interop, and it does not apply to us. >> >> As a result, far from helping anyone to understand the VWRAP architecture, >> all it does is increase the amount of confusion surrounding VWRAP, because >> it does not reflect anything useful about what we are trying to implement. >> >> The nearest we get in VWRAP to something that might have been conceived >> originally as the "Agent Domain" in OGP is roughly "The set of places and >> items and resources that this world will permit an agent to visit or >> interact with ", which is approximately the same thing as saying "the closed >> walled garden". It is a singularly counter-productive concept for a group >> that has the important goal of achieving interop between worlds. >> >> So no, it's not helpful, either visually or otherwise. The term is just >> another obstacle on the road to VW interop. That OGP whiteboard never had >> other fluffy clouds on it labeled "Virtual world B", "Virtual world C", and >> so on. The concept of interop between worlds was denied, because Agent >> Domain controlled access to Region Domains, and so nothing outside AD+RD >> existed in OGP. >> >> But we are not designing OGP, we are designing VWRAP, a set of protocols >> that embraces interoperation between worlds as well. That is why the Agent >> Domain does not exist as a useful concept in this work. It elevates world >> closure, negates interoperation, and does not even admit other worlds into >> the picture, because Agent Domain is defined to exclude them. >> >> It's a very bad idea, both in text and as fluffy clouds. >> >> >> Morgaine. >> > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --0016362848b409508904a00c790b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On a purely academic side note, the theory of "learning styles" h= as been disputed and some would even say debunked. =A0Current research show= s that depending upon the context and activity we're involved with and = our specific physical abilities, people generally all learn in visual, audi= tory, kinesthetic, etc. ways. =A0Unfortunately the website for the primary = journal article I wanted to reference appears to be down at the moment, but= see=A0http://chronicle.com/article/Matching-Teaching-Style-to-/49497/= =A0for a pretty good explanation. =A0

I admit that I don't know enough VWRAP history to fully = understand the crux of this debate, but=A0I'm having a hard time drawin= g the connection between criticism of how a term term like "Agent Doma= in" has been/is being used and how that relates to accessibility issue= s. =A0I hope moving forward we're all careful about being critical of i= deas versus criticizing a person's abilities and perhaps we can dial ba= ck the rhetoric a bit to keep the discussion focused and positive.


Sincerely,

- Chris/Fleep


Chris M. Collins (SL= : Fleep Tuque)
Project Manager, UC Second Life=A0
Secon= d Life Ambassador, Ohio Learning Network=A0
UCit Instructional & Research Computing
University of Ci= ncinnati=A0
406E Zimmer Hall
PO Box 210088
Ci= ncinnati, OH 45221-0088
(513)556-3018






On Sun, Apr 3, 2011 at 4:08 PM, Dzonatas Sol &l= t;dzonatas@gmail.com> w= rote:
As stated, "it didn't happen."= ; The concepts and ideas are still iconic natured and useful as such. It= 9;s iconic usefulness as like that of infinite tense that all English teach= ers want their students to write in & with figure-of-speech, its the wr= ong way. That is the nature of English infinite tense. All other tenses are= correct, and teachers expect you to "correct" infinite tense, ye= t they don't teach that. That's the basis of sentience. Infinite te= nse is logically always in error.

Now with that in mind, "we" did not misunderstand the issues. Don= 't blame others until you look in the mirror more. What makes sense to = you doesn't guarantee it makes sense to everybody else. The "graph= ic form" does not denote sense to visual people! Don't assume this= ! Like I said, visual people need complete ideas. Visual people don't r= emember dictionary definitions as much as auditory people don't remembe= r graphic notations. It's because 60% of the people are auditory (they = remember active speech) they are at constant battle with themselves in atte= mpts to help the other 40% everywhere they don't need help -- is why th= ere is ANY miscomprehension.

Visual people find it completely dumb idea to have dictionaries full words = that have any prefixes or suffixes, as that is wasted resources. Only the r= oot words with possible prefixes and suffixes are of need. The reason why t= hey don't exist this way is because of "figure-of-speech" and= proof of that 60%. Unless you are somehow smarter than the best and the br= ightest, I doubt you can solely point out bad ideas such as dictionaries th= at list every combination of root words with every possible suffix and pref= ix individually such that basically kills us off slowly with lack of symbio= tic flow due to trees used for the numerous pages published as scholarly wo= rks. It's a killing.



Morgaine wrote:
I'm afraid you misunderstand the issue, Dzonatas. =A0I'll add a bit= of background.

This has nothing to do with visual versus graphical presentation. =A0I'= m a big fan of both, and like yourself I think spatially most of the time a= bout architectures, which is a graphic form. =A0Likewise, it has nothing to= do with accessibility whatsoever, of which I've been a very enthusiast= ic proponent in Second Life for many years.

The only thing with which the "domain" argument is concerned is w= hether the concept reflects something useful in VWRAP that we can observe, = query, interact with, or design a protocol around. =A0The answer is "N= o" on all these counts for "Agent Domain" in VWRAP, because = it refers to a concept in OGP that denied interop, and it does not apply to= us.

As a result, far from helping anyone to understand the VWRAP architecture, = all it does is increase the amount of confusion surrounding VWRAP, because = it does not reflect anything useful about what we are trying to implement.<= br>
The nearest we get in VWRAP to something that might have been conceived ori= ginally as the "Agent Domain" in OGP is roughly "The set of = places and items and resources that this world will permit an agent to visi= t or interact with ", which is approximately the same thing as saying = "the closed walled garden". =A0It is a singularly counter-product= ive concept for a group that has the important goal of achieving interop be= tween worlds.

So no, it's not helpful, either visually or otherwise. =A0The term is j= ust another obstacle on the road to VW interop. =A0That OGP whiteboard neve= r had other fluffy clouds on it labeled "Virtual world B", "= Virtual world C", and so on. =A0The concept of interop between worlds = was denied, because Agent Domain controlled access to Region Domains, and s= o nothing outside AD+RD existed in OGP.

But we are not designing OGP, we are designing VWRAP, a set of protocols th= at embraces interoperation between worlds as well. =A0That is why the Agent= Domain does not exist as a useful concept in this work. =A0It elevates wor= ld closure, negates interoperation, and does not even admit other worlds in= to the picture, because Agent Domain is defined to exclude them.

It's a very bad idea, both in text and as fluffy clouds.


Morgaine.

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

--0016362848b409508904a00c790b-- From dzonatas@gmail.com Sun Apr 3 17:40:19 2011 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 2413F3A6889 for ; Sun, 3 Apr 2011 17:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] 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 XVJVAEG3VqCT for ; Sun, 3 Apr 2011 17:40:16 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 747773A68C0 for ; Sun, 3 Apr 2011 17:40:16 -0700 (PDT) Received: by iye19 with SMTP id 19so6366213iye.31 for ; Sun, 03 Apr 2011 17:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8VVCSKLy6IrFSXJ0DLvjrJPn/zfudy9241jE/Ct1GKs=; b=pJ+Z3v/KPa1gC07E3PA5jh4wkVS8Fu1jB8/lIknX7w9lPZGEiSVYma3vD/vZ2Cdofb 4NdD/VAIX9pnFPbAHPV0bigwwi/L9hscjq9PZwI0srBQfqbmpDjqj/xFY70/WTgXIY7T GJqVxxBAW7ehp8L+VdP1wneA7Mv1PNI1nwDH4= 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=YaD8CyWdEQYqZc1/3ol9YmImQe93dcEwAUowfgG9ukCeaTc3GYMbrJxbkSa7rF5PIE ruVHEUNu3k1UL7ewSzK8yKXLffPXCvp7Mi/aUbYac3KXhMXH+peqR7/YiuKZLsq/lg0/ q7VUWEgvzDnAnVKq1A6jeQQAuuNvhiZmRMi5c= Received: by 10.43.55.81 with SMTP id vx17mr549156icb.52.1301877718284; Sun, 03 Apr 2011 17:41:58 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id va4sm3095076icb.3.2011.04.03.17.41.55 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Apr 2011 17:41:56 -0700 (PDT) Message-ID: <4D991403.9000700@gmail.com> Date: Sun, 03 Apr 2011 17:42:43 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Fleep Tuque References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> <4D98B07E.8090601@gmail.com> <4D98C11D.5050208@gmail.com> <4D98D3D9.2060307@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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, 04 Apr 2011 00:40:19 -0000 It's hard to consider deaf and blind people as only theoritically deaf and theoretically blind. The differences between sight & sound is beyond theory. Consider that many have tried to falsify "learning styles" or other nature of such visual, auditory, kinetic, and kinesthetic, and believed they have debunked such issues, only makes it official science. Science is based on falsifiable claims and not unfalsifiable claims. Every scientist either goes through such evil or checks out with their PhD (the universities' gamble/gambits), as their claims are philosophy until otherwise official. Those are the obvious limits of science. Usual "learning styles" only relate to the first 20 years (applied limits), and then after that more official science backs up the cases. It's just not easy to debunk real world experiences outside of educational institutions. Either people are born as experts as beings that learn the same way, or we are all learn different. Neither have been proven, and the link you gave doesn't debunk either. There are "strength" groups defined, however. By the tried and proven tests (psychology) that 60% auditory is very definitive. Given that majority rules usually means auditory wins@>50%, its hard for any other "strength" group to make their case. That's enough signifigant enough to remain useful weight in various cases in court where it is mainly based on "hearings". Court only gives interpreters to those that are obvious in need of them. Any effort to debunk these differences only make it harder for those that are not so obviously different from "hearing" enabled. Given that courts still haven't changed, it remains that 'hard to draw such connections' even in such cases. Otherwise, more back on track, VWs have helped in many areas in regards to accessibilities. I just hate to detail every reason and make examples. Carefully, hope... Fleep Tuque wrote: > On a purely academic side note, the theory of "learning styles" has > been disputed and some would even say debunked. �Current research > shows that depending upon the context and activity we're involved with > and our specific physical abilities, people generally all learn in > visual, auditory, kinesthetic, etc. ways. �Unfortunately the website > for the primary journal article I wanted to reference appears to be > down at the moment, but > see�http://chronicle.com/article/Matching-Teaching-Style-to-/49497/�for > a pretty good explanation. � > > I admit that I don't know enough VWRAP history to fully understand the > crux of this debate, but�I'm having a hard time drawing the connection > between criticism of how a term term like "Agent Domain" has been/is > being used and how that relates to accessibility issues. �I hope > moving forward we're all careful about being critical of ideas versus > criticizing a person's abilities and perhaps we can dial back the > rhetoric a bit to keep the discussion focused and positive. > > > Sincerely, > > - Chris/Fleep > > > Chris M. Collins (SL: Fleep Tuque) > Project Manager, UC Second Life� > Second Life Ambassador, Ohio Learning Network� > UCit Instructional & Research Computing > University of Cincinnati� > 406E Zimmer Hall > PO Box 210088 > Cincinnati, OH 45221-0088 > (513)556-3018 > chris.collins@uc.edu > > UC Second Life: � http://homepages.uc.edu/secondlife > OLN Second Life: http://www.oln.org/emerging_technologies/emtech.php > > > > > > On Sun, Apr 3, 2011 at 4:08 PM, Dzonatas Sol > wrote: > > As stated, "it didn't happen." The concepts and ideas are still > iconic natured and useful as such. It's iconic usefulness as like > that of infinite tense that all English teachers want their > students to write in & with figure-of-speech, its the wrong way. > That is the nature of English infinite tense. All other tenses are > correct, and teachers expect you to "correct" infinite tense, yet > they don't teach that. That's the basis of sentience. Infinite > tense is logically always in error. > > Now with that in mind, "we" did not misunderstand the issues. > Don't blame others until you look in the mirror more. What makes > sense to you doesn't guarantee it makes sense to everybody else. > The "graphic form" does not denote sense to visual people! Don't > assume this! Like I said, visual people need complete ideas. > Visual people don't remember dictionary definitions as much as > auditory people don't remember graphic notations. It's because 60% > of the people are auditory (they remember active speech) they are > at constant battle with themselves in attempts to help the other > 40% everywhere they don't need help -- is why there is ANY > miscomprehension. > > Visual people find it completely dumb idea to have dictionaries > full words that have any prefixes or suffixes, as that is wasted > resources. Only the root words with possible prefixes and suffixes > are of need. The reason why they don't exist this way is because > of "figure-of-speech" and proof of that 60%. Unless you are > somehow smarter than the best and the brightest, I doubt you can > solely point out bad ideas such as dictionaries that list every > combination of root words with every possible suffix and prefix > individually such that basically kills us off slowly with lack of > symbiotic flow due to trees used for the numerous pages published > as scholarly works. It's a killing. > > > > Morgaine wrote: > > I'm afraid you misunderstand the issue, Dzonatas. �I'll add a > bit of background. > > This has nothing to do with visual versus graphical > presentation. �I'm a big fan of both, and like yourself I > think spatially most of the time about architectures, which is > a graphic form. �Likewise, it has nothing to do with > accessibility whatsoever, of which I've been a very > enthusiastic proponent in Second Life for many years. > > The only thing with which the "domain" argument is concerned > is whether the concept reflects something useful in VWRAP that > we can observe, query, interact with, or design a protocol > around. �The answer is "No" on all these counts for "Agent > Domain" in VWRAP, because it refers to a concept in OGP that > denied interop, and it does not apply to us. > > As a result, far from helping anyone to understand the VWRAP > architecture, all it does is increase the amount of confusion > surrounding VWRAP, because it does not reflect anything useful > about what we are trying to implement. > > The nearest we get in VWRAP to something that might have been > conceived originally as the "Agent Domain" in OGP is roughly > "The set of places and items and resources that this world > will permit an agent to visit or interact with ", which is > approximately the same thing as saying "the closed walled > garden". �It is a singularly counter-productive concept for a > group that has the important goal of achieving interop between > worlds. > > So no, it's not helpful, either visually or otherwise. �The > term is just another obstacle on the road to VW interop. �That > OGP whiteboard never had other fluffy clouds on it labeled > "Virtual world B", "Virtual world C", and so on. �The concept > of interop between worlds was denied, because Agent Domain > controlled access to Region Domains, and so nothing outside > AD+RD existed in OGP. > > But we are not designing OGP, we are designing VWRAP, a set of > protocols that embraces interoperation between worlds as well. > �That is why the Agent Domain does not exist as a useful > concept in this work. �It elevates world closure, negates > interoperation, and does not even admit other worlds into the > picture, because Agent Domain is defined to exclude them. > > It's a very bad idea, both in text and as fluffy clouds. > > > Morgaine. > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Sun Apr 3 17:57:33 2011 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 AEA2B3A68E7 for ; Sun, 3 Apr 2011 17:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] 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 WxrWL-+kMh3n for ; Sun, 3 Apr 2011 17:57:31 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id ED7E43A68CE for ; Sun, 3 Apr 2011 17:57:30 -0700 (PDT) Received: by iwn39 with SMTP id 39so6188487iwn.31 for ; Sun, 03 Apr 2011 17:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=H4khJki2B1UowT6X2PZSPs3/H2DsZ5MAqL1bzGs1zSI=; b=ThQaPLhBnSPUYXE2DBU6sK92ZFlvf7bt9Yzt3hAP2yrW2c+EM/vvrjEAVfD1NTmEiO KqzlrfN6aDnLguFYaZDnBSvShQxERHDLSgv1X6jpMRyWelP4NdCdUzWJiQ29d2gbaBNK g7eQzm/DxzrMqj44yU9krs58Rwce1nY61dU0U= 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=WsYWfNb0uDib7ANmLCBn3pPdr8B0t1Xj+QuopjLBcLKuhZOYpghQMr/Hi6q4kwwFWH 75LuxUxh5dhy0pJ8eFRLbMG1edc2CtgfyO6w5pf1nr0QvcjIyhO7XndWjyOsowEaI5M6 4G3Ws2D3ByBK4lj29MlZRh0SFJozU6jfds6aU= Received: by 10.42.131.67 with SMTP id y3mr4123136ics.363.1301878752930; Sun, 03 Apr 2011 17:59:12 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id wo15sm3103570icb.4.2011.04.03.17.59.11 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Apr 2011 17:59:12 -0700 (PDT) Message-ID: <4D99180F.5060100@gmail.com> Date: Sun, 03 Apr 2011 17:59:59 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Dzonatas Sol References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> <4D98B07E.8090601@gmail.com> <4D98C11D.5050208@gmail.com> <4D98D3D9.2060307@gmail.com> <4D991403.9000700@gmail.com> In-Reply-To: <4D991403.9000700@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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, 04 Apr 2011 00:57:34 -0000 Maybe I should note I'm also eager to see some VW that makes it possible for the deaf or of any such degree can use the VW as the courtroom and not have to deal with anything in terms of "hearing", that meaning, or anything that would be regarded as interpretation or translations. I know I'm not the only one, especially when people are serious to create such practice instead feel so alienated. (Or, feel alienated by any need to having to explain oneself... to any disability). Of course, security is kept in mind between VWs & simulations. Dzonatas Sol wrote: > It's hard to consider deaf and blind people as only theoritically deaf > and theoretically blind. The differences between sight & sound is > beyond theory. > > Consider that many have tried to falsify "learning styles" or other > nature of such visual, auditory, kinetic, and kinesthetic, and > believed they have debunked such issues, only makes it official > science. Science is based on falsifiable claims and not unfalsifiable > claims. Every scientist either goes through such evil or checks out > with their PhD (the universities' gamble/gambits), as their claims are > philosophy until otherwise official. Those are the obvious limits of > science. > > Usual "learning styles" only relate to the first 20 years (applied > limits), and then after that more official science backs up the cases. > It's just not easy to debunk real world experiences outside of > educational institutions. Either people are born as experts as beings > that learn the same way, or we are all learn different. Neither have > been proven, and the link you gave doesn't debunk either. There are > "strength" groups defined, however. By the tried and proven tests > (psychology) that 60% auditory is very definitive. Given that majority > rules usually means auditory wins@>50%, its hard for any other > "strength" group to make their case. That's enough signifigant enough > to remain useful weight in various cases in court where it is mainly > based on "hearings". Court only gives interpreters to those that are > obvious in need of them. Any effort to debunk these differences only > make it harder for those that are not so obviously different from > "hearing" enabled. Given that courts still haven't changed, it remains > that 'hard to draw such connections' even in such cases. > > Otherwise, more back on track, VWs have helped in many areas in > regards to accessibilities. I just hate to detail every reason and > make examples. Carefully, hope... > > Fleep Tuque wrote: >> On a purely academic side note, the theory of "learning styles" has >> been disputed and some would even say debunked. �Current research >> shows that depending upon the context and activity we're involved >> with and our specific physical abilities, people generally all learn >> in visual, auditory, kinesthetic, etc. ways. �Unfortunately the >> website for the primary journal article I wanted to reference appears >> to be down at the moment, but >> see�http://chronicle.com/article/Matching-Teaching-Style-to-/49497/�for >> a pretty good explanation. � >> >> I admit that I don't know enough VWRAP history to fully understand >> the crux of this debate, but�I'm having a hard time drawing the >> connection between criticism of how a term term like "Agent Domain" >> has been/is being used and how that relates to accessibility issues. >> �I hope moving forward we're all careful about being critical of >> ideas versus criticizing a person's abilities and perhaps we can dial >> back the rhetoric a bit to keep the discussion focused and positive. >> >> >> Sincerely, >> >> - Chris/Fleep >> >> >> Chris M. Collins (SL: Fleep Tuque) >> Project Manager, UC Second Life� >> Second Life Ambassador, Ohio Learning Network� >> UCit Instructional & Research Computing >> University of Cincinnati� >> 406E Zimmer Hall >> PO Box 210088 >> Cincinnati, OH 45221-0088 >> (513)556-3018 >> chris.collins@uc.edu >> >> UC Second Life: � http://homepages.uc.edu/secondlife >> OLN Second Life: http://www.oln.org/emerging_technologies/emtech.php >> >> >> >> >> >> On Sun, Apr 3, 2011 at 4:08 PM, Dzonatas Sol > > wrote: >> >> As stated, "it didn't happen." The concepts and ideas are still >> iconic natured and useful as such. It's iconic usefulness as like >> that of infinite tense that all English teachers want their >> students to write in & with figure-of-speech, its the wrong way. >> That is the nature of English infinite tense. All other tenses are >> correct, and teachers expect you to "correct" infinite tense, yet >> they don't teach that. That's the basis of sentience. Infinite >> tense is logically always in error. >> >> Now with that in mind, "we" did not misunderstand the issues. >> Don't blame others until you look in the mirror more. What makes >> sense to you doesn't guarantee it makes sense to everybody else. >> The "graphic form" does not denote sense to visual people! Don't >> assume this! Like I said, visual people need complete ideas. >> Visual people don't remember dictionary definitions as much as >> auditory people don't remember graphic notations. It's because 60% >> of the people are auditory (they remember active speech) they are >> at constant battle with themselves in attempts to help the other >> 40% everywhere they don't need help -- is why there is ANY >> miscomprehension. >> >> Visual people find it completely dumb idea to have dictionaries >> full words that have any prefixes or suffixes, as that is wasted >> resources. Only the root words with possible prefixes and suffixes >> are of need. The reason why they don't exist this way is because >> of "figure-of-speech" and proof of that 60%. Unless you are >> somehow smarter than the best and the brightest, I doubt you can >> solely point out bad ideas such as dictionaries that list every >> combination of root words with every possible suffix and prefix >> individually such that basically kills us off slowly with lack of >> symbiotic flow due to trees used for the numerous pages published >> as scholarly works. It's a killing. >> >> >> >> Morgaine wrote: >> >> I'm afraid you misunderstand the issue, Dzonatas. �I'll add a >> bit of background. >> >> This has nothing to do with visual versus graphical >> presentation. �I'm a big fan of both, and like yourself I >> think spatially most of the time about architectures, which is >> a graphic form. �Likewise, it has nothing to do with >> accessibility whatsoever, of which I've been a very >> enthusiastic proponent in Second Life for many years. >> >> The only thing with which the "domain" argument is concerned >> is whether the concept reflects something useful in VWRAP that >> we can observe, query, interact with, or design a protocol >> around. �The answer is "No" on all these counts for "Agent >> Domain" in VWRAP, because it refers to a concept in OGP that >> denied interop, and it does not apply to us. >> >> As a result, far from helping anyone to understand the VWRAP >> architecture, all it does is increase the amount of confusion >> surrounding VWRAP, because it does not reflect anything useful >> about what we are trying to implement. >> >> The nearest we get in VWRAP to something that might have been >> conceived originally as the "Agent Domain" in OGP is roughly >> "The set of places and items and resources that this world >> will permit an agent to visit or interact with ", which is >> approximately the same thing as saying "the closed walled >> garden". �It is a singularly counter-productive concept for a >> group that has the important goal of achieving interop between >> worlds. >> >> So no, it's not helpful, either visually or otherwise. �The >> term is just another obstacle on the road to VW interop. �That >> OGP whiteboard never had other fluffy clouds on it labeled >> "Virtual world B", "Virtual world C", and so on. �The concept >> of interop between worlds was denied, because Agent Domain >> controlled access to Region Domains, and so nothing outside >> AD+RD existed in OGP. >> >> But we are not designing OGP, we are designing VWRAP, a set of >> protocols that embraces interoperation between worlds as well. >> �That is why the Agent Domain does not exist as a useful >> concept in this work. �It elevates world closure, negates >> interoperation, and does not even admit other worlds into the >> picture, because Agent Domain is defined to exclude them. >> >> It's a very bad idea, both in text and as fluffy clouds. >> >> >> Morgaine. >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From carlo@alinoe.com Mon Apr 4 05:09:49 2011 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 49E8D3A6989 for ; Mon, 4 Apr 2011 05:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_00=-2.599, SARE_DIPLOMA2=0.9] 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 iH80bQ3zOnxp for ; Mon, 4 Apr 2011 05:09:48 -0700 (PDT) Received: from fep15.mx.upcmail.net (fep15.mx.upcmail.net [62.179.121.35]) by core3.amsl.com (Postfix) with ESMTP id 51F513A67A1 for ; Mon, 4 Apr 2011 05:09:47 -0700 (PDT) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep15-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110404121128.UFIS1633.viefep15-int.chello.at@edge03.upcmail.net>; Mon, 4 Apr 2011 14:11:28 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge03.upcmail.net with edge id TQBS1g02T0FlQed03QBTsL; Mon, 04 Apr 2011 14:11:28 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q6icw-0007Eg-HA; Mon, 04 Apr 2011 14:11:26 +0200 Date: Mon, 4 Apr 2011 14:11:26 +0200 From: Carlo Wood To: "dyerbrookme@juno.com" Message-ID: <20110404141126.621cfcec@hikaru.localdomain> In-Reply-To: <20110402.161242.14055.0@webmail07.vgs.untd.com> References: <20110402.161242.14055.0@webmail07.vgs.untd.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=HQ3F56nxkum+cgCiDL7AXQpbvw7DWrWCBJRnYYnM0Zc= c=1 sm=0 a=CxkBH-eyvKEA:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=NoAKp6exAAAA:8 a=BjFOTwK7AAAA:8 a=3D6hEhHG_RrHcGq_CaUA:9 a=CjuIK1q_8ugA:10 a=B0cvAcWxpcAA:10 a=bW3kdApBr58A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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, 04 Apr 2011 12:09:49 -0000 On Sat, 2 Apr 2011 20:12:42 GMT "dyerbrookme@juno.com" wrote: > Dear Patnad, I post on this list about twice a year. My post is not a > rant, it is not a flame, it is not a troll, it is not a personal > attack. For the record, whatever it was.. I choose deliberately to ignore it (not reply) and I stopped reading somewhere halfway when it was clear what kind of person was writing it. So call it what you want, you might want to reconsider your diplomatic skills. -- Carlo Wood From izzyalanis@gmail.com Mon Apr 4 20:00:34 2011 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 4E0083A6840 for ; Mon, 4 Apr 2011 20:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 oDpx2bLOreEz for ; Mon, 4 Apr 2011 20:00:33 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B06D63A6866 for ; Mon, 4 Apr 2011 20:00:32 -0700 (PDT) Received: by fxm15 with SMTP id 15so4967890fxm.31 for ; Mon, 04 Apr 2011 20:02:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OpgUR6PqQ7dfQ7lNwEOsdaB4cBvYal47p6AWv/S+Y60=; b=C28I260P60hfRTXk98DX8X+L9n9gCPJ5yGUET2d5H6XB5y3+Ds1O4PP71njanNkt/l +UEoGczxVxflExqm2f9I39nrOvSeULz1EyRZRuipuiC981P2WDXlIrtstr8K3wTXKkod H7uVFnF7lVRcTqTfhbsRc9bjxjIVPNjYC1Xwk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Nb+9xcN7uJy/rOA2jctnLghfujvEG/CyzFv2x9JSa+ceTid4iqd/XuMuXmW2qyz7/b LR3ZYvA6nN2SLZJk0bo6bF6u+SUOhhVc55iyDXbFnV5cE9clfayQ4qlX0NTxnUSUGqHT hKFIrtlY2tE2YzYQuQtpTzbi/UARjZAAJin1Q= MIME-Version: 1.0 Received: by 10.223.63.212 with SMTP id c20mr1114903fai.63.1301972535034; Mon, 04 Apr 2011 20:02:15 -0700 (PDT) Received: by 10.223.81.66 with HTTP; Mon, 4 Apr 2011 20:02:14 -0700 (PDT) In-Reply-To: References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> Date: Mon, 4 Apr 2011 23:02:14 -0400 Message-ID: From: Izzy Alanis To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 05 Apr 2011 03:00:34 -0000 I applaud the effort to further the documentation... but, what does it mean to say "then that change is accepted as part of VWRAP"? > * Whenever a change X in the protocol is proposed (which might be > an addition, a change of existing protocol or even deletion: any > change, making the protocol > *# (VWRAP) go from A --> B), then > that change is accepted as part of VWRAP provided that: > *# Protocol B can do everything that A could do. > *# Good use-case justification for B is provided. > *# Implementation requirements of B are listed. Things that have *consensus* become part of the protocol. If changes meet reasonable criteria (such as the above), they will be more likely have consensus. Changes that do things like break backwards compatibility or limit 'flexibility' will likely be hard to get consensus on. But I agree with Mike when he said "We don't need to make a process that forces agreement under a set of terms...". That's not an argument against flexibility. But I do question why we need to have consensus on this abstract meta-issue? Do we really need explicit written consensus on overly general principles like "flexibility is good", or "scalability is good" or "sunshine and puppies are good" to make progress? Specific features and details will or will not become part of the protocol based on their merits. If a minority interest (a potential "vetoer") has no interest in a particular use case, and their concerns are resolved or mitigated -- by limiting the impact to their implementation of the previous version of the protocol, making the change/proposed feature optional, etc -- then we can still reach consensus. Consensus doesn't mean unanimity. On Fri, Apr 1, 2011 at 11:01 AM, Morgaine wrote: > I agree 100% with every point made by Carlo in this post. > > Please note that I have extended Carlo's 2-clause proposal from his earli= er > email, because in his original formulation, flexibility in the protocol i= s > easily vetoed by backward-looking detractors or vested interests. > > My formulation is here -- > http://www.ietf.org/mail-archive/web/vwrap/current/msg00637.html .=A0 I a= m > sure it can be improved still further. > > My goal is that (i) new areas of flexibility should be justified by use > cases and supported by engineering solutions, and (ii) not subject to vet= o > by those who are not interested in those use cases.=A0 That's how you mak= e > technical progress. > > > Morgaine. > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Fri, Apr 1, 2011 at 3:13 PM, Carlo Wood wrote: >> >> On Wed, 30 Mar 2011 14:27:27 +0000 >> "Dickson, Mike (ISS Software)" wrote: >> >> > We don't need to make a process that forces agreement under a set of >> > terms. =A0That's not how the IETF works. =A0We need consensus and >> > documents. >> >> Nobody forces you to anything. I'm asking if there is consensus >> about this point. Frankly, I'm disappointed that you disagree >> already - at THIS level of abstraction. Perhaps it's caused by >> a false sense of fear that you would be forced to accept things >> into the protocol: you clearly want control. You want to decide >> on a case by case basis if you like it or not. >> >> But hell, that is NOT possible at this abstraction level. >> Please rethink carefully what the proposal means: do you REALLY >> want to reject the Ideal of an open protocol that doesn't deny >> support for use-cases that YOU don't want? >> >> > =A0As a contributor I'll choose to agree or disagree based >> > on the topic. =A0And in some cases I'm not sure I'd choose flexibility >> > over stability, etc. >> >> I don't see the 'etc' here. And IF the minimal support that >> an implementer would have to add who does NOT needed X would >> lead to instability then surely you wouldn't be able to speak >> of "No substantial extra demands are being made"! >> >> If implementation is so difficult, even for implementers NOT >> needing it, that it causes the danger of instability then you >> have EVER possibility to go against it, even if now you agree >> with the Principle of trying to be flexible. >> >> > It seems to me we've sorted drifted to a point we're there are 2 >> > camps and a proposal was made for how to deal with it. =A0There are >> > those that want to work on service level interop. =A0And others want t= o >> > define the whole concept of virtual world interop. IMO we need to >> > either agree that seperation exists and arrange the docs so it >> > describes the 2 work streams or agree that we can't agree and >> > disband. =A0The service level interop. is a subset of the other and >> > given our track record I prefer to walk rather than run. >> >> I am not really sure how this applies to making the choice if >> you want to be flexible, or - put differently - want to cripple >> the protocol to make certain applications of it impossible. >> >> > =A0And I don't buy the "evil corporate interests" argument. >> >> ... unless this is the case. And you just want to win a battle >> before it started. >> >> > =A0Ideally if we do this right there *should* be some participation >> > from business interests that are looking at the space. >> >> A flexible protocol would be superset of what those businesses >> need (see point 1: Protocol B can do everything that A could do). >> So, if they would be interested when the protocol can only do A, >> please explain why they won't be interested anymore when it >> can do B? >> >> > Mike (speaking as me and not for HP) >> >> -- >> Carlo Wood >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > From morgaine.dinova@googlemail.com Mon Apr 4 21:28:49 2011 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 EB19E3A6886 for ; Mon, 4 Apr 2011 21:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.789 X-Spam-Level: X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dz0y8wQl+rBv for ; Mon, 4 Apr 2011 21:28:46 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 76E963A6877 for ; Mon, 4 Apr 2011 21:28:46 -0700 (PDT) Received: by qwc23 with SMTP id 23so877212qwc.31 for ; Mon, 04 Apr 2011 21:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=z53W6WDN1tXYvZvVbo/r0SBq5rqoqwHawp67jdcTzq8=; b=tbnVBijGQWRMe79z2EW7/zP/rfH9NPPhH8ITkK1kd+8xq1tGbYapbGC2anOPowaxKx eaCn/vmUP6C62nIe+gYedCfjxOhKkVLqB6qQcoXE/ub2MRAnuhgMZGawRGybmPT3E+oR fwjDl7xevh5cmiDUcJHv7n8idM7QBKvezhO9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rKy1/eZw8baAeOWrABa+p/Ov2nk5l+SnEhVbOdqHVhHC5XlCQMgmKFPVE8yd97Q5aS xho7nEB6HxM59op3SyLSDEhFQim4nWfjKtI5qr7+1v6tAOLMfyir3XjUXXoA/lYmLJgK 3BW+ZR8cBs8Fh/1ARnzS/87JbYPri+kL1v6nQ= MIME-Version: 1.0 Received: by 10.229.124.145 with SMTP id u17mr6514858qcr.71.1301977828525; Mon, 04 Apr 2011 21:30:28 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Mon, 4 Apr 2011 21:30:28 -0700 (PDT) In-Reply-To: References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> Date: Tue, 5 Apr 2011 05:30:28 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd25caef986f504a0245530 Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 05 Apr 2011 04:28:49 -0000 --000e0cd25caef986f504a0245530 Content-Type: text/plain; charset=ISO-8859-1 I expect that Carlo wanted prior agreement on the principle of generally accepting superset requirements simply to avoid perpetual wrangling between progressives and regressives. Or if that term is disliked (nobody likes to admit that they are regressive after all), between those who want to design for tomorrow and those who want to design for today. And it's not only a theoretical worry either, because we've already seen several instances of participants not wanting to design for tomorrow, for example in not wanting the open metaverse of VW tourism, or arguing against open extensibility, or rejecting IPv6-specific enhancements. I'm on the "design for tomorrow" platform, but I do recognize that if you want the cart pulled in a specific direction then you have to be the principle puller yourself. You can't expect others who don't share your interest to pull it for you. This is why I added points #2 and #3 so that the onus is on the people who have the superset requirements to justify them and do the design legwork for them. Point #1 is just as important though. As long as a new requirement results in a protocol that is a superset of the previous one, detractors argue against it either because they see very strong engineering reasons why it is bad or else they argue unconvincingly, because having your requirement included but vetoing someone else's requirement just because you don't want it is unacceptable. This is why supersets are important: they replace one-side-wins either/or arguments by both-sides-win either/and arguments, which gain agreement much more easily. Funnily enough, we've already heard arguments against the motherhood and apple pie of scalability, so I had to chuckle when I read your penultimate paragraph. :-) I support Carlo's suggestion very strongly. These are such early days in the evolution of virtual worlds that designing for today seems just plain silly to me, and I would like to see "design for tomorrow" enshrined by agreement. Morgaine. =============================== On Tue, Apr 5, 2011 at 4:02 AM, Izzy Alanis wrote: > I applaud the effort to further the documentation... but, what does it > mean to say "then that change is accepted as part of VWRAP"? > > > * Whenever a change X in the protocol is proposed (which might be > > an addition, a change of existing protocol or even deletion: any > > change, making the protocol > *# (VWRAP) go from A --> B), then > > that change is accepted as part of VWRAP provided that: > > *# Protocol B can do everything that A could do. > > *# Good use-case justification for B is provided. > > *# Implementation requirements of B are listed. > > Things that have *consensus* become part of the protocol. If changes > meet reasonable criteria (such as the above), they will be more likely > have consensus. Changes that do things like break backwards > compatibility or limit 'flexibility' will likely be hard to get > consensus on. > > But I agree with Mike when he said "We don't need to make a process > that forces agreement under a set of terms...". > > That's not an argument against flexibility. But I do question why we > need to have consensus on this abstract meta-issue? Do we really need > explicit written consensus on overly general principles like > "flexibility is good", or "scalability is good" or "sunshine and > puppies are good" to make progress? Specific features and details will > or will not become part of the protocol based on their merits. > > If a minority interest (a potential "vetoer") has no interest in a > particular use case, and their concerns are resolved or mitigated -- > by limiting the impact to their implementation of the previous version > of the protocol, making the change/proposed feature optional, etc -- > then we can still reach consensus. Consensus doesn't mean unanimity. > > > > On Fri, Apr 1, 2011 at 11:01 AM, Morgaine > wrote: > > I agree 100% with every point made by Carlo in this post. > > > > Please note that I have extended Carlo's 2-clause proposal from his > earlier > > email, because in his original formulation, flexibility in the protocol > is > > easily vetoed by backward-looking detractors or vested interests. > > > > My formulation is here -- > > http://www.ietf.org/mail-archive/web/vwrap/current/msg00637.html . I am > > sure it can be improved still further. > > > > My goal is that (i) new areas of flexibility should be justified by use > > cases and supported by engineering solutions, and (ii) not subject to > veto > > by those who are not interested in those use cases. That's how you make > > technical progress. > > > > > > Morgaine. > > > > > > > > > > ===================== > > > > On Fri, Apr 1, 2011 at 3:13 PM, Carlo Wood wrote: > >> > >> On Wed, 30 Mar 2011 14:27:27 +0000 > >> "Dickson, Mike (ISS Software)" wrote: > >> > >> > We don't need to make a process that forces agreement under a set of > >> > terms. That's not how the IETF works. We need consensus and > >> > documents. > >> > >> Nobody forces you to anything. I'm asking if there is consensus > >> about this point. Frankly, I'm disappointed that you disagree > >> already - at THIS level of abstraction. Perhaps it's caused by > >> a false sense of fear that you would be forced to accept things > >> into the protocol: you clearly want control. You want to decide > >> on a case by case basis if you like it or not. > >> > >> But hell, that is NOT possible at this abstraction level. > >> Please rethink carefully what the proposal means: do you REALLY > >> want to reject the Ideal of an open protocol that doesn't deny > >> support for use-cases that YOU don't want? > >> > >> > As a contributor I'll choose to agree or disagree based > >> > on the topic. And in some cases I'm not sure I'd choose flexibility > >> > over stability, etc. > >> > >> I don't see the 'etc' here. And IF the minimal support that > >> an implementer would have to add who does NOT needed X would > >> lead to instability then surely you wouldn't be able to speak > >> of "No substantial extra demands are being made"! > >> > >> If implementation is so difficult, even for implementers NOT > >> needing it, that it causes the danger of instability then you > >> have EVER possibility to go against it, even if now you agree > >> with the Principle of trying to be flexible. > >> > >> > It seems to me we've sorted drifted to a point we're there are 2 > >> > camps and a proposal was made for how to deal with it. There are > >> > those that want to work on service level interop. And others want to > >> > define the whole concept of virtual world interop. IMO we need to > >> > either agree that seperation exists and arrange the docs so it > >> > describes the 2 work streams or agree that we can't agree and > >> > disband. The service level interop. is a subset of the other and > >> > given our track record I prefer to walk rather than run. > >> > >> I am not really sure how this applies to making the choice if > >> you want to be flexible, or - put differently - want to cripple > >> the protocol to make certain applications of it impossible. > >> > >> > And I don't buy the "evil corporate interests" argument. > >> > >> ... unless this is the case. And you just want to win a battle > >> before it started. > >> > >> > Ideally if we do this right there *should* be some participation > >> > from business interests that are looking at the space. > >> > >> A flexible protocol would be superset of what those businesses > >> need (see point 1: Protocol B can do everything that A could do). > >> So, if they would be interested when the protocol can only do A, > >> please explain why they won't be interested anymore when it > >> can do B? > >> > >> > Mike (speaking as me and not for HP) > >> > >> -- > >> Carlo Wood > >> _______________________________________________ > >> 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 > > > > > --000e0cd25caef986f504a0245530 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I expect that Carlo wanted prior agreement on the principle of generally ac= cepting superset requirements simply to avoid perpetual wrangling between p= rogressives and regressives.=A0 Or if that term is disliked (nobody likes t= o admit that they are regressive after all), between those who want to desi= gn for tomorrow and those who want to design for today.

And it's not only a theoretical worry either, because we've alr= eady seen several instances of participants not wanting to design for tomor= row, for example in not wanting the open metaverse of VW tourism, or arguin= g against open extensibility, or rejecting IPv6-specific enhancements.

I'm on the "design for tomorrow" platform, but I do recog= nize that if you want the cart pulled in a specific direction then you have= to be the principle puller yourself.=A0 You can't expect others who do= n't share your interest to pull it for you.

This is why I added points #2 and #3 so that the onus is on the people = who have the superset requirements to justify them and do the design legwor= k for them.

Point #1 is just as important though.=A0 As long as a ne= w requirement results in a protocol that is a superset of the previous one,= detractors argue against it either because they see very strong engineerin= g reasons why it is bad or else they argue unconvincingly, because having y= our requirement included but vetoing someone else's requirement just be= cause you don't want it is unacceptable.=A0 This is why supersets are i= mportant:=A0 they replace one-side-wins either/or arguments by both-sides-w= in either/and arguments, which gain agreement much more easily.

Funnily enough, we've already heard arguments against the motherhoo= d and apple pie of scalability, so I had to chuckle when I read your penult= imate paragraph. :-)

I support Carlo's suggestion very strongly.= =A0 These are such early days in the evolution of virtual worlds that desig= ning for today seems just plain silly to me, and I would like to see "= design for tomorrow" enshrined by agreement.


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


On Tue, Apr 5, 2011 at 4:02 AM, Izzy Alanis <izzyalanis@gmail.com= > wrote:
I applaud the eff= ort to further the documentation... but, what does it
mean to say "then that change is accepted as part of VWRAP"?

> * Whenever a change X in the protocol is proposed (which might be
> an addition, a change of existing protocol or even deletion: any
> change, making the protocol > *# (VWRAP) go from A --> B), then<= br> > that change is accepted as part of VWRAP provided that:
> *# Protocol B can do everything that A could do.
> *# Good use-case justification for B is provided.
> *# Implementation requirements of B are listed.

Things that have *consensus* become part of the protocol. If changes
meet reasonable criteria (such as the above), they will be more likely
have consensus. Changes that do things like break backwards
compatibility or limit 'flexibility' will likely be hard to get
consensus on.

But I agree with Mike when he said "We don't need to make a proces= s
that forces agreement under a set of terms...".

That's not an argument against flexibility. But I do question why= we
need to have consensus on this abstract meta-issue? Do we really need
explicit written consensus on overly general principles like
"flexibility is good", or "scalability is good" or &quo= t;sunshine and
puppies are good" to make progress? Specific features and details will=
or will not become part of the protocol based on their merits.

If a minority interest (a potential "vetoer") has no interest in = a
particular use case, and their concerns are resolved or mitigated --
by limiting the impact to their implementation of the previous version
of the protocol, making the change/proposed feature optional, etc --
then we can still reach consensus. Consensus doesn't mean unanimity.


On Fri, Apr 1, 2011 at 11:01 AM, Morgaine
<mor= gaine.dinova@googlemail.com> wrote:
> I agree 100% with every point = made by Carlo in this post.
>
> Please note that I have extended Carlo's 2-clause proposal from hi= s earlier
> email, because in his original formulation, flexibility in the protoco= l is
> easily vetoed by backward-looking detractors or vested interests.
>
> My formulation is here --
> http://www.ietf.org/mail-archive/web/vwrap/current= /msg00637.html .=A0 I am
> sure it can be improved still further.
>
> My goal is that (i) new areas of flexibility should be justified by us= e
> cases and supported by engineering solutions, and (ii) not subject to = veto
> by those who are not interested in those use cases.=A0 That's how = you make
> technical progress.
>
>
> Morgaine.
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> On Fri, Apr 1, 2011 at 3:13 PM, Carlo Wood <carlo@alinoe.com> wrote:
>>
>> On Wed, 30 Mar 2011 14:27:27 +0000
>> "Dickson, Mike (ISS Software)" <mike.dickson@hp.com> wrote:
>>
>> > We don't need to make a process that forces agreement und= er a set of
>> > terms. =A0That's not how the IETF works. =A0We need conse= nsus and
>> > documents.
>>
>> Nobody forces you to anything. I'm asking if there is consensu= s
>> about this point. Frankly, I'm disappointed that you disagree<= br> >> already - at THIS level of abstraction. Perhaps it's caused by=
>> a false sense of fear that you would be forced to accept things >> into the protocol: you clearly want control. You want to decide >> on a case by case basis if you like it or not.
>>
>> But hell, that is NOT possible at this abstraction level.
>> Please rethink carefully what the proposal means: do you REALLY >> want to reject the Ideal of an open protocol that doesn't deny=
>> support for use-cases that YOU don't want?
>>
>> > =A0As a contributor I'll choose to agree or disagree base= d
>> > on the topic. =A0And in some cases I'm not sure I'd c= hoose flexibility
>> > over stability, etc.
>>
>> I don't see the 'etc' here. And IF the minimal support= that
>> an implementer would have to add who does NOT needed X would
>> lead to instability then surely you wouldn't be able to speak<= br> >> of "No substantial extra demands are being made"!
>>
>> If implementation is so difficult, even for implementers NOT
>> needing it, that it causes the danger of instability then you
>> have EVER possibility to go against it, even if now you agree
>> with the Principle of trying to be flexible.
>>
>> > It seems to me we've sorted drifted to a point we're = there are 2
>> > camps and a proposal was made for how to deal with it. =A0The= re are
>> > those that want to work on service level interop. =A0And othe= rs want to
>> > define the whole concept of virtual world interop. IMO we nee= d to
>> > either agree that seperation exists and arrange the docs so i= t
>> > describes the 2 work streams or agree that we can't agree= and
>> > disband. =A0The service level interop. is a subset of the oth= er and
>> > given our track record I prefer to walk rather than run.
>>
>> I am not really sure how this applies to making the choice if
>> you want to be flexible, or - put differently - want to cripple >> the protocol to make certain applications of it impossible.
>>
>> > =A0And I don't buy the "evil corporate interests&quo= t; argument.
>>
>> ... unless this is the case. And you just want to win a battle
>> before it started.
>>
>> > =A0Ideally if we do this right there *should* be some partici= pation
>> > from business interests that are looking at the space.
>>
>> A flexible protocol would be superset of what those businesses
>> need (see point 1: Protocol B can do everything that A could do).<= br> >> So, if they would be interested when the protocol can only do A, >> please explain why they won't be interested anymore when it >> can do B?
>>
>> > Mike (speaking as me and not for HP)
>>
>> --
>> Carlo Wood <carlo@alinoe.co= m>
>> _______________________________________________
>> 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
>
>

--000e0cd25caef986f504a0245530-- From carlo@alinoe.com Tue Apr 5 06:18:53 2011 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 A3F5528C0FE for ; Tue, 5 Apr 2011 06:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 vIiwLTDUKnPp for ; Tue, 5 Apr 2011 06:18:46 -0700 (PDT) Received: from fep19.mx.upcmail.net (fep19.mx.upcmail.net [62.179.121.39]) by core3.amsl.com (Postfix) with ESMTP id 1469E28C0E4 for ; Tue, 5 Apr 2011 06:18:45 -0700 (PDT) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep19-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110405132027.JDVG14354.viefep19-int.chello.at@edge01.upcmail.net> for ; Tue, 5 Apr 2011 15:20:27 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upcmail.net with edge id TpLS1g00n0FlQed01pLTA1; Tue, 05 Apr 2011 15:20:27 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q76BF-0000k1-MI for vwrap@ietf.org; Tue, 05 Apr 2011 15:20:26 +0200 Date: Tue, 5 Apr 2011 15:20:25 +0200 From: Carlo Wood To: vwrap@ietf.org Message-ID: <20110405152025.26ba8f77@hikaru.localdomain> In-Reply-To: References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=Nww7yNiXF4C1XGF+VcigPkOcTpD8wJaI1KQuZlH5eEk= c=1 sm=0 a=SNAFxGGoWQUA:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=pGLkceISAAAA:8 a=iq1A7DzuAAAA:8 a=BjFOTwK7AAAA:8 a=C8UJIPsWbgAKlrHuwrEA:9 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=bW3kdApBr58A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 05 Apr 2011 13:18:53 -0000 On Mon, 4 Apr 2011 23:02:14 -0400 Izzy Alanis wrote: > That's not an argument against flexibility. But I do question why we > need to have consensus on this abstract meta-issue? Do we really need > explicit written consensus on overly general principles like > "flexibility is good", or "scalability is good" or "sunshine and > puppies are good" to make progress? Specific features and details will > or will not become part of the protocol based on their merits. Clearly we do: we already can't reach consensus on something as logical (aka Spock) and trivial as my very first meta-issue as you call it. That baffles me, and to be honest, that alone is reason again for me to abandon this project. It is ridiculous that not everyone just said: Aye / Ok / Of course / trivial! I can only guess to the reasons (varying from stupidity (you'd never see such reactions on a mailinglist with math researchers) to paranoia), but it definitely is working against any progress. The discussions (and non-progress) on this mailinglist makes me think of a book I once called read, "Surely you're joking, Mr.Feynman" (http://buffman.net/ebooks/Richard_P_Feynman-Surely_Youre_Joking_Mr_Feynman_v5.pdf about page 67, starting with "This committee had men like Compton and Tolman..."). -- Carlo Wood From carlo@alinoe.com Tue Apr 5 08:13:21 2011 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 36C993A680D for ; Tue, 5 Apr 2011 08:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 eXTiPuF1mlXs for ; Tue, 5 Apr 2011 08:13:20 -0700 (PDT) Received: from fep13.mx.upcmail.net (fep13.mx.upcmail.net [62.179.121.33]) by core3.amsl.com (Postfix) with ESMTP id 32B8A3A67F5 for ; Tue, 5 Apr 2011 08:13:19 -0700 (PDT) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep13-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110405151501.NSWX1429.viefep13-int.chello.at@edge01.upcmail.net> for ; Tue, 5 Apr 2011 17:15:01 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upcmail.net with edge id TrF01g01p0FlQed01rF1SQ; Tue, 05 Apr 2011 17:15:01 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q77y8-0001cy-9D for vwrap@ietf.org; Tue, 05 Apr 2011 17:15:00 +0200 Date: Tue, 5 Apr 2011 17:15:00 +0200 From: Carlo Wood To: vwrap@ietf.org Message-ID: <20110405171500.3831ab7a@hikaru.localdomain> In-Reply-To: References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=Nww7yNiXF4C1XGF+VcigPkOcTpD8wJaI1KQuZlH5eEk= c=1 sm=0 a=SNAFxGGoWQUA:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=mK_AVkanAAAA:8 a=oUpCIMHNDJ7P_6j1WIYA:9 a=ZTYJDQgxmekzzpN68T4A:7 a=CjuIK1q_8ugA:10 a=9xyTavCNlvEA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 05 Apr 2011 15:13:21 -0000 Well said. A lot less specific and "mathematical" but I agree that the phrase "design for tomorrow" captures a great deal of the idea behind it. As I said a few times before now... We can impossibly know what the future will bring, or require. In fact, we will very likely be unable to design the protocol the Right Way for today either, on our first attempt. We should realize this and think ahead: flexibility is the only way to deal with that in the future. [For the not so "great men": the picture I have in my head with this is several large virtual worlds that are using VWRAP, with hundred of thousands of users. Then we discover that something is inefficient or just can't be gotten right. There is a solution but it would require to change the definition of VWRAP. This IS going to happen. Don't ignore it until it's too late (until that day where already thousands are using the protocol)] On Tue, 5 Apr 2011 05:30:28 +0100 Morgaine wrote: > I support Carlo's suggestion very strongly. These are such early > days in the evolution of virtual worlds that designing for today > seems just plain silly to me, and I would like to see "design for > tomorrow" enshrined by agreement. > > Morgaine. From dzonatas@gmail.com Tue Apr 5 09:36:04 2011 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 8931A3A6967 for ; Tue, 5 Apr 2011 09:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ApAmbM9jQZ39 for ; Tue, 5 Apr 2011 09:36:03 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id CE38D3A6966 for ; Tue, 5 Apr 2011 09:36:02 -0700 (PDT) Received: by iwn39 with SMTP id 39so693877iwn.31 for ; Tue, 05 Apr 2011 09:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4U41t5HcOAAXHiSiYB7yqiGCEy7+Fwm04MvVvDsXVqI=; b=FaXRqE6qZ8WgyTCnCC1p2FIiUQb8cC7XXi8TdJqghjLgEY/GqGtyKhyeu5X0SUGmlr oQmWGUoEvmhLPKUhXtKkpw4uIzjNG/sVbIhgSl88fAMOZKo+s0mTI5SamZiPccO/2uB8 yrJwlA7VTW5YXNvYrdDOC2+icr6Icj0XyEKww= 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=eqwp71peqkxamYmjb/QKka1NRXuX3Ig8p549WYmF5RuZs0ZINzBzdmZ3DdKnauVAwm uqA/xw1K9oHhakKd0vitP6k2syoU4u4j6qc7OyqZran948wp5e4tLCwj6fMU1hWU4UAR iWR9Gfd7M+Dr+e+8a0FFTTkSmwl43gavRf6eU= Received: by 10.42.168.6 with SMTP id u6mr358659icy.46.1302021463004; Tue, 05 Apr 2011 09:37:43 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id d9sm2895373ibb.2.2011.04.05.09.37.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 09:37:41 -0700 (PDT) Message-ID: <4D9B4586.9080004@gmail.com> Date: Tue, 05 Apr 2011 09:38:30 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Carlo Wood References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <20110405152025.26ba8f77@hikaru.localdomain> In-Reply-To: <20110405152025.26ba8f77@hikaru.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 05 Apr 2011 16:36:04 -0000 Carlo, Do you think we are ready to implement some asset services now, with/without complete documentation? What more do you think is needed? Carlo Wood wrote: > On Mon, 4 Apr 2011 23:02:14 -0400 > Izzy Alanis wrote: > >> That's not an argument against flexibility. But I do question why we >> need to have consensus on this abstract meta-issue? Do we really need >> explicit written consensus on overly general principles like >> "flexibility is good", or "scalability is good" or "sunshine and >> puppies are good" to make progress? Specific features and details will >> or will not become part of the protocol based on their merits. >> > > Clearly we do: we already can't reach consensus on > something as logical (aka Spock) and trivial as my very first > meta-issue as you call it. That baffles me, and to be > honest, that alone is reason again for me to abandon this > project. > > It is ridiculous that not everyone just said: Aye / Ok / Of course / > trivial! > > I can only guess to the reasons (varying from stupidity (you'd never > see such reactions on a mailinglist with math researchers) to paranoia), > but it definitely is working against any progress. > > The discussions (and non-progress) on this mailinglist makes me > think of a book I once called read, "Surely you're joking, Mr.Feynman" > (http://buffman.net/ebooks/Richard_P_Feynman-Surely_Youre_Joking_Mr_Feynman_v5.pdf > about page 67, starting with "This committee had men like Compton and > Tolman..."). > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Tue Apr 5 09:41:48 2011 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 D70273A6965 for ; Tue, 5 Apr 2011 09:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 sjOIwIqUqYCH for ; Tue, 5 Apr 2011 09:41:48 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 0213D3A6968 for ; Tue, 5 Apr 2011 09:41:47 -0700 (PDT) Received: by iwn39 with SMTP id 39so699899iwn.31 for ; Tue, 05 Apr 2011 09:43:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=c/b6MpK2rJZEO3CGgpwxnys3iAZqEZ7Dk2BtgC0/+88=; b=ZOG/OkQWX9Bkaw+urTNgfnUvDFxp1KpPLgw+P9ArQy5sd4S2Vee+wjbpvrxqgYe/s1 GtFaXCz5pNQ9o8ogK3MwYIkULDfXs2Yztce09Kz+Hg3V/Uo/+036qPLUkCzdT1nZILW+ hl227hmgrtKmPsj4VH432nIp7y36tOgJDjZFg= 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=ua8s7wt3hdIq5taSi5LPFesvlhr0ewmBoFQqcvrLE46vPVH4JAtdQ2XuOSGDUCqEyw vzEP+/SxgcqtWWXgUuFIXvIM5lCGA9bjGtnj1OXENtUaad/ykBBoGouvUxSohM7qKypD 8+EEeB6TKlJcdCzNhSxy+SpB1WDrtGs1bX04I= Received: by 10.231.116.92 with SMTP id l28mr9099709ibq.20.1302021811188; Tue, 05 Apr 2011 09:43:31 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id 19sm4574026ibx.1.2011.04.05.09.43.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 09:43:30 -0700 (PDT) Message-ID: <4D9B46E3.4050202@gmail.com> Date: Tue, 05 Apr 2011 09:44:19 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Izzy Alanis References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 05 Apr 2011 16:41:48 -0000 Izzy, After the months that have gone by I would like to see what we can implement. I pointed out asset services as the obvious piece we can unitize somehow. I think we got the login process documented enough to move in this direction. It just seems stuck at the actual transfer of assets due to the load of comments about this main task. Some implementation would help us take further steps to document more. Izzy Alanis wrote: > Things that have *consensus* become part of the protocol. If changes > meet reasonable criteria (such as the above), they will be more likely > have consensus. Changes that do things like break backwards > compatibility or limit 'flexibility' will likely be hard to get > consensus on. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From izzyalanis@gmail.com Tue Apr 5 10:09:39 2011 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 713D728C125 for ; Tue, 5 Apr 2011 10:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.529 X-Spam-Level: X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 rHKdT3gd5gVn for ; Tue, 5 Apr 2011 10:09:37 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 7616E28C120 for ; Tue, 5 Apr 2011 10:09:37 -0700 (PDT) Received: by fxm15 with SMTP id 15so487323fxm.31 for ; Tue, 05 Apr 2011 10:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=angyXClT+x76vZe/3Aj1JVO53gIs4D8NMLbCD79b6qE=; b=dPctyaH8ZiQDTaV28ATW5qSgb2md05CTZOyPAmwW4UDEMdOLlruKyCE25WdQGnMiO5 o+KEGNEJVE5Z2QTPqWbT3k96WEbZ06sbZmvrcgSpmL4sKwhxe4wrFcYfSHC8otiaNWGG 4ZNbwBwrdoK0lhxdwlRuQQ1mvzJdiIZCMBNZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NY1Ga6lrJnhIgcjvH0Bj+rclTda3ftisGsINgfq6m4oi8xm7vjlNT0efOj0y8CSbOP jWo1GzJP0Iyb2oSB7W2CsU4UO0ZeyV39GMoMaAhB7+zjUpSpMoO1FV6dHdvuhsH/KEKU T+NB44ln1RRq1aRgnD+deXJxblj2Jtuw1ir0M= MIME-Version: 1.0 Received: by 10.223.2.8 with SMTP id 8mr20359fah.82.1302023016925; Tue, 05 Apr 2011 10:03:36 -0700 (PDT) Received: by 10.223.81.66 with HTTP; Tue, 5 Apr 2011 10:03:36 -0700 (PDT) In-Reply-To: References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> Date: Tue, 5 Apr 2011 13:03:36 -0400 Message-ID: From: Izzy Alanis To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 05 Apr 2011 17:09:39 -0000 I'm not against the "design for tomorrow" platform. I'm pro-"design for tomorrow", but I believe the proposition, as currently worded, does not appropriately communicate those intentions. I could agree with the following wording (though I still don't believe it communicates your 'design for tomorrow intentions'): * Whenever a change X in the protocol is proposed (which might be an addition, a change of existing protocol or even deletion: any change, making the protocol > *# (VWRAP) go from A --> B), then *# Protocol B SHOULD do everything that A could do. *# Good use-case justification for B MUST be provided. *# Implementation requirements of B MUST be listed. On Tue, Apr 5, 2011 at 12:30 AM, Morgaine wrote: > I expect that Carlo wanted prior agreement on the principle of generally > accepting superset requirements simply to avoid perpetual wrangling betwe= en > progressives and regressives.=A0 Or if that term is disliked (nobody like= s to > admit that they are regressive after all), between those who want to desi= gn > for tomorrow and those who want to design for today. > > And it's not only a theoretical worry either, because we've already seen > several instances of participants not wanting to design for tomorrow, for > example in not wanting the open metaverse of VW tourism, or arguing again= st > open extensibility, or rejecting IPv6-specific enhancements. > > I'm on the "design for tomorrow" platform, but I do recognize that if you > want the cart pulled in a specific direction then you have to be the > principle puller yourself.=A0 You can't expect others who don't share you= r > interest to pull it for you. > > This is why I added points #2 and #3 so that the onus is on the people wh= o > have the superset requirements to justify them and do the design legwork = for > them. > > Point #1 is just as important though.=A0 As long as a new requirement res= ults > in a protocol that is a superset of the previous one, detractors argue > against it either because they see very strong engineering reasons why it= is > bad or else they argue unconvincingly, because having your requirement > included but vetoing someone else's requirement just because you don't wa= nt > it is unacceptable.=A0 This is why supersets are important:=A0 they repla= ce > one-side-wins either/or arguments by both-sides-win either/and arguments, > which gain agreement much more easily. > > Funnily enough, we've already heard arguments against the motherhood and > apple pie of scalability, so I had to chuckle when I read your penultimat= e > paragraph. :-) > > I support Carlo's suggestion very strongly.=A0 These are such early days = in > the evolution of virtual worlds that designing for today seems just plain > silly to me, and I would like to see "design for tomorrow" enshrined by > agreement. > > > 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 > > > On Tue, Apr 5, 2011 at 4:02 AM, Izzy Alanis wrote: >> >> I applaud the effort to further the documentation... but, what does it >> mean to say "then that change is accepted as part of VWRAP"? >> >> > * Whenever a change X in the protocol is proposed (which might be >> > an addition, a change of existing protocol or even deletion: any >> > change, making the protocol > *# (VWRAP) go from A --> B), then >> > that change is accepted as part of VWRAP provided that: >> > *# Protocol B can do everything that A could do. >> > *# Good use-case justification for B is provided. >> > *# Implementation requirements of B are listed. >> >> Things that have *consensus* become part of the protocol. If changes >> meet reasonable criteria (such as the above), they will be more likely >> have consensus. Changes that do things like break backwards >> compatibility or limit 'flexibility' will likely be hard to get >> consensus on. >> >> But I agree with Mike when he said "We don't need to make a process >> that forces agreement under a set of terms...". >> >> That's not an argument against flexibility. But I do question why we >> need to have consensus on this abstract meta-issue? Do we really need >> explicit written consensus on overly general principles like >> "flexibility is good", or "scalability is good" or "sunshine and >> puppies are good" to make progress? Specific features and details will >> or will not become part of the protocol based on their merits. >> >> If a minority interest (a potential "vetoer") has no interest in a >> particular use case, and their concerns are resolved or mitigated -- >> by limiting the impact to their implementation of the previous version >> of the protocol, making the change/proposed feature optional, etc -- >> then we can still reach consensus. Consensus doesn't mean unanimity. >> >> >> >> On Fri, Apr 1, 2011 at 11:01 AM, Morgaine >> wrote: >> > I agree 100% with every point made by Carlo in this post. >> > >> > Please note that I have extended Carlo's 2-clause proposal from his >> > earlier >> > email, because in his original formulation, flexibility in the protoco= l >> > is >> > easily vetoed by backward-looking detractors or vested interests. >> > >> > My formulation is here -- >> > http://www.ietf.org/mail-archive/web/vwrap/current/msg00637.html .=A0 = I am >> > sure it can be improved still further. >> > >> > My goal is that (i) new areas of flexibility should be justified by us= e >> > cases and supported by engineering solutions, and (ii) not subject to >> > veto >> > by those who are not interested in those use cases.=A0 That's how you = make >> > technical progress. >> > >> > >> > Morgaine. >> > >> > >> > >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> > On Fri, Apr 1, 2011 at 3:13 PM, Carlo Wood wrote: >> >> >> >> On Wed, 30 Mar 2011 14:27:27 +0000 >> >> "Dickson, Mike (ISS Software)" wrote: >> >> >> >> > We don't need to make a process that forces agreement under a set o= f >> >> > terms. =A0That's not how the IETF works. =A0We need consensus and >> >> > documents. >> >> >> >> Nobody forces you to anything. I'm asking if there is consensus >> >> about this point. Frankly, I'm disappointed that you disagree >> >> already - at THIS level of abstraction. Perhaps it's caused by >> >> a false sense of fear that you would be forced to accept things >> >> into the protocol: you clearly want control. You want to decide >> >> on a case by case basis if you like it or not. >> >> >> >> But hell, that is NOT possible at this abstraction level. >> >> Please rethink carefully what the proposal means: do you REALLY >> >> want to reject the Ideal of an open protocol that doesn't deny >> >> support for use-cases that YOU don't want? >> >> >> >> > =A0As a contributor I'll choose to agree or disagree based >> >> > on the topic. =A0And in some cases I'm not sure I'd choose flexibil= ity >> >> > over stability, etc. >> >> >> >> I don't see the 'etc' here. And IF the minimal support that >> >> an implementer would have to add who does NOT needed X would >> >> lead to instability then surely you wouldn't be able to speak >> >> of "No substantial extra demands are being made"! >> >> >> >> If implementation is so difficult, even for implementers NOT >> >> needing it, that it causes the danger of instability then you >> >> have EVER possibility to go against it, even if now you agree >> >> with the Principle of trying to be flexible. >> >> >> >> > It seems to me we've sorted drifted to a point we're there are 2 >> >> > camps and a proposal was made for how to deal with it. =A0There are >> >> > those that want to work on service level interop. =A0And others wan= t to >> >> > define the whole concept of virtual world interop. IMO we need to >> >> > either agree that seperation exists and arrange the docs so it >> >> > describes the 2 work streams or agree that we can't agree and >> >> > disband. =A0The service level interop. is a subset of the other and >> >> > given our track record I prefer to walk rather than run. >> >> >> >> I am not really sure how this applies to making the choice if >> >> you want to be flexible, or - put differently - want to cripple >> >> the protocol to make certain applications of it impossible. >> >> >> >> > =A0And I don't buy the "evil corporate interests" argument. >> >> >> >> ... unless this is the case. And you just want to win a battle >> >> before it started. >> >> >> >> > =A0Ideally if we do this right there *should* be some participation >> >> > from business interests that are looking at the space. >> >> >> >> A flexible protocol would be superset of what those businesses >> >> need (see point 1: Protocol B can do everything that A could do). >> >> So, if they would be interested when the protocol can only do A, >> >> please explain why they won't be interested anymore when it >> >> can do B? >> >> >> >> > Mike (speaking as me and not for HP) >> >> >> >> -- >> >> Carlo Wood >> >> _______________________________________________ >> >> 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 dzonatas@gmail.com Tue Apr 5 11:36:50 2011 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 099CD3A6976 for ; Tue, 5 Apr 2011 11:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 fmTnE0VTcvoi for ; Tue, 5 Apr 2011 11:36:47 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id E47D33A67E6 for ; Tue, 5 Apr 2011 11:36:46 -0700 (PDT) Received: by iye19 with SMTP id 19so811833iye.31 for ; Tue, 05 Apr 2011 11:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jj9Cx2fHaFAcSEiYCkCBV7/JaOYm48CH6/6Y7hFP2SY=; b=ofi/GwN7J+dH5A85NYdIto6NEepLsVdNurtQajRSnf5G+hgu4QPCmloopwik8tVVib 5EsTGmm1IYyOT8of8wuzFI3xsgib1HODBuxhskHdv3miDT18wvmlaXpBy69J8CxMXyAa KoUQYkHJ8K4Ldm9zmjBsSbljvl9fTJPk7OSwQ= 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=Ih+GLGSEFr2tnEZ+Ed0XgAsQApkcPFB4v/k/DFdkuEh/6PUNk8vuhjKvbwArvMixD5 8efPCOEvMIB8LFdbh8B05lXcXgIAbbZVdAsB9SXtVv9g8Qm6DjFekpfGuHDzI8qCmRWH iGczVuCMzEnEChWnSn38EGocR6rffUAVFaYdY= Received: by 10.42.65.73 with SMTP id k9mr2626445ici.427.1302028709821; Tue, 05 Apr 2011 11:38:29 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id 19sm4626460ibx.52.2011.04.05.11.38.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 11:38:27 -0700 (PDT) Message-ID: <4D9B61D4.3000906@gmail.com> Date: Tue, 05 Apr 2011 11:39:16 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Meadhbh Hamrick References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] informal description of the DSD interface description language 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, 05 Apr 2011 18:36:50 -0000 Some notes... in line... Meadhbh Hamrick wrote: > hey peeps, it shouldn't be shocking to anyone i'm not a big fan of > lentczner's "little" interface description language, llidl. while it > can be argued it's "condensed" format is easy enough to use, once > mastered, i prefer something mildly more expressive. when i was > working on the last version of the LLSD draft, i solicited comments > from several implementers inside and outside Linden, and they all said > the same thing: "LLIDL is cool enough, but it looks like line noise if > you don't know what you're looking at." > > i came up with the following interface description language to address > the "looks like line noise" critique. this is the IDL that's going in > the DSD draft, since that's what we're using at sl8.us > and various sensor projects that are using DSD. i'm assuming you've > read and understand the LLIDL section of the most recent type system > draft. > > again, i have no idea if this will be relevant since no one's stepped > up to be an document author for future revisions of this group's docs > or an editor to re-draft a new charter. but on the off chance people > do this and still want to work on the type system, these are the > changes recommended by several LLIDL users and implementers. Be sure to see review these to see how I based off LLIDL: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375#Queries_.26_Type_System http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Asset http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Interface (and others there) Note that I used more of what is in regards to ReST than only LLIDL. > > *item 0 : disentangling resources from interfaces.* > > LLIDL sort of conflated a resource (something to be accessed) with the > method of accessing it. there was no way to "officially" define a > "resource" independent of the semantics to access it. DSD says that > RESOURCEs are just data definitions. INTERFACEs define how they're used. As I see "resource", it manly is untranslated to any particalar implementation. Some still think there is an obvious implementation due to common resources being used by HTTP. I think you have some like C#'s interface in mind? > > *item 1 : say good-bye to the di-graphs.* > > several people noted that LLIDL, at first glance, looks like line > noise. this is because of the use of digraphs to represent messaging > semantics. cast your memory back to the LLIDL resource description for > the seed cap: > > %% seed > -> { capabilities: [ string, ... ] } > <- { capabilities: { $: uri } } > > > the '%%' digraph means 'start of resource description'. the '->' means > 'this is what i'm going to send you' and the '<-' digraph means 'i > expect you to send me this back'. > > instead of digraphs, the DSD resource description language uses the > keyword "RESOURCE" to begin a resource. it also terminates the > resource definition with a semi colon. so a resource declaration would > look something like this: > > RESOURCE [resource definition] ; > > resource DEFINITIONs look more or less like they used to. for example, > here's a RESOURCE definition for a typical error response: > > # Resource description for a typical error resource > RESOURCE error_simple { > success : false, # clients check the success element to > see if there was an error > errno : integer, # this is a numeric code representing > the error > error : string, # this is a text description of the error > description : uri # this is a URL that points to a HTML > web page describing the error > }; > Think we discussed this before, which I said wasn't much of the worry since the what is pivotal is more significant. That said, however, be sure to keep in mind that anything like digraphs make it easier to use non-English only keywords. We seem to agree in structure. > > *item 2 : the use of type literals instead of type names* > > in the example above, we used 'false' instead of 'boolean' as the type > definition for the 'success' element of the error resource. DSD > resource definitions can use type literals to imply that the element > should exist, and should have a specific value. so if you wanted to > define a resource that represented the origin of a 3d space, you could > use: > > # Point in a 3D rectangular space > RESOURCE cartesian_point [ > real, # x coordinate > real, # y coordinate > real # z coordinate > ]; > > # Origin of a rectangular (cartesian) space > RESOURCE cartesian_origin [ 0.0, 0.0, 0.0 ]; > Good idea, I'm just not quite sure if it is so obvious in practice. > > *item 3 : type specifiers use the same names as the elements inside > the XML serialization.* > > instead of using "int", we use "integer." ditto for other types. so > the resource definition. here's a resource definition for something > with an integer in it: > > # Random resource definition of a map with an integer in it > RESOURCE whatever { > element : integer > }; > This is made obvious by the default use of LLSD, still. Notice SNOW-375 I did have a few extras for optional fields and proprietary fields. We know they are there, but probably won't have an public definition of such structures. Guess we need that tidbit formalized. > > *item 4 : DSD variant declarations don't suck for beginners* > > i always thought repeated '&' definitions to denote variants was sort > of snobbish. it makes sense to peeps who've sat through classes on > regular grammars and ABNF, but i wouldn't mind it too much if someone > with a basic understanding of procedural coding could understand what > was going on. so i came up with the VARIANT keyword. it looks like this: > > VARIANT : { } > > so here's an example: > > # Enhanced Error resource > > RESOURCE error_enhanced VARIANT error_type : string { > 'number' : { > success : false, > errno : integer > }, > 'string' : { > success : false, > error : string > }, > 'url' : { > success : false, > description : uri > } > }; > > > what this means is that the "error_enhanced" resource has three valid > forms, that look like: > > RESOURCE error_enhanced { > error_type : 'number', > success : false, > errno : integer > }; > > RESOURCE error_enhanced { > error_type : 'string', > success : false, > error : string > } > > RESOURCE error_enhanced { > error_type : 'url', > success : false, > description : uri > } > > > so the shows up as an element in each of the valid > forms as an literal element of type . Did I find any significant use for such? I mean is there somewhere in specific that that variant structure is more helpful than what I used? I think as we get into more specific usage and documentation of that usage we do need simplified ways makes some redundancy obvious. I just used wiki markup for that for now, I think. > > *item 5 : say good by to HTTP verbs.* > > LLIDL as specified is pretty much intertwined with HTTP. many people > thought that was a bad idea. In creating an interface, DSD uses five > abstract "interaction semantics": CREATE, READ, UPDATE, DELETE and EVENT. > > the first four do what you expect them to do while the last one > describes the form or "shape" of an unsolicited message coming from > the event queue. > > so if you wanted to login, you might use the following interface > > INTERFACE CREATE session_factory { > username : string, > secret : binary > } RESPONSE VARIANT success : boolean { > false : { > errno : integer, > err : string, > description : uri > }, > true : { > seed : uri > } > }; > > > or, you could do the following: > > RESOURCE error { > errno : integer, > err : string, > description : uri > }; > > INTERFACE CREATE session_factory { > username : string, > secret : binary > } RESPONSE VARIANT success : boolean { > false : error, > true : { > seed : uri > } > }; > > > so anyway, i'm writing up this stuff in the DSD type system draft. > feel free to comment. as things stand, if VWRAP continues as a working > group, i'll integrate your comments on the draft. if not, i'll modify > the draft so as to remain compatibility with existing DSD > implementations and publish it a an individual / informational draft > for the purpose of registering the mime types. As long as usage doesn't fall out of ReST than it'll work. Remember that ReST doesn't have to use HTTP. If you see my implementation, there is the ReST queue being full of tasks and part of those task relate to HTTP methods. People don't seem to often split ReST queries as different than HTTP verbs, but I do. I guess that is like resource/interface differences. I thought I saw another submitted document to review, yet couldn't find it. Was there a newer version? -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Tue Apr 5 11:54:43 2011 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 BFCF73A6974 for ; Tue, 5 Apr 2011 11:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHnc+JnPLfUu for ; Tue, 5 Apr 2011 11:54:39 -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 2CA0C3A6359 for ; Tue, 5 Apr 2011 11:54:39 -0700 (PDT) Received: by pvh1 with SMTP id 1so329425pvh.31 for ; Tue, 05 Apr 2011 11:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=7xPmh8tHQaUpyb8+6Q5WnEzISfZPPBAL7fg3KyNiUiU=; b=LUQWTbau3J5ANcTbNieLIwN2ZSrvrTDyvVODKyCSVqS7ztKZgsTxDBeTJoWO7DzdY0 5t33OJyc9req2XeVZ/g4aAYD4lCMuHZEAyaT1o9iVXNiAisOretN4vXy0351r/blpc6H Vm31L1t6B4ARAPO7+9hdSEoK9l37eZd50Gk6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=uvX5YyhofEkq2gq7+osq9lvfUnQyqW4Vw45HLvScEa7MoMQmCZRACQRAQbSxIr7LsH UOeUBzlU7Xn8WdJsviBf3CM9lKO5y21xoA9a7IxmzRbf8INIfGeCVcKBODCpC9qMzIb5 kvk7asKgKfAerO6PMuWsBxeSh2vbr1yr3wcHE= MIME-Version: 1.0 Received: by 10.142.122.40 with SMTP id u40mr12515wfc.335.1302029782162; Tue, 05 Apr 2011 11:56:22 -0700 (PDT) Received: by 10.142.246.6 with HTTP; Tue, 5 Apr 2011 11:56:21 -0700 (PDT) In-Reply-To: <4D9B4586.9080004@gmail.com> References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <20110405152025.26ba8f77@hikaru.localdomain> <4D9B4586.9080004@gmail.com> Date: Tue, 5 Apr 2011 19:56:21 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=001636e1f7e1a71e9904a0306ee4 Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 05 Apr 2011 18:54:43 -0000 --001636e1f7e1a71e9904a0306ee4 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol wrote: > > Do you think we are ready to implement some asset services now, > with/without complete documentation? > > What more do you think is needed? > > > Two or three things seem to be needed: - Defining the asset addressing concept is an extremely important matter, almost certainly the most important matter of all, because that determines how robust and scalable our worlds will be. I've already examined alternatives for that in some depth, and the design with the best engineering properties so far seems to be universal hash-based addressing. I first described that approach on the list here --- http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html , and referred to it in various subsequent discussions. - Defining the data flows between regions, clients, and asset services and which parameters control the flows needs to be done before a test asset service can be implemented. Without that, an asset service is just a network-accessible storage service, not an asset service in the VWRAP sense. Network storage services exist already, so just implementing one of those would not advance VWRAP. - We need to examine how various deployment patterns will use the asset services, and how the *multiple* asset services that interop introduces are handled. I am working on this currently. None of the above is particularly hard. I think it won't be long before we have a scheme worked out and are ready for some implementation work. Morgaine. --001636e1f7e1a71e9904a0306ee4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
=

Do you think we are ready to implement some asset services now, with/withou= t complete documentation?

What more do you think is needed?


Two or three things seem to be needed:

<= ul>
  • Defining the asset addressing concept is an extremely important matt= er, almost certainly the most important matter of all, because that determi= nes how robust and scalable our worlds will be.=A0 I've already examine= d alternatives for that in some depth, and the design with the best enginee= ring properties so far seems to be universal hash-based addressing.=A0 I fi= rst described that approach on the list here --- http://www.ietf.org/mail= -archive/web/vwrap/current/msg00463.html , and referred to it in variou= s subsequent discussions.
    • Defining the data flows between regions, clients, and ass= et services and which parameters control the flows needs to be done before = a test asset service can be implemented.=A0 Without that, an asset service = is just a network-accessible storage service, not an asset service in the V= WRAP sense.=A0 Network storage services exist already, so just implementing= one of those would not advance VWRAP.
    • We need to examine how various deployment patterns will use th= e asset services, and how the multiple asset services that interop i= ntroduces are handled.=A0 I am working on this currently.

    None= of the above is particularly hard.=A0 I think it won't be long before = we have a scheme worked out and are ready for some implementation work.


    Morgaine.




    --001636e1f7e1a71e9904a0306ee4-- From dzonatas@gmail.com Tue Apr 5 12:04:44 2011 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 84BFA3A697E for ; Tue, 5 Apr 2011 12:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 nI4BvbgN6YbX for ; Tue, 5 Apr 2011 12:04:42 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id BC9353A6974 for ; Tue, 5 Apr 2011 12:04:42 -0700 (PDT) Received: by iwn39 with SMTP id 39so849622iwn.31 for ; Tue, 05 Apr 2011 12:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bstsvF/cHmcvVEtcjKYQZdJJCa692T7sXbKsxQd67Vc=; b=YJF7SQDdnGzmZpLdocbjHrVQbpOiD84lQvKpov/ra5jUBi9OOh5TA5H4hVVFr5ZoaQ 5l4aUi9P0qt8pg93hOBXRMCpK4CHZThdd84fu5RnYVmS5xyw42AFe3AZRqZGySAh/kNg mC4oRXTkTs+YH4lZ13ZquTCVmay2JfmKRMZlE= 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=P87gIeBGYRKaTDxlIuIpaJ+1Yj7X0TUj5+snRT5Fm6tBx87HsfcdkNaif899gYcRQZ AjU7n2GuvoAK4ATN6NSPDeHEn22zYFrBCD/lNJmgLlrol23yKVFRcpXL2confviCXZZp TwAk7b6q/n+LlZ+FZpv7E+r4goaNi0jGpIg2c= Received: by 10.42.74.194 with SMTP id x2mr87069icj.113.1302030385651; Tue, 05 Apr 2011 12:06:25 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id mv26sm4636669ibb.28.2011.04.05.12.06.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 12:06:24 -0700 (PDT) Message-ID: <4D9B6861.4030704@gmail.com> Date: Tue, 05 Apr 2011 12:07:13 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Dzonatas Sol References: <4D9B61D4.3000906@gmail.com> In-Reply-To: <4D9B61D4.3000906@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org, Meadhbh Hamrick Subject: Re: [vwrap] informal description of the DSD interface description language 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, 05 Apr 2011 19:04:44 -0000 There are two(/three) significant touches I made: First, burst mode. Already as people upgrade to capabilities rather than the older UDP style we can see they complain about bottlenecks due to individual requests being made. This is more of fault of the implementators not doing full ReST rather than the limits of capabilities. I denote "burst mode" to make sure full ReST is being implemented. This is where RESOURCES & INTERFACES keep the very basic object oriented message paradigm. Then capabilities then can become used for specific individual queries to combined multiple resource queries. This alleviates the individual connections per item into the non-issue bit-bucket. The only new issue with "burst mode" is limits on how many items can be combined (length of overall body and parts). Second, public resources. The significance I put on "resources" is that these are the public names being referred to for any such related message and/or method. Already implemented are the private version of these resources. Maybe there needs to be some syntax to note that the resources appear as something else under specific conditions. The current private URIs are just a digest of given capabilities present (used by lookup tables). Internally, only the public resources are of need, yet the private URI may contain something in regards to the basic object oriented message paradigm. It's not that complicated once one separates the ReST paradigm from HTTP methods and implements the full ReST paradigm internally. When the implementator relies on HTTP as the queue, then they don't have a true ReST paradigm, only something compatible (for quick implementation). Third, private resources, as above and already implemented by LL (stateless). We haven't got into stateful tranfer connections. *sigh* These would be ideal for the keep-alive, long-poll, and bust mode options. Dzonatas Sol wrote: > Some notes... in line... > > Meadhbh Hamrick wrote: >> hey peeps, it shouldn't be shocking to anyone i'm not a big fan of >> lentczner's "little" interface description language, llidl. while it >> can be argued it's "condensed" format is easy enough to use, once >> mastered, i prefer something mildly more expressive. when i was >> working on the last version of the LLSD draft, i solicited comments >> from several implementers inside and outside Linden, and they all >> said the same thing: "LLIDL is cool enough, but it looks like line >> noise if you don't know what you're looking at." >> >> i came up with the following interface description language to >> address the "looks like line noise" critique. this is the IDL that's >> going in the DSD draft, since that's what we're using at sl8.us >> and various sensor projects that are using DSD. i'm >> assuming you've read and understand the LLIDL section of the most >> recent type system draft. >> >> again, i have no idea if this will be relevant since no one's stepped >> up to be an document author for future revisions of this group's docs >> or an editor to re-draft a new charter. but on the off chance people >> do this and still want to work on the type system, these are the >> changes recommended by several LLIDL users and implementers. > > Be sure to see review these to see how I based off LLIDL: > http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375#Queries_.26_Type_System > > http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Asset > > http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Interface > > (and others there) > > Note that I used more of what is in regards to ReST than only LLIDL. > >> >> *item 0 : disentangling resources from interfaces.* >> >> LLIDL sort of conflated a resource (something to be accessed) with >> the method of accessing it. there was no way to "officially" define a >> "resource" independent of the semantics to access it. DSD says that >> RESOURCEs are just data definitions. INTERFACEs define how they're used. > > As I see "resource", it manly is untranslated to any particalar > implementation. Some still think there is an obvious implementation > due to common resources being used by HTTP. I think you have some like > C#'s interface in mind? > > >> >> *item 1 : say good-bye to the di-graphs.* >> >> several people noted that LLIDL, at first glance, looks like line >> noise. this is because of the use of digraphs to represent messaging >> semantics. cast your memory back to the LLIDL resource description >> for the seed cap: >> >> %% seed >> -> { capabilities: [ string, ... ] } >> <- { capabilities: { $: uri } } >> >> >> the '%%' digraph means 'start of resource description'. the '->' >> means 'this is what i'm going to send you' and the '<-' digraph means >> 'i expect you to send me this back'. >> >> instead of digraphs, the DSD resource description language uses the >> keyword "RESOURCE" to begin a resource. it also terminates the >> resource definition with a semi colon. so a resource declaration >> would look something like this: >> >> RESOURCE [resource definition] ; >> >> resource DEFINITIONs look more or less like they used to. for >> example, here's a RESOURCE definition for a typical error response: >> >> # Resource description for a typical error resource >> RESOURCE error_simple { >> success : false, # clients check the success element to >> see if there was an error >> errno : integer, # this is a numeric code representing >> the error >> error : string, # this is a text description of the error >> description : uri # this is a URL that points to a HTML >> web page describing the error >> }; >> > > Think we discussed this before, which I said wasn't much of the worry > since the what is pivotal is more significant. That said, however, be > sure to keep in mind that anything like digraphs make it easier to use > non-English only keywords. > > We seem to agree in structure. > > > >> >> *item 2 : the use of type literals instead of type names* >> >> in the example above, we used 'false' instead of 'boolean' as the >> type definition for the 'success' element of the error resource. DSD >> resource definitions can use type literals to imply that the element >> should exist, and should have a specific value. so if you wanted to >> define a resource that represented the origin of a 3d space, you >> could use: >> >> # Point in a 3D rectangular space RESOURCE cartesian_point [ >> real, # x coordinate >> real, # y coordinate >> real # z coordinate >> ]; >> >> # Origin of a rectangular (cartesian) space >> RESOURCE cartesian_origin [ 0.0, 0.0, 0.0 ]; >> > > Good idea, I'm just not quite sure if it is so obvious in practice. > > >> >> *item 3 : type specifiers use the same names as the elements inside >> the XML serialization.* >> >> instead of using "int", we use "integer." ditto for other types. so >> the resource definition. here's a resource definition for something >> with an integer in it: >> >> # Random resource definition of a map with an integer in it >> RESOURCE whatever { >> element : integer >> }; >> > > This is made obvious by the default use of LLSD, still. Notice > SNOW-375 I did have a few extras for optional fields and proprietary > fields. We know they are there, but probably won't have an public > definition of such structures. Guess we need that tidbit formalized. > > >> >> *item 4 : DSD variant declarations don't suck for beginners* >> >> i always thought repeated '&' definitions to denote variants was sort >> of snobbish. it makes sense to peeps who've sat through classes on >> regular grammars and ABNF, but i wouldn't mind it too much if someone >> with a basic understanding of procedural coding could understand what >> was going on. so i came up with the VARIANT keyword. it looks like this: >> >> VARIANT : { } >> >> so here's an example: >> >> # Enhanced Error resource >> >> RESOURCE error_enhanced VARIANT error_type : string { >> 'number' : { >> success : false, >> errno : integer >> }, >> 'string' : { >> success : false, >> error : string >> }, >> 'url' : { >> success : false, >> description : uri >> } >> }; >> >> >> what this means is that the "error_enhanced" resource has three valid >> forms, that look like: >> >> RESOURCE error_enhanced { >> error_type : 'number', >> success : false, >> errno : integer >> }; >> >> RESOURCE error_enhanced { >> error_type : 'string', >> success : false, >> error : string >> } >> >> RESOURCE error_enhanced { >> error_type : 'url', >> success : false, >> description : uri >> } >> >> >> so the shows up as an element in each of the valid >> forms as an literal element of type . > > Did I find any significant use for such? I mean is there somewhere in > specific that that variant structure is more helpful than what I used? > I think as we get into more specific usage and documentation of that > usage we do need simplified ways makes some redundancy obvious. I just > used wiki markup for that for now, I think. > > >> >> *item 5 : say good by to HTTP verbs.* >> >> LLIDL as specified is pretty much intertwined with HTTP. many people >> thought that was a bad idea. In creating an interface, DSD uses five >> abstract "interaction semantics": CREATE, READ, UPDATE, DELETE and >> EVENT. >> >> the first four do what you expect them to do while the last one >> describes the form or "shape" of an unsolicited message coming from >> the event queue. >> >> so if you wanted to login, you might use the following interface >> >> INTERFACE CREATE session_factory { >> username : string, >> secret : binary >> } RESPONSE VARIANT success : boolean { >> false : { >> errno : integer, >> err : string, >> description : uri >> }, >> true : { >> seed : uri >> } >> }; >> >> >> or, you could do the following: >> >> RESOURCE error { >> errno : integer, >> err : string, >> description : uri >> }; >> >> INTERFACE CREATE session_factory { >> username : string, >> secret : binary >> } RESPONSE VARIANT success : boolean { >> false : error, >> true : { >> seed : uri >> } >> }; >> >> >> so anyway, i'm writing up this stuff in the DSD type system draft. >> feel free to comment. as things stand, if VWRAP continues as a >> working group, i'll integrate your comments on the draft. if not, >> i'll modify the draft so as to remain compatibility with existing DSD >> implementations and publish it a an individual / informational draft >> for the purpose of registering the mime types. > As long as usage doesn't fall out of ReST than it'll work. Remember > that ReST doesn't have to use HTTP. If you see my implementation, > there is the ReST queue being full of tasks and part of those task > relate to HTTP methods. People don't seem to often split ReST queries > as different than HTTP verbs, but I do. I guess that is like > resource/interface differences. > > I thought I saw another submitted document to review, yet couldn't > find it. Was there a newer version? > > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Tue Apr 5 12:26:21 2011 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 7B9213A6980 for ; Tue, 5 Apr 2011 12:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.507 X-Spam-Level: X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 1rCE+sfQCLNQ for ; Tue, 5 Apr 2011 12:26:19 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6E4C23A67AE for ; Tue, 5 Apr 2011 12:26:19 -0700 (PDT) Received: by iwn39 with SMTP id 39so870409iwn.31 for ; Tue, 05 Apr 2011 12:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fioxXPGt4tXjbRpyRba98ZiF98ug2OSq6dQ187FuUXU=; b=mnLVFzOg1DjHHEN/KD3670ixXd4rKiU/olK9Zo/Al+GQVpH6xqbFJN9TUdViCqhD/X MC3XFo45IBqwlz3VLZXZ31eTraGf6Mp4PRYlQNwip0xdPTBkGOKr+xWOaEDgqEl8YtHa QwMYhxb6zVKZ8/waIMKwTGaJ/bcP6tVLPh6rI= 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=hWfDa9YTPvL+cpPTyNT9/xXkhzegYBOiTbiNLQ6q83IiQ2TOObG20sHWa6YOykzaUN cUkEjEzm3SVSuHEdZfgc4cReo07ZwYc0i9cCEIPzTwP6E1Td9geYxdQ9z5HYP4e2A4Fc XRW6GDjf5jn7trR1dOBF0dhdnr4WAqSoOmKzE= Received: by 10.231.51.5 with SMTP id b5mr64333ibg.94.1302031681483; Tue, 05 Apr 2011 12:28:01 -0700 (PDT) Received: from [192.168.0.50] ([71.137.195.251]) by mx.google.com with ESMTPS id o3sm4647895ibd.44.2011.04.05.12.27.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 12:28:00 -0700 (PDT) Message-ID: <4D9B6D71.5030400@gmail.com> Date: Tue, 05 Apr 2011 12:28:49 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Dzonatas Sol References: <4D9B61D4.3000906@gmail.com> <4D9B6861.4030704@gmail.com> In-Reply-To: <4D9B6861.4030704@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org, Meadhbh Hamrick Subject: Re: [vwrap] informal description of the DSD interface description language 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, 05 Apr 2011 19:26:21 -0000 Re: "bust mode" or "combined" See the syntax I used here: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Asset I used the the curly brackets {} with ellipses to show what kind of data can be combine as an array in LLSD. Here note that the UUID moves from the RESOURCE into the array as the individual items are combined, such that indivual requests for: /Asset/Notecard/|00000000-0000-0000-0000-000000000001| /Asset/Notecard/|00000000-0000-0000-0000-000000000002| /Asset/Notecard/|00000000-0000-0000-0000-000000000003| /Asset/Notecard/|00000000-0000-0000-0000-000000000004 become |/Asset/Notecard/s { |00000000-0000-0000-0000-000000000001, ||00000000-0000-0000-0000-000000000002, ||00000000-0000-0000-0000-000000000003, ||00000000-0000-0000-0000-000000000004 } || The combined reply may look like: |/Asset/Notecard/s { |00000000-0000-0000-0000-000000000001, { asset-data... } ||00000000-0000-0000-0000-000000000002, ||{ asset-data... }| |00000000-0000-0000-0000-000000000003, ||{ asset-data... }| |00000000-0000-0000-0000-000000000004 ||{ asset-data... }| |} || |Handling assets not immediately available are easy, I just stick the individual response codes in the array instead of expect it as an httpcode. Dzonatas Sol wrote: > There are two(/three) significant touches I made: > > First, burst mode. Already as people upgrade to capabilities rather > than the older UDP style we can see they complain about bottlenecks > due to individual requests being made. This is more of fault of the > implementators not doing full ReST rather than the limits of > capabilities. I denote "burst mode" to make sure full ReST is being > implemented. This is where RESOURCES & INTERFACES keep the very basic > object oriented message paradigm. Then capabilities then can become > used for specific individual queries to combined multiple resource > queries. This alleviates the individual connections per item into the > non-issue bit-bucket. The only new issue with "burst mode" is limits > on how many items can be combined (length of overall body and parts). > > Second, public resources. The significance I put on "resources" is > that these are the public names being referred to for any such related > message and/or method. Already implemented are the private version of > these resources. Maybe there needs to be some syntax to note that the > resources appear as something else under specific conditions. The > current private URIs are just a digest of given capabilities present > (used by lookup tables). Internally, only the public resources are of > need, yet the private URI may contain something in regards to the > basic object oriented message paradigm. It's not that complicated once > one separates the ReST paradigm from HTTP methods and implements the > full ReST paradigm internally. When the implementator relies on HTTP > as the queue, then they don't have a true ReST paradigm, only > something compatible (for quick implementation). > > Third, private resources, as above and already implemented by LL > (stateless). We haven't got into stateful tranfer connections. *sigh* > These would be ideal for the keep-alive, long-poll, and bust mode > options. > > > Dzonatas Sol wrote: >> Some notes... in line... >> >> Meadhbh Hamrick wrote: >>> hey peeps, it shouldn't be shocking to anyone i'm not a big fan of >>> lentczner's "little" interface description language, llidl. while it >>> can be argued it's "condensed" format is easy enough to use, once >>> mastered, i prefer something mildly more expressive. when i was >>> working on the last version of the LLSD draft, i solicited comments >>> from several implementers inside and outside Linden, and they all >>> said the same thing: "LLIDL is cool enough, but it looks like line >>> noise if you don't know what you're looking at." >>> >>> i came up with the following interface description language to >>> address the "looks like line noise" critique. this is the IDL that's >>> going in the DSD draft, since that's what we're using at sl8.us >>> and various sensor projects that are using DSD. i'm >>> assuming you've read and understand the LLIDL section of the most >>> recent type system draft. >>> >>> again, i have no idea if this will be relevant since no one's >>> stepped up to be an document author for future revisions of this >>> group's docs or an editor to re-draft a new charter. but on the off >>> chance people do this and still want to work on the type system, >>> these are the changes recommended by several LLIDL users and >>> implementers. >> >> Be sure to see review these to see how I based off LLIDL: >> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375#Queries_.26_Type_System >> >> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Asset >> >> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Interface >> >> (and others there) >> >> Note that I used more of what is in regards to ReST than only LLIDL. >> >>> >>> *item 0 : disentangling resources from interfaces.* >>> >>> LLIDL sort of conflated a resource (something to be accessed) with >>> the method of accessing it. there was no way to "officially" define >>> a "resource" independent of the semantics to access it. DSD says >>> that RESOURCEs are just data definitions. INTERFACEs define how >>> they're used. >> >> As I see "resource", it manly is untranslated to any particalar >> implementation. Some still think there is an obvious implementation >> due to common resources being used by HTTP. I think you have some >> like C#'s interface in mind? >> >> >>> >>> *item 1 : say good-bye to the di-graphs.* >>> >>> several people noted that LLIDL, at first glance, looks like line >>> noise. this is because of the use of digraphs to represent messaging >>> semantics. cast your memory back to the LLIDL resource description >>> for the seed cap: >>> >>> %% seed >>> -> { capabilities: [ string, ... ] } >>> <- { capabilities: { $: uri } } >>> >>> >>> the '%%' digraph means 'start of resource description'. the '->' >>> means 'this is what i'm going to send you' and the '<-' digraph >>> means 'i expect you to send me this back'. >>> >>> instead of digraphs, the DSD resource description language uses the >>> keyword "RESOURCE" to begin a resource. it also terminates the >>> resource definition with a semi colon. so a resource declaration >>> would look something like this: >>> >>> RESOURCE [resource definition] ; >>> >>> resource DEFINITIONs look more or less like they used to. for >>> example, here's a RESOURCE definition for a typical error response: >>> >>> # Resource description for a typical error resource >>> RESOURCE error_simple { >>> success : false, # clients check the success element to >>> see if there was an error >>> errno : integer, # this is a numeric code representing >>> the error >>> error : string, # this is a text description of the >>> error >>> description : uri # this is a URL that points to a HTML >>> web page describing the error >>> }; >>> >> >> Think we discussed this before, which I said wasn't much of the worry >> since the what is pivotal is more significant. That said, however, be >> sure to keep in mind that anything like digraphs make it easier to >> use non-English only keywords. >> >> We seem to agree in structure. >> >> >> >>> >>> *item 2 : the use of type literals instead of type names* >>> >>> in the example above, we used 'false' instead of 'boolean' as the >>> type definition for the 'success' element of the error resource. DSD >>> resource definitions can use type literals to imply that the element >>> should exist, and should have a specific value. so if you wanted to >>> define a resource that represented the origin of a 3d space, you >>> could use: >>> >>> # Point in a 3D rectangular space RESOURCE cartesian_point [ >>> real, # x coordinate >>> real, # y coordinate >>> real # z coordinate >>> ]; >>> >>> # Origin of a rectangular (cartesian) space >>> RESOURCE cartesian_origin [ 0.0, 0.0, 0.0 ]; >>> >> >> Good idea, I'm just not quite sure if it is so obvious in practice. >> >> >>> >>> *item 3 : type specifiers use the same names as the elements inside >>> the XML serialization.* >>> >>> instead of using "int", we use "integer." ditto for other types. so >>> the resource definition. here's a resource definition for something >>> with an integer in it: >>> >>> # Random resource definition of a map with an integer in it >>> RESOURCE whatever { >>> element : integer >>> }; >>> >> >> This is made obvious by the default use of LLSD, still. Notice >> SNOW-375 I did have a few extras for optional fields and proprietary >> fields. We know they are there, but probably won't have an public >> definition of such structures. Guess we need that tidbit formalized. >> >> >>> >>> *item 4 : DSD variant declarations don't suck for beginners* >>> >>> i always thought repeated '&' definitions to denote variants was >>> sort of snobbish. it makes sense to peeps who've sat through classes >>> on regular grammars and ABNF, but i wouldn't mind it too much if >>> someone with a basic understanding of procedural coding could >>> understand what was going on. so i came up with the VARIANT keyword. >>> it looks like this: >>> >>> VARIANT : { } >>> >>> so here's an example: >>> >>> # Enhanced Error resource >>> >>> RESOURCE error_enhanced VARIANT error_type : string { >>> 'number' : { >>> success : false, >>> errno : integer >>> }, >>> 'string' : { >>> success : false, >>> error : string >>> }, >>> 'url' : { >>> success : false, >>> description : uri >>> } >>> }; >>> >>> >>> what this means is that the "error_enhanced" resource has three >>> valid forms, that look like: >>> >>> RESOURCE error_enhanced { >>> error_type : 'number', >>> success : false, >>> errno : integer >>> }; >>> >>> RESOURCE error_enhanced { >>> error_type : 'string', >>> success : false, >>> error : string >>> } >>> >>> RESOURCE error_enhanced { >>> error_type : 'url', >>> success : false, >>> description : uri >>> } >>> >>> >>> so the shows up as an element in each of the valid >>> forms as an literal element of type . >> >> Did I find any significant use for such? I mean is there somewhere in >> specific that that variant structure is more helpful than what I >> used? I think as we get into more specific usage and documentation of >> that usage we do need simplified ways makes some redundancy obvious. >> I just used wiki markup for that for now, I think. >> >> >>> >>> *item 5 : say good by to HTTP verbs.* >>> >>> LLIDL as specified is pretty much intertwined with HTTP. many people >>> thought that was a bad idea. In creating an interface, DSD uses five >>> abstract "interaction semantics": CREATE, READ, UPDATE, DELETE and >>> EVENT. >>> >>> the first four do what you expect them to do while the last one >>> describes the form or "shape" of an unsolicited message coming from >>> the event queue. >>> >>> so if you wanted to login, you might use the following interface >>> >>> INTERFACE CREATE session_factory { >>> username : string, >>> secret : binary >>> } RESPONSE VARIANT success : boolean { >>> false : { >>> errno : integer, >>> err : string, >>> description : uri >>> }, >>> true : { >>> seed : uri >>> } >>> }; >>> >>> >>> or, you could do the following: >>> >>> RESOURCE error { >>> errno : integer, >>> err : string, >>> description : uri >>> }; >>> >>> INTERFACE CREATE session_factory { >>> username : string, >>> secret : binary >>> } RESPONSE VARIANT success : boolean { >>> false : error, >>> true : { >>> seed : uri >>> } >>> }; >>> >>> >>> so anyway, i'm writing up this stuff in the DSD type system draft. >>> feel free to comment. as things stand, if VWRAP continues as a >>> working group, i'll integrate your comments on the draft. if not, >>> i'll modify the draft so as to remain compatibility with existing >>> DSD implementations and publish it a an individual / informational >>> draft for the purpose of registering the mime types. >> As long as usage doesn't fall out of ReST than it'll work. Remember >> that ReST doesn't have to use HTTP. If you see my implementation, >> there is the ReST queue being full of tasks and part of those task >> relate to HTTP methods. People don't seem to often split ReST queries >> as different than HTTP verbs, but I do. I guess that is like >> resource/interface differences. >> >> I thought I saw another submitted document to review, yet couldn't >> find it. Was there a newer version? >> >> >> > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Tue Apr 5 12:32:09 2011 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 915B93A696F for ; Tue, 5 Apr 2011 12:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 flxKoLolgiB4 for ; Tue, 5 Apr 2011 12:32:07 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8ED8E3A67AE for ; Tue, 5 Apr 2011 12:32:07 -0700 (PDT) Received: by iwn39 with SMTP id 39so875817iwn.31 for ; Tue, 05 Apr 2011 12:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6ER/r9QUxMjArDa4nsaRPQ/hwV0gmgR0uhyoKKJ5Gbw=; b=GyQax2Ce4k9V3vzbUmyBnHS5JIw9R5L/ZKtQDAqUF16Fp+guYck7zGceKG06uftNi7 I/ntfRGPf6A3VPTVWY4HlyW42lZGAAxTEI1jmpmn0+VPVbVGZTstYp+MbjDRnkTax5Xe Nffe1btBFHFkRxDE+uQ4wjn5HWSew6Y5YN3JI= 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=GN/QOnWHloip14I+9KOa5oTrD1MBX3im3OP15wgb4RKttPADjkdgQhcgBJbqS7BfS8 vOrbAn52shfittQDHaOrMpRpC2Kqty4T1xwPiKvUWtT3Arn0oqRThuWiMzAgc5SCGtN0 Ge2Rz71yEG8KpnMO6VRfgiX6lehZuvG6jHhrA= Received: by 10.42.223.65 with SMTP id ij1mr106286icb.243.1302032030587; Tue, 05 Apr 2011 12:33:50 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id gx2sm4654008ibb.60.2011.04.05.12.33.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 12:33:49 -0700 (PDT) Message-ID: <4D9B6ECE.9000705@gmail.com> Date: Tue, 05 Apr 2011 12:34:38 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Dzonatas Sol References: <4D9B61D4.3000906@gmail.com> <4D9B6861.4030704@gmail.com> <4D9B6D71.5030400@gmail.com> In-Reply-To: <4D9B6D71.5030400@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org, Meadhbh Hamrick Subject: Re: [vwrap] informal description of the DSD interface description language 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, 05 Apr 2011 19:32:10 -0000 Let me reformat... there were extra chars (processed): Re: "bust mode" or "combined" See the syntax I used here: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Asset I used the the curly brackets {} with ellipses to show what kind of data can be combine as an array in LLSD. Here note that the UUID moves from the RESOURCE into the array as the individual items are combined, such that indivual requests for: /Asset/Notecard/00000000-0000-0000-0000-000000000001 /Asset/Notecard/00000000-0000-0000-0000-000000000002 /Asset/Notecard/00000000-0000-0000-0000-000000000003 /Asset/Notecard/00000000-0000-0000-0000-000000000004 become /Asset/Notecard/s { 00000000-0000-0000-0000-000000000001, 00000000-0000-0000-0000-000000000002, 00000000-0000-0000-0000-000000000003, 00000000-0000-0000-0000-000000000004 } The combined reply may look like: /Asset/Notecard/s { 00000000-0000-0000-0000-000000000001, { asset-data... } 00000000-0000-0000-0000-000000000002, { asset-data... } 00000000-0000-0000-0000-000000000003, { asset-data... } 00000000-0000-0000-0000-000000000004 { asset-data... } } Handling assets not immediately available are easy, I just stick the individual response codes in the array instead of expect it as an httpcode. Dzonatas Sol wrote: > > Dzonatas Sol wrote: >> There are two(/three) significant touches I made: >> >> First, burst mode. Already as people upgrade to capabilities rather >> than the older UDP style we can see they complain about bottlenecks >> due to individual requests being made. This is more of fault of the >> implementators not doing full ReST rather than the limits of >> capabilities. I denote "burst mode" to make sure full ReST is being >> implemented. This is where RESOURCES & INTERFACES keep the very >> basic object oriented message paradigm. Then capabilities then can >> become used for specific individual queries to combined multiple >> resource queries. This alleviates the individual connections per item >> into the non-issue bit-bucket. The only new issue with "burst mode" >> is limits on how many items can be combined (length of overall body >> and parts). >> >> Second, public resources. The significance I put on "resources" is >> that these are the public names being referred to for any such >> related message and/or method. Already implemented are the private >> version of these resources. Maybe there needs to be some syntax to >> note that the resources appear as something else under specific >> conditions. The current private URIs are just a digest of given >> capabilities present (used by lookup tables). Internally, only the >> public resources are of need, yet the private URI may contain >> something in regards to the basic object oriented message paradigm. >> It's not that complicated once one separates the ReST paradigm from >> HTTP methods and implements the full ReST paradigm internally. When >> the implementator relies on HTTP as the queue, then they don't have a >> true ReST paradigm, only something compatible (for quick >> implementation). >> >> Third, private resources, as above and already implemented by LL >> (stateless). We haven't got into stateful tranfer connections. *sigh* >> These would be ideal for the keep-alive, long-poll, and bust mode >> options. >> >> >> Dzonatas Sol wrote: >>> Some notes... in line... >>> >>> Meadhbh Hamrick wrote: >>>> hey peeps, it shouldn't be shocking to anyone i'm not a big fan of >>>> lentczner's "little" interface description language, llidl. while >>>> it can be argued it's "condensed" format is easy enough to use, >>>> once mastered, i prefer something mildly more expressive. when i >>>> was working on the last version of the LLSD draft, i solicited >>>> comments from several implementers inside and outside Linden, and >>>> they all said the same thing: "LLIDL is cool enough, but it looks >>>> like line noise if you don't know what you're looking at." >>>> >>>> i came up with the following interface description language to >>>> address the "looks like line noise" critique. this is the IDL >>>> that's going in the DSD draft, since that's what we're using at >>>> sl8.us and various sensor projects that are using >>>> DSD. i'm assuming you've read and understand the LLIDL section of >>>> the most recent type system draft. >>>> >>>> again, i have no idea if this will be relevant since no one's >>>> stepped up to be an document author for future revisions of this >>>> group's docs or an editor to re-draft a new charter. but on the off >>>> chance people do this and still want to work on the type system, >>>> these are the changes recommended by several LLIDL users and >>>> implementers. >>> >>> Be sure to see review these to see how I based off LLIDL: >>> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375#Queries_.26_Type_System >>> >>> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Asset >>> >>> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Interface >>> >>> (and others there) >>> >>> Note that I used more of what is in regards to ReST than only LLIDL. >>> >>>> >>>> *item 0 : disentangling resources from interfaces.* >>>> >>>> LLIDL sort of conflated a resource (something to be accessed) with >>>> the method of accessing it. there was no way to "officially" define >>>> a "resource" independent of the semantics to access it. DSD says >>>> that RESOURCEs are just data definitions. INTERFACEs define how >>>> they're used. >>> >>> As I see "resource", it manly is untranslated to any particalar >>> implementation. Some still think there is an obvious implementation >>> due to common resources being used by HTTP. I think you have some >>> like C#'s interface in mind? >>> >>> >>>> >>>> *item 1 : say good-bye to the di-graphs.* >>>> >>>> several people noted that LLIDL, at first glance, looks like line >>>> noise. this is because of the use of digraphs to represent >>>> messaging semantics. cast your memory back to the LLIDL resource >>>> description for the seed cap: >>>> >>>> %% seed >>>> -> { capabilities: [ string, ... ] } >>>> <- { capabilities: { $: uri } } >>>> >>>> >>>> the '%%' digraph means 'start of resource description'. the '->' >>>> means 'this is what i'm going to send you' and the '<-' digraph >>>> means 'i expect you to send me this back'. >>>> >>>> instead of digraphs, the DSD resource description language uses the >>>> keyword "RESOURCE" to begin a resource. it also terminates the >>>> resource definition with a semi colon. so a resource declaration >>>> would look something like this: >>>> >>>> RESOURCE [resource definition] ; >>>> >>>> resource DEFINITIONs look more or less like they used to. for >>>> example, here's a RESOURCE definition for a typical error response: >>>> >>>> # Resource description for a typical error resource >>>> RESOURCE error_simple { >>>> success : false, # clients check the success element to >>>> see if there was an error >>>> errno : integer, # this is a numeric code representing >>>> the error >>>> error : string, # this is a text description of the >>>> error >>>> description : uri # this is a URL that points to a HTML >>>> web page describing the error >>>> }; >>>> >>> >>> Think we discussed this before, which I said wasn't much of the >>> worry since the what is pivotal is more significant. That said, >>> however, be sure to keep in mind that anything like digraphs make it >>> easier to use non-English only keywords. >>> >>> We seem to agree in structure. >>> >>> >>> >>>> >>>> *item 2 : the use of type literals instead of type names* >>>> >>>> in the example above, we used 'false' instead of 'boolean' as the >>>> type definition for the 'success' element of the error resource. >>>> DSD resource definitions can use type literals to imply that the >>>> element should exist, and should have a specific value. so if you >>>> wanted to define a resource that represented the origin of a 3d >>>> space, you could use: >>>> >>>> # Point in a 3D rectangular space RESOURCE cartesian_point [ >>>> real, # x coordinate >>>> real, # y coordinate >>>> real # z coordinate >>>> ]; >>>> >>>> # Origin of a rectangular (cartesian) space >>>> RESOURCE cartesian_origin [ 0.0, 0.0, 0.0 ]; >>>> >>> >>> Good idea, I'm just not quite sure if it is so obvious in practice. >>> >>> >>>> >>>> *item 3 : type specifiers use the same names as the elements inside >>>> the XML serialization.* >>>> >>>> instead of using "int", we use "integer." ditto for other types. so >>>> the resource definition. here's a resource definition for something >>>> with an integer in it: >>>> >>>> # Random resource definition of a map with an integer in it >>>> RESOURCE whatever { >>>> element : integer >>>> }; >>>> >>> >>> This is made obvious by the default use of LLSD, still. Notice >>> SNOW-375 I did have a few extras for optional fields and proprietary >>> fields. We know they are there, but probably won't have an public >>> definition of such structures. Guess we need that tidbit formalized. >>> >>> >>>> >>>> *item 4 : DSD variant declarations don't suck for beginners* >>>> >>>> i always thought repeated '&' definitions to denote variants was >>>> sort of snobbish. it makes sense to peeps who've sat through >>>> classes on regular grammars and ABNF, but i wouldn't mind it too >>>> much if someone with a basic understanding of procedural coding >>>> could understand what was going on. so i came up with the VARIANT >>>> keyword. it looks like this: >>>> >>>> VARIANT : { } >>>> >>>> so here's an example: >>>> >>>> # Enhanced Error resource >>>> >>>> RESOURCE error_enhanced VARIANT error_type : string { >>>> 'number' : { >>>> success : false, >>>> errno : integer >>>> }, >>>> 'string' : { >>>> success : false, >>>> error : string >>>> }, >>>> 'url' : { >>>> success : false, >>>> description : uri >>>> } >>>> }; >>>> >>>> >>>> what this means is that the "error_enhanced" resource has three >>>> valid forms, that look like: >>>> >>>> RESOURCE error_enhanced { >>>> error_type : 'number', >>>> success : false, >>>> errno : integer >>>> }; >>>> >>>> RESOURCE error_enhanced { >>>> error_type : 'string', >>>> success : false, >>>> error : string >>>> } >>>> >>>> RESOURCE error_enhanced { >>>> error_type : 'url', >>>> success : false, >>>> description : uri >>>> } >>>> >>>> >>>> so the shows up as an element in each of the valid >>>> forms as an literal element of type . >>> >>> Did I find any significant use for such? I mean is there somewhere >>> in specific that that variant structure is more helpful than what I >>> used? I think as we get into more specific usage and documentation >>> of that usage we do need simplified ways makes some redundancy >>> obvious. I just used wiki markup for that for now, I think. >>> >>> >>>> >>>> *item 5 : say good by to HTTP verbs.* >>>> >>>> LLIDL as specified is pretty much intertwined with HTTP. many >>>> people thought that was a bad idea. In creating an interface, DSD >>>> uses five abstract "interaction semantics": CREATE, READ, UPDATE, >>>> DELETE and EVENT. >>>> >>>> the first four do what you expect them to do while the last one >>>> describes the form or "shape" of an unsolicited message coming from >>>> the event queue. >>>> >>>> so if you wanted to login, you might use the following interface >>>> >>>> INTERFACE CREATE session_factory { >>>> username : string, >>>> secret : binary >>>> } RESPONSE VARIANT success : boolean { >>>> false : { >>>> errno : integer, >>>> err : string, >>>> description : uri >>>> }, >>>> true : { >>>> seed : uri >>>> } >>>> }; >>>> >>>> >>>> or, you could do the following: >>>> >>>> RESOURCE error { >>>> errno : integer, >>>> err : string, >>>> description : uri >>>> }; >>>> >>>> INTERFACE CREATE session_factory { >>>> username : string, >>>> secret : binary >>>> } RESPONSE VARIANT success : boolean { >>>> false : error, >>>> true : { >>>> seed : uri >>>> } >>>> }; >>>> >>>> >>>> so anyway, i'm writing up this stuff in the DSD type system draft. >>>> feel free to comment. as things stand, if VWRAP continues as a >>>> working group, i'll integrate your comments on the draft. if not, >>>> i'll modify the draft so as to remain compatibility with existing >>>> DSD implementations and publish it a an individual / informational >>>> draft for the purpose of registering the mime types. >>> As long as usage doesn't fall out of ReST than it'll work. Remember >>> that ReST doesn't have to use HTTP. If you see my implementation, >>> there is the ReST queue being full of tasks and part of those task >>> relate to HTTP methods. People don't seem to often split ReST >>> queries as different than HTTP verbs, but I do. I guess that is like >>> resource/interface differences. >>> >>> I thought I saw another submitted document to review, yet couldn't >>> find it. Was there a newer version? >>> >>> >>> >> >> > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Tue Apr 5 12:53:34 2011 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 A55023A6990 for ; Tue, 5 Apr 2011 12:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 32ALuxaLLdjX for ; Tue, 5 Apr 2011 12:53:33 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 33D593A6407 for ; Tue, 5 Apr 2011 12:53:33 -0700 (PDT) Received: by iye19 with SMTP id 19so891719iye.31 for ; Tue, 05 Apr 2011 12:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=M6p5B57aPg9l+CA2IBV/F0zul21ZpKFTUMw82syAOvE=; b=d3MoVtAB0QKezctwa76O1efKr/xLUP1g+XHzZCXzHr467JgAEBc458PEX8jlTr13C+ 2fBwTBowmYpI+pD9Eu6Y+ne8mMnsAmyMjqoOwRPHkYQ1dRV4h0q3qJAfesMSEQyI6tON unFvIDPSmVY4eyiVf5PoS9Jutbyk+yGbBdspA= 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=q1mQ4TV4vSMktBXdbxbVh7McdDWyJizPXkA+h4hVLkcmCpOnaAl0xd7suOWO/uDGjY bV1r4gNWjmzz3k74wDKSkzpeKFP5iAbYEnE8I37WGXIQBziZAr7CJjzYBCaPOB1XEcMP jBjnNbkKkSumDIlagTnpGK7vOnyg8wijkygI0= Received: by 10.43.62.13 with SMTP id wy13mr96265icb.360.1302033316102; Tue, 05 Apr 2011 12:55:16 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id vr5sm4348238icb.12.2011.04.05.12.55.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 12:55:15 -0700 (PDT) Message-ID: <4D9B73D5.4000809@gmail.com> Date: Tue, 05 Apr 2011 12:56:05 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <20110405152025.26ba8f77@hikaru.localdomain> <4D9B4586.9080004@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 05 Apr 2011 19:53:34 -0000 Morgaine, we mooted your hash-based idea. This does nothing to help implement asset services. The only significant point you made is some expression for optimization, not correct functionality, which is needed first As for your other two, we can summarize those with public resources and flow (forward/reverse). Any more specific network topology than that only makes it harder to address. The only thing to worry about is already custom resources that overlap with newer public resources. Morgaine wrote: > On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol > wrote: > > > Do you think we are ready to implement some asset services now, > with/without complete documentation? > > What more do you think is needed? > > > Two or three things seem to be needed: > > * Defining the asset addressing concept is an extremely important > matter, almost certainly the most important matter of all, > because that determines how robust and scalable our worlds will > be.� I've already examined alternatives for that in some depth, > and the design with the best engineering properties so far seems > to be universal hash-based addressing.� I first described that > approach on the list here --- > http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html > , and referred to it in various subsequent discussions. > > * Defining the data flows between regions, clients, and asset > services and which parameters control the flows needs to be done > before a test asset service can be implemented.� Without that, > an asset service is just a network-accessible storage service, > not an asset service in the VWRAP sense.� Network storage > services exist already, so just implementing one of those would > not advance VWRAP. > > * We need to examine how various deployment patterns will use the > asset services, and how the /multiple/ asset services that > interop introduces are handled.� I am working on this currently. > > > None of the above is particularly hard.� I think it won't be long > before we have a scheme worked out and are ready for some > implementation work. > > > Morgaine. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Tue Apr 5 13:07:25 2011 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 33DFA3A697C for ; Tue, 5 Apr 2011 13:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.512 X-Spam-Level: X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 VU0Aqf0EuyKz for ; Tue, 5 Apr 2011 13:07:20 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 086E93A67A2 for ; Tue, 5 Apr 2011 13:07:19 -0700 (PDT) Received: by iwn39 with SMTP id 39so909751iwn.31 for ; Tue, 05 Apr 2011 13:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FO9Ymr5nCimwi5vtdzEt1vp1W3rLqIOhx8AuUzb+HDE=; b=jZks4UwqmPuCc+W8x7hIDwgtlOcYGMwMAtX638E4VBKkhAP3u3Yu+WJUeQB6tg9v4n doPWRzj/IzpjMyjwHTux37bxunY3wuWE2gg1oVtExvTf2VHNxNkRtFIBlyvMsNVMBQXS 88Cfsy5yh4tcm4v+pPYwPJbasgbhw+7n5l3Hs= 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=Jf2e2E/qcsY10eMYjqVEp6OsaQNOqMTeFPFNsBjrBHwpxK1kxzlD7wCgsyrJTeyYZ1 DpKB7wx/BvTcWDzennK0Q8aPPoJz3yEmDSGzCcq5cdrFdE+NwmCiIqUYoWVSbc00ssX6 E/mWtSsUKn0RVlHkHJphH9t9TeASNugAu5VUE= Received: by 10.43.61.197 with SMTP id wx5mr109119icb.286.1302034141595; Tue, 05 Apr 2011 13:09:01 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id mv26sm4667060ibb.11.2011.04.05.13.08.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 13:09:00 -0700 (PDT) Message-ID: <4D9B770D.4050207@gmail.com> Date: Tue, 05 Apr 2011 13:09:49 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Dzonatas Sol References: <4D9B61D4.3000906@gmail.com> <4D9B6861.4030704@gmail.com> <4D9B6D71.5030400@gmail.com> <4D9B6ECE.9000705@gmail.com> In-Reply-To: <4D9B6ECE.9000705@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org, Meadhbh Hamrick Subject: Re: [vwrap] informal description of the DSD interface description language 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, 05 Apr 2011 20:07:25 -0000 Further, I wanted to give more details about mime-parts used in instead of LLSD array for combined formats. To describe mime-parts seems like an overdose: xml-org-ietf-vwrap-* where * becomes the public resource. Need to uncompress the overall idea we're stuck at here. Mime-parts seems ideal for keep-alive and long-poll while LLSD arrays seem ideal otherwise. Dzonatas Sol wrote: > Let me reformat... there were extra chars (processed): > > Re: "bust mode" or "combined" > > See the syntax I used here: > http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Asset > > > I used the the curly brackets {} with ellipses to show what kind of > data can be combine as an array in LLSD. Here note that the UUID moves > from the RESOURCE into the array as the individual items are combined, > such that indivual requests for: > > /Asset/Notecard/00000000-0000-0000-0000-000000000001 > /Asset/Notecard/00000000-0000-0000-0000-000000000002 > /Asset/Notecard/00000000-0000-0000-0000-000000000003 > /Asset/Notecard/00000000-0000-0000-0000-000000000004 > > become > > /Asset/Notecard/s > { > 00000000-0000-0000-0000-000000000001, > 00000000-0000-0000-0000-000000000002, > 00000000-0000-0000-0000-000000000003, > 00000000-0000-0000-0000-000000000004 > } > > The combined reply may look like: > > /Asset/Notecard/s > { > 00000000-0000-0000-0000-000000000001, { asset-data... } > 00000000-0000-0000-0000-000000000002, { asset-data... } > 00000000-0000-0000-0000-000000000003, { asset-data... } > 00000000-0000-0000-0000-000000000004 { asset-data... } > } > > Handling assets not immediately available are easy, I just stick the > individual response codes in the array instead of expect it as an > httpcode. > > Dzonatas Sol wrote: >> >> Dzonatas Sol wrote: >>> There are two(/three) significant touches I made: >>> >>> First, burst mode. Already as people upgrade to capabilities rather >>> than the older UDP style we can see they complain about bottlenecks >>> due to individual requests being made. This is more of fault of the >>> implementators not doing full ReST rather than the limits of >>> capabilities. I denote "burst mode" to make sure full ReST is being >>> implemented. This is where RESOURCES & INTERFACES keep the very >>> basic object oriented message paradigm. Then capabilities then can >>> become used for specific individual queries to combined multiple >>> resource queries. This alleviates the individual connections per >>> item into the non-issue bit-bucket. The only new issue with "burst >>> mode" is limits on how many items can be combined (length of overall >>> body and parts). >>> >>> Second, public resources. The significance I put on "resources" is >>> that these are the public names being referred to for any such >>> related message and/or method. Already implemented are the private >>> version of these resources. Maybe there needs to be some syntax to >>> note that the resources appear as something else under specific >>> conditions. The current private URIs are just a digest of given >>> capabilities present (used by lookup tables). Internally, only the >>> public resources are of need, yet the private URI may contain >>> something in regards to the basic object oriented message paradigm. >>> It's not that complicated once one separates the ReST paradigm from >>> HTTP methods and implements the full ReST paradigm internally. When >>> the implementator relies on HTTP as the queue, then they don't have >>> a true ReST paradigm, only something compatible (for quick >>> implementation). >>> >>> Third, private resources, as above and already implemented by LL >>> (stateless). We haven't got into stateful tranfer connections. >>> *sigh* These would be ideal for the keep-alive, long-poll, and bust >>> mode options. >>> >>> >>> Dzonatas Sol wrote: >>>> Some notes... in line... >>>> >>>> Meadhbh Hamrick wrote: >>>>> hey peeps, it shouldn't be shocking to anyone i'm not a big fan of >>>>> lentczner's "little" interface description language, llidl. while >>>>> it can be argued it's "condensed" format is easy enough to use, >>>>> once mastered, i prefer something mildly more expressive. when i >>>>> was working on the last version of the LLSD draft, i solicited >>>>> comments from several implementers inside and outside Linden, and >>>>> they all said the same thing: "LLIDL is cool enough, but it looks >>>>> like line noise if you don't know what you're looking at." >>>>> >>>>> i came up with the following interface description language to >>>>> address the "looks like line noise" critique. this is the IDL >>>>> that's going in the DSD draft, since that's what we're using at >>>>> sl8.us and various sensor projects that are using >>>>> DSD. i'm assuming you've read and understand the LLIDL section of >>>>> the most recent type system draft. >>>>> >>>>> again, i have no idea if this will be relevant since no one's >>>>> stepped up to be an document author for future revisions of this >>>>> group's docs or an editor to re-draft a new charter. but on the >>>>> off chance people do this and still want to work on the type >>>>> system, these are the changes recommended by several LLIDL users >>>>> and implementers. >>>> >>>> Be sure to see review these to see how I based off LLIDL: >>>> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375#Queries_.26_Type_System >>>> >>>> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Asset >>>> >>>> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Interface >>>> >>>> (and others there) >>>> >>>> Note that I used more of what is in regards to ReST than only LLIDL. >>>> >>>>> >>>>> *item 0 : disentangling resources from interfaces.* >>>>> >>>>> LLIDL sort of conflated a resource (something to be accessed) with >>>>> the method of accessing it. there was no way to "officially" >>>>> define a "resource" independent of the semantics to access it. DSD >>>>> says that RESOURCEs are just data definitions. INTERFACEs define >>>>> how they're used. >>>> >>>> As I see "resource", it manly is untranslated to any particalar >>>> implementation. Some still think there is an obvious implementation >>>> due to common resources being used by HTTP. I think you have some >>>> like C#'s interface in mind? >>>> >>>> >>>>> >>>>> *item 1 : say good-bye to the di-graphs.* >>>>> >>>>> several people noted that LLIDL, at first glance, looks like line >>>>> noise. this is because of the use of digraphs to represent >>>>> messaging semantics. cast your memory back to the LLIDL resource >>>>> description for the seed cap: >>>>> >>>>> %% seed >>>>> -> { capabilities: [ string, ... ] } >>>>> <- { capabilities: { $: uri } } >>>>> >>>>> >>>>> the '%%' digraph means 'start of resource description'. the '->' >>>>> means 'this is what i'm going to send you' and the '<-' digraph >>>>> means 'i expect you to send me this back'. >>>>> >>>>> instead of digraphs, the DSD resource description language uses >>>>> the keyword "RESOURCE" to begin a resource. it also terminates the >>>>> resource definition with a semi colon. so a resource declaration >>>>> would look something like this: >>>>> >>>>> RESOURCE [resource definition] ; >>>>> >>>>> resource DEFINITIONs look more or less like they used to. for >>>>> example, here's a RESOURCE definition for a typical error response: >>>>> >>>>> # Resource description for a typical error resource >>>>> RESOURCE error_simple { >>>>> success : false, # clients check the success element to >>>>> see if there was an error >>>>> errno : integer, # this is a numeric code representing >>>>> the error >>>>> error : string, # this is a text description of the >>>>> error >>>>> description : uri # this is a URL that points to a HTML >>>>> web page describing the error >>>>> }; >>>>> >>>> >>>> Think we discussed this before, which I said wasn't much of the >>>> worry since the what is pivotal is more significant. That said, >>>> however, be sure to keep in mind that anything like digraphs make >>>> it easier to use non-English only keywords. >>>> >>>> We seem to agree in structure. >>>> >>>> >>>> >>>>> >>>>> *item 2 : the use of type literals instead of type names* >>>>> >>>>> in the example above, we used 'false' instead of 'boolean' as the >>>>> type definition for the 'success' element of the error resource. >>>>> DSD resource definitions can use type literals to imply that the >>>>> element should exist, and should have a specific value. so if you >>>>> wanted to define a resource that represented the origin of a 3d >>>>> space, you could use: >>>>> >>>>> # Point in a 3D rectangular space RESOURCE cartesian_point [ >>>>> real, # x coordinate >>>>> real, # y coordinate >>>>> real # z coordinate >>>>> ]; >>>>> >>>>> # Origin of a rectangular (cartesian) space >>>>> RESOURCE cartesian_origin [ 0.0, 0.0, 0.0 ]; >>>>> >>>> >>>> Good idea, I'm just not quite sure if it is so obvious in practice. >>>> >>>> >>>>> >>>>> *item 3 : type specifiers use the same names as the elements >>>>> inside the XML serialization.* >>>>> >>>>> instead of using "int", we use "integer." ditto for other types. >>>>> so the resource definition. here's a resource definition for >>>>> something with an integer in it: >>>>> >>>>> # Random resource definition of a map with an integer in it >>>>> RESOURCE whatever { >>>>> element : integer >>>>> }; >>>>> >>>> >>>> This is made obvious by the default use of LLSD, still. Notice >>>> SNOW-375 I did have a few extras for optional fields and >>>> proprietary fields. We know they are there, but probably won't have >>>> an public definition of such structures. Guess we need that tidbit >>>> formalized. >>>> >>>> >>>>> >>>>> *item 4 : DSD variant declarations don't suck for beginners* >>>>> >>>>> i always thought repeated '&' definitions to denote variants was >>>>> sort of snobbish. it makes sense to peeps who've sat through >>>>> classes on regular grammars and ABNF, but i wouldn't mind it too >>>>> much if someone with a basic understanding of procedural coding >>>>> could understand what was going on. so i came up with the VARIANT >>>>> keyword. it looks like this: >>>>> >>>>> VARIANT : { } >>>>> >>>>> so here's an example: >>>>> >>>>> # Enhanced Error resource >>>>> >>>>> RESOURCE error_enhanced VARIANT error_type : string { >>>>> 'number' : { >>>>> success : false, >>>>> errno : integer >>>>> }, >>>>> 'string' : { >>>>> success : false, >>>>> error : string >>>>> }, >>>>> 'url' : { >>>>> success : false, >>>>> description : uri >>>>> } >>>>> }; >>>>> >>>>> >>>>> what this means is that the "error_enhanced" resource has three >>>>> valid forms, that look like: >>>>> >>>>> RESOURCE error_enhanced { >>>>> error_type : 'number', >>>>> success : false, >>>>> errno : integer >>>>> }; >>>>> >>>>> RESOURCE error_enhanced { >>>>> error_type : 'string', >>>>> success : false, >>>>> error : string >>>>> } >>>>> >>>>> RESOURCE error_enhanced { >>>>> error_type : 'url', >>>>> success : false, >>>>> description : uri >>>>> } >>>>> >>>>> >>>>> so the shows up as an element in each of the valid >>>>> forms as an literal element of type . >>>> >>>> Did I find any significant use for such? I mean is there somewhere >>>> in specific that that variant structure is more helpful than what I >>>> used? I think as we get into more specific usage and documentation >>>> of that usage we do need simplified ways makes some redundancy >>>> obvious. I just used wiki markup for that for now, I think. >>>> >>>> >>>>> >>>>> *item 5 : say good by to HTTP verbs.* >>>>> >>>>> LLIDL as specified is pretty much intertwined with HTTP. many >>>>> people thought that was a bad idea. In creating an interface, DSD >>>>> uses five abstract "interaction semantics": CREATE, READ, UPDATE, >>>>> DELETE and EVENT. >>>>> >>>>> the first four do what you expect them to do while the last one >>>>> describes the form or "shape" of an unsolicited message coming >>>>> from the event queue. >>>>> >>>>> so if you wanted to login, you might use the following interface >>>>> >>>>> INTERFACE CREATE session_factory { >>>>> username : string, >>>>> secret : binary >>>>> } RESPONSE VARIANT success : boolean { >>>>> false : { >>>>> errno : integer, >>>>> err : string, >>>>> description : uri >>>>> }, >>>>> true : { >>>>> seed : uri >>>>> } >>>>> }; >>>>> >>>>> >>>>> or, you could do the following: >>>>> >>>>> RESOURCE error { >>>>> errno : integer, >>>>> err : string, >>>>> description : uri >>>>> }; >>>>> >>>>> INTERFACE CREATE session_factory { >>>>> username : string, >>>>> secret : binary >>>>> } RESPONSE VARIANT success : boolean { >>>>> false : error, >>>>> true : { >>>>> seed : uri >>>>> } >>>>> }; >>>>> >>>>> >>>>> so anyway, i'm writing up this stuff in the DSD type system draft. >>>>> feel free to comment. as things stand, if VWRAP continues as a >>>>> working group, i'll integrate your comments on the draft. if not, >>>>> i'll modify the draft so as to remain compatibility with existing >>>>> DSD implementations and publish it a an individual / informational >>>>> draft for the purpose of registering the mime types. >>>> As long as usage doesn't fall out of ReST than it'll work. Remember >>>> that ReST doesn't have to use HTTP. If you see my implementation, >>>> there is the ReST queue being full of tasks and part of those task >>>> relate to HTTP methods. People don't seem to often split ReST >>>> queries as different than HTTP verbs, but I do. I guess that is >>>> like resource/interface differences. >>>> >>>> I thought I saw another submitted document to review, yet couldn't >>>> find it. Was there a newer version? >>>> >>>> >>>> >>> >>> >> >> > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From ohmeadhbh@gmail.com Tue Apr 5 13:09:17 2011 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 CC9C33A6998 for ; Tue, 5 Apr 2011 13:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nF5pCkEZcPHc for ; Tue, 5 Apr 2011 13:09:15 -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 9B6663A67A3 for ; Tue, 5 Apr 2011 13:09:15 -0700 (PDT) Received: by pvh1 with SMTP id 1so360898pvh.31 for ; Tue, 05 Apr 2011 13:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=NcLKH9Ai8TCj8PV00YrmfCvH7tb5NR5wJdVo2pwcfwg=; b=E0Nogdgily0qXCA40X9iU9rUuXb0Nxni8BfhXDZ8zL8Po1M5OdEA3Ms2y0wi0seBGk C7EoqS/ISsF1qhEQ4E2tESlEGB2LXMADyIIDHvs1RCCEi+rxMfjtleW9JI/y8Wtvfgpr ovJWF7iTwwXQYm3Wiptwaetl8ZRKZsnQ1LWzc= 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=wrBdgJm6h9w4FyH83FbYIbL2v7mrg1tW2WGggVfjDyggn5VwD8Uf4Jr8zPfkKO9hsY mCgQ7HqG3Q5SbAC30TrsGllVO4MVoffLX9RawsWiOQLTviSDbLW1phF3F7puYJKxrj1h hVk3rRTgU6ap73vlrpVQSCMuEdvwbJsBQ6dS0= Received: by 10.143.158.4 with SMTP id k4mr83092wfo.205.1302034258911; Tue, 05 Apr 2011 13:10:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.60.164 with HTTP; Tue, 5 Apr 2011 13:10:32 -0700 (PDT) In-Reply-To: <4D9B6ECE.9000705@gmail.com> References: <4D9B61D4.3000906@gmail.com> <4D9B6861.4030704@gmail.com> <4D9B6D71.5030400@gmail.com> <4D9B6ECE.9000705@gmail.com> From: Meadhbh Hamrick Date: Tue, 5 Apr 2011 13:10:32 -0700 Message-ID: To: Dzonatas Sol Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] informal description of the DSD interface description language 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, 05 Apr 2011 20:09:17 -0000 actually, you can find more notes on DSD at http://blog.meadhbh.org/2010/07/abstract-resource-definitions-vs-llidl.html though i am likely abandoning it since there's no telling what's happening with this group. if this group continues, i'll be happy to submit it as a draft here. if this group disbands, i'll likely submit it as an informational individual submission to the RFC editor so existing sites that use DSD (sl8.us, etc.) can take the X- off their content type headers. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Tue, Apr 5, 2011 at 12:34 PM, Dzonatas Sol wrote: > Let me reformat... =A0there were extra chars (processed): > > Re: "bust mode" or "combined" > > See the syntax I used here: > http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Asse= t > > I used the the curly brackets {} with ellipses to show what kind of data = can > be combine as an array in LLSD. Here note that the UUID moves from the > RESOURCE into the array as the individual items are combined, such that > indivual requests for: > > /Asset/Notecard/00000000-0000-0000-0000-000000000001 > /Asset/Notecard/00000000-0000-0000-0000-000000000002 > /Asset/Notecard/00000000-0000-0000-0000-000000000003 > /Asset/Notecard/00000000-0000-0000-0000-000000000004 > > become > > /Asset/Notecard/s > { > 00000000-0000-0000-0000-000000000001, > 00000000-0000-0000-0000-000000000002, > 00000000-0000-0000-0000-000000000003, > 00000000-0000-0000-0000-000000000004 > } > > The combined reply may look like: > > /Asset/Notecard/s > { > 00000000-0000-0000-0000-000000000001, { asset-data... } > 00000000-0000-0000-0000-000000000002, { asset-data... } > 00000000-0000-0000-0000-000000000003, { asset-data... } > 00000000-0000-0000-0000-000000000004 =A0{ asset-data... } > } > > Handling assets not immediately available are easy, I just stick the > individual response codes in the array instead of expect it as an httpcod= e. > > Dzonatas Sol wrote: >> >> Dzonatas Sol wrote: >>> >>> There are two(/three) significant touches I made: >>> >>> First, burst mode. Already as people upgrade to capabilities rather tha= n >>> the older UDP style we can see they complain about bottlenecks due to >>> individual requests being made. This is more of fault of the implementa= tors >>> not doing full ReST rather than the limits of capabilities. I denote "b= urst >>> mode" to make sure full ReST is being implemented. =A0This is where RES= OURCES >>> & INTERFACES keep the very basic object oriented message paradigm. Then >>> capabilities then can become used for specific individual queries to >>> combined multiple resource queries. This alleviates the individual >>> connections per item into the non-issue bit-bucket. The only new issue = with >>> "burst mode" is limits on how many items can be combined (length of ove= rall >>> body and parts). >>> >>> Second, public resources. The significance I put on "resources" is that >>> these are the public names being referred to for any such related messa= ge >>> and/or method. Already implemented are the private version of these >>> resources. Maybe there needs to be some syntax to note that the resourc= es >>> appear as something else under specific conditions. The current private= URIs >>> are just a digest of given capabilities present (used by lookup tables)= . >>> Internally, only the public resources are of need, yet the private URI = may >>> contain something in regards to the basic object oriented message parad= igm. >>> It's not that complicated once one separates the ReST paradigm from HTT= P >>> methods and implements the full ReST paradigm internally. When the >>> implementator relies on HTTP as the queue, then they don't have a true = ReST >>> paradigm, only something compatible (for quick implementation). >>> >>> Third, private resources, as above and already implemented by LL >>> (stateless). We haven't got into stateful tranfer connections. *sigh* T= hese >>> would be ideal for the keep-alive, long-poll, and bust mode options. >>> >>> >>> Dzonatas Sol wrote: >>>> >>>> Some notes... in line... >>>> >>>> Meadhbh Hamrick wrote: >>>>> >>>>> hey peeps, it shouldn't be shocking to anyone i'm not a big fan of >>>>> lentczner's "little" interface description language, llidl. while it = can be >>>>> argued it's "condensed" format is easy enough to use, once mastered, = i >>>>> prefer something mildly more expressive. when i was working on the la= st >>>>> version of the LLSD draft, i solicited comments from several implemen= ters >>>>> inside and outside Linden, and they all said the same thing: "LLIDL i= s cool >>>>> enough, but it looks like line noise if you don't know what you're lo= oking >>>>> at." >>>>> >>>>> i came up with the following interface description language to addres= s >>>>> the "looks like line noise" critique. this is the IDL that's going in= the >>>>> DSD draft, since that's what we're using at sl8.us an= d >>>>> various sensor projects that are using DSD. i'm assuming you've read = and >>>>> understand the LLIDL section of the most recent type system draft. >>>>> >>>>> again, i have no idea if this will be relevant since no one's stepped >>>>> up to be an document author for future revisions of this group's docs= or an >>>>> editor to re-draft a new charter. but on the off chance people do thi= s and >>>>> still want to work on the type system, these are the changes recommen= ded by >>>>> several LLIDL users and implementers. >>>> >>>> Be sure to see review these to see how I based off LLIDL: >>>> >>>> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375#Queries_.26= _Type_System >>>> >>>> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/A= sset >>>> >>>> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/I= nterface >>>> (and others there) >>>> >>>> Note that I used more of what is in regards to ReST than only LLIDL. >>>> >>>>> >>>>> *item 0 : disentangling resources from interfaces.* >>>>> >>>>> LLIDL sort of conflated a resource (something to be accessed) with th= e >>>>> method of accessing it. there was no way to "officially" define a "re= source" >>>>> independent of the semantics to access it. DSD says that RESOURCEs ar= e just >>>>> data definitions. INTERFACEs define how they're used. >>>> >>>> As I see "resource", it manly is untranslated to any particalar >>>> implementation. Some still think there is an obvious implementation du= e to >>>> common resources being used by HTTP. I think you have some like C#'s >>>> interface in mind? >>>> >>>> >>>>> >>>>> *item 1 : say good-bye to the di-graphs.* >>>>> >>>>> several people noted that LLIDL, at first glance, looks like line >>>>> noise. this is because of the use of digraphs to represent messaging >>>>> semantics. cast your memory back to the LLIDL resource description fo= r the >>>>> seed cap: >>>>> >>>>> =A0 =A0%% seed >>>>> =A0 =A0 =A0-> { capabilities: [ string, ... ] } >>>>> =A0 =A0 =A0<- { capabilities: { $: uri } } >>>>> >>>>> >>>>> the '%%' digraph means 'start of resource description'. the '->' mean= s >>>>> 'this is what i'm going to send you' and the '<-' digraph means 'i ex= pect >>>>> you to send me this back'. >>>>> >>>>> instead of digraphs, the DSD resource description language uses the >>>>> keyword "RESOURCE" to begin a resource. it also terminates the resour= ce >>>>> definition with a semi colon. so a resource declaration would look so= mething >>>>> like this: >>>>> >>>>> RESOURCE [resource definition] ; >>>>> >>>>> resource DEFINITIONs look more or less like they used to. for example= , >>>>> here's a RESOURCE definition for a typical error response: >>>>> >>>>> =A0 =A0# Resource description for a typical error resource >>>>> =A0 =A0RESOURCE error_simple { >>>>> =A0 =A0 =A0 success =A0 =A0 : false, =A0 =A0# clients check the succe= ss element to >>>>> =A0 =A0see if there was an error >>>>> =A0 =A0 =A0 errno =A0 =A0 =A0 : integer, =A0# this is a numeric code = representing >>>>> =A0 =A0the error >>>>> =A0 =A0 =A0 error =A0 =A0 =A0 : string, =A0 # this is a text descript= ion of the error >>>>> =A0 =A0 =A0 description : uri =A0 =A0 =A0 # this is a URL that points= to a HTML >>>>> =A0 =A0web page describing the error >>>>> =A0 =A0}; >>>>> >>>> >>>> Think we discussed this before, which I said wasn't much of the worry >>>> since the what is pivotal is more significant. That said, however, be = sure >>>> to keep in mind that anything like digraphs make it easier to use >>>> non-English only keywords. >>>> >>>> We seem to agree in structure. >>>> >>>> >>>> >>>>> >>>>> *item 2 : the use of type literals instead of type names* >>>>> >>>>> in the example above, we used 'false' instead of 'boolean' as the typ= e >>>>> definition for the 'success' element of the error resource. DSD resou= rce >>>>> definitions can use type literals to imply that the element should ex= ist, >>>>> and should have a specific value. so if you wanted to define a resour= ce that >>>>> represented the origin of a 3d space, you could use: >>>>> >>>>> =A0 =A0# Point in a 3D rectangular space =A0 =A0 RESOURCE cartesian_p= oint [ >>>>> =A0 =A0 =A0 real, =A0# x coordinate >>>>> =A0 =A0 =A0 real, =A0# y coordinate >>>>> =A0 =A0 =A0 real =A0 # z coordinate >>>>> =A0 =A0]; >>>>> >>>>> =A0 =A0# Origin of a rectangular (cartesian) space >>>>> =A0 =A0RESOURCE cartesian_origin [ 0.0, 0.0, 0.0 ]; >>>>> >>>> >>>> Good idea, I'm just not quite sure if it is so obvious in practice. >>>> >>>> >>>>> >>>>> *item 3 : type specifiers use the same names as the elements inside t= he >>>>> XML serialization.* >>>>> >>>>> instead of using "int", we use "integer." ditto for other types. so t= he >>>>> resource definition. here's a resource definition for something with = an >>>>> integer in it: >>>>> >>>>> =A0 =A0# Random resource definition of a map with an integer in it >>>>> =A0 =A0RESOURCE whatever { >>>>> =A0 =A0 =A0 element : integer >>>>> =A0 =A0}; >>>>> >>>> >>>> This is made obvious by the default use of LLSD, still. Notice SNOW-37= 5 >>>> I did have a few extras for optional fields and proprietary fields. We= know >>>> they are there, but probably won't have an public definition of such >>>> structures. Guess we need that tidbit formalized. >>>> >>>> >>>>> >>>>> *item 4 : DSD variant declarations don't suck for beginners* >>>>> >>>>> i always thought repeated '&' definitions to denote variants was sort >>>>> of snobbish. it makes sense to peeps who've sat through classes on re= gular >>>>> grammars and ABNF, but i wouldn't mind it too much if someone with a = basic >>>>> understanding of procedural coding could understand what was going on= . so i >>>>> came up with the VARIANT keyword. it looks like this: >>>>> >>>>> VARIANT : { } >>>>> >>>>> so here's an example: >>>>> >>>>> # Enhanced Error resource >>>>> >>>>> =A0 =A0RESOURCE error_enhanced VARIANT error_type : string { >>>>> =A0 =A0 =A0 =A0'number' : { >>>>> =A0 =A0 =A0 =A0 =A0success : false, >>>>> =A0 =A0 =A0 =A0 =A0errno : integer >>>>> =A0 =A0 =A0 }, >>>>> =A0 =A0 =A0 'string' : { >>>>> =A0 =A0 =A0 =A0 =A0success : false, >>>>> =A0 =A0 =A0 =A0 =A0error : string >>>>> =A0 =A0 =A0 }, >>>>> =A0 =A0 =A0 'url' : { >>>>> =A0 =A0 =A0 =A0 =A0success : false, >>>>> =A0 =A0 =A0 =A0 =A0description : uri >>>>> =A0 =A0 =A0 } >>>>> =A0 =A0}; >>>>> >>>>> >>>>> what this means is that the "error_enhanced" resource has three valid >>>>> forms, that look like: >>>>> >>>>> =A0 =A0RESOURCE error_enhanced { >>>>> =A0 =A0 =A0 error_type : 'number', >>>>> =A0 =A0 =A0 success : false, >>>>> =A0 =A0 =A0 errno : integer >>>>> =A0 =A0}; >>>>> >>>>> =A0 =A0RESOURCE error_enhanced { >>>>> =A0 =A0 =A0 error_type : 'string', >>>>> =A0 =A0 =A0 success : false, >>>>> =A0 =A0 =A0 error : string >>>>> =A0 =A0} >>>>> >>>>> =A0 =A0RESOURCE error_enhanced { >>>>> =A0 =A0 =A0 error_type : 'url', >>>>> =A0 =A0 =A0 success : false, >>>>> =A0 =A0 =A0 description : uri >>>>> =A0 =A0} >>>>> >>>>> >>>>> so the shows up as an element in each of the valid for= ms >>>>> as an literal element of type . >>>> >>>> Did I find any significant use for such? I mean is there somewhere in >>>> specific that that variant structure is more helpful than what I used?= I >>>> think as we get into more specific usage and documentation of that usa= ge we >>>> do need simplified ways makes some redundancy obvious. I just used wik= i >>>> markup for that for now, I think. >>>> >>>> >>>>> >>>>> *item 5 : say good by to HTTP verbs.* >>>>> >>>>> LLIDL as specified is pretty much intertwined with HTTP. many people >>>>> thought that was a bad idea. In creating an interface, DSD uses five >>>>> abstract "interaction semantics": CREATE, READ, UPDATE, DELETE and EV= ENT. >>>>> >>>>> the first four do what you expect them to do while the last one >>>>> describes the form or "shape" of an unsolicited message coming from t= he >>>>> event queue. >>>>> >>>>> so if you wanted to login, you might use the following interface >>>>> >>>>> =A0 =A0INTERFACE CREATE session_factory { >>>>> =A0 =A0 =A0 username : string, >>>>> =A0 =A0 =A0 secret : binary >>>>> =A0 =A0} RESPONSE VARIANT success : boolean { >>>>> =A0 =A0 =A0 false : { >>>>> =A0 =A0 =A0 =A0 =A0errno : integer, >>>>> =A0 =A0 =A0 =A0 =A0err : string, >>>>> =A0 =A0 =A0 =A0 =A0description : uri >>>>> =A0 =A0 =A0 }, >>>>> =A0 =A0 =A0 true : { >>>>> =A0 =A0 =A0 =A0 =A0seed : uri >>>>> =A0 =A0 =A0 } >>>>> =A0 =A0}; >>>>> >>>>> >>>>> or, you could do the following: >>>>> >>>>> =A0 =A0RESOURCE error { >>>>> =A0 =A0 =A0 errno : integer, >>>>> =A0 =A0 =A0 err : string, >>>>> =A0 =A0 =A0 description : uri >>>>> =A0 =A0}; >>>>> >>>>> =A0 =A0INTERFACE CREATE session_factory { >>>>> =A0 =A0 =A0 username : string, >>>>> =A0 =A0 =A0 secret : binary >>>>> =A0 =A0} RESPONSE VARIANT success : boolean { >>>>> =A0 =A0 =A0 false : error, >>>>> =A0 =A0 =A0 true : { >>>>> =A0 =A0 =A0 =A0 =A0seed : uri >>>>> =A0 =A0 =A0 } >>>>> =A0 =A0}; >>>>> >>>>> >>>>> so anyway, i'm writing up this stuff in the DSD type system draft. fe= el >>>>> free to comment. as things stand, if VWRAP continues as a working gro= up, >>>>> i'll integrate your comments on the draft. if not, i'll modify the dr= aft so >>>>> as to remain compatibility with existing DSD implementations and publ= ish it >>>>> a an individual / informational draft for the purpose of registering = the >>>>> mime types. >>>> >>>> As long as usage doesn't fall out of ReST than it'll work. Remember th= at >>>> ReST doesn't have to use HTTP. If you see my implementation, there is = the >>>> ReST queue being full of tasks and part of those task relate to HTTP >>>> methods. People don't seem to often split ReST queries as different th= an >>>> HTTP verbs, but I do. I guess that is like resource/interface differen= ces. >>>> >>>> I thought I saw another submitted document to review, yet couldn't fin= d >>>> it. Was there a newer version? >>>> >>>> >>>> >>> >>> >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > From ohmeadhbh@gmail.com Tue Apr 5 13:11:01 2011 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 B9D8D28C136 for ; Tue, 5 Apr 2011 13:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 JWh0EGoWOuYL for ; Tue, 5 Apr 2011 13:10:50 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by core3.amsl.com (Postfix) with ESMTP id 3EC1A28C12B for ; Tue, 5 Apr 2011 13:10:48 -0700 (PDT) Received: by pxi20 with SMTP id 20so497929pxi.27 for ; Tue, 05 Apr 2011 13:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=bfWl4wMU3dgJ4ZalvqlufmSNsIVTan5TkY6aHJ2VEnw=; b=ucZxa3nNfBsDXQQiwy78BW0HBABcUxcWXVbnwE+UPvcWFtgPdh9K0DLIN8Q32TBsfz ibVGDaC3mrooqAbC6mRgmz6ljQgHl5DL7yCtyrtXmApKo2Uzfs30t9wcKRgzfWouuwCA Iu6CXu9WhZAgmAf3ScxcL+vxtnW/XnnXD7NkU= 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=R9AEwikwy3BMyIwER/+yIoNm8bO9nmavArMYFKU8NmzT7d7u4y7/0cUxi7y2Bz1VYv /PTU+fLyNrdBYKad2mnxk3Fsw0aLm+XehHXgvs65KvHKOksSOPccjPScEPsQyNFC4Sez mntB0ywxIOCU6CT+AkNKvgQqgE+6s2zRrCNcM= Received: by 10.142.209.12 with SMTP id h12mr106778wfg.91.1302034351409; Tue, 05 Apr 2011 13:12:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.60.164 with HTTP; Tue, 5 Apr 2011 13:12:10 -0700 (PDT) In-Reply-To: <4D9B770D.4050207@gmail.com> References: <4D9B61D4.3000906@gmail.com> <4D9B6861.4030704@gmail.com> <4D9B6D71.5030400@gmail.com> <4D9B6ECE.9000705@gmail.com> <4D9B770D.4050207@gmail.com> From: Meadhbh Hamrick Date: Tue, 5 Apr 2011 13:12:10 -0700 Message-ID: To: Dzonatas Sol Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] informal description of the DSD interface description language 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, 05 Apr 2011 20:11:01 -0000 also. in terms of nomenclature... LLSD is the abstract type system under consideration here. DSD is an extension to LLSD i put together for my personal projects. ergo... DSD is probably outside the scope of this effort, LLSD is not. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Tue, Apr 5, 2011 at 1:09 PM, Dzonatas Sol wrote: > Further, > > I wanted to give more details about mime-parts used in instead of LLSD ar= ray > for combined formats. To describe mime-parts seems like an overdose: > xml-org-ietf-vwrap-* where * becomes the public resource. Need to uncompr= ess > the overall idea we're stuck at here. Mime-parts seems ideal for keep-ali= ve > and long-poll while LLSD arrays seem ideal otherwise. > > > Dzonatas Sol wrote: >> >> Let me reformat... =A0there were extra chars (processed): >> >> Re: "bust mode" or "combined" >> >> See the syntax I used here: >> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Ass= et >> >> I used the the curly brackets {} with ellipses to show what kind of data >> can be combine as an array in LLSD. Here note that the UUID moves from t= he >> RESOURCE into the array as the individual items are combined, such that >> indivual requests for: >> >> /Asset/Notecard/00000000-0000-0000-0000-000000000001 >> /Asset/Notecard/00000000-0000-0000-0000-000000000002 >> /Asset/Notecard/00000000-0000-0000-0000-000000000003 >> /Asset/Notecard/00000000-0000-0000-0000-000000000004 >> >> become >> >> /Asset/Notecard/s >> { >> 00000000-0000-0000-0000-000000000001, >> 00000000-0000-0000-0000-000000000002, >> 00000000-0000-0000-0000-000000000003, >> 00000000-0000-0000-0000-000000000004 >> } >> >> The combined reply may look like: >> >> /Asset/Notecard/s >> { >> 00000000-0000-0000-0000-000000000001, { asset-data... } >> 00000000-0000-0000-0000-000000000002, { asset-data... } >> 00000000-0000-0000-0000-000000000003, { asset-data... } >> 00000000-0000-0000-0000-000000000004 =A0{ asset-data... } >> } >> >> Handling assets not immediately available are easy, I just stick the >> individual response codes in the array instead of expect it as an httpco= de. >> >> Dzonatas Sol wrote: >>> >>> Dzonatas Sol wrote: >>>> >>>> There are two(/three) significant touches I made: >>>> >>>> First, burst mode. Already as people upgrade to capabilities rather th= an >>>> the older UDP style we can see they complain about bottlenecks due to >>>> individual requests being made. This is more of fault of the implement= ators >>>> not doing full ReST rather than the limits of capabilities. I denote "= burst >>>> mode" to make sure full ReST is being implemented. =A0This is where RE= SOURCES >>>> & INTERFACES keep the very basic object oriented message paradigm. The= n >>>> capabilities then can become used for specific individual queries to >>>> combined multiple resource queries. This alleviates the individual >>>> connections per item into the non-issue bit-bucket. The only new issue= with >>>> "burst mode" is limits on how many items can be combined (length of ov= erall >>>> body and parts). >>>> >>>> Second, public resources. The significance I put on "resources" is tha= t >>>> these are the public names being referred to for any such related mess= age >>>> and/or method. Already implemented are the private version of these >>>> resources. Maybe there needs to be some syntax to note that the resour= ces >>>> appear as something else under specific conditions. The current privat= e URIs >>>> are just a digest of given capabilities present (used by lookup tables= ). >>>> Internally, only the public resources are of need, yet the private URI= may >>>> contain something in regards to the basic object oriented message para= digm. >>>> It's not that complicated once one separates the ReST paradigm from HT= TP >>>> methods and implements the full ReST paradigm internally. When the >>>> implementator relies on HTTP as the queue, then they don't have a true= ReST >>>> paradigm, only something compatible (for quick implementation). >>>> >>>> Third, private resources, as above and already implemented by LL >>>> (stateless). We haven't got into stateful tranfer connections. *sigh* = These >>>> would be ideal for the keep-alive, long-poll, and bust mode options. >>>> >>>> >>>> Dzonatas Sol wrote: >>>>> >>>>> Some notes... in line... >>>>> >>>>> Meadhbh Hamrick wrote: >>>>>> >>>>>> hey peeps, it shouldn't be shocking to anyone i'm not a big fan of >>>>>> lentczner's "little" interface description language, llidl. while it= can be >>>>>> argued it's "condensed" format is easy enough to use, once mastered,= i >>>>>> prefer something mildly more expressive. when i was working on the l= ast >>>>>> version of the LLSD draft, i solicited comments from several impleme= nters >>>>>> inside and outside Linden, and they all said the same thing: "LLIDL = is cool >>>>>> enough, but it looks like line noise if you don't know what you're l= ooking >>>>>> at." >>>>>> >>>>>> i came up with the following interface description language to addre= ss >>>>>> the "looks like line noise" critique. this is the IDL that's going i= n the >>>>>> DSD draft, since that's what we're using at sl8.us a= nd >>>>>> various sensor projects that are using DSD. i'm assuming you've read= and >>>>>> understand the LLIDL section of the most recent type system draft. >>>>>> >>>>>> again, i have no idea if this will be relevant since no one's steppe= d >>>>>> up to be an document author for future revisions of this group's doc= s or an >>>>>> editor to re-draft a new charter. but on the off chance people do th= is and >>>>>> still want to work on the type system, these are the changes recomme= nded by >>>>>> several LLIDL users and implementers. >>>>> >>>>> Be sure to see review these to see how I based off LLIDL: >>>>> >>>>> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375#Queries_.2= 6_Type_System >>>>> >>>>> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/= Asset >>>>> >>>>> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/= Interface >>>>> (and others there) >>>>> >>>>> Note that I used more of what is in regards to ReST than only LLIDL. >>>>> >>>>>> >>>>>> *item 0 : disentangling resources from interfaces.* >>>>>> >>>>>> LLIDL sort of conflated a resource (something to be accessed) with t= he >>>>>> method of accessing it. there was no way to "officially" define a "r= esource" >>>>>> independent of the semantics to access it. DSD says that RESOURCEs a= re just >>>>>> data definitions. INTERFACEs define how they're used. >>>>> >>>>> As I see "resource", it manly is untranslated to any particalar >>>>> implementation. Some still think there is an obvious implementation d= ue to >>>>> common resources being used by HTTP. I think you have some like C#'s >>>>> interface in mind? >>>>> >>>>> >>>>>> >>>>>> *item 1 : say good-bye to the di-graphs.* >>>>>> >>>>>> several people noted that LLIDL, at first glance, looks like line >>>>>> noise. this is because of the use of digraphs to represent messaging >>>>>> semantics. cast your memory back to the LLIDL resource description f= or the >>>>>> seed cap: >>>>>> >>>>>> =A0 =A0%% seed >>>>>> =A0 =A0 =A0-> { capabilities: [ string, ... ] } >>>>>> =A0 =A0 =A0<- { capabilities: { $: uri } } >>>>>> >>>>>> >>>>>> the '%%' digraph means 'start of resource description'. the '->' mea= ns >>>>>> 'this is what i'm going to send you' and the '<-' digraph means 'i e= xpect >>>>>> you to send me this back'. >>>>>> >>>>>> instead of digraphs, the DSD resource description language uses the >>>>>> keyword "RESOURCE" to begin a resource. it also terminates the resou= rce >>>>>> definition with a semi colon. so a resource declaration would look s= omething >>>>>> like this: >>>>>> >>>>>> RESOURCE [resource definition] ; >>>>>> >>>>>> resource DEFINITIONs look more or less like they used to. for exampl= e, >>>>>> here's a RESOURCE definition for a typical error response: >>>>>> >>>>>> =A0 =A0# Resource description for a typical error resource >>>>>> =A0 =A0RESOURCE error_simple { >>>>>> =A0 =A0 =A0 success =A0 =A0 : false, =A0 =A0# clients check the succ= ess element to >>>>>> =A0 =A0see if there was an error >>>>>> =A0 =A0 =A0 errno =A0 =A0 =A0 : integer, =A0# this is a numeric code= representing >>>>>> =A0 =A0the error >>>>>> =A0 =A0 =A0 error =A0 =A0 =A0 : string, =A0 # this is a text descrip= tion of the >>>>>> error >>>>>> =A0 =A0 =A0 description : uri =A0 =A0 =A0 # this is a URL that point= s to a HTML >>>>>> =A0 =A0web page describing the error >>>>>> =A0 =A0}; >>>>>> >>>>> >>>>> Think we discussed this before, which I said wasn't much of the worry >>>>> since the what is pivotal is more significant. That said, however, be= sure >>>>> to keep in mind that anything like digraphs make it easier to use >>>>> non-English only keywords. >>>>> >>>>> We seem to agree in structure. >>>>> >>>>> >>>>> >>>>>> >>>>>> *item 2 : the use of type literals instead of type names* >>>>>> >>>>>> in the example above, we used 'false' instead of 'boolean' as the ty= pe >>>>>> definition for the 'success' element of the error resource. DSD reso= urce >>>>>> definitions can use type literals to imply that the element should e= xist, >>>>>> and should have a specific value. so if you wanted to define a resou= rce that >>>>>> represented the origin of a 3d space, you could use: >>>>>> >>>>>> =A0 =A0# Point in a 3D rectangular space =A0 =A0 RESOURCE cartesian_= point [ >>>>>> =A0 =A0 =A0 real, =A0# x coordinate >>>>>> =A0 =A0 =A0 real, =A0# y coordinate >>>>>> =A0 =A0 =A0 real =A0 # z coordinate >>>>>> =A0 =A0]; >>>>>> >>>>>> =A0 =A0# Origin of a rectangular (cartesian) space >>>>>> =A0 =A0RESOURCE cartesian_origin [ 0.0, 0.0, 0.0 ]; >>>>>> >>>>> >>>>> Good idea, I'm just not quite sure if it is so obvious in practice. >>>>> >>>>> >>>>>> >>>>>> *item 3 : type specifiers use the same names as the elements inside >>>>>> the XML serialization.* >>>>>> >>>>>> instead of using "int", we use "integer." ditto for other types. so >>>>>> the resource definition. here's a resource definition for something = with an >>>>>> integer in it: >>>>>> >>>>>> =A0 =A0# Random resource definition of a map with an integer in it >>>>>> =A0 =A0RESOURCE whatever { >>>>>> =A0 =A0 =A0 element : integer >>>>>> =A0 =A0}; >>>>>> >>>>> >>>>> This is made obvious by the default use of LLSD, still. Notice SNOW-3= 75 >>>>> I did have a few extras for optional fields and proprietary fields. W= e know >>>>> they are there, but probably won't have an public definition of such >>>>> structures. Guess we need that tidbit formalized. >>>>> >>>>> >>>>>> >>>>>> *item 4 : DSD variant declarations don't suck for beginners* >>>>>> >>>>>> i always thought repeated '&' definitions to denote variants was sor= t >>>>>> of snobbish. it makes sense to peeps who've sat through classes on r= egular >>>>>> grammars and ABNF, but i wouldn't mind it too much if someone with a= basic >>>>>> understanding of procedural coding could understand what was going o= n. so i >>>>>> came up with the VARIANT keyword. it looks like this: >>>>>> >>>>>> VARIANT : { } >>>>>> >>>>>> so here's an example: >>>>>> >>>>>> # Enhanced Error resource >>>>>> >>>>>> =A0 =A0RESOURCE error_enhanced VARIANT error_type : string { >>>>>> =A0 =A0 =A0 =A0'number' : { >>>>>> =A0 =A0 =A0 =A0 =A0success : false, >>>>>> =A0 =A0 =A0 =A0 =A0errno : integer >>>>>> =A0 =A0 =A0 }, >>>>>> =A0 =A0 =A0 'string' : { >>>>>> =A0 =A0 =A0 =A0 =A0success : false, >>>>>> =A0 =A0 =A0 =A0 =A0error : string >>>>>> =A0 =A0 =A0 }, >>>>>> =A0 =A0 =A0 'url' : { >>>>>> =A0 =A0 =A0 =A0 =A0success : false, >>>>>> =A0 =A0 =A0 =A0 =A0description : uri >>>>>> =A0 =A0 =A0 } >>>>>> =A0 =A0}; >>>>>> >>>>>> >>>>>> what this means is that the "error_enhanced" resource has three vali= d >>>>>> forms, that look like: >>>>>> >>>>>> =A0 =A0RESOURCE error_enhanced { >>>>>> =A0 =A0 =A0 error_type : 'number', >>>>>> =A0 =A0 =A0 success : false, >>>>>> =A0 =A0 =A0 errno : integer >>>>>> =A0 =A0}; >>>>>> >>>>>> =A0 =A0RESOURCE error_enhanced { >>>>>> =A0 =A0 =A0 error_type : 'string', >>>>>> =A0 =A0 =A0 success : false, >>>>>> =A0 =A0 =A0 error : string >>>>>> =A0 =A0} >>>>>> >>>>>> =A0 =A0RESOURCE error_enhanced { >>>>>> =A0 =A0 =A0 error_type : 'url', >>>>>> =A0 =A0 =A0 success : false, >>>>>> =A0 =A0 =A0 description : uri >>>>>> =A0 =A0} >>>>>> >>>>>> >>>>>> so the shows up as an element in each of the valid >>>>>> forms as an literal element of type . >>>>> >>>>> Did I find any significant use for such? I mean is there somewhere in >>>>> specific that that variant structure is more helpful than what I used= ? I >>>>> think as we get into more specific usage and documentation of that us= age we >>>>> do need simplified ways makes some redundancy obvious. I just used wi= ki >>>>> markup for that for now, I think. >>>>> >>>>> >>>>>> >>>>>> *item 5 : say good by to HTTP verbs.* >>>>>> >>>>>> LLIDL as specified is pretty much intertwined with HTTP. many people >>>>>> thought that was a bad idea. In creating an interface, DSD uses five >>>>>> abstract "interaction semantics": CREATE, READ, UPDATE, DELETE and E= VENT. >>>>>> >>>>>> the first four do what you expect them to do while the last one >>>>>> describes the form or "shape" of an unsolicited message coming from = the >>>>>> event queue. >>>>>> >>>>>> so if you wanted to login, you might use the following interface >>>>>> >>>>>> =A0 =A0INTERFACE CREATE session_factory { >>>>>> =A0 =A0 =A0 username : string, >>>>>> =A0 =A0 =A0 secret : binary >>>>>> =A0 =A0} RESPONSE VARIANT success : boolean { >>>>>> =A0 =A0 =A0 false : { >>>>>> =A0 =A0 =A0 =A0 =A0errno : integer, >>>>>> =A0 =A0 =A0 =A0 =A0err : string, >>>>>> =A0 =A0 =A0 =A0 =A0description : uri >>>>>> =A0 =A0 =A0 }, >>>>>> =A0 =A0 =A0 true : { >>>>>> =A0 =A0 =A0 =A0 =A0seed : uri >>>>>> =A0 =A0 =A0 } >>>>>> =A0 =A0}; >>>>>> >>>>>> >>>>>> or, you could do the following: >>>>>> >>>>>> =A0 =A0RESOURCE error { >>>>>> =A0 =A0 =A0 errno : integer, >>>>>> =A0 =A0 =A0 err : string, >>>>>> =A0 =A0 =A0 description : uri >>>>>> =A0 =A0}; >>>>>> >>>>>> =A0 =A0INTERFACE CREATE session_factory { >>>>>> =A0 =A0 =A0 username : string, >>>>>> =A0 =A0 =A0 secret : binary >>>>>> =A0 =A0} RESPONSE VARIANT success : boolean { >>>>>> =A0 =A0 =A0 false : error, >>>>>> =A0 =A0 =A0 true : { >>>>>> =A0 =A0 =A0 =A0 =A0seed : uri >>>>>> =A0 =A0 =A0 } >>>>>> =A0 =A0}; >>>>>> >>>>>> >>>>>> so anyway, i'm writing up this stuff in the DSD type system draft. >>>>>> feel free to comment. as things stand, if VWRAP continues as a worki= ng >>>>>> group, i'll integrate your comments on the draft. if not, i'll modif= y the >>>>>> draft so as to remain compatibility with existing DSD implementation= s and >>>>>> publish it a an individual / informational draft for the purpose of >>>>>> registering the mime types. >>>>> >>>>> As long as usage doesn't fall out of ReST than it'll work. Remember >>>>> that ReST doesn't have to use HTTP. If you see my implementation, the= re is >>>>> the ReST queue being full of tasks and part of those task relate to H= TTP >>>>> methods. People don't seem to often split ReST queries as different t= han >>>>> HTTP verbs, but I do. I guess that is like resource/interface differe= nces. >>>>> >>>>> I thought I saw another submitted document to review, yet couldn't fi= nd >>>>> it. Was there a newer version? >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > From carlo@alinoe.com Tue Apr 5 14:10:05 2011 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 5C4FC3A67DB for ; Tue, 5 Apr 2011 14:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 Udk-VxnGJ2SU for ; Tue, 5 Apr 2011 14:10:04 -0700 (PDT) Received: from fep12.mx.upcmail.net (fep12.mx.upcmail.net [62.179.121.32]) by core3.amsl.com (Postfix) with ESMTP id 51A463A67D9 for ; Tue, 5 Apr 2011 14:10:04 -0700 (PDT) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep12-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110405211146.WSGY18728.viefep12-int.chello.at@edge04.upcmail.net> for ; Tue, 5 Apr 2011 23:11:46 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upcmail.net with edge id TxBk1g01Q0FlQed04xBlBy; Tue, 05 Apr 2011 23:11:46 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q7DXM-0004PA-FG for vwrap@ietf.org; Tue, 05 Apr 2011 23:11:44 +0200 Date: Tue, 5 Apr 2011 23:11:44 +0200 From: Carlo Wood To: vwrap@ietf.org Message-ID: <20110405231144.4cec7412@hikaru.localdomain> In-Reply-To: References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=tMVj8KYobzzX0EiRnC7vY2isLrCxFvdg4RrHWPZXwJ0= c=1 sm=0 a=SNAFxGGoWQUA:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=pGLkceISAAAA:8 a=BjFOTwK7AAAA:8 a=t5_XcuIdZpuDyaOzd4wA:9 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=bW3kdApBr58A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 05 Apr 2011 21:10:05 -0000 On Tue, 5 Apr 2011 13:03:36 -0400 Izzy Alanis wrote: > I'm not against the "design for tomorrow" platform. I'm pro-"design > for tomorrow", but I believe the proposition, as currently worded, > does not appropriately communicate those intentions. > > I could agree with the following wording (though I still don't believe > it communicates your 'design for tomorrow intentions'): > > * Whenever a change X in the protocol is proposed (which might be > an addition, a change of existing protocol or even deletion: any > change, making the protocol (VWRAP) go from A --> B), then > *# Protocol B SHOULD do everything that A could do. > *# Good use-case justification for B MUST be provided. > *# Implementation requirements of B MUST be listed. That completely changes the whole intent of the proposal: to make progress by reaching consensus on an (abstract) goal. My goal is to have less discussion about whether or not something should be supported by making clear that if there is even a single use case, maybe, that might need it, then why not? Then people wont have to defend anymore why that use case is essential, or morally ok, or not endangering the private agenda of someone. Then it's just clear from the start that "Oh yes, someone might want that, so VWRAP HAS to support that"... There shouldn't be any discussion about something like that. In your bullet points, I don't see that goal back at all anymore. Worse, I oppose to it. If A then B is NOT the same as if B then A. You changed the meaning completely. What you are saying that it is forbidden to even make a proposal for a change unless the result can still do exactly what it could be before that. That means we can't make any real CHANGES anymore. Everything we have done so far is set in stone and apparently holy (correct, without errors). -- Carlo Wood From morgaine.dinova@googlemail.com Tue Apr 5 14:20:10 2011 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 AC7CB3A67D8 for ; Tue, 5 Apr 2011 14:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.792 X-Spam-Level: X-Spam-Status: No, score=-2.792 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2XDOnqQ+ILq for ; Tue, 5 Apr 2011 14:20:08 -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 B6BE43A67C1 for ; Tue, 5 Apr 2011 14:20:08 -0700 (PDT) Received: by pzk30 with SMTP id 30so387294pzk.31 for ; Tue, 05 Apr 2011 14:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=q+awjxTadWjHHIeRpJdEYg3jrY7Ahvlu/IpS2CYwU0w=; b=JUPeyNaDLoJcC5VMXWg+TjFjFGNnP2U8KsWK4wCIZar5tmURKhWc+puF+UlMnSzWuD SmSqKG8r1qcw/Yj9LOh+pXmMV18dfrMqLyR8pXAC3PAncsV2kF46DYiUdmqyfcAmsLYH zySPff855Io1wiHrM+Rex3aD4pjLpvO0JZOB8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=EbJd7KvbFfmDoKuo1RqGwxQZhNAhXwJIFOMqqnRPfcTjDFC3c5MIcMCtMT1QGBccbc AniWNKeSxLlwEySs4+zZCJEZZovBAiD0kWKJ9TKyu+fdfAnVYHlKlHKbXS1BOfwCLZrZ kqUUDvHyFKwQgvFRJKX3UZfqSaCVG5S+N5RIY= MIME-Version: 1.0 Received: by 10.142.196.12 with SMTP id t12mr119443wff.449.1302038512056; Tue, 05 Apr 2011 14:21:52 -0700 (PDT) Received: by 10.142.246.6 with HTTP; Tue, 5 Apr 2011 14:21:51 -0700 (PDT) In-Reply-To: <4D9B73D5.4000809@gmail.com> References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <20110405152025.26ba8f77@hikaru.localdomain> <4D9B4586.9080004@gmail.com> <4D9B73D5.4000809@gmail.com> Date: Tue, 5 Apr 2011 22:21:51 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd2e1ecfeb99b04a03276b3 Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 05 Apr 2011 21:20:10 -0000 --000e0cd2e1ecfeb99b04a03276b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Unfortunately your response was devoid of technical content, Dzonatas. If you have something technical to say about hash-based addressing, I would love to hear it. I have detailed in some depth the many benefits of hash-based addressing in the article I linked, and subsequently. If other good schemes exist, we should of course analyze them for technical merit and compare their benefit= s against those of hash-based addressing. That's the engineering process for making VWRAP as good as it can be. 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 On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol wrote: > Morgaine, we mooted your hash-based idea. This does nothing to help > implement asset services. The only significant point you made is some > expression for optimization, not correct functionality, which is needed > first > > As for your other two, we can summarize those with public resources and > flow (forward/reverse). Any more specific network topology than that only > makes it harder to address. The only thing to worry about is already cust= om > resources that overlap with newer public resources. > > Morgaine wrote: > >> On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol > dzonatas@gmail.com>> wrote: >> >> >> Do you think we are ready to implement some asset services now, >> with/without complete documentation? >> >> What more do you think is needed? >> >> >> Two or three things seem to be needed: >> >> * Defining the asset addressing concept is an extremely important >> matter, almost certainly the most important matter of all, >> because that determines how robust and scalable our worlds will >> be.=EF=BF=BD I've already examined alternatives for that in some de= pth, >> and the design with the best engineering properties so far seems >> to be universal hash-based addressing.=EF=BF=BD I first described t= hat >> approach on the list here --- >> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >> , and referred to it in various subsequent discussions. >> >> * Defining the data flows between regions, clients, and asset >> services and which parameters control the flows needs to be done >> before a test asset service can be implemented.=EF=BF=BD Without th= at, >> an asset service is just a network-accessible storage service, >> not an asset service in the VWRAP sense.=EF=BF=BD Network storage >> services exist already, so just implementing one of those would >> not advance VWRAP. >> >> * We need to examine how various deployment patterns will use the >> asset services, and how the /multiple/ asset services that >> interop introduces are handled.=EF=BF=BD I am working on this curre= ntly. >> >> >> None of the above is particularly hard.=EF=BF=BD I think it won't be lon= g before >> we have a scheme worked out and are ready for some implementation work. >> >> >> Morgaine. >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > --000e0cd2e1ecfeb99b04a03276b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Unfortunately your response was devoid of technical content, Dzonatas.
    <= br>If you have something technical to say about hash-based addressing, I wo= uld love to hear it.

    I have detailed in some depth the many benefits= of hash-based addressing in the article I linked, and subsequently.=C2=A0 = If other good schemes exist, we should of course analyze them for technical= merit and compare their benefits against those of hash-based addressing.
    That's the engineering process for making VWRAP as good as it can b= e.


    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

    On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:=
    Morgaine, we moot= ed your hash-based idea. This does nothing to help implement asset services= . The only significant point you made is some expression for optimization, = not correct functionality, which is needed first

    As for your other two, we can summarize those with public resources and flo= w (forward/reverse). Any more specific network topology than that only make= s it harder to address. The only thing to worry about is already custom res= ources that overlap with newer public resources.

    Morgaine wrote:
    <= div class=3D"h5"> On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol <dzonatas@gmail.com <mailto:dzonatas@gmail.com>>= wrote:


    =C2=A0 =C2=A0Do you think we are ready to implement some asset services no= w,
    =C2=A0 =C2=A0with/without complete documentation?

    =C2=A0 =C2=A0What more do you think is needed?


    Two or three things seem to be needed:

    =C2=A0 =C2=A0* Defining the asset addressing concept is an extremely impor= tant
    =C2=A0 =C2=A0 =C2=A0matter, almost certainly the most important matter of = all,
    =C2=A0 =C2=A0 =C2=A0because that determines how robust and scalable our wo= rlds will
    =C2=A0 =C2=A0 =C2=A0be.=EF=BF=BD I've already examined alternatives fo= r that in some depth,
    =C2=A0 =C2=A0 =C2=A0and the design with the best engineering properties so= far seems
    =C2=A0 =C2=A0 =C2=A0to be universal hash-based addressing.=EF=BF=BD I firs= t described that
    =C2=A0 =C2=A0 =C2=A0approach on the list here ---
    =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/mail-archive/w= eb/vwrap/current/msg00463.html
    =C2=A0 =C2=A0 =C2=A0, and referred to it in various subsequent discussions= .

    =C2=A0 =C2=A0* Defining the data flows between regions, clients, and asset=
    =C2=A0 =C2=A0 =C2=A0services and which parameters control the flows needs = to be done
    =C2=A0 =C2=A0 =C2=A0before a test asset service can be implemented.=EF=BF= =BD Without that,
    =C2=A0 =C2=A0 =C2=A0an asset service is just a network-accessible storage = service,
    =C2=A0 =C2=A0 =C2=A0not an asset service in the VWRAP sense.=EF=BF=BD Netw= ork storage
    =C2=A0 =C2=A0 =C2=A0services exist already, so just implementing one of th= ose would
    =C2=A0 =C2=A0 =C2=A0not advance VWRAP.

    =C2=A0 =C2=A0* We need to examine how various deployment patterns will use= the
    =C2=A0 =C2=A0 =C2=A0asset services, and how the /multiple/ asset services = that
    =C2=A0 =C2=A0 =C2=A0interop introduces are handled.=EF=BF=BD I am working = on this currently.


    None of the above is particularly hard.=EF=BF=BD I think it won't be lo= ng before we have a scheme worked out and are ready for some implementation= work.


    Morgaine.




    ------------------------------------------------------------------------

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


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


    --000e0cd2e1ecfeb99b04a03276b3-- From dzonatas@gmail.com Tue Apr 5 14:31:48 2011 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 31DFA3A67D7 for ; Tue, 5 Apr 2011 14:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 5HBS1iQweZTM for ; Tue, 5 Apr 2011 14:31:46 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id BC7043A67C1 for ; Tue, 5 Apr 2011 14:31:46 -0700 (PDT) Received: by iwn39 with SMTP id 39so991879iwn.31 for ; Tue, 05 Apr 2011 14:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vvdjfkfkk9KWbIYeN00UxFPq/Aw1ZNGdi+mgA8YfuQ8=; b=dXnF+uaPzB0spmKhVl8HD+tTm/NPbDWFYz08cCaP8p0uuS/3GK8Xrm5icszOSsMpvy GV+5LpSI6+ZbtwiX2xOzMz6n/+UPqSFKvWmaOmTrIyLimjGQzturxtU+FMlh/vByiBKB JoQYqKXllq7NMj3BFDolz7dklACjU+MS6g1Bc= 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=dRkCkcR8SvOMJ5TiaSmHXkZxTAquWRyXLtUIt6bPgcMbGJytxv6EO7JNGcvMB5Ll4f 02/mdAWql34H1Q6ui1qddgOP29qCPHHc2IJaFabdRfuRB9cv+IkPJxRZeiwbth3oS//G 0gjK0hHd2LSosThpcGB1BDzVydxiea5vKrd7A= Received: by 10.42.75.133 with SMTP id a5mr240922ick.288.1302039209063; Tue, 05 Apr 2011 14:33:29 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id gx2sm4705472ibb.26.2011.04.05.14.33.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 14:33:28 -0700 (PDT) Message-ID: <4D9B8ADA.9000106@gmail.com> Date: Tue, 05 Apr 2011 14:34:18 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <20110405152025.26ba8f77@hikaru.localdomain> <4D9B4586.9080004@gmail.com> <4D9B73D5.4000809@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 05 Apr 2011 21:31:48 -0000 Again Morgaine, your appeals alone don't support themselves, and your ridicule is unwelcome. If you can not honestly make any serious response, please move on and don't reply to my posts just to further ridicule. It's very RUDE. If you have any implementation of your hash-based idea or actual technical detailed documentation ready for implementation, then introduce it. Until then, it's stuck in your head, and sounds other's ideas just with your name on it. Plus security by obscurity makes it as moot point. Documentation... ? Remember people tried to take one temp variable away from the JPEG2000 int multiple/divide routine because the idea it looks good (on paper) with one less variable. Actual implementation reveals, with timed tests, it is slower when anybody takes away that one temp variable. Morgaine wrote: > Unfortunately your response was devoid of technical content, Dzonatas. > > If you have something technical to say about hash-based addressing, I > would love to hear it. > > I have detailed in some depth the many benefits of hash-based > addressing in the article I linked, and subsequently. If other good > schemes exist, we should of course analyze them for technical merit > and compare their benefits against those of hash-based addressing. > > That's the engineering process for making VWRAP as good as it can be. > > > Morgaine. > > > > > ========================= > > On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol > wrote: > > Morgaine, we mooted your hash-based idea. This does nothing to > help implement asset services. The only significant point you made > is some expression for optimization, not correct functionality, > which is needed first > > As for your other two, we can summarize those with public > resources and flow (forward/reverse). Any more specific network > topology than that only makes it harder to address. The only thing > to worry about is already custom resources that overlap with newer > public resources. > > Morgaine wrote: > > On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol > > >> wrote: > > > Do you think we are ready to implement some asset services now, > with/without complete documentation? > > What more do you think is needed? > > > Two or three things seem to be needed: > > * Defining the asset addressing concept is an extremely > important > matter, almost certainly the most important matter of all, > because that determines how robust and scalable our > worlds will > be.� I've already examined alternatives for that in some > depth, > and the design with the best engineering properties so > far seems > to be universal hash-based addressing.� I first described > that > approach on the list here --- > > http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html > , and referred to it in various subsequent discussions. > > * Defining the data flows between regions, clients, and asset > services and which parameters control the flows needs to > be done > before a test asset service can be implemented.� Without > that, > an asset service is just a network-accessible storage > service, > not an asset service in the VWRAP sense.� Network storage > services exist already, so just implementing one of those > would > not advance VWRAP. > > * We need to examine how various deployment patterns will > use the > asset services, and how the /multiple/ asset services that > interop introduces are handled.� I am working on this > currently. > > > None of the above is particularly hard.� I think it won't be > long before we have a scheme worked out and are ready for some > implementation work. > > > Morgaine. > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Tue Apr 5 14:46:53 2011 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 17A5F28C113 for ; Tue, 5 Apr 2011 14:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msznGRPVtOjh for ; Tue, 5 Apr 2011 14:46:51 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 1F33628C105 for ; Tue, 5 Apr 2011 14:46:51 -0700 (PDT) Received: by qyk7 with SMTP id 7so560295qyk.10 for ; Tue, 05 Apr 2011 14:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=15ln1yBmo15L2mhRtG6xU+g37IX5UxNNJNXPJkm/uOQ=; b=rHIlVARMuC6FxwBVvwTEQJ4kSM3mdjfeLIT7Kz/FhE3MZPmKDwJIGO9+oXunHLPA52 Pn7D3O9XkjUFWbXhLFU6XGPPYS7aeUbXn0RTS9gj+TLMJHL9jBgjrWbUfiLMRGG8sQvM Ef95SioTwl7DfIb/9l/myfkO6d2M7bA2vVr1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=baKkl39v4qyaHTJtfjGFKFSVI4YuRJF+qr0+Ums4Z5X0CqSI/O1yme8Dcw7aKr0cXY 0coA6CMjd6hgoVMsMtwxRTGh70uP2WYHAtfUfOmwG3ikWtM3c1nnhuwcP81XSoKIYH/y a8ebDzBKom2ORTdo7kcgdKf/50d2SQ+ry57Wg= MIME-Version: 1.0 Received: by 10.229.37.130 with SMTP id x2mr181275qcd.147.1302040113130; Tue, 05 Apr 2011 14:48:33 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Tue, 5 Apr 2011 14:48:32 -0700 (PDT) In-Reply-To: <4D9B8ADA.9000106@gmail.com> References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <20110405152025.26ba8f77@hikaru.localdomain> <4D9B4586.9080004@gmail.com> <4D9B73D5.4000809@gmail.com> <4D9B8ADA.9000106@gmail.com> Date: Tue, 5 Apr 2011 22:48:32 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016368340c06d2d9b04a032d6fc Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 05 Apr 2011 21:46:53 -0000 --0016368340c06d2d9b04a032d6fc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How hash-based addressing works and is how the addresses are structured and used in URIs is fully specified in my first article, Dzonatas. The only element of the design not specified is *WHICH* particular hash digest algorithm is employed, since the choice is not particularly significant. The merits of the design are attained regardless of the particular digest chosen. Because we are trying to achieve extensibility for future proofing, a good approach would be to use an URI style that make= s choice of digest algorithm explicit. As for implementations, a test implementation is already running in Mojito Sorbet's experimental world and client, which are open source. I welcome analysis of this addressing scheme, and of alternative addressing schemes. I haven't yet seen one with engineering properties that are anywhere near as good as this, as I detailed in the article. Hash-based addressing sets the merit bar very high. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Tue, Apr 5, 2011 at 10:34 PM, Dzonatas Sol wrote: > Again Morgaine, your appeals alone don't support themselves, and your > ridicule is unwelcome. If you can not honestly make any serious response, > please move on and don't reply to my posts just to further ridicule. It's > very RUDE. > > If you have any implementation of your hash-based idea or actual technica= l > detailed documentation ready for implementation, then introduce it. Until > then, it's stuck in your head, and sounds other's ideas just with your na= me > on it. Plus security by obscurity makes it as moot point. > > Documentation... ? > > Remember people tried to take one temp variable away from the JPEG2000 in= t > multiple/divide routine because the idea it looks good (on paper) with on= e > less variable. Actual implementation reveals, with timed tests, it is slo= wer > when anybody takes away that one temp variable. > > Morgaine wrote: > >> Unfortunately your response was devoid of technical content, Dzonatas. >> >> If you have something technical to say about hash-based addressing, I >> would love to hear it. >> >> I have detailed in some depth the many benefits of hash-based addressing >> in the article I linked, and subsequently. If other good schemes exist,= we >> should of course analyze them for technical merit and compare their bene= fits >> against those of hash-based addressing. >> >> That's the engineering process for making VWRAP as good as it can be. >> >> >> 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 >> >> On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol > dzonatas@gmail.com>> wrote: >> >> Morgaine, we mooted your hash-based idea. This does nothing to >> help implement asset services. The only significant point you made >> is some expression for optimization, not correct functionality, >> which is needed first >> >> As for your other two, we can summarize those with public >> resources and flow (forward/reverse). Any more specific network >> topology than that only makes it harder to address. The only thing >> to worry about is already custom resources that overlap with newer >> public resources. >> >> Morgaine wrote: >> >> On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol >> >> >> wrote: >> >> >> Do you think we are ready to implement some asset services now= , >> with/without complete documentation? >> >> What more do you think is needed? >> >> >> Two or three things seem to be needed: >> >> * Defining the asset addressing concept is an extremely >> important >> matter, almost certainly the most important matter of all, >> because that determines how robust and scalable our >> worlds will >> be.=EF=BF=BD I've already examined alternatives for that in = some >> depth, >> and the design with the best engineering properties so >> far seems >> to be universal hash-based addressing.=EF=BF=BD I first desc= ribed >> that >> approach on the list here --- >> >> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >> , and referred to it in various subsequent discussions. >> >> * Defining the data flows between regions, clients, and asset >> services and which parameters control the flows needs to >> be done >> before a test asset service can be implemented.=EF=BF=BD Wit= hout >> that, >> an asset service is just a network-accessible storage >> service, >> not an asset service in the VWRAP sense.=EF=BF=BD Network st= orage >> services exist already, so just implementing one of those >> would >> not advance VWRAP. >> >> * We need to examine how various deployment patterns will >> use the >> asset services, and how the /multiple/ asset services that >> interop introduces are handled.=EF=BF=BD I am working on thi= s >> currently. >> >> >> None of the above is particularly hard.=EF=BF=BD I think it won't= be >> long before we have a scheme worked out and are ready for some >> implementation work. >> >> >> Morgaine. >> >> >> >> >> >> -----------------------------------------------------------------------= - >> >> >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > --0016368340c06d2d9b04a032d6fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How hash-based addressing works and is how the addresses are structured and= used in URIs is fully specified in my first article, Dzonatas.

    The = only element of the design not specified is WHICH particular hash di= gest algorithm is employed, since the choice is not particularly significan= t.=C2=A0 The merits of the design are attained regardless of the particular= digest chosen.=C2=A0 Because we are trying to achieve extensibility for fu= ture proofing, a good approach would be to use an URI style that makes choi= ce of digest algorithm explicit.

    As for implementations, a test implementation is already running in Moj= ito Sorbet's experimental world and client, which are open source.
    <= br>I welcome analysis of this addressing scheme, and of alternative address= ing schemes.=C2=A0 I haven't yet seen one with engineering properties t= hat are anywhere near as good as this, as I detailed in the article.=C2=A0 = Hash-based addressing sets the merit bar very high.


    Morgaine.





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

    On Tue, Apr 5, 2011= at 10:34 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
    Again Morgaine, y= our appeals alone don't support themselves, and your ridicule is unwelc= ome. If you can not honestly make any serious response, please move on and = don't reply to my posts just to further ridicule. It's very RUDE.
    If you have any implementation of your hash-based idea or actual technical = detailed documentation ready for implementation, then introduce it. Until t= hen, it's stuck in your head, and sounds other's ideas just with yo= ur name on it. Plus security by obscurity makes it as moot point.

    Documentation... ?

    Remember people tried to take one temp variable away from the JPEG2000 int = multiple/divide routine because the idea it looks good (on paper) with one = less variable. Actual implementation reveals, with timed tests, it is slowe= r when anybody takes away that one temp variable.

    Morgaine wrote:
    Unfortunately your response was devoid of technical content, Dzonatas.

    If you have something technical to say about hash-based addressing, I would= love to hear it.

    I have detailed in some depth the many benefits of hash-based addressing in= the article I linked, and subsequently. =C2=A0If other good schemes exist,= we should of course analyze them for technical merit and compare their ben= efits against those of hash-based addressing.

    That's the engineering process for making VWRAP as good as it can be.

    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=

    On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol <dzonatas@gmail.com <mailto:dzonatas@gmail.com>>= wrote:

    =C2=A0 =C2=A0Morgaine, we mooted your hash-based idea. This does nothing t= o
    =C2=A0 =C2=A0help implement asset services. The only significant point you= made
    =C2=A0 =C2=A0is some expression for optimization, not correct functionalit= y,
    =C2=A0 =C2=A0which is needed first

    =C2=A0 =C2=A0As for your other two, we can summarize those with public
    =C2=A0 =C2=A0resources and flow (forward/reverse). Any more specific netwo= rk
    =C2=A0 =C2=A0topology than that only makes it harder to address. The only = thing
    =C2=A0 =C2=A0to worry about is already custom resources that overlap with = newer
    =C2=A0 =C2=A0public resources.

    =C2=A0 =C2=A0Morgaine wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol =C2=A0 =C2=A0 =C2=A0 =C2=A0<dzonatas@gmail.com <mailto:dzonatas@gmail.com>
    <= /div>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>> wrote= :


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Do you think we are ready to implement = some asset services now,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with/without complete documentation?
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 What more do you think is needed?


    =C2=A0 =C2=A0 =C2=A0 =C2=A0Two or three things seem to be needed:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * Defining the asset addressing concept= is an extremely
    =C2=A0 =C2=A0 =C2=A0 =C2=A0important
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 matter, almost certainly the mos= t important matter of all,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 because that determines how robu= st and scalable our
    =C2=A0 =C2=A0 =C2=A0 =C2=A0worlds will
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be.=EF=BF=BD I've already ex= amined alternatives for that in some
    =C2=A0 =C2=A0 =C2=A0 =C2=A0depth,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and the design with the best eng= ineering properties so
    =C2=A0 =C2=A0 =C2=A0 =C2=A0far seems
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to be universal hash-based addre= ssing.=EF=BF=BD I first described
    =C2=A0 =C2=A0 =C2=A0 =C2=A0that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 approach on the list here --- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.= html
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 , and referred to it in various = subsequent discussions.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * Defining the data flows between regio= ns, clients, and asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 services and which parameters co= ntrol the flows needs to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0be done
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 before a test asset service can = be implemented.=EF=BF=BD Without
    =C2=A0 =C2=A0 =C2=A0 =C2=A0that,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 an asset service is just a netwo= rk-accessible storage
    =C2=A0 =C2=A0 =C2=A0 =C2=A0service,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not an asset service in the VWRA= P sense.=EF=BF=BD Network storage
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 services exist already, so just = implementing one of those
    =C2=A0 =C2=A0 =C2=A0 =C2=A0would
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not advance VWRAP.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * We need to examine how various deploy= ment patterns will
    =C2=A0 =C2=A0 =C2=A0 =C2=A0use the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 asset services, and how the /mul= tiple/ asset services that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interop introduces are handled.= =EF=BF=BD I am working on this
    =C2=A0 =C2=A0 =C2=A0 =C2=A0currently.


    =C2=A0 =C2=A0 =C2=A0 =C2=A0None of the above is particularly hard.=EF=BF= =BD I think it won't be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0long before we have a scheme worked out and are= ready for some
    =C2=A0 =C2=A0 =C2=A0 =C2=A0implementation work.


    =C2=A0 =C2=A0 =C2=A0 =C2=A0Morgaine.




    =C2=A0 =C2=A0 =C2=A0 =C2=A0-----------------------------------------------= -------------------------



    =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________________________________=
    =C2=A0 =C2=A0 =C2=A0 =C2=A0vwrap mailing list
    =C2=A0 =C2=A0 =C2=A0 =C2=A0vwrap@ietf.org <mailto:vwrap@ietf.org>

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


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


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


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


    --0016368340c06d2d9b04a032d6fc-- From dzonatas@gmail.com Tue Apr 5 14:47:01 2011 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 ADD9D28C147 for ; Tue, 5 Apr 2011 14:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 YdI3Cfl9Tr6k for ; Tue, 5 Apr 2011 14:47:00 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 6846D28C12B for ; Tue, 5 Apr 2011 14:46:59 -0700 (PDT) Received: by iye19 with SMTP id 19so999240iye.31 for ; Tue, 05 Apr 2011 14:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zmYSiRDTqZN962uLoZ3P0n8P2pGL2Xm6zQn4Imd/MyY=; b=ALdtexRZjYCp3PccDI2ZSipnFo08Hmp5WmYJJTLCp6Fz00asUdnbZiokQRyGpS6/3z MXl3IR/yx80TV57sCYG+C1w5jELBOr1ikomxeMqvBD7wB5T2RZmGoK7pWqDkO2ht+Jgq 5HuACgsVn55AXqCn1jwOcZ0eQMhmSUmNl0Tcg= 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=LdivRQej4PhXsnm3oBd8PMq30o6Hug7AS6z+RZV/LzTvbi8Qo9E5sNT2rdD5IKS9Rn /BpBBEeLkiYEHA+J+Pl9+f0hioHd1tYlkhxHp8ok8jiVp2mzBzkAf11skIpmj3k8ub4t 6Ts7E4HF8biffMaAgW7n+0iHJjjCEoXHjYRlQ= Received: by 10.43.62.195 with SMTP id xb3mr246369icb.458.1302040122751; Tue, 05 Apr 2011 14:48:42 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id i3sm4713870iby.40.2011.04.05.14.48.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 14:48:41 -0700 (PDT) Message-ID: <4D9B8E6B.6010409@gmail.com> Date: Tue, 05 Apr 2011 14:49:31 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: vwrap@ietf.org References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <20110405231144.4cec7412@hikaru.localdomain> In-Reply-To: <20110405231144.4cec7412@hikaru.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 05 Apr 2011 21:47:01 -0000 IETF seems to already have this nailed down on the political side. The working groups help. Any proposal needs documentation, so that is where any consensus happens aside from implementation (actual or attempted). We can assume succession of RFCs. Carlo Wood wrote: > On Tue, 5 Apr 2011 13:03:36 -0400 > Izzy Alanis wrote: > >> I'm not against the "design for tomorrow" platform. I'm pro-"design >> for tomorrow", but I believe the proposition, as currently worded, >> does not appropriately communicate those intentions. >> >> I could agree with the following wording (though I still don't believe >> it communicates your 'design for tomorrow intentions'): >> >> * Whenever a change X in the protocol is proposed (which might be >> an addition, a change of existing protocol or even deletion: any >> change, making the protocol (VWRAP) go from A --> B), then >> *# Protocol B SHOULD do everything that A could do. >> *# Good use-case justification for B MUST be provided. >> *# Implementation requirements of B MUST be listed. >> > > That completely changes the whole intent of the proposal: > to make progress by reaching consensus on an (abstract) goal. > > My goal is to have less discussion about whether or not something > should be supported by making clear that if there is even a single > use case, maybe, that might need it, then why not? Then people wont > have to defend anymore why that use case is essential, or morally ok, > or not endangering the private agenda of someone. Then it's just > clear from the start that "Oh yes, someone might want that, so VWRAP > HAS to support that"... There shouldn't be any discussion about > something like that. > > In your bullet points, I don't see that goal back at all anymore. > > Worse, I oppose to it. If A then B is NOT the same as if B then A. > You changed the meaning completely. What you are saying that it > is forbidden to even make a proposal for a change unless the result can > still do exactly what it could be before that. That means we can't make > any real CHANGES anymore. Everything we have done so far is set in > stone and apparently holy (correct, without errors). > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Tue Apr 5 15:08:37 2011 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 976EF3A67EB for ; Tue, 5 Apr 2011 15:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 sXRlfaFcncj7 for ; Tue, 5 Apr 2011 15:08:36 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 0AB463A67D2 for ; Tue, 5 Apr 2011 15:08:35 -0700 (PDT) Received: by iwn39 with SMTP id 39so1024506iwn.31 for ; Tue, 05 Apr 2011 15:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DOA1zjIJgTBQNRI2pZfKTLkDq19d2GdKIDdcDGmjXU4=; b=HgDHq33lkjCwgwJMCpn2rTjOkC4LOKvmwlWYE4oIwY2x0SReP3arArvO9nfIMMqP4i Cnd04JugXL7Vn3KSMxGUsvVy8sy59go7Ub5QgUJ+f09SAyTXZDoHf55qvbFtFRr3byM+ BrgwrieoJpDzrimXF/WnQwv7As1DX27Fdl65k= 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=v6HGQ8C+Kq4ru2L4Y3Wd8FG4haFzDXK2pbWFcLhATF/Ek/4rqW8lT9ahs1gZe1ApRy Gv2sDO62toDuwdnZkVAqjjErYGUpLIvvrrVWhYi3Pw0NBc4UCHtqhMhTAXuDOw2gM6p0 JNPp4oC8hWnSwaOnWhVZVoHN1RMFaOytx1TUs= Received: by 10.231.141.20 with SMTP id k20mr195984ibu.132.1302041419275; Tue, 05 Apr 2011 15:10:19 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id mv26sm4729761ibb.62.2011.04.05.15.10.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 15:10:18 -0700 (PDT) Message-ID: <4D9B937C.1040403@gmail.com> Date: Tue, 05 Apr 2011 15:11:08 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <20110405152025.26ba8f77@hikaru.localdomain> <4D9B4586.9080004@gmail.com> <4D9B73D5.4000809@gmail.com> <4D9B8ADA.9000106@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 05 Apr 2011 22:08:37 -0000 I don't see any description of LLIDL or anything trivially like it being described or based on documents now provided on the ietf vwrap wiki. Therefore, documentation incomplete. Moot point. Local cache is still internal design, so what happen internally for cache optimizations does not mean all other aspect of the network are "the best design" by default. Again, correct functionality first. Local cache is not part of vwrap. Digest URIs seem similar to the combined resources I already implemented and used even a year before you wrote that. Despite that, it seems like the age old IHAVE/SENDME protocols you can find RFCs dated before the late 80s. IHAVE/SENDME just didn't have to deal with public resource (combinable), as I have implemented: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375 Your approach, besides exploitations, has the typical problem to assume asset IDs are only needed and are hash-able. I don't think you comprehend the moot point here, and thus probably have an agenda. (whatever it is... the ridicule and mockery make it apparent) I think what you really want is the same thing I described with asset-"manafacturing", universal identifiers in URIs. Simple, it looks like "UUID:UUID", like any basic public key. Documentation...? Morgaine wrote: > How hash-based addressing works and is how the addresses are > structured and used in URIs is fully specified in my first article, > Dzonatas. > > The only element of the design not specified is *WHICH* particular > hash digest algorithm is employed, since the choice is not > particularly significant. The merits of the design are attained > regardless of the particular digest chosen. Because we are trying to > achieve extensibility for future proofing, a good approach would be to > use an URI style that makes choice of digest algorithm explicit. > > As for implementations, a test implementation is already running in > Mojito Sorbet's experimental world and client, which are open source. > > I welcome analysis of this addressing scheme, and of alternative > addressing schemes. I haven't yet seen one with engineering > properties that are anywhere near as good as this, as I detailed in > the article. Hash-based addressing sets the merit bar very high. > > > Morgaine. > > > > > > ================== > > On Tue, Apr 5, 2011 at 10:34 PM, Dzonatas Sol > wrote: > > Again Morgaine, your appeals alone don't support themselves, and > your ridicule is unwelcome. If you can not honestly make any > serious response, please move on and don't reply to my posts just > to further ridicule. It's very RUDE. > > If you have any implementation of your hash-based idea or actual > technical detailed documentation ready for implementation, then > introduce it. Until then, it's stuck in your head, and sounds > other's ideas just with your name on it. Plus security by > obscurity makes it as moot point. > > Documentation... ? > > Remember people tried to take one temp variable away from the > JPEG2000 int multiple/divide routine because the idea it looks > good (on paper) with one less variable. Actual implementation > reveals, with timed tests, it is slower when anybody takes away > that one temp variable. > > Morgaine wrote: > > Unfortunately your response was devoid of technical content, > Dzonatas. > > If you have something technical to say about hash-based > addressing, I would love to hear it. > > I have detailed in some depth the many benefits of hash-based > addressing in the article I linked, and subsequently. If > other good schemes exist, we should of course analyze them for > technical merit and compare their benefits against those of > hash-based addressing. > > That's the engineering process for making VWRAP as good as it > can be. > > > Morgaine. > > > > > ========================= > > On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol > > >> wrote: > > Morgaine, we mooted your hash-based idea. This does nothing to > help implement asset services. The only significant point > you made > is some expression for optimization, not correct functionality, > which is needed first > > As for your other two, we can summarize those with public > resources and flow (forward/reverse). Any more specific network > topology than that only makes it harder to address. The > only thing > to worry about is already custom resources that overlap > with newer > public resources. > > Morgaine wrote: > > On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol > > > > > >>> wrote: > > > Do you think we are ready to implement some asset > services now, > with/without complete documentation? > > What more do you think is needed? > > > Two or three things seem to be needed: > > * Defining the asset addressing concept is an extremely > important > matter, almost certainly the most important matter > of all, > because that determines how robust and scalable our > worlds will > be.� I've already examined alternatives for that > in some > depth, > and the design with the best engineering properties so > far seems > to be universal hash-based addressing.� I first > described > that > approach on the list here --- > > http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html > , and referred to it in various subsequent > discussions. > > * Defining the data flows between regions, clients, > and asset > services and which parameters control the flows > needs to > be done > before a test asset service can be implemented.� > Without > that, > an asset service is just a network-accessible storage > service, > not an asset service in the VWRAP sense.� Network > storage > services exist already, so just implementing one > of those > would > not advance VWRAP. > > * We need to examine how various deployment patterns > will > use the > asset services, and how the /multiple/ asset > services that > interop introduces are handled.� I am working on this > currently. > > > None of the above is particularly hard.� I think it > won't be > long before we have a scheme worked out and are ready > for some > implementation work. > > > Morgaine. > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > > https://www.ietf.org/mailman/listinfo/vwrap > > > > -- --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, > Consultant > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Tue Apr 5 15:22:35 2011 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 46DD028C0EE for ; Tue, 5 Apr 2011 15:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZoDBCa8CezS for ; Tue, 5 Apr 2011 15:22:33 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 9ACBF3A67F3 for ; Tue, 5 Apr 2011 15:22:30 -0700 (PDT) Received: by qyk29 with SMTP id 29so1972105qyk.10 for ; Tue, 05 Apr 2011 15:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=bAhwzqNmdlvNYTSau3R5EE+/8Zn8AgTAfPn73cn9PUQ=; b=e8sbfgSSVNtA+BVRHTarEHzeXxbo7ffAyymb8u8/FxkoNIystFdbec/nH+4brMRvi/ IDkSEPk9qkXKC0VPOSFTUifZ1oeHtKH6hvizajU8iCJ8sqN2teGHXGv8D5l2h8cy0G0b jjFg6/M8kCxcXEFv9zz6cLkD6XDo3Z2Hwy5AE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=TDM+ysH/n853Vt+dXfJXLor1bMj4B8C8XFfGnpvSWHJP0f3dvKUPyxBOU/OsNmJjHi tsBcBzXIgyBJdeqjzzRnyR8QBvQk37Uv4SbYLz7u4cs3VfuEQ09QCSeZDUlEOVxG/1jP LDtQTjd+6111wmTlVH7YPwXvQUGetSKtx0Gi4= MIME-Version: 1.0 Received: by 10.229.78.22 with SMTP id i22mr225355qck.33.1302042253669; Tue, 05 Apr 2011 15:24:13 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Tue, 5 Apr 2011 15:24:13 -0700 (PDT) In-Reply-To: <4D9B937C.1040403@gmail.com> References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <20110405152025.26ba8f77@hikaru.localdomain> <4D9B4586.9080004@gmail.com> <4D9B73D5.4000809@gmail.com> <4D9B8ADA.9000106@gmail.com> <4D9B937C.1040403@gmail.com> Date: Tue, 5 Apr 2011 23:24:13 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00235429d8f40338f404a03356b2 Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 05 Apr 2011 22:22:35 -0000 --00235429d8f40338f404a03356b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 5, 2011 at 11:11 PM, Dzonatas Sol wrote: > > Your approach, besides exploitations, has the typical problem to assume > asset IDs are only needed and are hash-able. > Asset IDs are not hash-able, it is the asset data that is hashed. The asse= t identifier is the hash of the asset data using a defined hash digest algorithm. The asset identifier is not guessable unless you already have access to the asset. 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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> On Tue, Apr 5, 2011 at 10:34 PM, Dzonatas Sol > dzonatas@gmail.com>> wrote: >> >> Again Morgaine, your appeals alone don't support themselves, and >> your ridicule is unwelcome. If you can not honestly make any >> serious response, please move on and don't reply to my posts just >> to further ridicule. It's very RUDE. >> >> If you have any implementation of your hash-based idea or actual >> technical detailed documentation ready for implementation, then >> introduce it. Until then, it's stuck in your head, and sounds >> other's ideas just with your name on it. Plus security by >> obscurity makes it as moot point. >> >> Documentation... ? >> >> Remember people tried to take one temp variable away from the >> JPEG2000 int multiple/divide routine because the idea it looks >> good (on paper) with one less variable. Actual implementation >> reveals, with timed tests, it is slower when anybody takes away >> that one temp variable. >> >> Morgaine wrote: >> >> Unfortunately your response was devoid of technical content, >> Dzonatas. >> >> If you have something technical to say about hash-based >> addressing, I would love to hear it. >> >> I have detailed in some depth the many benefits of hash-based >> addressing in the article I linked, and subsequently. If >> other good schemes exist, we should of course analyze them for >> technical merit and compare their benefits against those of >> hash-based addressing. >> >> That's the engineering process for making VWRAP as good as it >> can be. >> >> >> 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 >> >> On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol >> >> >> wrote: >> >> Morgaine, we mooted your hash-based idea. This does nothing to >> help implement asset services. The only significant point >> you made >> is some expression for optimization, not correct functionality= , >> which is needed first >> >> As for your other two, we can summarize those with public >> resources and flow (forward/reverse). Any more specific networ= k >> topology than that only makes it harder to address. The >> only thing >> to worry about is already custom resources that overlap >> with newer >> public resources. >> >> Morgaine wrote: >> >> On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol >> >> > >> >> >>> wrote: >> >> >> Do you think we are ready to implement some asset >> services now, >> with/without complete documentation? >> >> What more do you think is needed? >> >> >> Two or three things seem to be needed: >> >> * Defining the asset addressing concept is an extremely >> important >> matter, almost certainly the most important matter >> of all, >> because that determines how robust and scalable our >> worlds will >> be.=EF=BF=BD I've already examined alternatives for t= hat >> in some >> depth, >> and the design with the best engineering properties s= o >> far seems >> to be universal hash-based addressing.=EF=BF=BD I fir= st >> described >> that >> approach on the list here --- >> >> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >> , and referred to it in various subsequent >> discussions. >> >> * Defining the data flows between regions, clients, >> and asset >> services and which parameters control the flows >> needs to >> be done >> before a test asset service can be implemented.=EF=BF= =BD >> Without >> that, >> an asset service is just a network-accessible storage >> service, >> not an asset service in the VWRAP sense.=EF=BF=BD Net= work >> storage >> services exist already, so just implementing one >> of those >> would >> not advance VWRAP. >> >> * We need to examine how various deployment patterns >> will >> use the >> asset services, and how the /multiple/ asset >> services that >> interop introduces are handled.=EF=BF=BD I am working= on this >> currently. >> >> >> None of the above is particularly hard.=EF=BF=BD I think i= t >> won't be >> long before we have a scheme worked out and are ready >> for some >> implementation work. >> >> >> Morgaine. >> >> >> >> >> >> -----------------------------------------------------------------------= - >> >> >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> > >> >> >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, >> Consultant >> >> >> >> -----------------------------------------------------------------------= - >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > --00235429d8f40338f404a03356b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 5, 2011 at 11:11 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
    =

    Your approach, besides exploitations, has the typical problem to assume ass= et IDs are only needed and are hash-able.


    Asse= t IDs are not hash-able, it is the asset data that is hashed.=C2=A0 The ass= et identifier is the hash of the asset data using a defined hash digest alg= orithm.=C2=A0 The asset identifier is not guessable unless you already have= access to the asset.


    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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    On Tue, Apr 5, 2011 at 10:34 PM, Dzonatas Sol <dzonatas@gmail.com <mailto:dzonatas@gmail.com>>= ; wrote:

    =C2=A0 =C2=A0Again Morgaine, your appeals alone don't support themselv= es, and
    =C2=A0 =C2=A0your ridicule is unwelcome. If you can not honestly make any<= br> =C2=A0 =C2=A0serious response, please move on and don't reply to my po= sts just
    =C2=A0 =C2=A0to further ridicule. It's very RUDE.

    =C2=A0 =C2=A0If you have any implementation of your hash-based idea or act= ual
    =C2=A0 =C2=A0technical detailed documentation ready for implementation, th= en
    =C2=A0 =C2=A0introduce it. Until then, it's stuck in your head, and so= unds
    =C2=A0 =C2=A0other's ideas just with your name on it. Plus security by=
    =C2=A0 =C2=A0obscurity makes it as moot point.

    =C2=A0 =C2=A0Documentation... ?

    =C2=A0 =C2=A0Remember people tried to take one temp variable away from the=
    =C2=A0 =C2=A0JPEG2000 int multiple/divide routine because the idea it look= s
    =C2=A0 =C2=A0good (on paper) with one less variable. Actual implementation=
    =C2=A0 =C2=A0reveals, with timed tests, it is slower when anybody takes aw= ay
    =C2=A0 =C2=A0that one temp variable.

    =C2=A0 =C2=A0Morgaine wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0Unfortunately your response was devoid of techn= ical content,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0Dzonatas.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0If you have something technical to say about ha= sh-based
    =C2=A0 =C2=A0 =C2=A0 =C2=A0addressing, I would love to hear it.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0I have detailed in some depth the many benefits= of hash-based
    =C2=A0 =C2=A0 =C2=A0 =C2=A0addressing in the article I linked, and subsequ= ently. =C2=A0If
    =C2=A0 =C2=A0 =C2=A0 =C2=A0other good schemes exist, we should of course a= nalyze them for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0technical merit and compare their benefits agai= nst those of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0hash-based addressing.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0That's the engineering process for making V= WRAP as good as it
    =C2=A0 =C2=A0 =C2=A0 =C2=A0can be.


    =C2=A0 =C2=A0 =C2=A0 =C2=A0Morgaine.




    =C2=A0 =C2=A0 =C2=A0 =C2=A0=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

    =C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol =C2=A0 =C2=A0 =C2=A0 =C2=A0<dzonatas@gmail.com <mailto:dzonatas@gmail.com>
    =
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>> wrote= :

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Morgaine, we mooted your hash-based ide= a. This does nothing to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 help implement asset services. The only= significant point
    =C2=A0 =C2=A0 =C2=A0 =C2=A0you made
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is some expression for optimization, no= t correct functionality,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 which is needed first

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 As for your other two, we can summarize= those with public
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 resources and flow (forward/reverse). A= ny more specific network
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 topology than that only makes it harder= to address. The
    =C2=A0 =C2=A0 =C2=A0 =C2=A0only thing
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to worry about is already custom resour= ces that overlap
    =C2=A0 =C2=A0 =C2=A0 =C2=A0with newer
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 public resources.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Morgaine wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Tue, Apr 5, 2011 at 5:= 38 PM, Dzonatas Sol
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <dzonatas@gmail.com <mailto:dzonatas@gmail.com>= ;
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com <mailto= :dzonatas@gmail.com= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>> w= rote:


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Do you think= we are ready to implement some asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0services now,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with/without= complete documentation?

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0What more do= you think is needed?


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Two or three things seem = to be needed:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Defining t= he asset addressing concept is an extremely
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 important
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0matte= r, almost certainly the most important matter
    =C2=A0 =C2=A0 =C2=A0 =C2=A0of all,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0becau= se that determines how robust and scalable our
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 worlds will
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be.= =EF=BF=BD I've already examined alternatives for that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0in some
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 depth,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and t= he design with the best engineering properties so
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 far seems
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to be= universal hash-based addressing.=EF=BF=BD I first
    =C2=A0 =C2=A0 =C2=A0 =C2=A0described
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0appro= ach on the list here ---
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www= .ietf.org/mail-archive/web/vwrap/current/msg00463.html
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0, and= referred to it in various subsequent
    =C2=A0 =C2=A0 =C2=A0 =C2=A0discussions.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Defining t= he data flows between regions, clients,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0and asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0servi= ces and which parameters control the flows
    =C2=A0 =C2=A0 =C2=A0 =C2=A0needs to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be done
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0befor= e a test asset service can be implemented.=EF=BF=BD
    =C2=A0 =C2=A0 =C2=A0 =C2=A0Without
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0an as= set service is just a network-accessible storage
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 service,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not a= n asset service in the VWRAP sense.=EF=BF=BD Network
    =C2=A0 =C2=A0 =C2=A0 =C2=A0storage
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0servi= ces exist already, so just implementing one
    =C2=A0 =C2=A0 =C2=A0 =C2=A0of those
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 would
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not a= dvance VWRAP.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* We need to= examine how various deployment patterns
    =C2=A0 =C2=A0 =C2=A0 =C2=A0will
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 use the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0asset= services, and how the /multiple/ asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0services that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inter= op introduces are handled.=EF=BF=BD I am working on this
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 currently.


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 None of the above is part= icularly hard.=EF=BF=BD I think it
    =C2=A0 =C2=A0 =C2=A0 =C2=A0won't be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 long before we have a sch= eme worked out and are ready
    =C2=A0 =C2=A0 =C2=A0 =C2=A0for some
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implementation work.


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Morgaine.




    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0------------------------------------------------------------------------=



    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _________________________= ______________________
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vwrap mailing list
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vwrap@ietf.org <mailto:vwrap@ietf.org>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>>


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailm= an/listinfo/vwrap
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- =C2=A0 =C2=A0 --- https://twitter.com/Dzonatas_S= ol ---
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Web Development, Software Engineering, = Virtual Reality,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0Consultant


    =C2=A0 =C2=A0 =C2=A0 =C2=A0-----------------------------------------------= -------------------------

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


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


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


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


    --00235429d8f40338f404a03356b2-- From dzonatas@gmail.com Tue Apr 5 15:50:28 2011 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 C300A28C163 for ; Tue, 5 Apr 2011 15:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 JDp+wUZeozxu for ; Tue, 5 Apr 2011 15:50:27 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 0803928C162 for ; Tue, 5 Apr 2011 15:50:26 -0700 (PDT) Received: by iwn39 with SMTP id 39so1059835iwn.31 for ; Tue, 05 Apr 2011 15:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cGaJpCUbnbaJT6AMaFno7aEGNNlcDmT/RBDFIntq9qM=; b=xiHTP7wrLqzMmtdoF52KqHYqdifU+B3/OyN1pEu1Vp1MC7xJ+iNVm3lCFf8oU3jmRR 3IT9XJsulE/QEQemy/WuXVjTjjM9y8I/AVAm9jE5iphLalcchs8tcKKhowukqURmwfsd +WevT9Jk1OWQmUEMv8h3B0nj93dAPlLnMCz6A= 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=YpbiKCn33E2x5Tp4QGuwqql6dqVoBDWMT83KaTaK4q7jqgnL0Ma+ei0LPo5WEhWAjB OevPi9T+0Axp8kJb3QRddowagI/bOUCkPQIBmTcNjItH+EP/6br9IM00zg2S5C2PDl/w TuDUE3CXZUvEmbMEj1PRuRRqwdOoEtpua0vg8= Received: by 10.43.69.202 with SMTP id yd10mr371492icb.375.1302043930340; Tue, 05 Apr 2011 15:52:10 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id wu1sm4439016icb.22.2011.04.05.15.52.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 15:52:09 -0700 (PDT) Message-ID: <4D9B9D4A.7050006@gmail.com> Date: Tue, 05 Apr 2011 15:52:58 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <20110405152025.26ba8f77@hikaru.localdomain> <4D9B4586.9080004@gmail.com> <4D9B73D5.4000809@gmail.com> <4D9B8ADA.9000106@gmail.com> <4D9B937C.1040403@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 05 Apr 2011 22:50:28 -0000 And... still local cache.. not vwrap. I think it would be more wise to go with the implementations of Google's and/or Siemens object identification to RFID codes. At least we know this part won't exploit content. It has further advantages than just that. I went into detail awhile ago, yet with basic QM: http://icyspherical.blogspot.com/2010/07/optimizing-simulations-with-basic.html No, even given the possibilities presented, I don't think your idea comes close to anything new in regards to the best. It's just your preference. Morgaine wrote: > On Tue, Apr 5, 2011 at 11:11 PM, Dzonatas Sol > wrote: > > > Your approach, besides exploitations, has the typical problem to > assume asset IDs are only needed and are hash-able. > > > > Asset IDs are not hash-able, it is the asset data that is hashed. The > asset identifier is the hash of the asset data using a defined hash > digest algorithm. The asset identifier is not guessable unless you > already have access to the asset. > > > Morgaine. > > > > > ============================= > > > > ================== > > On Tue, Apr 5, 2011 at 10:34 PM, Dzonatas Sol > > >> wrote: > > Again Morgaine, your appeals alone don't support > themselves, and > your ridicule is unwelcome. If you can not honestly make any > serious response, please move on and don't reply to my > posts just > to further ridicule. It's very RUDE. > > If you have any implementation of your hash-based idea or > actual > technical detailed documentation ready for implementation, then > introduce it. Until then, it's stuck in your head, and sounds > other's ideas just with your name on it. Plus security by > obscurity makes it as moot point. > > Documentation... ? > > Remember people tried to take one temp variable away from the > JPEG2000 int multiple/divide routine because the idea it looks > good (on paper) with one less variable. Actual implementation > reveals, with timed tests, it is slower when anybody takes away > that one temp variable. > > Morgaine wrote: > > Unfortunately your response was devoid of technical > content, > Dzonatas. > > If you have something technical to say about hash-based > addressing, I would love to hear it. > > I have detailed in some depth the many benefits of > hash-based > addressing in the article I linked, and subsequently. If > other good schemes exist, we should of course analyze > them for > technical merit and compare their benefits against those of > hash-based addressing. > > That's the engineering process for making VWRAP as good > as it > can be. > > > Morgaine. > > > > > ========================= > > On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol > > > > > >>> wrote: > > Morgaine, we mooted your hash-based idea. This does > nothing to > help implement asset services. The only significant > point > you made > is some expression for optimization, not correct > functionality, > which is needed first > > As for your other two, we can summarize those with > public > resources and flow (forward/reverse). Any more > specific network > topology than that only makes it harder to address. The > only thing > to worry about is already custom resources that overlap > with newer > public resources. > > Morgaine wrote: > > On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol > > > > > >> > > > > >>>> wrote: > > > Do you think we are ready to implement some asset > services now, > with/without complete documentation? > > What more do you think is needed? > > > Two or three things seem to be needed: > > * Defining the asset addressing concept is an > extremely > important > matter, almost certainly the most important > matter > of all, > because that determines how robust and > scalable our > worlds will > be.� I've already examined alternatives for > that > in some > depth, > and the design with the best engineering > properties so > far seems > to be universal hash-based addressing.� I first > described > that > approach on the list here --- > > http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html > , and referred to it in various subsequent > discussions. > > * Defining the data flows between regions, > clients, > and asset > services and which parameters control the flows > needs to > be done > before a test asset service can be > implemented.� > Without > that, > an asset service is just a > network-accessible storage > service, > not an asset service in the VWRAP sense.� > Network > storage > services exist already, so just > implementing one > of those > would > not advance VWRAP. > > * We need to examine how various deployment > patterns > will > use the > asset services, and how the /multiple/ asset > services that > interop introduces are handled.� I am > working on this > currently. > > > None of the above is particularly hard.� I think it > won't be > long before we have a scheme worked out and are > ready > for some > implementation work. > > > Morgaine. > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > > >> > > > https://www.ietf.org/mailman/listinfo/vwrap > > > -- --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, > Consultant > > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > https://www.ietf.org/mailman/listinfo/vwrap > > > > -- --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, > Consultant > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Tue Apr 5 16:30:13 2011 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 878A23A69AA for ; Tue, 5 Apr 2011 16:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpyB2rSWgYyz for ; Tue, 5 Apr 2011 16:30:10 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 1D7F93A69A2 for ; Tue, 5 Apr 2011 16:30:10 -0700 (PDT) Received: by qyk7 with SMTP id 7so599407qyk.10 for ; Tue, 05 Apr 2011 16:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=CR+QyS+sUqipcZh8JNlOykkk7xlVUemawwooqYHkalo=; b=L/pTUSij+p69zuWPZ9CfRAxFhOlThANQRHWg7b3mbs7B6Gl+O7rwh/IrKH5ltWIgHF PVOsAMYYFN+mEbbv5YhKuX8++Qnr3o3l+JDY2mVjASGULwmYDQsdS1SdZPlGUD/WezMb KLlie6xguvLBB7wC5w4zQ+kQT6hB7Icznq1Ng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=GJ975moah/qvytTPJm9wQWFJfJlNBLg9EMw1ZmX68BhD45xbNyxnAkt6YFxM6AJYNI gE33TAZkY5CiR9/VXMULtPm0RlyW7xNPDJNuAEYlbNBYhGlLVkZRMT0NwOQvNpkGdOAE VsYVxvAqoGQvQKOmGZRKeRsaA960jxGMekLC8= MIME-Version: 1.0 Received: by 10.229.124.145 with SMTP id u17mr253759qcr.71.1302046312712; Tue, 05 Apr 2011 16:31:52 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Tue, 5 Apr 2011 16:31:52 -0700 (PDT) In-Reply-To: References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <20110405152025.26ba8f77@hikaru.localdomain> <4D9B4586.9080004@gmail.com> Date: Wed, 6 Apr 2011 00:31:52 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd25caef34b6404a034475c Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 05 Apr 2011 23:30:13 -0000 --000e0cd25caef34b6404a034475c Content-Type: text/plain; charset=ISO-8859-1 Before those 3 bullet points that I listed earlier disappear from immediate scope, I would like to point out an important issue that fits under bullet point #2 about data flows and fetch queries. The parameters that need to be supplied to an asset service when a particular asset is requested will not be the same in all cases. There are at least two different issues that will result in variations in fetch parameters: - Firstly, different VWRAP deployment patterns may affect the nature of the query. For example, in a deployment pattern that proxies all asset accesses, the query parameters all come from a server-side host (typically but not necessarily the region simulator), and the region credentials are quite likely to be implicit in the session between region and asset service. In contrast, in a deployment in which the client issues fetch requests to asset services directly, the region credentials are likely to take the form of an extra parameter supplied in each fetch request, and in addition, other user-oriented credentials may need to be supplied by the client. Other deployments may result in still different query parametrization to reflect the varying architecture. This is an area which we have not yet examined against different forms of deployment. - Secondly, different types of asset can require different types of query parametrization. For example, all the usual open content licenses (taking the Creative Commons licenses as an example) share the common property that the licenses are non-revocable and that the covered content is redistributable to all parties without exception in perpetuity. As a result, there is no point in supplying a credential of any kind in order to fetch such an asset, and therefore the fetch operation can be made slimmer and hence more efficient. The burden of encrypted sessions and endpoint identification certificates can be omitted entirely. This saves both time and other resources, and applies similarly to queries from both the client and the server side. It is easy to foresee that some community asset services will choose to serve open-licensed content only, as a matter of principle, in the same way that some Linux distribution provide only free/libre software as a matter of principle. Such asset services will not need the mechanisms of authorization that commercial or proprietary services are likely to require, and will gain a simplification and a performance gain as a result. Although the issues in this area are fairly straightforward, it will require quite a lot of work to catch all the likely deployments. Since we do not have advocates for more than 2 or 3 common deployments in this group, we had better make sure that the protocol machinery we provide is extensible to cater for others that are bound to emerge. Morgaine. ====================== On Tue, Apr 5, 2011 at 7:56 PM, Morgaine wrote: > On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol wrote: > >> >> Do you think we are ready to implement some asset services now, >> with/without complete documentation? >> >> What more do you think is needed? >> >> >> Two or three things seem to be needed: > > > - Defining the asset addressing concept is an extremely important > matter, almost certainly the most important matter of all, because that > determines how robust and scalable our worlds will be. I've already > examined alternatives for that in some depth, and the design with the best > engineering properties so far seems to be universal hash-based addressing. > I first described that approach on the list here --- > http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html , and > referred to it in various subsequent discussions. > > > - Defining the data flows between regions, clients, and asset services > and which parameters control the flows needs to be done before a test asset > service can be implemented. Without that, an asset service is just a > network-accessible storage service, not an asset service in the VWRAP > sense. Network storage services exist already, so just implementing one of > those would not advance VWRAP. > > > - We need to examine how various deployment patterns will use the asset > services, and how the *multiple* asset services that interop introduces > are handled. I am working on this currently. > > > None of the above is particularly hard. I think it won't be long before we > have a scheme worked out and are ready for some implementation work. > > > Morgaine. > > > > > --000e0cd25caef34b6404a034475c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Before those 3 bullet points that I listed earlier disappear from immediate= scope, I would like to point out an important issue that fits under bullet= point #2 about data flows and fetch queries.

    The parameters that ne= ed to be supplied to an asset service when a particular asset is requested = will not be the same in all cases.=A0 There are at least two different issu= es that will result in variations in fetch parameters:

    • Firstly, different VWRAP deployment patterns may affect the nat= ure of the query.=A0 For example, in a deployment pattern that proxies all = asset accesses, the query parameters all come from a server-side host (typi= cally but not necessarily the region simulator), and the region credentials= are quite likely to be implicit in the session between region and asset se= rvice.=A0 In contrast, in a deployment in which the client issues fetch req= uests to asset services directly, the region credentials are likely to take= the form of an extra parameter supplied in each fetch request, and in addi= tion, other user-oriented credentials may need to be supplied by the client= .=A0 Other deployments may result in still different query parametrization = to reflect the varying architecture.=A0 This is an area which we have not y= et examined against different forms of deployment.
    • Secondly, different types of asset can require different types= of query parametrization.=A0 For example, all the usual open content licen= ses (taking the Creative Commons licenses as an example) share the common p= roperty that the licenses are non-revocable and that the covered content is= redistributable to all parties without exception in perpetuity.=A0 As a re= sult, there is no point in supplying a credential of any kind in order to f= etch such an asset, and therefore the fetch operation can be made slimmer a= nd hence more efficient.=A0 The burden of encrypted sessions and endpoint i= dentification certificates can be omitted entirely.=A0 This saves both time= and other resources, and applies similarly to queries from both the client= and the server side.=A0 It is easy to foresee that some community asset se= rvices will choose to serve open-licensed content only, as a matter of prin= ciple, in the same way that some Linux distribution provide only free/libre= software as a matter of principle.=A0 Such asset services will not need th= e mechanisms of authorization that commercial or proprietary services are l= ikely to require, and will gain a simplification and a performance gain as = a result.


    Although the issues in this area are fairly straightforward, i= t will require quite a lot of work to catch all the likely deployments.=A0 = Since we do not have advocates for more than 2 or 3 common deployments in t= his group, we had better make sure that the protocol machinery we provide i= s extensible to cater for others that are bound to emerge.


    Morgaine.





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

    On Tue,= Apr 5, 2011 at 7:56 PM, Morgaine <morgaine.dinova@googlemail.com> wrote:
    On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol <dzonatas@gmail.com>= wrote:

    Do you think we are ready to implement some asset services now, with/withou= t complete documentation?

    What more do you think is needed?


    Two or three things seem to be needed:
    • Defining the asset addressing concept is an extremely importan= t matter, almost certainly the most important matter of all, because that d= etermines how robust and scalable our worlds will be.=A0 I've already e= xamined alternatives for that in some depth, and the design with the best e= ngineering properties so far seems to be universal hash-based addressing.= =A0 I first described that approach on the list here --- http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html , an= d referred to it in various subsequent discussions.
    • Defining the data flows between regions, clients, and ass= et services and which parameters control the flows needs to be done before = a test asset service can be implemented.=A0 Without that, an asset service = is just a network-accessible storage service, not an asset service in the V= WRAP sense.=A0 Network storage services exist already, so just implementing= one of those would not advance VWRAP.
    • We need to examine how various deployment patterns will use th= e asset services, and how the multiple asset services that interop i= ntroduces are handled.=A0 I am working on this currently.

    None= of the above is particularly hard.=A0 I think it won't be long before = we have a scheme worked out and are ready for some implementation work.


    Morgaine.





    --000e0cd25caef34b6404a034475c-- From morgaine.dinova@googlemail.com Tue Apr 5 17:02:40 2011 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 ADDFF3A6846 for ; Tue, 5 Apr 2011 17:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1] 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 W6IlaORm4RUJ for ; Tue, 5 Apr 2011 17:02:38 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 42DBD3A6844 for ; Tue, 5 Apr 2011 17:02:38 -0700 (PDT) Received: by qwc23 with SMTP id 23so676559qwc.31 for ; Tue, 05 Apr 2011 17:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=lk8VABYZtUqM8owNK+HOdNicn/6tk+oNofMmr1YMWws=; b=E9aS3+EH6NDHpt2hSg2hgGLZbamqcyUhon1F3k8jmDB2zV41L8n43Ts7HKZZGD31tp LFT0HoHIHbSJfJzkuq17Hj1awC94fMlCy5djc+p7t1/thr3ylk3UQ9kaahwxQU7cJyPA Ab7fFGCPwVX563Mbg533BcT/gGHbWFdau5qM0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=c9lBB6cLtxWfrP7siZwShhCpLXzhrUVgF8/2tRJ1sGIRMcZxucyoGoOgACpAgCyeWj 0WmNWgkVwmZJS9ipRsvRO2Y7iozOP+rgKCB16hg3HISKJzVXstr0ceyY2oFWPmZmJBYH eTqDdcsBWDzy4z+vqoc00aw6YfhDkDd+d0X1M= MIME-Version: 1.0 Received: by 10.229.37.130 with SMTP id x2mr250931qcd.147.1302048261257; Tue, 05 Apr 2011 17:04:21 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Tue, 5 Apr 2011 17:04:20 -0700 (PDT) In-Reply-To: <4D9B9D4A.7050006@gmail.com> References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <20110405152025.26ba8f77@hikaru.localdomain> <4D9B4586.9080004@gmail.com> <4D9B73D5.4000809@gmail.com> <4D9B8ADA.9000106@gmail.com> <4D9B937C.1040403@gmail.com> <4D9B9D4A.7050006@gmail.com> Date: Wed, 6 Apr 2011 01:04:20 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016368340c017b90204a034bc95 Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 06 Apr 2011 00:02:41 -0000 --0016368340c017b90204a034bc95 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The asset fetch performance gain of a protocol in which asset identifiers make cross-world assets cacheable versus a protocol whose asset identifiers do not allow this is an extremely large factor of *many orders of magnitude*on all but the first occurrence of an asset. For all intents and purposes, avoiding the need to fetch an asset over the network represents a gain of infinity, and this gain may be repeated many times over. I think it's pretty uncontestable that giving VWRAP an asset addressing scheme which is orders of magnitude more efficient than any other scheme that has yet been proposed would be an important benefit for the protocol, and highly likely to make it popular. Conversely, if it lacks this benefit then another protocol will use it and will hugely out-perform VWRAP. We were talking about designing for the future. Hash-based asset addressin= g is a case in point, and how we handle this proposal is apparently our first test case. 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 On Tue, Apr 5, 2011 at 11:52 PM, Dzonatas Sol wrote: > And... still local cache.. not vwrap. > > I think it would be more wise to go with the implementations of Google's > and/or Siemens object identification to RFID codes. At least we know this > part won't exploit content. > > It has further advantages than just that. I went into detail awhile ago, > yet with basic QM: > http://icyspherical.blogspot.com/2010/07/optimizing-simulations-with-basi= c.html > > No, even given the possibilities presented, I don't think your idea comes > close to anything new in regards to the best. It's just your preference. > > Morgaine wrote: > >> On Tue, Apr 5, 2011 at 11:11 PM, Dzonatas Sol > dzonatas@gmail.com>> wrote: >> >> >> Your approach, besides exploitations, has the typical problem to >> assume asset IDs are only needed and are hash-able. >> >> >> >> Asset IDs are not hash-able, it is the asset data that is hashed. The >> asset identifier is the hash of the asset data using a defined hash dige= st >> algorithm. The asset identifier is not guessable unless you already hav= e >> access to the asset. >> >> >> 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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> On Tue, Apr 5, 2011 at 10:34 PM, Dzonatas Sol >> >> >> wrote: >> >> Again Morgaine, your appeals alone don't support >> themselves, and >> your ridicule is unwelcome. If you can not honestly make any >> serious response, please move on and don't reply to my >> posts just >> to further ridicule. It's very RUDE. >> >> If you have any implementation of your hash-based idea or >> actual >> technical detailed documentation ready for implementation, the= n >> introduce it. Until then, it's stuck in your head, and sounds >> other's ideas just with your name on it. Plus security by >> obscurity makes it as moot point. >> >> Documentation... ? >> >> Remember people tried to take one temp variable away from the >> JPEG2000 int multiple/divide routine because the idea it looks >> good (on paper) with one less variable. Actual implementation >> reveals, with timed tests, it is slower when anybody takes awa= y >> that one temp variable. >> >> Morgaine wrote: >> >> Unfortunately your response was devoid of technical >> content, >> Dzonatas. >> >> If you have something technical to say about hash-based >> addressing, I would love to hear it. >> >> I have detailed in some depth the many benefits of >> hash-based >> addressing in the article I linked, and subsequently. If >> other good schemes exist, we should of course analyze >> them for >> technical merit and compare their benefits against those o= f >> hash-based addressing. >> >> That's the engineering process for making VWRAP as good >> as it >> can be. >> >> >> 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 >> >> On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol >> >> > >> >> >>> wrote: >> >> Morgaine, we mooted your hash-based idea. This does >> nothing to >> help implement asset services. The only significant >> point >> you made >> is some expression for optimization, not correct >> functionality, >> which is needed first >> >> As for your other two, we can summarize those with >> public >> resources and flow (forward/reverse). Any more >> specific network >> topology than that only makes it harder to address. The >> only thing >> to worry about is already custom resources that overlap >> with newer >> public resources. >> >> Morgaine wrote: >> >> On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol >> >> > >> >> >> >> > > > >> >> >>>> wrote: >> >> >> Do you think we are ready to implement some asse= t >> services now, >> with/without complete documentation? >> >> What more do you think is needed? >> >> >> Two or three things seem to be needed: >> >> * Defining the asset addressing concept is an >> extremely >> important >> matter, almost certainly the most important >> matter >> of all, >> because that determines how robust and >> scalable our >> worlds will >> be.=EF=BF=BD I've already examined alternative= s for >> that >> in some >> depth, >> and the design with the best engineering >> properties so >> far seems >> to be universal hash-based addressing.=EF=BF= =BD I first >> described >> that >> approach on the list here --- >> >> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >> , and referred to it in various subsequent >> discussions. >> >> * Defining the data flows between regions, >> clients, >> and asset >> services and which parameters control the flow= s >> needs to >> be done >> before a test asset service can be >> implemented.=EF=BF=BD >> Without >> that, >> an asset service is just a >> network-accessible storage >> service, >> not an asset service in the VWRAP sense.=EF=BF= =BD >> Network >> storage >> services exist already, so just >> implementing one >> of those >> would >> not advance VWRAP. >> >> * We need to examine how various deployment >> patterns >> will >> use the >> asset services, and how the /multiple/ asset >> services that >> interop introduces are handled.=EF=BF=BD I am >> working on this >> currently. >> >> >> None of the above is particularly hard.=EF=BF=BD I = think it >> won't be >> long before we have a scheme worked out and are >> ready >> for some >> implementation work. >> >> >> Morgaine. >> >> >> >> >> >> -----------------------------------------------------------------------= - >> >> >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> > >> >> >> >> >> >> https://www.ietf.org/mailman/listinfo/vwrap >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, >> Consultant >> >> >> >> -----------------------------------------------------------------------= - >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, >> Consultant >> >> >> >> -----------------------------------------------------------------------= - >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > --0016368340c017b90204a034bc95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The asset fetch performance gain of a protocol in which asset identifiers m= ake cross-world assets cacheable versus a protocol whose asset identifiers = do not allow this is an extremely large factor of many orders of magnitu= de on all but the first occurrence of an asset.=C2=A0 For all intents a= nd purposes, avoiding the need to fetch an asset over the network represent= s a gain of infinity, and this gain may be repeated many times over.

    I think it's pretty uncontestable that giving VWRAP an asset addres= sing scheme which is orders of magnitude more efficient than any other sche= me that has yet been proposed would be an important benefit for the protoco= l, and highly likely to make it popular.=C2=A0 Conversely, if it lacks this= benefit then another protocol will use it and will hugely out-perform VWRA= P.

    We were talking about designing for the future.=C2=A0 Hash-based asset = addressing is a case in point, and how we handle this proposal is apparentl= y our first test case.


    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


    On Tue, Apr 5, 2011 at 11:52 PM, Dzonata= s Sol <dzonatas@= gmail.com> wrote:
    And... still local cache.. not vwrap.

    I think it would be more wise to go with the implementations of Google'= s and/or Siemens object identification to RFID codes. At least we know this= part won't exploit content.

    It has further advantages than just that. I went into detail awhile ago, ye= t with basic QM: http://icyspherical.blo= gspot.com/2010/07/optimizing-simulations-with-basic.html

    No, even given the possibilities presented, I don't think your idea com= es close to anything new in regards to the best. It's just your prefere= nce.

    Morgaine wrote:
    On Tue, Apr 5, 2011 at 11:11 PM, Dzonatas Sol <dzonatas@gmail.com <mailto:dzonatas@gmail.com>>= ; wrote:


    =C2=A0 =C2=A0Your approach, besides exploitations, has the typical problem= to
    =C2=A0 =C2=A0assume asset IDs are only needed and are hash-able.



    Asset IDs are not hash-able, it is the asset data that is hashed. =C2=A0The= asset identifier is the hash of the asset data using a defined hash digest= algorithm. =C2=A0The asset identifier is not guessable unless you already = have access to the asset.


    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



    =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

    =C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, Apr 5, 2011 at 10:34 PM, Dzonatas Sol =C2=A0 =C2=A0 =C2=A0 =C2=A0<dzonatas@gmail.com <mailto:dzonatas@gmail.com>
    <= /div>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>> wrote= :

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Again Morgaine, your appeals alone don&= #39;t support
    =C2=A0 =C2=A0 =C2=A0 =C2=A0themselves, and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 your ridicule is unwelcome. If you can = not honestly make any
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 serious response, please move on and do= n't reply to my
    =C2=A0 =C2=A0 =C2=A0 =C2=A0posts just
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to further ridicule. It's very RUDE= .

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If you have any implementation of your = hash-based idea or
    =C2=A0 =C2=A0 =C2=A0 =C2=A0actual
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 technical detailed documentation ready = for implementation, then
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 introduce it. Until then, it's stuc= k in your head, and sounds
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 other's ideas just with your name o= n it. Plus security by
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 obscurity makes it as moot point.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Documentation... ?

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Remember people tried to take one temp = variable away from the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 JPEG2000 int multiple/divide routine be= cause the idea it looks
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 good (on paper) with one less variable.= Actual implementation
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 reveals, with timed tests, it is slower= when anybody takes away
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that one temp variable.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Morgaine wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Unfortunately your respon= se was devoid of technical
    =C2=A0 =C2=A0 =C2=A0 =C2=A0content,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Dzonatas.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If you have something tec= hnical to say about hash-based
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 addressing, I would love = to hear it.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I have detailed in some d= epth the many benefits of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0hash-based
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 addressing in the article= I linked, and subsequently. =C2=A0If
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 other good schemes exist,= we should of course analyze
    =C2=A0 =C2=A0 =C2=A0 =C2=A0them for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 technical merit and compa= re their benefits against those of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hash-based addressing.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 That's the engineerin= g process for making VWRAP as good
    =C2=A0 =C2=A0 =C2=A0 =C2=A0as it
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 can be.


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Morgaine.




    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Tue, Apr 5, 2011 at 8:= 56 PM, Dzonatas Sol
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <dzonatas@gmail.com <mailto:dzonatas@gmail.com>= ;
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>
    =
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com <mailto= :dzonatas@gmail.com= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>> w= rote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Morgaine, we= mooted your hash-based idea. This does
    =C2=A0 =C2=A0 =C2=A0 =C2=A0nothing to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0help impleme= nt asset services. The only significant
    =C2=A0 =C2=A0 =C2=A0 =C2=A0point
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 you made
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is some expr= ession for optimization, not correct
    =C2=A0 =C2=A0 =C2=A0 =C2=A0functionality,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0which is nee= ded first

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As for your = other two, we can summarize those with
    =C2=A0 =C2=A0 =C2=A0 =C2=A0public
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0resources an= d flow (forward/reverse). Any more
    =C2=A0 =C2=A0 =C2=A0 =C2=A0specific network
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0topology tha= n that only makes it harder to address. The
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 only thing
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to worry abo= ut is already custom resources that overlap
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with newer
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public resou= rces.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Morgaine wro= te:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<dzonatas@gma= il.com <mailto:dzonatas@gmail.com>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com <mailto= :dzonatas@gmail.com= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<mailto:dzona= tas@gmail.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com> <mailto:dzonatas@gmail.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com <mailto= :dzonatas@gmail.com= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>>&g= t; wrote:


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Do you think we are ready to implement some asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 services now,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 with/without complete documentation?

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 What more do you think is needed?


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Two or three things seem to be needed:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 * Defining the asset addressing concept is an
    =C2=A0 =C2=A0 =C2=A0 =C2=A0extremely
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0important
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 matter, almost certainly the most important
    =C2=A0 =C2=A0 =C2=A0 =C2=A0matter
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of all,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 because that determines how robust and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0scalable our
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0worlds will
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 be.=EF=BF=BD I've already examined alternatives for =C2=A0 =C2=A0 =C2=A0 =C2=A0that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in some
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0depth,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 and the design with the best engineering
    =C2=A0 =C2=A0 =C2=A0 =C2=A0properties so
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0far seems
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 to be universal hash-based addressing.=EF=BF=BD I first =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 described
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 approach on the list here ---
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/mail-archive/we= b/vwrap/current/msg00463.html
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 , and referred to it in various subsequent
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 discussions.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 * Defining the data flows between regions,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0clients,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 services and which parameters control the flows
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 needs to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0be done
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 before a test asset service can be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0implemented.=EF=BF=BD
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Without
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0that,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 an asset service is just a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0network-accessible storage
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0service,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 not an asset service in the VWRAP sense.=EF=BF=BD
    =C2=A0 =C2=A0 =C2=A0 =C2=A0Network
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 storage
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 services exist already, so just
    =C2=A0 =C2=A0 =C2=A0 =C2=A0implementing one
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of those
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0would
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 not advance VWRAP.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 * We need to examine how various deployment
    =C2=A0 =C2=A0 =C2=A0 =C2=A0patterns
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 will
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0use the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 asset services, and how the /multiple/ asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 services that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 interop introduces are handled.=EF=BF=BD I am
    =C2=A0 =C2=A0 =C2=A0 =C2=A0working on this
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0currently.


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0None of the above is particularly hard.=EF=BF=BD I think it
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 won't be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0long before we have a scheme worked out and are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0ready
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for some
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0implementation work.


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Morgaine.




    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-----------------------= -------------------------------------------------



    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0_______________________________________________
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0vwrap mailing list
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0vwrap@ietf.org &= lt;mailto:vwrap@ietf.or= g>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>>>


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0https://www.ietf.org/mailman/listinfo/vwrap
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- =C2=A0 = =C2=A0 --- h= ttps://twitter.com/Dzonatas_Sol ---
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Web Developm= ent, Software Engineering, Virtual Reality,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Consultant


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0------------------------------------------------------------------------=

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _________________________= ______________________
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vwrap mailing list
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vwrap@ietf.org <mailto:vwrap@ietf.org>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailm= an/listinfo/vwrap
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- =C2=A0 =C2=A0 --- https://twitter.com/Dzonatas_S= ol ---
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Web Development, Software Engineering, = Virtual Reality,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0Consultant


    =C2=A0 =C2=A0 =C2=A0 =C2=A0-----------------------------------------------= -------------------------

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


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


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


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


    --0016368340c017b90204a034bc95-- From izzyalanis@gmail.com Tue Apr 5 17:07:45 2011 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 4B03A3A6881 for ; Tue, 5 Apr 2011 17:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.053 X-Spam-Level: X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 iss0M12h-svu for ; Tue, 5 Apr 2011 17:07:43 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id A2E963A6844 for ; Tue, 5 Apr 2011 17:07:43 -0700 (PDT) Received: by qyk7 with SMTP id 7so611506qyk.10 for ; Tue, 05 Apr 2011 17:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-type:message-id:content-transfer-encoding:cc:x-mailer:from :subject:date:to; bh=vSOh0OAo3vBQ00wuNXYSN5rc1vemlI42+8tQHROFHWg=; b=rJTxaLkKC66GzwTvBIJy74f1i0ipeHigGBGUuop96ptPphkq6DPo/1vKbp/VMteaI5 nSiSKi3XCJ0vPYWpff1hjwM0L7lSFwoQdpmdS1orCucMQJM3fbQiVuGmqNe0MAaHoZi7 oBM1bnnLuvk/Npo8i8uEr7lYoXmk70xkTYBlo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; b=PvemgplaHkfe7hZhe5xWFQk1UZ1ghFtHXVo32ilShQrxx51TN60CE48vVncoR7O/Tt 3A0y/hWmHA4WtnoxRemfv0JDru/hJuP5i/lhQDcVBGWfhtq2nE+uGKyxD5o/EIXWimk1 qqqlRWZNoqK14Z/52nRk21mUPV/rpHUwPzAcI= Received: by 10.224.74.14 with SMTP id s14mr258727qaj.191.1302048566995; Tue, 05 Apr 2011 17:09:26 -0700 (PDT) Received: from [192.168.1.104] (c-75-68-52-200.hsd1.nh.comcast.net [75.68.52.200]) by mx.google.com with ESMTPS id m3sm10784qck.26.2011.04.05.17.09.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 17:09:25 -0700 (PDT) References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <20110405231144.4cec7412@hikaru.localdomain> <4D9B8E6B.6010409@gmail.com> In-Reply-To: <4D9B8E6B.6010409@gmail.com> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Type: text/plain; charset=us-ascii Message-Id: <7EE0A3BB-C52C-4DEC-8928-E0D990B2487D@gmail.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8C148) From: Izzy Alanis Date: Tue, 5 Apr 2011 20:09:13 -0400 To: Dzonatas Sol Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 06 Apr 2011 00:07:45 -0000 I agree, this is a purely academic exercise, but I think Carlo wanted to pra= ctice attempting to reach a consensus. Proposal, counter proposal, discuss t= he ramifications of specific verbiage, etc... ;) - Izzy On Apr 5, 2011, at 5:49 PM, Dzonatas Sol wrote: > IETF seems to already have this nailed down on the political side. The wor= king groups help. >=20 > Any proposal needs documentation, so that is where any consensus happens a= side from implementation (actual or attempted). >=20 > We can assume succession of RFCs. >=20 > Carlo Wood wrote: >> On Tue, 5 Apr 2011 13:03:36 -0400 >> Izzy Alanis wrote: >> =20 >>> I'm not against the "design for tomorrow" platform. I'm pro-"design >>> for tomorrow", but I believe the proposition, as currently worded, >>> does not appropriately communicate those intentions. >>>=20 >>> I could agree with the following wording (though I still don't believe >>> it communicates your 'design for tomorrow intentions'): >>>=20 >>> * Whenever a change X in the protocol is proposed (which might be >>> an addition, a change of existing protocol or even deletion: any >>> change, making the protocol (VWRAP) go from A --> B), then >>> *# Protocol B SHOULD do everything that A could do. >>> *# Good use-case justification for B MUST be provided. >>> *# Implementation requirements of B MUST be listed. >>> =20 >>=20 >> That completely changes the whole intent of the proposal: >> to make progress by reaching consensus on an (abstract) goal. >>=20 >> My goal is to have less discussion about whether or not something >> should be supported by making clear that if there is even a single >> use case, maybe, that might need it, then why not? Then people wont >> have to defend anymore why that use case is essential, or morally ok, >> or not endangering the private agenda of someone. Then it's just >> clear from the start that "Oh yes, someone might want that, so VWRAP >> HAS to support that"... There shouldn't be any discussion about >> something like that. >>=20 >> In your bullet points, I don't see that goal back at all anymore. >>=20 >> Worse, I oppose to it. If A then B is NOT the same as if B then A. >> You changed the meaning completely. What you are saying that it >> is forbidden to even make a proposal for a change unless the result can >> still do exactly what it could be before that. That means we can't make >> any real CHANGES anymore. Everything we have done so far is set in >> stone and apparently holy (correct, without errors). >>=20 >> =20 >=20 >=20 > --=20 > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant >=20 > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap From dzonatas@gmail.com Tue Apr 5 17:24:13 2011 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 5014A3A6942 for ; Tue, 5 Apr 2011 17:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.52 X-Spam-Level: X-Spam-Status: No, score=-3.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Q2MTtb1JFeQz for ; Tue, 5 Apr 2011 17:24:11 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 725833A6844 for ; Tue, 5 Apr 2011 17:24:11 -0700 (PDT) Received: by iye19 with SMTP id 19so1121223iye.31 for ; Tue, 05 Apr 2011 17:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=b+R4GfoulYGsv7BXrMfHfVhdsqxXm89n9Bw/Du6n7Qg=; b=F1ISTucHyVQRGoVwYwG0Ecc1g6rybhsVJsKv+WanfdTMWb4/PGFv5TNQxl4IxngEM/ MUZDUJxEDJh1bFzAQcghDCeiJfCa+Un+ha22Y/UQgeaqGIYmVxmkHQxNUoT0gJHB1PHi 4dzj6NwdNFheWNY5Cfe7StToHS+Kr/NXTcMe4= 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=Bxdb/WZgQvdZOV4ZtyCHumER82trvf6v3J9h9ckqOvTKC41/99i2QfoPCeD/vFQq/n 4zw0H/U0pKjLay4ZNz6peURnNRFsWCQF4gJ56kqPGA3AJla2ML58skwdRNfYNGtUF/8a 06zpn62CamL8TIIL05/UyQ945Gy/SjpLiTq/c= Received: by 10.42.28.129 with SMTP id n1mr447325icc.287.1302049554307; Tue, 05 Apr 2011 17:25:54 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id vx7sm4469469icb.2.2011.04.05.17.25.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 17:25:53 -0700 (PDT) Message-ID: <4D9BB342.7020607@gmail.com> Date: Tue, 05 Apr 2011 17:26:42 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <20110405152025.26ba8f77@hikaru.localdomain> <4D9B4586.9080004@gmail.com> <4D9B73D5.4000809@gmail.com> <4D9B8ADA.9000106@gmail.com> <4D9B937C.1040403@gmail.com> <4D9B9D4A.7050006@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 06 Apr 2011 00:24:13 -0000 We were and still are in discussion about VWRAP documents. As someone that implements, they don't want to read anything like "many orders of magnitude" or "the best idea" or such exaggerated adjectives. Don't expect your ideas ever to get implemented based on such language. Need just the facts, and the documents. Please, stop with how great you think your idea is and produce the documents! Please include specific use of the resources, LLIDL, DSD, etc. If this continues to be just discussion and neither documentation nor implementation than I'm with the chair(s) to disband. Morgaine wrote: > The asset fetch performance gain of a protocol in which asset > identifiers make cross-world assets cacheable versus a protocol whose > asset identifiers do not allow this is an extremely large factor of > *many orders of magnitude* on all but the first occurrence of an > asset. For all intents and purposes, avoiding the need to fetch an > asset over the network represents a gain of infinity, and this gain > may be repeated many times over. > > I think it's pretty uncontestable that giving VWRAP an asset > addressing scheme which is orders of magnitude more efficient than any > other scheme that has yet been proposed would be an important benefit > for the protocol, and highly likely to make it popular. Conversely, > if it lacks this benefit then another protocol will use it and will > hugely out-perform VWRAP. > > We were talking about designing for the future. Hash-based asset > addressing is a case in point, and how we handle this proposal is > apparently our first test case. > > > Morgaine. > > > > > > =============================== > > > On Tue, Apr 5, 2011 at 11:52 PM, Dzonatas Sol > wrote: > > And... still local cache.. not vwrap. > > I think it would be more wise to go with the implementations of > Google's and/or Siemens object identification to RFID codes. At > least we know this part won't exploit content. > > It has further advantages than just that. I went into detail > awhile ago, yet with basic QM: > http://icyspherical.blogspot.com/2010/07/optimizing-simulations-with-basic.html > > No, even given the possibilities presented, I don't think your > idea comes close to anything new in regards to the best. It's just > your preference. > > Morgaine wrote: > > On Tue, Apr 5, 2011 at 11:11 PM, Dzonatas Sol > > >> wrote: > > > Your approach, besides exploitations, has the typical > problem to > assume asset IDs are only needed and are hash-able. > > > > Asset IDs are not hash-able, it is the asset data that is > hashed. The asset identifier is the hash of the asset data > using a defined hash digest algorithm. The asset identifier > is not guessable unless you already have access to the asset. > > > Morgaine. > > > > > ============================= > > > > ================== > > On Tue, Apr 5, 2011 at 10:34 PM, Dzonatas Sol > > > > > >>> wrote: > > Again Morgaine, your appeals alone don't support > themselves, and > your ridicule is unwelcome. If you can not honestly > make any > serious response, please move on and don't reply to my > posts just > to further ridicule. It's very RUDE. > > If you have any implementation of your hash-based > idea or > actual > technical detailed documentation ready for > implementation, then > introduce it. Until then, it's stuck in your head, > and sounds > other's ideas just with your name on it. Plus > security by > obscurity makes it as moot point. > > Documentation... ? > > Remember people tried to take one temp variable away > from the > JPEG2000 int multiple/divide routine because the > idea it looks > good (on paper) with one less variable. Actual > implementation > reveals, with timed tests, it is slower when anybody > takes away > that one temp variable. > > Morgaine wrote: > > Unfortunately your response was devoid of technical > content, > Dzonatas. > > If you have something technical to say about > hash-based > addressing, I would love to hear it. > > I have detailed in some depth the many benefits of > hash-based > addressing in the article I linked, and > subsequently. If > other good schemes exist, we should of course > analyze > them for > technical merit and compare their benefits > against those of > hash-based addressing. > > That's the engineering process for making VWRAP > as good > as it > can be. > > > Morgaine. > > > > > ========================= > > On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol > > > > > >> > > > > >>>> wrote: > > Morgaine, we mooted your hash-based idea. > This does > nothing to > help implement asset services. The only > significant > point > you made > is some expression for optimization, not correct > functionality, > which is needed first > > As for your other two, we can summarize those > with > public > resources and flow (forward/reverse). Any more > specific network > topology than that only makes it harder to > address. The > only thing > to worry about is already custom resources > that overlap > with newer > public resources. > > Morgaine wrote: > > On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol > > > > >> > > > > >>> > > > > > >> > > > > >>>>> wrote: > > > Do you think we are ready to implement > some asset > services now, > with/without complete documentation? > > What more do you think is needed? > > > Two or three things seem to be needed: > > * Defining the asset addressing > concept is an > extremely > important > matter, almost certainly the most > important > matter > of all, > because that determines how robust and > scalable our > worlds will > be.� I've already examined > alternatives for > that > in some > depth, > and the design with the best engineering > properties so > far seems > to be universal hash-based > addressing.� I first > described > that > approach on the list here --- > > http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html > , and referred to it in various > subsequent > discussions. > > * Defining the data flows between regions, > clients, > and asset > services and which parameters > control the flows > needs to > be done > before a test asset service can be > implemented.� > Without > that, > an asset service is just a > network-accessible storage > service, > not an asset service in the VWRAP > sense.� > Network > storage > services exist already, so just > implementing one > of those > would > not advance VWRAP. > > * We need to examine how various > deployment > patterns > will > use the > asset services, and how the > /multiple/ asset > services that > interop introduces are handled.� I am > working on this > currently. > > > None of the above is particularly hard.� > I think it > won't be > long before we have a scheme worked out > and are > ready > for some > implementation work. > > > Morgaine. > > > > > > ------------------------------------------------------------------------ > > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > > >> > > > > > >>> > > > https://www.ietf.org/mailman/listinfo/vwrap > > -- --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, > Virtual Reality, > Consultant > > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > > >> > https://www.ietf.org/mailman/listinfo/vwrap > > > -- --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, > Consultant > > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > https://www.ietf.org/mailman/listinfo/vwrap > > > > -- --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, > Consultant > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Tue Apr 5 17:59:24 2011 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 23C413A6834 for ; Tue, 5 Apr 2011 17:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.803 X-Spam-Level: X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARzgGisiJNsz for ; Tue, 5 Apr 2011 17:59:21 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 24DAA3A682D for ; Tue, 5 Apr 2011 17:59:21 -0700 (PDT) Received: by qwc23 with SMTP id 23so694610qwc.31 for ; Tue, 05 Apr 2011 18:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=1hlem1NJ+RSTA+veNd6fg0zjODxjs2xUdKf2p11ytcc=; b=wFuBNI0fekMOrOdeVG9iZ2DhU+21xLHhVe66vTYXrSnz8XuMYxsqqI0PIlO2yDj/rM psY/46wB8FUliTUavgJuHl11VSNh4+gi4a4fWs43o84vtkGDdJTIPcsPC47FXEdH9XDX KssNO97qL0Fs2ydgQUXxWpu4jKXTDwdMV7L7A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=USA0WmkRFGZYx+rBgUJaHj+GIuN16/e7OKeF066lnnZ4P2/awpoQRWfAlCuwWj2d6p d1Q8um8pr8T76aFobfoyPIrjKynjHCI/YKLmlUJ3Zfnl5Olw9tOKiSqBwA+ecJUq7Q+0 WMhWxHjI7tIs6NSvDoD/Wcejp9cM+FaWqpb9g= MIME-Version: 1.0 Received: by 10.229.78.22 with SMTP id i22mr301084qck.33.1302051663400; Tue, 05 Apr 2011 18:01:03 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Tue, 5 Apr 2011 18:01:03 -0700 (PDT) In-Reply-To: <4D9BB342.7020607@gmail.com> References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <20110405152025.26ba8f77@hikaru.localdomain> <4D9B4586.9080004@gmail.com> <4D9B73D5.4000809@gmail.com> <4D9B8ADA.9000106@gmail.com> <4D9B937C.1040403@gmail.com> <4D9B9D4A.7050006@gmail.com> <4D9BB342.7020607@gmail.com> Date: Wed, 6 Apr 2011 02:01:03 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00235429d8f4e0524a04a0358691 Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 06 Apr 2011 00:59:24 -0000 --00235429d8f4e0524a04a0358691 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable *"Facts and documents*": Link already provided. Hash-based asset addressing is just one protocol design element out of many hundreds in VWRAP, and it would appear as a small technical detail in a future VWRAP document, not a VWRAP document in its own right. "*Many orders of magnitude*": Performance Gain =3D (time to fetch an asset over the network) / (time to fetch an asset from client cache with no network access required) . This could easily be 5 orders of magnitude unde= r normal operation, and a lot more under conditions of service congestion. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Wed, Apr 6, 2011 at 1:26 AM, Dzonatas Sol wrote: > We were and still are in discussion about VWRAP documents. > > As someone that implements, they don't want to read anything like "many > orders of magnitude" or "the best idea" or such exaggerated adjectives. > Don't expect your ideas ever to get implemented based on such language. > > Need just the facts, and the documents. Please, stop with how great you > think your idea is and produce the documents! Please include specific use= of > the resources, LLIDL, DSD, etc. > > If this continues to be just discussion and neither documentation nor > implementation than I'm with the chair(s) to disband. > > Morgaine wrote: > >> The asset fetch performance gain of a protocol in which asset identifier= s >> make cross-world assets cacheable versus a protocol whose asset identifi= ers >> do not allow this is an extremely large factor of *many orders of magnit= ude* >> on all but the first occurrence of an asset. For all intents and purpos= es, >> avoiding the need to fetch an asset over the network represents a gain o= f >> infinity, and this gain may be repeated many times over. >> >> I think it's pretty uncontestable that giving VWRAP an asset addressing >> scheme which is orders of magnitude more efficient than any other scheme >> that has yet been proposed would be an important benefit for the protoco= l, >> and highly likely to make it popular. Conversely, if it lacks this bene= fit >> then another protocol will use it and will hugely out-perform VWRAP. >> >> We were talking about designing for the future. Hash-based asset >> addressing is a case in point, and how we handle this proposal is appare= ntly >> our first test case. >> >> >> 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 >> >> >> On Tue, Apr 5, 2011 at 11:52 PM, Dzonatas Sol > dzonatas@gmail.com>> wrote: >> >> And... still local cache.. not vwrap. >> >> I think it would be more wise to go with the implementations of >> Google's and/or Siemens object identification to RFID codes. At >> least we know this part won't exploit content. >> >> It has further advantages than just that. I went into detail >> awhile ago, yet with basic QM: >> >> http://icyspherical.blogspot.com/2010/07/optimizing-simulations-with-bas= ic.html >> >> No, even given the possibilities presented, I don't think your >> idea comes close to anything new in regards to the best. It's just >> your preference. >> >> Morgaine wrote: >> >> On Tue, Apr 5, 2011 at 11:11 PM, Dzonatas Sol >> >> >> wrote: >> >> >> Your approach, besides exploitations, has the typical >> problem to >> assume asset IDs are only needed and are hash-able. >> >> >> >> Asset IDs are not hash-able, it is the asset data that is >> hashed. The asset identifier is the hash of the asset data >> using a defined hash digest algorithm. The asset identifier >> is not guessable unless you already have access to the asset. >> >> >> 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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> On Tue, Apr 5, 2011 at 10:34 PM, Dzonatas Sol >> >> > >> >> >>> wrote: >> >> Again Morgaine, your appeals alone don't support >> themselves, and >> your ridicule is unwelcome. If you can not honestly >> make any >> serious response, please move on and don't reply to my >> posts just >> to further ridicule. It's very RUDE. >> >> If you have any implementation of your hash-based >> idea or >> actual >> technical detailed documentation ready for >> implementation, then >> introduce it. Until then, it's stuck in your head, >> and sounds >> other's ideas just with your name on it. Plus >> security by >> obscurity makes it as moot point. >> >> Documentation... ? >> >> Remember people tried to take one temp variable away >> from the >> JPEG2000 int multiple/divide routine because the >> idea it looks >> good (on paper) with one less variable. Actual >> implementation >> reveals, with timed tests, it is slower when anybody >> takes away >> that one temp variable. >> >> Morgaine wrote: >> >> Unfortunately your response was devoid of technical >> content, >> Dzonatas. >> >> If you have something technical to say about >> hash-based >> addressing, I would love to hear it. >> >> I have detailed in some depth the many benefits of >> hash-based >> addressing in the article I linked, and >> subsequently. If >> other good schemes exist, we should of course >> analyze >> them for >> technical merit and compare their benefits >> against those of >> hash-based addressing. >> >> That's the engineering process for making VWRAP >> as good >> as it >> can be. >> >> >> 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 >> >> On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol >> >> > >> >> >> >> > > > >> >> >>>> wrote: >> >> Morgaine, we mooted your hash-based idea. >> This does >> nothing to >> help implement asset services. The only >> significant >> point >> you made >> is some expression for optimization, not correct >> functionality, >> which is needed first >> >> As for your other two, we can summarize those >> with >> public >> resources and flow (forward/reverse). Any more >> specific network >> topology than that only makes it harder to >> address. The >> only thing >> to worry about is already custom resources >> that overlap >> with newer >> public resources. >> >> Morgaine wrote: >> >> On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol >> > > > >> >> >> >> > > > >> >> >>> >> > >> > >> >> >> >> > > > >> >> >>>>> wrote= : >> >> >> Do you think we are ready to implement >> some asset >> services now, >> with/without complete documentation? >> >> What more do you think is needed? >> >> >> Two or three things seem to be needed: >> >> * Defining the asset addressing >> concept is an >> extremely >> important >> matter, almost certainly the most >> important >> matter >> of all, >> because that determines how robust and >> scalable our >> worlds will >> be.=EF=BF=BD I've already examined >> alternatives for >> that >> in some >> depth, >> and the design with the best engineerin= g >> properties so >> far seems >> to be universal hash-based >> addressing.=EF=BF=BD I first >> described >> that >> approach on the list here --- >> >> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >> , and referred to it in various >> subsequent >> discussions. >> >> * Defining the data flows between regions= , >> clients, >> and asset >> services and which parameters >> control the flows >> needs to >> be done >> before a test asset service can be >> implemented.=EF=BF=BD >> Without >> that, >> an asset service is just a >> network-accessible storage >> service, >> not an asset service in the VWRAP >> sense.=EF=BF=BD >> Network >> storage >> services exist already, so just >> implementing one >> of those >> would >> not advance VWRAP. >> >> * We need to examine how various >> deployment >> patterns >> will >> use the >> asset services, and how the >> /multiple/ asset >> services that >> interop introduces are handled.=EF=BF= =BD I am >> working on this >> currently. >> >> >> None of the above is particularly hard.=EF= =BF=BD >> I think it >> won't be >> long before we have a scheme worked out >> and are >> ready >> for some >> implementation work. >> >> >> Morgaine. >> >> >> >> >> >> -----------------------------------------------------------------------= - >> >> >> >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> > >> >> >> >> >> > >> >> >>> >> >> >> https://www.ietf.org/mailman/listinfo/vwrap >> -- --- >> https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, >> Virtual Reality, >> Consultant >> >> >> >> -----------------------------------------------------------------------= - >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> > >> >> >> >> https://www.ietf.org/mailman/listinfo/vwrap >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, >> Consultant >> >> >> >> -----------------------------------------------------------------------= - >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, >> Consultant >> >> >> >> -----------------------------------------------------------------------= - >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > --00235429d8f4e0524a04a0358691 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "Facts and documents":=C2=A0 Link already provided.=C2=A0 = Hash-based asset addressing is just one protocol design element out of many= hundreds in VWRAP, and it would appear as a small technical detail in a fu= ture VWRAP document, not a VWRAP document in its own right.

    "Many orders of magnitude":=C2=A0 Performance Gain =3D= (time to fetch an asset over the network) / (time to fetch an asset from c= lient cache with no network access required) .=C2=A0 This could easily be 5= orders of magnitude under normal operation, and a lot more under condition= s of service congestion.


    Morgaine.



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

    On Wed, Apr 6, 2011 at= 1:26 AM, Dzonatas Sol <dzonatas@gmail.com> wrote:
    We were and still= are in discussion about VWRAP documents.

    As someone that implements, they don't want to read anything like "= ;many orders of magnitude" or "the best idea" or such exagge= rated adjectives. Don't expect your ideas ever to get implemented based= on such language.

    Need just the facts, and the documents. Please, stop with how great you thi= nk your idea is and produce the documents! Please include specific use of t= he resources, LLIDL, DSD, etc.

    If this continues to be just discussion and neither documentation nor imple= mentation than I'm with the chair(s) to disband.

    Morgaine wrote:
    The asset fetch performance gain of a protocol in which asset identifiers m= ake cross-world assets cacheable versus a protocol whose asset identifiers = do not allow this is an extremely large factor of *many orders of magnitude= * on all but the first occurrence of an asset. =C2=A0For all intents and pu= rposes, avoiding the need to fetch an asset over the network represents a g= ain of infinity, and this gain may be repeated many times over.

    I think it's pretty uncontestable that giving VWRAP an asset addressing= scheme which is orders of magnitude more efficient than any other scheme t= hat has yet been proposed would be an important benefit for the protocol, a= nd highly likely to make it popular. =C2=A0Conversely, if it lacks this ben= efit then another protocol will use it and will hugely out-perform VWRAP.
    We were talking about designing for the future. =C2=A0Hash-based asset addr= essing is a case in point, and how we handle this proposal is apparently ou= r first test case.


    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


    On Tue, Apr 5, 2011 at 11:52 PM, Dzonatas Sol <dzonatas@gmail.com <mailto:dzonatas@gmail.com>>= ; wrote:

    =C2=A0 =C2=A0And... still local cache.. not vwrap.

    =C2=A0 =C2=A0I think it would be more wise to go with the implementations = of
    =C2=A0 =C2=A0Google's and/or Siemens object identification to RFID cod= es. At
    =C2=A0 =C2=A0least we know this part won't exploit content.

    =C2=A0 =C2=A0It has further advantages than just that. I went into detail<= br> =C2=A0 =C2=A0awhile ago, yet with basic QM:
    =C2=A0 =C2=A0http://icyspherical.blogsp= ot.com/2010/07/optimizing-simulations-with-basic.html

    =C2=A0 =C2=A0No, even given the possibilities presented, I don't think= your
    =C2=A0 =C2=A0idea comes close to anything new in regards to the best. It&#= 39;s just
    =C2=A0 =C2=A0your preference.

    =C2=A0 =C2=A0Morgaine wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, Apr 5, 2011 at 11:11 PM, Dzonatas Sol =C2=A0 =C2=A0 =C2=A0 =C2=A0<dzonatas@gmail.com <mailto:dzonatas@gmail.com>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>> wrote= :


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Your approach, besides exploitations, h= as the typical
    =C2=A0 =C2=A0 =C2=A0 =C2=A0problem to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 assume asset IDs are only needed and ar= e hash-able.



    =C2=A0 =C2=A0 =C2=A0 =C2=A0Asset IDs are not hash-able, it is the asset da= ta that is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0hashed. =C2=A0The asset identifier is the hash = of the asset data
    =C2=A0 =C2=A0 =C2=A0 =C2=A0using a defined hash digest algorithm. =C2=A0Th= e asset identifier
    =C2=A0 =C2=A0 =C2=A0 =C2=A0is not guessable unless you already have access= to the asset.


    =C2=A0 =C2=A0 =C2=A0 =C2=A0Morgaine.




    =C2=A0 =C2=A0 =C2=A0 =C2=A0=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



    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Tue, Apr 5, 2011 at 10= :34 PM, Dzonatas Sol
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <dzonatas@gmail.com <mailto:dzonatas@gmail.com>= ;
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>
    =
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com <mailto= :dzonatas@gmail.com= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>> w= rote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Again Morgai= ne, your appeals alone don't support
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 themselves, and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0your ridicul= e is unwelcome. If you can not honestly
    =C2=A0 =C2=A0 =C2=A0 =C2=A0make any
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0serious resp= onse, please move on and don't reply to my
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 posts just
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to further r= idicule. It's very RUDE.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If you have = any implementation of your hash-based
    =C2=A0 =C2=A0 =C2=A0 =C2=A0idea or
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 actual
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0technical de= tailed documentation ready for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0implementation, then
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0introduce it= . Until then, it's stuck in your head,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0and sounds
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0other's = ideas just with your name on it. Plus
    =C2=A0 =C2=A0 =C2=A0 =C2=A0security by
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0obscurity ma= kes it as moot point.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Documentatio= n... ?

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Remember peo= ple tried to take one temp variable away
    =C2=A0 =C2=A0 =C2=A0 =C2=A0from the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0JPEG2000 int= multiple/divide routine because the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0idea it looks
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0good (on pap= er) with one less variable. Actual
    =C2=A0 =C2=A0 =C2=A0 =C2=A0implementation
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reveals, wit= h timed tests, it is slower when anybody
    =C2=A0 =C2=A0 =C2=A0 =C2=A0takes away
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that one tem= p variable.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Morgaine wro= te:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Unfortunately your response was devoid of technical
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 content,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Dzonatas.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0If you have something technical to say about
    =C2=A0 =C2=A0 =C2=A0 =C2=A0hash-based
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0addressing, I would love to hear it.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0I have detailed in some depth the many benefits of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hash-based
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0addressing in the article I linked, and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0subsequently. =C2=A0If
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0other good schemes exist, we should of course
    =C2=A0 =C2=A0 =C2=A0 =C2=A0analyze
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 them for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0technical merit and compare their benefits
    =C2=A0 =C2=A0 =C2=A0 =C2=A0against those of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0hash-based addressing.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0That's the engineering process for making VWRAP
    =C2=A0 =C2=A0 =C2=A0 =C2=A0as good
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 as it
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0can be.


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Morgaine.




    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=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

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<dzonatas@gma= il.com <mailto:dzonatas@gmail.com>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com <mailto= :dzonatas@gmail.com= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<mailto:dzona= tas@gmail.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com> <mailto:dzonatas@gmail.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com <mailto= :dzonatas@gmail.com= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>>&g= t; wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Morgaine, we mooted your hash-based idea.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0This does
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 nothing to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 help implement asset services. The only
    =C2=A0 =C2=A0 =C2=A0 =C2=A0significant
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 point
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0you made
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 is some expression for optimization, not correct
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 functionality,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 which is needed first

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 As for your other two, we can summarize those
    =C2=A0 =C2=A0 =C2=A0 =C2=A0with
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 public
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 resources and flow (forward/reverse). Any more
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specific network
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 topology than that only makes it harder to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0address. The
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0only thing
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 to worry about is already custom resources
    =C2=A0 =C2=A0 =C2=A0 =C2=A0that overlap
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0with newer
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 public resources.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Morgaine wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <dzonatas@gmail.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com> <mailto:dzonatas@gmail.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com <mailto= :dzonatas@gmail.com= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<mailto:dzona= tas@gmail.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com> <mailto:dzonatas@gmail.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com <mailto= :dzonatas@gmail.com= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com <mailto= :dzonatas@gmail.com= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com <mailto= :dzonatas@gmail.com= >>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<mailto:dzona= tas@gmail.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com> <mailto:dzonatas@gmail.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com <mailto= :dzonatas@gmail.com= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>>&g= t;> wrote:


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Do you think we are ready to implemen= t
    =C2=A0 =C2=A0 =C2=A0 =C2=A0some asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0services now,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with/without complete documentation?<= br>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0What more do you think is needed?


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Two or three things seem to be needed:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Defining the asset addressing
    =C2=A0 =C2=A0 =C2=A0 =C2=A0concept is an
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 extremely
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 important
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0matter, almost certainly the m= ost
    =C2=A0 =C2=A0 =C2=A0 =C2=A0important
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 matter
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0of all,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0because that determines how ro= bust and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 scalable our
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 worlds will
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be.=EF=BF=BD I've already = examined
    =C2=A0 =C2=A0 =C2=A0 =C2=A0alternatives for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0in some
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 depth,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and the design with the best e= ngineering
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 properties so
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 far seems
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to be universal hash-based
    =C2=A0 =C2=A0 =C2=A0 =C2=A0addressing.=EF=BF=BD I first
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0described
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0approach on the list here ---<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.h= tml
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0, and referred to it in variou= s
    =C2=A0 =C2=A0 =C2=A0 =C2=A0subsequent
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0discussions.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Defining the data flows between reg= ions,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 clients,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0and asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0services and which parameters<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0control the flows
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0needs to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 be done
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0before a test asset service ca= n be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implemented.=EF=BF=BD
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Without
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 that,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0an asset service is just a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 network-accessible storag= e
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 service,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not an asset service in the VW= RAP
    =C2=A0 =C2=A0 =C2=A0 =C2=A0sense.=EF=BF=BD
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Network
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0storage
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0services exist already, so jus= t
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implementing one
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0of those
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 would
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not advance VWRAP.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* We need to examine how various
    =C2=A0 =C2=A0 =C2=A0 =C2=A0deployment
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 patterns
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0will
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 use the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0asset services, and how the =C2=A0 =C2=A0 =C2=A0 =C2=A0/multiple/ asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0services that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interop introduces are handled= .=EF=BF=BD I am
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 working on this
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 currently.


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 None of the above is particularly hard.=EF=BF=BD =C2=A0 =C2=A0 =C2=A0 =C2=A0I think it
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0won't be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 long before we have a scheme worked out
    =C2=A0 =C2=A0 =C2=A0 =C2=A0and are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ready
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0for some
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 implementation work.


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Morgaine.




    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0------------------------------------------------= ------------------------



    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________= ________________________
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 vwrap mailing list
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 vwrap@ietf.org <mailto:vwrap@ietf.org>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<mailto:vwrap@iet= f.org <mailto:vw= rap@ietf.org>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>>>>


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/vwrap
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- =C2=A0 =C2=A0 --- https://twitter.com/Dzonatas_Sol= ---
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Web Development, Software Engineering,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0Virtual Reality,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Consultant


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-----------------------= -------------------------------------------------

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0_______________________________________________
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0vwrap mailing list
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0vwrap@ietf.org &= lt;mailto:vwrap@ietf.or= g>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0https://www.ietf.org/mailman/listinfo/vwrap
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- =C2=A0 = =C2=A0 --- h= ttps://twitter.com/Dzonatas_Sol ---
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Web Developm= ent, Software Engineering, Virtual Reality,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Consultant


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0------------------------------------------------------------------------=

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _________________________= ______________________
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vwrap mailing list
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vwrap@ietf.org <mailto:vwrap@ietf.org>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailm= an/listinfo/vwrap
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- =C2=A0 =C2=A0 --- https://twitter.com/Dzonatas_S= ol ---
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Web Development, Software Engineering, = Virtual Reality,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0Consultant


    =C2=A0 =C2=A0 =C2=A0 =C2=A0-----------------------------------------------= -------------------------

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


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


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


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


    --00235429d8f4e0524a04a0358691-- From izzyalanis@gmail.com Tue Apr 5 18:23:16 2011 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 622BF3A69A0 for ; Tue, 5 Apr 2011 18:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 0-0gnjhwl8tr for ; Tue, 5 Apr 2011 18:23:14 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id C67563A6825 for ; Tue, 5 Apr 2011 18:23:13 -0700 (PDT) Received: by fxm15 with SMTP id 15so765984fxm.31 for ; Tue, 05 Apr 2011 18:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/1xrj32bdCZzFQb2K0L+c6r6v+a7YHeMcGKk73PVNas=; b=FPOsBOqu8fOmpuILWn1SNsfnIrnFywk70sXQ7eGCd3Os96l1tLHN/lxMYQyWRIm3x4 +4GeTTLAU0I/ys5v2S6eVFvGefT8XV+xRGxqOawwDAryNd9XSPYDXDI3CExbG6HYtgdT 4gyKYQUlljrbGK1lbA89MOJqMjiqy0FEZGc6k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=f1kjDCO0PL+ffkcJWz551A9D+xKxFoRIunIxFl9B5dFaBQa31RnK/ZVlx7NqxOFSXZ NqH0kZ+Ma7WkE2T8fMpCEnVXhJ6i8Llyp8lIpVftGNsC/rZpFBWmtBy3zWfZBrKx5lTJ ji7j6LAqAQ5KNaTL20MnPa6fX3nmzeqjcT900= MIME-Version: 1.0 Received: by 10.223.9.137 with SMTP id l9mr415478fal.25.1302053096226; Tue, 05 Apr 2011 18:24:56 -0700 (PDT) Received: by 10.223.81.66 with HTTP; Tue, 5 Apr 2011 18:24:56 -0700 (PDT) In-Reply-To: <4D9BB342.7020607@gmail.com> References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <20110405152025.26ba8f77@hikaru.localdomain> <4D9B4586.9080004@gmail.com> <4D9B73D5.4000809@gmail.com> <4D9B8ADA.9000106@gmail.com> <4D9B937C.1040403@gmail.com> <4D9B9D4A.7050006@gmail.com> <4D9BB342.7020607@gmail.com> Date: Tue, 5 Apr 2011 21:24:56 -0400 Message-ID: From: Izzy Alanis To: Dzonatas Sol Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Cc: vwrap@ietf.org Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 06 Apr 2011 01:23:16 -0000 QWxvbmcgdGhlIGxpbmVzIG9mIGRvY3VtZW50YXRpb24uLi4gYXJlIHdlIHNhbHZhZ2luZyB0aGUg bGFzdCBkcmFmdAppbnRybyBkb2Mgb3Igc2NyYXBwaW5nIGl0PyBJZiB3ZSdyZSBzY3JhcHBpbmcg aXQsIHdoYXQgYWJvdXQgaXQgZGlkbid0CndlIGxpa2UsIHdoYXQgYWJvdXQgaXQgd2FzIGdvb2Q/ IFRoZSB3b3JrIG9uIHNob3JpbmcgdXAgZGVmaW5pdGlvbnMgaXMKZGlyZWN0bHkgYXBwbGljYWJs ZSB0byB0aGUgaW50cm8gZG9jLCBidXQgdGhlIG1pbnV0ZSBkZXRhaWxzIG9mIGFzc2V0CmFkZHJl c3NhYmlsaXR5IGFuZCBjYWNoZWFiaWxpdHkgYXJlIGxlYWRpbmcgdXMgZG93biBhIHJhdCBob2xl IC0tIGl0J3MKaW50ZXJlc3RpbmcgY29udmVyc2F0aW9uLCBidXQganVzdCBub3QgcHJvZHVjdGl2 ZSByaWdodCBub3cuCgpUb3dhcmQgQ2FybG8ncyBtaXNzaW9uIG9mICdmbGV4aWJpbGl0eSBmaXJz dCc6IGhvdyB3b3VsZCBhIHN0YXRlbWVudAphYm91dCB0aGUgZmxleGliaWxpdHkgb2YgdGhlIHBy b3RvY29sIGFwcGVhciBpbiBzdWNoIGEgZG9jdW1lbnQ/CgotIEl6enkKCgpPbiBUdWUsIEFwciA1 LCAyMDExIGF0IDg6MjYgUE0sIER6b25hdGFzIFNvbCA8ZHpvbmF0YXNAZ21haWwuY29tPiB3cm90 ZToKPiBXZSB3ZXJlIGFuZCBzdGlsbCBhcmUgaW4gZGlzY3Vzc2lvbiBhYm91dCBWV1JBUCBkb2N1 bWVudHMuCj4KPiBBcyBzb21lb25lIHRoYXQgaW1wbGVtZW50cywgdGhleSBkb24ndCB3YW50IHRv IHJlYWQgYW55dGhpbmcgbGlrZSAibWFueQo+IG9yZGVycyBvZiBtYWduaXR1ZGUiIG9yICJ0aGUg YmVzdCBpZGVhIiBvciBzdWNoIGV4YWdnZXJhdGVkIGFkamVjdGl2ZXMuCj4gRG9uJ3QgZXhwZWN0 IHlvdXIgaWRlYXMgZXZlciB0byBnZXQgaW1wbGVtZW50ZWQgYmFzZWQgb24gc3VjaCBsYW5ndWFn ZS4KPgo+IE5lZWQganVzdCB0aGUgZmFjdHMsIGFuZCB0aGUgZG9jdW1lbnRzLiBQbGVhc2UsIHN0 b3Agd2l0aCBob3cgZ3JlYXQgeW91Cj4gdGhpbmsgeW91ciBpZGVhIGlzIGFuZCBwcm9kdWNlIHRo ZSBkb2N1bWVudHMhIFBsZWFzZSBpbmNsdWRlIHNwZWNpZmljIHVzZSBvZgo+IHRoZSByZXNvdXJj ZXMsIExMSURMLCBEU0QsIGV0Yy4KPgo+IElmIHRoaXMgY29udGludWVzIHRvIGJlIGp1c3QgZGlz Y3Vzc2lvbiBhbmQgbmVpdGhlciBkb2N1bWVudGF0aW9uIG5vcgo+IGltcGxlbWVudGF0aW9uIHRo YW4gSSdtIHdpdGggdGhlIGNoYWlyKHMpIHRvIGRpc2JhbmQuCj4KPiBNb3JnYWluZSB3cm90ZToK Pj4KPj4gVGhlIGFzc2V0IGZldGNoIHBlcmZvcm1hbmNlIGdhaW4gb2YgYSBwcm90b2NvbCBpbiB3 aGljaCBhc3NldCBpZGVudGlmaWVycwo+PiBtYWtlIGNyb3NzLXdvcmxkIGFzc2V0cyBjYWNoZWFi bGUgdmVyc3VzIGEgcHJvdG9jb2wgd2hvc2UgYXNzZXQgaWRlbnRpZmllcnMKPj4gZG8gbm90IGFs bG93IHRoaXMgaXMgYW4gZXh0cmVtZWx5IGxhcmdlIGZhY3RvciBvZiAqbWFueSBvcmRlcnMgb2Yg bWFnbml0dWRlKgo+PiBvbiBhbGwgYnV0IHRoZSBmaXJzdCBvY2N1cnJlbmNlIG9mIGFuIGFzc2V0 LiDCoEZvciBhbGwgaW50ZW50cyBhbmQgcHVycG9zZXMsCj4+IGF2b2lkaW5nIHRoZSBuZWVkIHRv IGZldGNoIGFuIGFzc2V0IG92ZXIgdGhlIG5ldHdvcmsgcmVwcmVzZW50cyBhIGdhaW4gb2YKPj4g aW5maW5pdHksIGFuZCB0aGlzIGdhaW4gbWF5IGJlIHJlcGVhdGVkIG1hbnkgdGltZXMgb3Zlci4K Pj4KPj4gSSB0aGluayBpdCdzIHByZXR0eSB1bmNvbnRlc3RhYmxlIHRoYXQgZ2l2aW5nIFZXUkFQ IGFuIGFzc2V0IGFkZHJlc3NpbmcKPj4gc2NoZW1lIHdoaWNoIGlzIG9yZGVycyBvZiBtYWduaXR1 ZGUgbW9yZSBlZmZpY2llbnQgdGhhbiBhbnkgb3RoZXIgc2NoZW1lCj4+IHRoYXQgaGFzIHlldCBi ZWVuIHByb3Bvc2VkIHdvdWxkIGJlIGFuIGltcG9ydGFudCBiZW5lZml0IGZvciB0aGUgcHJvdG9j b2wsCj4+IGFuZCBoaWdobHkgbGlrZWx5IHRvIG1ha2UgaXQgcG9wdWxhci4gwqBDb252ZXJzZWx5 LCBpZiBpdCBsYWNrcyB0aGlzIGJlbmVmaXQKPj4gdGhlbiBhbm90aGVyIHByb3RvY29sIHdpbGwg dXNlIGl0IGFuZCB3aWxsIGh1Z2VseSBvdXQtcGVyZm9ybSBWV1JBUC4KPj4KPj4gV2Ugd2VyZSB0 YWxraW5nIGFib3V0IGRlc2lnbmluZyBmb3IgdGhlIGZ1dHVyZS4gwqBIYXNoLWJhc2VkIGFzc2V0 Cj4+IGFkZHJlc3NpbmcgaXMgYSBjYXNlIGluIHBvaW50LCBhbmQgaG93IHdlIGhhbmRsZSB0aGlz IHByb3Bvc2FsIGlzIGFwcGFyZW50bHkKPj4gb3VyIGZpcnN0IHRlc3QgY2FzZS4KPj4KPj4KPj4g TW9yZ2FpbmUuCj4+Cj4+Cj4+Cj4+Cj4+Cj4+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KPj4KPj4KPj4gT24gVHVlLCBBcHIgNSwgMjAxMSBhdCAxMTo1MiBQTSwgRHpvbmF0YXMgU29s IDxkem9uYXRhc0BnbWFpbC5jb20KPj4gPG1haWx0bzpkem9uYXRhc0BnbWFpbC5jb20+PiB3cm90 ZToKPj4KPj4gwqAgwqBBbmQuLi4gc3RpbGwgbG9jYWwgY2FjaGUuLiBub3QgdndyYXAuCj4+Cj4+ IMKgIMKgSSB0aGluayBpdCB3b3VsZCBiZSBtb3JlIHdpc2UgdG8gZ28gd2l0aCB0aGUgaW1wbGVt ZW50YXRpb25zIG9mCj4+IMKgIMKgR29vZ2xlJ3MgYW5kL29yIFNpZW1lbnMgb2JqZWN0IGlkZW50 aWZpY2F0aW9uIHRvIFJGSUQgY29kZXMuIEF0Cj4+IMKgIMKgbGVhc3Qgd2Uga25vdyB0aGlzIHBh cnQgd29uJ3QgZXhwbG9pdCBjb250ZW50Lgo+Pgo+PiDCoCDCoEl0IGhhcyBmdXJ0aGVyIGFkdmFu dGFnZXMgdGhhbiBqdXN0IHRoYXQuIEkgd2VudCBpbnRvIGRldGFpbAo+PiDCoCDCoGF3aGlsZSBh Z28sIHlldCB3aXRoIGJhc2ljIFFNOgo+Pgo+PiDCoGh0dHA6Ly9pY3lzcGhlcmljYWwuYmxvZ3Nw b3QuY29tLzIwMTAvMDcvb3B0aW1pemluZy1zaW11bGF0aW9ucy13aXRoLWJhc2ljLmh0bWwKPj4K Pj4gwqAgwqBObywgZXZlbiBnaXZlbiB0aGUgcG9zc2liaWxpdGllcyBwcmVzZW50ZWQsIEkgZG9u J3QgdGhpbmsgeW91cgo+PiDCoCDCoGlkZWEgY29tZXMgY2xvc2UgdG8gYW55dGhpbmcgbmV3IGlu IHJlZ2FyZHMgdG8gdGhlIGJlc3QuIEl0J3MganVzdAo+PiDCoCDCoHlvdXIgcHJlZmVyZW5jZS4K Pj4KPj4gwqAgwqBNb3JnYWluZSB3cm90ZToKPj4KPj4gwqAgwqAgwqAgwqBPbiBUdWUsIEFwciA1 LCAyMDExIGF0IDExOjExIFBNLCBEem9uYXRhcyBTb2wKPj4gwqAgwqAgwqAgwqA8ZHpvbmF0YXNA Z21haWwuY29tIDxtYWlsdG86ZHpvbmF0YXNAZ21haWwuY29tPgo+PiDCoCDCoCDCoCDCoDxtYWls dG86ZHpvbmF0YXNAZ21haWwuY29tIDxtYWlsdG86ZHpvbmF0YXNAZ21haWwuY29tPj4+IHdyb3Rl Ogo+Pgo+Pgo+PiDCoCDCoCDCoCDCoCDCoCBZb3VyIGFwcHJvYWNoLCBiZXNpZGVzIGV4cGxvaXRh dGlvbnMsIGhhcyB0aGUgdHlwaWNhbAo+PiDCoCDCoCDCoCDCoHByb2JsZW0gdG8KPj4gwqAgwqAg wqAgwqAgwqAgYXNzdW1lIGFzc2V0IElEcyBhcmUgb25seSBuZWVkZWQgYW5kIGFyZSBoYXNoLWFi bGUuCj4+Cj4+Cj4+Cj4+IMKgIMKgIMKgIMKgQXNzZXQgSURzIGFyZSBub3QgaGFzaC1hYmxlLCBp dCBpcyB0aGUgYXNzZXQgZGF0YSB0aGF0IGlzCj4+IMKgIMKgIMKgIMKgaGFzaGVkLiDCoFRoZSBh c3NldCBpZGVudGlmaWVyIGlzIHRoZSBoYXNoIG9mIHRoZSBhc3NldCBkYXRhCj4+IMKgIMKgIMKg IMKgdXNpbmcgYSBkZWZpbmVkIGhhc2ggZGlnZXN0IGFsZ29yaXRobS4gwqBUaGUgYXNzZXQgaWRl bnRpZmllcgo+PiDCoCDCoCDCoCDCoGlzIG5vdCBndWVzc2FibGUgdW5sZXNzIHlvdSBhbHJlYWR5 IGhhdmUgYWNjZXNzIHRvIHRoZSBhc3NldC4KPj4KPj4KPj4gwqAgwqAgwqAgwqBNb3JnYWluZS4K Pj4KPj4KPj4KPj4KPj4gwqAgwqAgwqAgwqA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PQo+ Pgo+Pgo+Pgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCA9PT09PT09PT09PT09PT09PT0KPj4KPj4g wqAgwqAgwqAgwqAgwqAgwqAgwqAgT24gVHVlLCBBcHIgNSwgMjAxMSBhdCAxMDozNCBQTSwgRHpv bmF0YXMgU29sCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIDxkem9uYXRhc0BnbWFpbC5jb20gPG1h aWx0bzpkem9uYXRhc0BnbWFpbC5jb20+Cj4+IMKgIMKgIMKgIMKgPG1haWx0bzpkem9uYXRhc0Bn bWFpbC5jb20gPG1haWx0bzpkem9uYXRhc0BnbWFpbC5jb20+Pgo+PiDCoCDCoCDCoCDCoCDCoCDC oCDCoCA8bWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbSA8bWFpbHRvOmR6b25hdGFzQGdtYWlsLmNv bT4KPj4gwqAgwqAgwqAgwqA8bWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbSA8bWFpbHRvOmR6b25h dGFzQGdtYWlsLmNvbT4+Pj4gd3JvdGU6Cj4+Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg QWdhaW4gTW9yZ2FpbmUsIHlvdXIgYXBwZWFscyBhbG9uZSBkb24ndCBzdXBwb3J0Cj4+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIHRoZW1zZWx2ZXMsIGFuZAo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHlvdXIgcmlkaWN1bGUgaXMgdW53ZWxjb21lLiBJZiB5b3UgY2FuIG5vdCBob25lc3RseQo+ PiDCoCDCoCDCoCDCoG1ha2UgYW55Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2VyaW91 cyByZXNwb25zZSwgcGxlYXNlIG1vdmUgb24gYW5kIGRvbid0IHJlcGx5IHRvIG15Cj4+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIHBvc3RzIGp1c3QKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0 byBmdXJ0aGVyIHJpZGljdWxlLiBJdCdzIHZlcnkgUlVERS4KPj4KPj4gwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBJZiB5b3UgaGF2ZSBhbnkgaW1wbGVtZW50YXRpb24gb2YgeW91ciBoYXNoLWJh c2VkCj4+IMKgIMKgIMKgIMKgaWRlYSBvcgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhY3R1YWwK Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0ZWNobmljYWwgZGV0YWlsZWQgZG9jdW1lbnRh dGlvbiByZWFkeSBmb3IKPj4gwqAgwqAgwqAgwqBpbXBsZW1lbnRhdGlvbiwgdGhlbgo+PiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoGludHJvZHVjZSBpdC4gVW50aWwgdGhlbiwgaXQncyBzdHVj ayBpbiB5b3VyIGhlYWQsCj4+IMKgIMKgIMKgIMKgYW5kIHNvdW5kcwo+PiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoG90aGVyJ3MgaWRlYXMganVzdCB3aXRoIHlvdXIgbmFtZSBvbiBpdC4gUGx1 cwo+PiDCoCDCoCDCoCDCoHNlY3VyaXR5IGJ5Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg b2JzY3VyaXR5IG1ha2VzIGl0IGFzIG1vb3QgcG9pbnQuCj4+Cj4+IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgRG9jdW1lbnRhdGlvbi4uLiA/Cj4+Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgUmVtZW1iZXIgcGVvcGxlIHRyaWVkIHRvIHRha2Ugb25lIHRlbXAgdmFyaWFibGUgYXdheQo+ PiDCoCDCoCDCoCDCoGZyb20gdGhlCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgSlBFRzIw MDAgaW50IG11bHRpcGxlL2RpdmlkZSByb3V0aW5lIGJlY2F1c2UgdGhlCj4+IMKgIMKgIMKgIMKg aWRlYSBpdCBsb29rcwo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGdvb2QgKG9uIHBhcGVy KSB3aXRoIG9uZSBsZXNzIHZhcmlhYmxlLiBBY3R1YWwKPj4gwqAgwqAgwqAgwqBpbXBsZW1lbnRh dGlvbgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHJldmVhbHMsIHdpdGggdGltZWQgdGVz dHMsIGl0IGlzIHNsb3dlciB3aGVuIGFueWJvZHkKPj4gwqAgwqAgwqAgwqB0YWtlcyBhd2F5Cj4+ IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdGhhdCBvbmUgdGVtcCB2YXJpYWJsZS4KPj4KPj4g wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBNb3JnYWluZSB3cm90ZToKPj4KPj4gwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBVbmZvcnR1bmF0ZWx5IHlvdXIgcmVzcG9uc2Ugd2FzIGRl dm9pZCBvZiB0ZWNobmljYWwKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgY29udGVudCwKPj4gwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBEem9uYXRhcy4KPj4KPj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBJZiB5b3UgaGF2ZSBzb21ldGhpbmcgdGVjaG5pY2FsIHRvIHNh eSBhYm91dAo+PiDCoCDCoCDCoCDCoGhhc2gtYmFzZWQKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBhZGRyZXNzaW5nLCBJIHdvdWxkIGxvdmUgdG8gaGVhciBpdC4KPj4KPj4gwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBJIGhhdmUgZGV0YWlsZWQgaW4gc29tZSBkZXB0 aCB0aGUgbWFueSBiZW5lZml0cyBvZgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBoYXNoLWJhc2Vk Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYWRkcmVzc2luZyBpbiB0aGUgYXJ0 aWNsZSBJIGxpbmtlZCwgYW5kCj4+IMKgIMKgIMKgIMKgc3Vic2VxdWVudGx5LiDCoElmCj4+IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgb3RoZXIgZ29vZCBzY2hlbWVzIGV4aXN0LCB3 ZSBzaG91bGQgb2YgY291cnNlCj4+IMKgIMKgIMKgIMKgYW5hbHl6ZQo+PiDCoCDCoCDCoCDCoCDC oCDCoCDCoCB0aGVtIGZvcgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRlY2hu aWNhbCBtZXJpdCBhbmQgY29tcGFyZSB0aGVpciBiZW5lZml0cwo+PiDCoCDCoCDCoCDCoGFnYWlu c3QgdGhvc2Ugb2YKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBoYXNoLWJhc2Vk IGFkZHJlc3NpbmcuCj4+Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgVGhhdCdz IHRoZSBlbmdpbmVlcmluZyBwcm9jZXNzIGZvciBtYWtpbmcgVldSQVAKPj4gwqAgwqAgwqAgwqBh cyBnb29kCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFzIGl0Cj4+IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgY2FuIGJlLgo+Pgo+Pgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoE1vcmdhaW5lLgo+Pgo+Pgo+Pgo+Pgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoD09PT09PT09PT09PT09PT09PT09PT09PT0KPj4KPj4gwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqBPbiBUdWUsIEFwciA1LCAyMDExIGF0IDg6NTYgUE0sIER6b25hdGFzIFNv bAo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDxkem9uYXRhc0BnbWFpbC5jb20g PG1haWx0bzpkem9uYXRhc0BnbWFpbC5jb20+Cj4+IMKgIMKgIMKgIMKgPG1haWx0bzpkem9uYXRh c0BnbWFpbC5jb20gPG1haWx0bzpkem9uYXRhc0BnbWFpbC5jb20+Pgo+PiDCoCDCoCDCoCDCoCDC oCDCoCDCoCA8bWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbSA8bWFpbHRvOmR6b25hdGFzQGdtYWls LmNvbT4KPj4gwqAgwqAgwqAgwqA8bWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbSA8bWFpbHRvOmR6 b25hdGFzQGdtYWlsLmNvbT4+Pgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDxt YWlsdG86ZHpvbmF0YXNAZ21haWwuY29tCj4+IMKgIMKgIMKgIMKgPG1haWx0bzpkem9uYXRhc0Bn bWFpbC5jb20+IDxtYWlsdG86ZHpvbmF0YXNAZ21haWwuY29tCj4+IMKgIMKgIMKgIMKgPG1haWx0 bzpkem9uYXRhc0BnbWFpbC5jb20+Pgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8bWFpbHRvOmR6 b25hdGFzQGdtYWlsLmNvbSA8bWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbT4KPj4gwqAgwqAgwqAg wqA8bWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbSA8bWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbT4+ Pj4+IHdyb3RlOgo+Pgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBNb3Jn YWluZSwgd2UgbW9vdGVkIHlvdXIgaGFzaC1iYXNlZCBpZGVhLgo+PiDCoCDCoCDCoCDCoFRoaXMg ZG9lcwo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBub3RoaW5nIHRvCj4+IMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGhlbHAgaW1wbGVtZW50IGFzc2V0IHNlcnZpY2VzLiBUaGUg b25seQo+PiDCoCDCoCDCoCDCoHNpZ25pZmljYW50Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHBv aW50Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgeW91IG1hZGUKPj4gwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXMgc29tZSBleHByZXNzaW9uIGZvciBvcHRp bWl6YXRpb24sIG5vdCBjb3JyZWN0Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZ1bmN0aW9uYWxp dHksCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdoaWNoIGlzIG5lZWRl ZCBmaXJzdAo+Pgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBBcyBmb3Ig eW91ciBvdGhlciB0d28sIHdlIGNhbiBzdW1tYXJpemUgdGhvc2UKPj4gwqAgwqAgwqAgwqB3aXRo Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHB1YmxpYwo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCByZXNvdXJjZXMgYW5kIGZsb3cgKGZvcndhcmQvcmV2ZXJzZSkuIEFueSBt b3JlCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNwZWNpZmljIG5ldHdvcmsKPj4gwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdG9wb2xvZ3kgdGhhbiB0aGF0IG9ubHkgbWFrZXMg aXQgaGFyZGVyIHRvCj4+IMKgIMKgIMKgIMKgYWRkcmVzcy4gVGhlCj4+IMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgb25seSB0aGluZwo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB0byB3b3JyeSBhYm91dCBpcyBhbHJlYWR5IGN1c3RvbSByZXNvdXJjZXMKPj4g wqAgwqAgwqAgwqB0aGF0IG92ZXJsYXAKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqB3aXRoIG5ld2VyCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHB1Ymxp YyByZXNvdXJjZXMuCj4+Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE1v cmdhaW5lIHdyb3RlOgo+Pgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBPbiBUdWUsIEFwciA1LCAyMDExIGF0IDU6MzggUE0sIER6b25hdGFzIFNvbAo+PiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8ZHpvbmF0YXNAZ21haWwuY29t Cj4+IMKgIMKgIMKgIMKgPG1haWx0bzpkem9uYXRhc0BnbWFpbC5jb20+IDxtYWlsdG86ZHpvbmF0 YXNAZ21haWwuY29tCj4+IMKgIMKgIMKgIMKgPG1haWx0bzpkem9uYXRhc0BnbWFpbC5jb20+Pgo+ PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8bWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbSA8bWFpbHRv OmR6b25hdGFzQGdtYWlsLmNvbT4KPj4gwqAgwqAgwqAgwqA8bWFpbHRvOmR6b25hdGFzQGdtYWls LmNvbSA8bWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbT4+Pgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoDxtYWlsdG86ZHpvbmF0YXNAZ21haWwuY29tCj4+IMKgIMKgIMKgIMKgPG1h aWx0bzpkem9uYXRhc0BnbWFpbC5jb20+IDxtYWlsdG86ZHpvbmF0YXNAZ21haWwuY29tCj4+IMKg IMKgIMKgIMKgPG1haWx0bzpkem9uYXRhc0BnbWFpbC5jb20+Pgo+PiDCoCDCoCDCoCDCoCDCoCDC oCDCoCA8bWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbSA8bWFpbHRvOmR6b25hdGFzQGdtYWlsLmNv bT4KPj4gwqAgwqAgwqAgwqA8bWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbSA8bWFpbHRvOmR6b25h dGFzQGdtYWlsLmNvbT4+Pj4KPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgPG1haWx0bzpkem9uYXRhc0BnbWFpbC5jb20KPj4gwqAgwqAgwqAgwqA8bWFpbHRvOmR6 b25hdGFzQGdtYWlsLmNvbT4KPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgPG1haWx0bzpkem9uYXRh c0BnbWFpbC5jb20gPG1haWx0bzpkem9uYXRhc0BnbWFpbC5jb20+Pgo+PiDCoCDCoCDCoCDCoDxt YWlsdG86ZHpvbmF0YXNAZ21haWwuY29tIDxtYWlsdG86ZHpvbmF0YXNAZ21haWwuY29tPgo+PiDC oCDCoCDCoCDCoCDCoCDCoCDCoCA8bWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbSA8bWFpbHRvOmR6 b25hdGFzQGdtYWlsLmNvbT4+Pgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDxt YWlsdG86ZHpvbmF0YXNAZ21haWwuY29tCj4+IMKgIMKgIMKgIMKgPG1haWx0bzpkem9uYXRhc0Bn bWFpbC5jb20+IDxtYWlsdG86ZHpvbmF0YXNAZ21haWwuY29tCj4+IMKgIMKgIMKgIMKgPG1haWx0 bzpkem9uYXRhc0BnbWFpbC5jb20+Pgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8bWFpbHRvOmR6 b25hdGFzQGdtYWlsLmNvbSA8bWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbT4KPj4gwqAgwqAgwqAg wqA8bWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbSA8bWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbT4+ Pj4+PiB3cm90ZToKPj4KPj4KPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBEbyB5b3UgdGhpbmsgd2UgYXJlIHJlYWR5IHRvIGltcGxlbWVudAo+PiDCoCDC oCDCoCDCoHNvbWUgYXNzZXQKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzZXJ2 aWNlcyBub3csCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgd2l0aC93aXRob3V0IGNvbXBsZXRlIGRvY3VtZW50YXRpb24/Cj4+Cj4+IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgV2hhdCBtb3JlIGRvIHlvdSB0aGlu ayBpcyBuZWVkZWQ/Cj4+Cj4+Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIFR3byBvciB0aHJlZSB0aGluZ3Mgc2VlbSB0byBiZSBuZWVkZWQ6Cj4+Cj4+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKiBEZWZpbmluZyB0aGUg YXNzZXQgYWRkcmVzc2luZwo+PiDCoCDCoCDCoCDCoGNvbmNlcHQgaXMgYW4KPj4gwqAgwqAgwqAg wqAgwqAgwqAgwqAgZXh0cmVtZWx5Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGltcG9ydGFudAo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoG1hdHRlciwgYWxtb3N0IGNlcnRhaW5seSB0aGUgbW9zdAo+PiDCoCDC oCDCoCDCoGltcG9ydGFudAo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBtYXR0ZXIKPj4gwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBvZiBhbGwsCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYmVjYXVzZSB0aGF0IGRldGVybWluZXMgaG93 IHJvYnVzdCBhbmQKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgc2NhbGFibGUgb3VyCj4+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdvcmxkcyB3aWxsCj4+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYmUu77+9IEkndmUg YWxyZWFkeSBleGFtaW5lZAo+PiDCoCDCoCDCoCDCoGFsdGVybmF0aXZlcyBmb3IKPj4gwqAgwqAg wqAgwqAgwqAgwqAgwqAgdGhhdAo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGlu IHNvbWUKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGVwdGgs Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYW5k IHRoZSBkZXNpZ24gd2l0aCB0aGUgYmVzdCBlbmdpbmVlcmluZwo+PiDCoCDCoCDCoCDCoCDCoCDC oCDCoCBwcm9wZXJ0aWVzIHNvCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGZhciBzZWVtcwo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoHRvIGJlIHVuaXZlcnNhbCBoYXNoLWJhc2VkCj4+IMKgIMKgIMKgIMKgYWRk cmVzc2luZy7vv70gSSBmaXJzdAo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGRl c2NyaWJlZAo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGF0 Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYXBw cm9hY2ggb24gdGhlIGxpc3QgaGVyZSAtLS0KPj4KPj4gwqBodHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvdndyYXAvY3VycmVudC9tc2cwMDQ2My5odG1sCj4+IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgLCBhbmQgcmVmZXJyZWQgdG8g aXQgaW4gdmFyaW91cwo+PiDCoCDCoCDCoCDCoHN1YnNlcXVlbnQKPj4gwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqBkaXNjdXNzaW9ucy4KPj4KPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIERlZmluaW5nIHRoZSBkYXRhIGZsb3dzIGJldHdl ZW4gcmVnaW9ucywKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgY2xpZW50cywKPj4gwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhbmQgYXNzZXQKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzZXJ2aWNlcyBhbmQgd2hpY2ggcGFyYW1ldGVy cwo+PiDCoCDCoCDCoCDCoGNvbnRyb2wgdGhlIGZsb3dzCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgbmVlZHMgdG8KPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgYmUgZG9uZQo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoGJlZm9yZSBhIHRlc3QgYXNzZXQgc2VydmljZSBjYW4gYmUKPj4gwqAgwqAg wqAgwqAgwqAgwqAgwqAgaW1wbGVtZW50ZWQu77+9Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgV2l0aG91dAo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB0aGF0LAo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoGFuIGFzc2V0IHNlcnZpY2UgaXMganVzdCBhCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKg IG5ldHdvcmstYWNjZXNzaWJsZSBzdG9yYWdlCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHNlcnZpY2UsCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgbm90IGFuIGFzc2V0IHNlcnZpY2UgaW4gdGhlIFZXUkFQCj4+ IMKgIMKgIMKgIMKgc2Vuc2Uu77+9Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIE5ldHdvcmsKPj4g wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzdG9yYWdlCj4+IMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2VydmljZXMgZXhpc3QgYWxyZWFk eSwgc28ganVzdAo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpbXBsZW1lbnRpbmcgb25lCj4+IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgb2YgdGhvc2UKPj4gwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgd291bGQKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBub3QgYWR2YW5jZSBWV1JBUC4KPj4KPj4gwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqIFdlIG5lZWQgdG8g ZXhhbWluZSBob3cgdmFyaW91cwo+PiDCoCDCoCDCoCDCoGRlcGxveW1lbnQKPj4gwqAgwqAgwqAg wqAgwqAgwqAgwqAgcGF0dGVybnMKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB3 aWxsCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHVzZSB0aGUK Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhc3Nl dCBzZXJ2aWNlcywgYW5kIGhvdyB0aGUKPj4gwqAgwqAgwqAgwqAvbXVsdGlwbGUvIGFzc2V0Cj4+ IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2VydmljZXMgdGhhdAo+PiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGludGVyb3AgaW50cm9k dWNlcyBhcmUgaGFuZGxlZC7vv70gSSBhbQo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3b3JraW5n IG9uIHRoaXMKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY3Vy cmVudGx5Lgo+Pgo+Pgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBOb25lIG9mIHRoZSBhYm92ZSBpcyBwYXJ0aWN1bGFybHkgaGFyZC7vv70KPj4gwqAgwqAgwqAg wqBJIHRoaW5rIGl0Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgd29uJ3QgYmUK Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbG9uZyBiZWZvcmUg d2UgaGF2ZSBhIHNjaGVtZSB3b3JrZWQgb3V0Cj4+IMKgIMKgIMKgIMKgYW5kIGFyZQo+PiDCoCDC oCDCoCDCoCDCoCDCoCDCoCByZWFkeQo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oGZvciBzb21lCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlt cGxlbWVudGF0aW9uIHdvcmsuCj4+Cj4+Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIE1vcmdhaW5lLgo+Pgo+Pgo+Pgo+Pgo+Pgo+PiDCoC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQo+Pgo+Pgo+Pgo+Pgo+PiDCoF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHZ3 cmFwIG1haWxpbmcgbGlzdAo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB2d3JhcEBpZXRmLm9yZyA8bWFpbHRvOnZ3cmFwQGlldGYub3JnPgo+PiDCoCDCoCDCoCDC oDxtYWlsdG86dndyYXBAaWV0Zi5vcmcgPG1haWx0bzp2d3JhcEBpZXRmLm9yZz4+Cj4+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIDxtYWlsdG86dndyYXBAaWV0Zi5vcmcgPG1haWx0bzp2d3JhcEBpZXRm Lm9yZz4KPj4gwqAgwqAgwqAgwqA8bWFpbHRvOnZ3cmFwQGlldGYub3JnIDxtYWlsdG86dndyYXBA aWV0Zi5vcmc+Pj4KPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqA8bWFpbHRvOnZ3 cmFwQGlldGYub3JnIDxtYWlsdG86dndyYXBAaWV0Zi5vcmc+Cj4+IMKgIMKgIMKgIMKgPG1haWx0 bzp2d3JhcEBpZXRmLm9yZyA8bWFpbHRvOnZ3cmFwQGlldGYub3JnPj4KPj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgPG1haWx0bzp2d3JhcEBpZXRmLm9yZyA8bWFpbHRvOnZ3cmFwQGlldGYub3JnPgo+ PiDCoCDCoCDCoCDCoDxtYWlsdG86dndyYXBAaWV0Zi5vcmcgPG1haWx0bzp2d3JhcEBpZXRmLm9y Zz4+Pj4KPj4KPj4KPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92d3JhcAo+PiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoC0tIMKgIMKgIC0tLQo+PiBodHRwczovL3R3aXR0ZXIuY29tL0R6b25hdGFzX1Nv bCAtLS0KPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgV2ViIERldmVsb3Bt ZW50LCBTb2Z0d2FyZSBFbmdpbmVlcmluZywKPj4gwqAgwqAgwqAgwqBWaXJ0dWFsIFJlYWxpdHks Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgQ29uc3VsdGFudAo+Pgo+Pgo+Pgo+ PiDCoC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQo+Pgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdndyYXAgbWFpbGluZyBsaXN0Cj4+IMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdndyYXBAaWV0Zi5vcmcgPG1haWx0bzp2d3JhcEBpZXRm Lm9yZz4KPj4gwqAgwqAgwqAgwqA8bWFpbHRvOnZ3cmFwQGlldGYub3JnIDxtYWlsdG86dndyYXBA aWV0Zi5vcmc+Pgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8bWFpbHRvOnZ3cmFwQGlldGYub3Jn IDxtYWlsdG86dndyYXBAaWV0Zi5vcmc+Cj4+IMKgIMKgIMKgIMKgPG1haWx0bzp2d3JhcEBpZXRm Lm9yZyA8bWFpbHRvOnZ3cmFwQGlldGYub3JnPj4+Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92d3JhcAo+Pgo+ PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoC0tIMKgIMKgIC0tLSBodHRwczovL3R3aXR0ZXIu Y29tL0R6b25hdGFzX1NvbCAtLS0KPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBXZWIgRGV2 ZWxvcG1lbnQsIFNvZnR3YXJlIEVuZ2luZWVyaW5nLCBWaXJ0dWFsIFJlYWxpdHksCj4+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIENvbnN1bHRhbnQKPj4KPj4KPj4KPj4gwqAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K Pj4KPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgdndyYXAgbWFpbGluZyBs aXN0Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHZ3cmFwQGlldGYub3JnIDxtYWlsdG86dndyYXBA aWV0Zi5vcmc+Cj4+IMKgIMKgIMKgIMKgPG1haWx0bzp2d3JhcEBpZXRmLm9yZyA8bWFpbHRvOnZ3 cmFwQGlldGYub3JnPj4KPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92d3JhcAo+Pgo+Pgo+PiDCoCDCoCDCoCDCoCDCoCAtLSDCoCDC oCAtLS0gaHR0cHM6Ly90d2l0dGVyLmNvbS9Eem9uYXRhc19Tb2wgLS0tCj4+IMKgIMKgIMKgIMKg IMKgIFdlYiBEZXZlbG9wbWVudCwgU29mdHdhcmUgRW5naW5lZXJpbmcsIFZpcnR1YWwgUmVhbGl0 eSwKPj4gwqAgwqAgwqAgwqBDb25zdWx0YW50Cj4+Cj4+Cj4+Cj4+IMKgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Cj4+Cj4+IMKgIMKgIMKgIMKgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KPj4gwqAgwqAgwqAgwqB2d3JhcCBtYWlsaW5nIGxpc3QKPj4gwqAgwqAgwqAgwqB2 d3JhcEBpZXRmLm9yZyA8bWFpbHRvOnZ3cmFwQGlldGYub3JnPgo+PiDCoCDCoCDCoCDCoGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdndyYXAKPj4KPj4KPj4KPj4gwqAgwqAt LSDCoCDCoCAtLS0gaHR0cHM6Ly90d2l0dGVyLmNvbS9Eem9uYXRhc19Tb2wgLS0tCj4+IMKgIMKg V2ViIERldmVsb3BtZW50LCBTb2Z0d2FyZSBFbmdpbmVlcmluZywgVmlydHVhbCBSZWFsaXR5LCBD b25zdWx0YW50Cj4+Cj4+Cj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Pgo+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiB2d3JhcCBtYWlsaW5nIGxpc3QKPj4g dndyYXBAaWV0Zi5vcmcKPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92 d3JhcAo+Pgo+Cj4KPiAtLQo+IC0tLSBodHRwczovL3R3aXR0ZXIuY29tL0R6b25hdGFzX1NvbCAt LS0KPiBXZWIgRGV2ZWxvcG1lbnQsIFNvZnR3YXJlIEVuZ2luZWVyaW5nLCBWaXJ0dWFsIFJlYWxp dHksIENvbnN1bHRhbnQKPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCj4gdndyYXAgbWFpbGluZyBsaXN0Cj4gdndyYXBAaWV0Zi5vcmcKPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Z3cmFwCj4K From morgaine.dinova@googlemail.com Tue Apr 5 19:10:24 2011 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 0465F3A683E for ; Tue, 5 Apr 2011 19:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[AWL=-0.663, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 X9Xr9S2pbiwq for ; Tue, 5 Apr 2011 19:10:21 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id BB8F03A683B for ; Tue, 5 Apr 2011 19:10:20 -0700 (PDT) Received: by qyk7 with SMTP id 7so650995qyk.10 for ; Tue, 05 Apr 2011 19:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=OSqY7ABiLWXVCBkhSnfW3gu/t1zdLd7DtldONuzEAw8=; b=hwEZaVTHawT88wzwii/DT7hlFUti6NgsfV7+bJwP9mFx1A2/H5LOuxRm5dkwkPxAmP xZFaSDD2fRnVOc05yE65382jURFFE4Z+isWUmA9wJM94hx+GZo+1G/X2vxnjA4z5n3+K w/OMvR8s8/kMBVrPuBe21PIA01Mc2Kpb8SGU8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Il2rVx8OdU2Qdkw2F8k3ZpVFC5PidRdnk72efvnlyMYB5O0+IVAvvNNZCFmWeD+3Q2 l2Tuji+W6+nL3K5PCPiwWnOfXkiH6gnKQhOhv3SerZsg1x603Dg8bSIX+gh47KfeoDKb +YMOC2bNZvlYuToL1BmmchbW5KPSSm1aZIIs0= MIME-Version: 1.0 Received: by 10.224.75.21 with SMTP id w21mr290825qaj.272.1302055923568; Tue, 05 Apr 2011 19:12:03 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Tue, 5 Apr 2011 19:12:03 -0700 (PDT) In-Reply-To: References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <20110405152025.26ba8f77@hikaru.localdomain> <4D9B4586.9080004@gmail.com> <4D9B73D5.4000809@gmail.com> <4D9B8ADA.9000106@gmail.com> <4D9B937C.1040403@gmail.com> <4D9B9D4A.7050006@gmail.com> <4D9BB342.7020607@gmail.com> Date: Wed, 6 Apr 2011 03:12:03 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016367d4f04cd50cb04a036841b Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 06 Apr 2011 02:10:24 -0000 --0016367d4f04cd50cb04a036841b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm not sure at what stage you joined us Izzy, but support for flexibility and extensibility in the protocol has been preached by us regularly throughout the entire lifetime of the MMOX, OGPX and now VWRAP groups, so it's nothing new, really. It could be said to have been lip service before though, seeing as no new features ever materialized from it. The only significant difference now is that Carlo has tried to turn that li= p service into an agreed process for promoting proposals that are aimed at providing extra flexibility and extensibility. The fact that this idea hasn't received much support is a bit worrying. It wouldn't matter at all if the group was by its nature strongly focused o= n creating a protocol "designed for the future", eagerly selecting the ideas with the best outlook for a massively scaled and buoyant metaverse, a protocol that recognizes that virtual worlds will evolve rapidly once they gain synergy from interoperation. Indeed, Carlo's a priori agreement would then be entirely superfluous. But instead of eagerly welcoming forward-looking proposals with excellent engineering merits, the few we've had so far seem to be greeted with intense resistance and avoidance of technical discussion. It's an uphill struggle. I can see why Carlo was so highly despondent in his last post. Conditions aren't too encouraging at the moment for an advanced, extensible protocol. And perhaps there is no solution. You can't make a horse drink, even when there is plenty of water provided. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Wed, Apr 6, 2011 at 2:24 AM, Izzy Alanis wrote: > Along the lines of documentation... are we salvaging the last draft > intro doc or scrapping it? If we're scrapping it, what about it didn't > we like, what about it was good? The work on shoring up definitions is > directly applicable to the intro doc, but the minute details of asset > addressability and cacheability are leading us down a rat hole -- it's > interesting conversation, but just not productive right now. > > Toward Carlo's mission of 'flexibility first': how would a statement > about the flexibility of the protocol appear in such a document? > > - Izzy > > > On Tue, Apr 5, 2011 at 8:26 PM, Dzonatas Sol wrote: > > We were and still are in discussion about VWRAP documents. > > > > As someone that implements, they don't want to read anything like "many > > orders of magnitude" or "the best idea" or such exaggerated adjectives. > > Don't expect your ideas ever to get implemented based on such language. > > > > Need just the facts, and the documents. Please, stop with how great you > > think your idea is and produce the documents! Please include specific u= se > of > > the resources, LLIDL, DSD, etc. > > > > If this continues to be just discussion and neither documentation nor > > implementation than I'm with the chair(s) to disband. > > > > Morgaine wrote: > >> > >> The asset fetch performance gain of a protocol in which asset > identifiers > >> make cross-world assets cacheable versus a protocol whose asset > identifiers > >> do not allow this is an extremely large factor of *many orders of > magnitude* > >> on all but the first occurrence of an asset. For all intents and > purposes, > >> avoiding the need to fetch an asset over the network represents a gain > of > >> infinity, and this gain may be repeated many times over. > >> > >> I think it's pretty uncontestable that giving VWRAP an asset addressin= g > >> scheme which is orders of magnitude more efficient than any other sche= me > >> that has yet been proposed would be an important benefit for the > protocol, > >> and highly likely to make it popular. Conversely, if it lacks this > benefit > >> then another protocol will use it and will hugely out-perform VWRAP. > >> > >> We were talking about designing for the future. Hash-based asset > >> addressing is a case in point, and how we handle this proposal is > apparently > >> our first test case. > >> > >> > >> 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 > >> > >> > >> On Tue, Apr 5, 2011 at 11:52 PM, Dzonatas Sol >> > wrote: > >> > >> And... still local cache.. not vwrap. > >> > >> I think it would be more wise to go with the implementations of > >> Google's and/or Siemens object identification to RFID codes. At > >> least we know this part won't exploit content. > >> > >> It has further advantages than just that. I went into detail > >> awhile ago, yet with basic QM: > >> > >> > http://icyspherical.blogspot.com/2010/07/optimizing-simulations-with-basi= c.html > >> > >> No, even given the possibilities presented, I don't think your > >> idea comes close to anything new in regards to the best. It's just > >> your preference. > >> > >> Morgaine wrote: > >> > >> On Tue, Apr 5, 2011 at 11:11 PM, Dzonatas Sol > >> > >> >> wrote: > >> > >> > >> Your approach, besides exploitations, has the typical > >> problem to > >> assume asset IDs are only needed and are hash-able. > >> > >> > >> > >> Asset IDs are not hash-able, it is the asset data that is > >> hashed. The asset identifier is the hash of the asset data > >> using a defined hash digest algorithm. The asset identifier > >> is not guessable unless you already have access to the asset. > >> > >> > >> 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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> On Tue, Apr 5, 2011 at 10:34 PM, Dzonatas Sol > >> > >> > > >> > >> >>> wrote= : > >> > >> Again Morgaine, your appeals alone don't support > >> themselves, and > >> your ridicule is unwelcome. If you can not honestly > >> make any > >> serious response, please move on and don't reply to m= y > >> posts just > >> to further ridicule. It's very RUDE. > >> > >> If you have any implementation of your hash-based > >> idea or > >> actual > >> technical detailed documentation ready for > >> implementation, then > >> introduce it. Until then, it's stuck in your head, > >> and sounds > >> other's ideas just with your name on it. Plus > >> security by > >> obscurity makes it as moot point. > >> > >> Documentation... ? > >> > >> Remember people tried to take one temp variable away > >> from the > >> JPEG2000 int multiple/divide routine because the > >> idea it looks > >> good (on paper) with one less variable. Actual > >> implementation > >> reveals, with timed tests, it is slower when anybody > >> takes away > >> that one temp variable. > >> > >> Morgaine wrote: > >> > >> Unfortunately your response was devoid of technic= al > >> content, > >> Dzonatas. > >> > >> If you have something technical to say about > >> hash-based > >> addressing, I would love to hear it. > >> > >> I have detailed in some depth the many benefits o= f > >> hash-based > >> addressing in the article I linked, and > >> subsequently. If > >> other good schemes exist, we should of course > >> analyze > >> them for > >> technical merit and compare their benefits > >> against those of > >> hash-based addressing. > >> > >> That's the engineering process for making VWRAP > >> as good > >> as it > >> can be. > >> > >> > >> 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 > >> > >> On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol > >> > >> > > >> > >> >> > >> >> >> > > >> > >> >>>> > wrote: > >> > >> Morgaine, we mooted your hash-based idea. > >> This does > >> nothing to > >> help implement asset services. The only > >> significant > >> point > >> you made > >> is some expression for optimization, not corre= ct > >> functionality, > >> which is needed first > >> > >> As for your other two, we can summarize those > >> with > >> public > >> resources and flow (forward/reverse). Any more > >> specific network > >> topology than that only makes it harder to > >> address. The > >> only thing > >> to worry about is already custom resources > >> that overlap > >> with newer > >> public resources. > >> > >> Morgaine wrote: > >> > >> On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas S= ol > >> >> >> > > >> > >> >> > >> >> >> > > >> > >> >>> > >> >> > >> > > >> > >> >> > >> >> >> > > >> > >> >>>>> > wrote: > >> > >> > >> Do you think we are ready to implement > >> some asset > >> services now, > >> with/without complete documentation? > >> > >> What more do you think is needed? > >> > >> > >> Two or three things seem to be needed: > >> > >> * Defining the asset addressing > >> concept is an > >> extremely > >> important > >> matter, almost certainly the most > >> important > >> matter > >> of all, > >> because that determines how robust an= d > >> scalable our > >> worlds will > >> be.=EF=BF=BD I've already examined > >> alternatives for > >> that > >> in some > >> depth, > >> and the design with the best > engineering > >> properties so > >> far seems > >> to be universal hash-based > >> addressing.=EF=BF=BD I first > >> described > >> that > >> approach on the list here --- > >> > >> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html > >> , and referred to it in various > >> subsequent > >> discussions. > >> > >> * Defining the data flows between > regions, > >> clients, > >> and asset > >> services and which parameters > >> control the flows > >> needs to > >> be done > >> before a test asset service can be > >> implemented.=EF=BF=BD > >> Without > >> that, > >> an asset service is just a > >> network-accessible storage > >> service, > >> not an asset service in the VWRAP > >> sense.=EF=BF=BD > >> Network > >> storage > >> services exist already, so just > >> implementing one > >> of those > >> would > >> not advance VWRAP. > >> > >> * We need to examine how various > >> deployment > >> patterns > >> will > >> use the > >> asset services, and how the > >> /multiple/ asset > >> services that > >> interop introduces are handled.=EF=BF= =BD I am > >> working on this > >> currently. > >> > >> > >> None of the above is particularly hard.=EF= =BF=BD > >> I think it > >> won't be > >> long before we have a scheme worked out > >> and are > >> ready > >> for some > >> implementation work. > >> > >> > >> Morgaine. > >> > >> > >> > >> > >> > >> > ------------------------------------------------------------------------ > >> > >> > >> > >> > >> _______________________________________________ > >> vwrap mailing list > >> vwrap@ietf.org > >> > > >> > >> >> > >> > >> > > >> > >> >>> > >> > >> > >> https://www.ietf.org/mailman/listinfo/vwra= p > >> -- --- > >> https://twitter.com/Dzonatas_Sol --- > >> Web Development, Software Engineering, > >> Virtual Reality, > >> Consultant > >> > >> > >> > >> > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> vwrap mailing list > >> vwrap@ietf.org > >> > > >> > >> >> > >> https://www.ietf.org/mailman/listinfo/vwrap > >> > >> -- --- https://twitter.com/Dzonatas_Sol --- > >> Web Development, Software Engineering, Virtual Realit= y, > >> Consultant > >> > >> > >> > >> > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> vwrap mailing list > >> vwrap@ietf.org > >> > > >> https://www.ietf.org/mailman/listinfo/vwrap > >> > >> > >> -- --- https://twitter.com/Dzonatas_Sol --- > >> Web Development, Software Engineering, Virtual Reality, > >> Consultant > >> > >> > >> > >> > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> vwrap mailing list > >> vwrap@ietf.org > >> https://www.ietf.org/mailman/listinfo/vwrap > >> > >> > >> > >> -- --- https://twitter.com/Dzonatas_Sol --- > >> Web Development, Software Engineering, Virtual Reality, Consultant > >> > >> > >> ----------------------------------------------------------------------= -- > >> > >> _______________________________________________ > >> vwrap mailing list > >> vwrap@ietf.org > >> https://www.ietf.org/mailman/listinfo/vwrap > >> > > > > > > -- > > --- 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 > > > --0016367d4f04cd50cb04a036841b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm not sure at what stage you joined us Izzy, but support for flexibil= ity and extensibility in the protocol has been preached by us regularly thr= oughout the entire lifetime of the MMOX, OGPX and now VWRAP groups, so it&#= 39;s nothing new, really.=C2=A0 It could be said to have been lip service b= efore though, seeing as no new features ever materialized from it.

    The only significant difference now is that Carlo has tried to turn tha= t lip service into an agreed process for promoting proposals that are aimed= at providing extra flexibility and extensibility.=C2=A0 The fact that this= idea hasn't received much support is a bit worrying.

    It wouldn't matter at all if the group was by its nature strongly f= ocused on creating a protocol "designed for the future", eagerly = selecting the ideas with the best outlook for a massively scaled and buoyan= t metaverse, a protocol that recognizes that virtual worlds will evolve rap= idly once they gain synergy from interoperation.=C2=A0 Indeed, Carlo's = a priori agreement would then be entirely superfluous.=C2=A0 But instead of= eagerly welcoming forward-looking proposals with excellent engineering mer= its, the few we've had so far seem to be greeted with intense resistanc= e and avoidance of technical discussion.=C2=A0 It's an uphill struggle.=

    I can see why Carlo was so highly despondent in his last post.=C2=A0 Co= nditions aren't too encouraging at the moment for an advanced, extensib= le protocol.

    And perhaps there is no solution.=C2=A0 You can't m= ake a horse drink, even when there is plenty of water provided.


    Morgaine.





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

    On W= ed, Apr 6, 2011 at 2:24 AM, Izzy Alanis <izzyalanis@gmail.com> wrote:
    Along the lines o= f documentation... are we salvaging the last draft
    intro doc or scrapping it? If we're scrapping it, what about it didn= 9;t
    we like, what about it was good? The work on shoring up definitions is
    directly applicable to the intro doc, but the minute details of asset
    addressability and cacheability are leading us down a rat hole -- it's<= br> interesting conversation, but just not productive right now.

    Toward Carlo's mission of 'flexibility first': how would a stat= ement
    about the flexibility of the protocol appear in such a document?

    - Izzy


    On Tue, Apr 5, 2011 at 8:26 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
    > We were and still are in discussion about VWRAP documents.
    >
    > As someone that implements, they don't want to read anything like = "many
    > orders of magnitude" or "the best idea" or such exagger= ated adjectives.
    > Don't expect your ideas ever to get implemented based on such lang= uage.
    >
    > Need just the facts, and the documents. Please, stop with how great yo= u
    > think your idea is and produce the documents! Please include specific = use of
    > the resources, LLIDL, DSD, etc.
    >
    > If this continues to be just discussion and neither documentation nor<= br> > implementation than I'm with the chair(s) to disband.
    >
    > Morgaine wrote:
    >>
    >> The asset fetch performance gain of a protocol in which asset iden= tifiers
    >> make cross-world assets cacheable versus a protocol whose asset id= entifiers
    >> do not allow this is an extremely large factor of *many orders of = magnitude*
    >> on all but the first occurrence of an asset. =C2=A0For all intents= and purposes,
    >> avoiding the need to fetch an asset over the network represents a = gain of
    >> infinity, and this gain may be repeated many times over.
    >>
    >> I think it's pretty uncontestable that giving VWRAP an asset a= ddressing
    >> scheme which is orders of magnitude more efficient than any other = scheme
    >> that has yet been proposed would be an important benefit for the p= rotocol,
    >> and highly likely to make it popular. =C2=A0Conversely, if it lack= s this benefit
    >> then another protocol will use it and will hugely out-perform VWRA= P.
    >>
    >> We were talking about designing for the future. =C2=A0Hash-based a= sset
    >> addressing is a case in point, and how we handle this proposal is = apparently
    >> our first test case.
    >>
    >>
    >> 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
    >>
    >>
    >> On Tue, Apr 5, 2011 at 11:52 PM, Dzonatas Sol <dzonatas@gmail.com
    >> <mailto:dzonatas@gmail.co= m>> wrote:
    >>
    >> =C2=A0 =C2=A0And... still local cache.. not vwrap.
    >>
    >> =C2=A0 =C2=A0I think it would be more wise to go with the implemen= tations of
    >> =C2=A0 =C2=A0Google's and/or Siemens object identification to = RFID codes. At
    >> =C2=A0 =C2=A0least we know this part won't exploit content. >>
    >> =C2=A0 =C2=A0It has further advantages than just that. I went into= detail
    >> =C2=A0 =C2=A0awhile ago, yet with basic QM:
    >>
    >> =C2=A0http://icyspherical.blogs= pot.com/2010/07/optimizing-simulations-with-basic.html
    >>
    >> =C2=A0 =C2=A0No, even given the possibilities presented, I don'= ;t think your
    >> =C2=A0 =C2=A0idea comes close to anything new in regards to the be= st. It's just
    >> =C2=A0 =C2=A0your preference.
    >>
    >> =C2=A0 =C2=A0Morgaine wrote:
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, Apr 5, 2011 at 11:11 PM, Dzonat= as Sol
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<dzonatas@gmail.com <mailto:= dzonatas@gmail.com>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>> wrote:
    >>
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Your approach, besides exploita= tions, has the typical
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0problem to
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 assume asset IDs are only neede= d and are hash-able.
    >>
    >>
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Asset IDs are not hash-able, it is the = asset data that is
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0hashed. =C2=A0The asset identifier is t= he hash of the asset data
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0using a defined hash digest algorithm. = =C2=A0The asset identifier
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0is not guessable unless you already hav= e access to the asset.
    >>
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Morgaine.
    >>
    >>
    >>
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0=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
    >>
    >>
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Tue, Apr 5, 20= 11 at 10:34 PM, Dzonatas Sol
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <dzonatas@gmail.com <mailto:dzonatas@gmail.com>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>> wrote:
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Agai= n Morgaine, your appeals alone don't support
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 themselves, and >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0your= ridicule is unwelcome. If you can not honestly
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0make any
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0seri= ous response, please move on and don't reply to my
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 posts just
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to f= urther ridicule. It's very RUDE.
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If y= ou have any implementation of your hash-based
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0idea or
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 actual
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tech= nical detailed documentation ready for
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0implementation, then
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0intr= oduce it. Until then, it's stuck in your head,
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0and sounds
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0othe= r's ideas just with your name on it. Plus
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0security by
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0obsc= urity makes it as moot point.
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Docu= mentation... ?
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Reme= mber people tried to take one temp variable away
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0from the
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0JPEG= 2000 int multiple/divide routine because the
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0idea it looks
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0good= (on paper) with one less variable. Actual
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0implementation
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reve= als, with timed tests, it is slower when anybody
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0takes away
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that= one temp variable.
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Morg= aine wrote:
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Unfortunately your response was devoid of technical
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 content,
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Dzonatas.
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0If you have something technical to say about
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0hash-based
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0addressing, I would love to hear it.
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0I have detailed in some depth the many benefits of
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hash-based
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0addressing in the article I linked, and
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0subsequently. =C2=A0If
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0other good schemes exist, we should of course
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0analyze
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 them for
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0technical merit and compare their benefits
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0against those of
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0hash-based addressing.
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0That's the engineering process for making VWRAP
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0as good
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 as it
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0can be.
    >>
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Morgaine.
    >>
    >>
    >>
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=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
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0<dzonatas@gmail.com = <mailto:dzonatas@gmail.com>=
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0<mailto:dzonatas@gmail.c= om
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com> <mailto:dzonatas@gmail.com
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com>>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>>> wrote:
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Morgaine, we mooted your hash-based idea.
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0This does
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 nothing to
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 help implement asset services. The only
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0significant
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 point
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0you made
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 is some expression for optimization, not correct
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 functionality, >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 which is needed first
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 As for your other two, we can summarize those
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0with
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 public
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 resources and flow (forward/reverse). Any more
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specific network<= br> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 topology than that only makes it harder to
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0address. The
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0only thing
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 to worry about is already custom resources
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0that overlap
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0with newer
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 public resources.
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Morgaine wrote:
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas So= l
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <d= zonatas@gmail.com
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com> <mailto:dzonatas@gmail.com
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com>>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0<mailto:dzonatas@gmail.c= om
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com> <mailto:dzonatas@gmail.com
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com>>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0<mailto:dzonatas@gmail.c= om
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com> <mailto:dzonatas@gmail.com
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com>>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dzonatas@gmail.com <mailto:dzonatas@gmail.com>>>>>> wrote:
    >>
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Do you think we are ready to i= mplement
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0some asset
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0services now,
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with/without complete document= ation?
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0What more do you think is need= ed?
    >>
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Two or three things seem to be needed:
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Defining the asset addressin= g
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0concept is an
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 extremely
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 important
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0matter, almost certainl= y the most
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0important
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 matter
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0of all,
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0because that determines= how robust and
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 scalable our
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 worlds will
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be.=EF=BF=BD I've a= lready examined
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0alternatives for
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0in some
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 depth,
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and the design with the= best engineering
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 properties so
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 far seems
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to be universal hash-ba= sed
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0addressing.=EF=BF=BD I first
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0described
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0approach on the list he= re ---
    >>
    >> =C2=A0http://www.ietf.org/mail-archive/web/vwr= ap/current/msg00463.html
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0, and referred to it in= various
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0subsequent
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0discussions.
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Defining the data flows betw= een regions,
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 clients,
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0and asset
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0services and which para= meters
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0control the flows
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0needs to
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be done
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0before a test asset ser= vice can be
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implemented.=EF= =BF=BD
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Without
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that,
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0an asset service is jus= t a
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 network-accessibl= e storage
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 service,
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not an asset service in= the VWRAP
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0sense.=EF=BF=BD
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Network
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0storage
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0services exist already,= so just
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implementing one<= br> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0of those
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 would
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not advance VWRAP.
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* We need to examine how vario= us
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0deployment
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 patterns
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0will
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 use the
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0asset services, and how= the
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0/multiple/ asset
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0services that
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interop introduces are = handled.=EF=BF=BD I am
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 working on this >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 currently.
    >>
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 None of the above is particularly hard.=EF= =BF=BD
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0I think it
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0won't be
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 long before we have a scheme worked out
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0and are
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ready
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0for some
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implementation work.
    >>
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Morgaine.
    >>
    >>
    >>
    >>
    >>
    >> =C2=A0------------------------------------------------------------= ------------
    >>
    >>
    >>
    >>
    >> =C2=A0_______________________________________________
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vwrap mailing list
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vwrap@iet= f.org <mailto:vwrap@ietf.org&g= t;
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:vwrap= @ietf.org>>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:vwrap= @ietf.org>>>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0<mailto:vwrap@ietf.org &= lt;mailto:vwrap@ietf.org>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:vwrap= @ietf.org>>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:vwrap= @ietf.org>>>>
    >>
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/vwrap<= /a>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- =C2=A0 =C2=A0 ---
    >>     htt= ps://twitter.com/Dzonatas_Sol ---
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Web Development, Software Engineering,
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Virtual Reality,
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Consultant
    >>
    >>
    >>
    >> =C2=A0------------------------------------------------------------= ------------
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0_______________________________________________
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0vwrap mailing list
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0vwrap@ietf.org <mailto:<= a href=3D"mailto:vwrap@ietf.org">vwrap@ietf.org>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:vwrap= @ietf.org>>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:vwrap= @ietf.org>>>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0https://www.ietf.org/mailman/listinfo/vwrap
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- = =C2=A0 =C2=A0 --- https://twitter.com/Dzonatas_Sol ---
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Web = Development, Software Engineering, Virtual Reality,
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Consultant
    >>
    >>
    >>
    >> =C2=A0------------------------------------------------------------= ------------
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _________________= ______________________________
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vwrap mailing lis= t
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vwrap@ietf.org <mailto:vwrap@ietf.org>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:vwrap= @ietf.org>>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.o= rg/mailman/listinfo/vwrap
    >>
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- =C2=A0 =C2=A0 --- https://twitter.com/Dz= onatas_Sol ---
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Web Development, Software Engin= eering, Virtual Reality,
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Consultant
    >>
    >>
    >>
    >> =C2=A0------------------------------------------------------------= ------------
    >>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________________________= ________
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0vwrap mailing list
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0vwrap= @ietf.org <mailto:vwrap@ietf.org>
    >> =C2=A0 =C2=A0 =C2=A0 =C2=A0    https://www.ietf.org/mailman/listinfo/vw= rap
    >>
    >>
    >>
    >> =C2=A0 =C2=A0-- =C2=A0 =C2=A0 --- https://twitter.com/Dzonatas_Sol ---
    >> =C2=A0 =C2=A0Web Development, Software Engineering, Virtual Realit= y, Consultant
    >>
    >>
    >> ------------------------------------------------------------------= ------
    >>
    >> _______________________________________________
    >> vwrap mailing list
    >> vwrap@ietf.org
    >> https://www.ietf.org/mailman/listinfo/vwrap
    >>
    >
    >
    > --
    > --- htt= ps://twitter.com/Dzonatas_Sol ---
    > Web Development, Software Engineering, Virtual Reality, Consultant
    >
    > _______________________________________________
    > vwrap mailing list
    > vwrap@ietf.org
    > https://www.ietf.org/mailman/listinfo/vwrap
    >

    --0016367d4f04cd50cb04a036841b-- From dzonatas@gmail.com Tue Apr 5 19:26:19 2011 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 9B59D3A69A9 for ; Tue, 5 Apr 2011 19:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 BDb7aua9PWRv for ; Tue, 5 Apr 2011 19:26:17 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 692C43A683B for ; Tue, 5 Apr 2011 19:26:17 -0700 (PDT) Received: by iwn39 with SMTP id 39so1223438iwn.31 for ; Tue, 05 Apr 2011 19:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YCNCg7/A5ZzaztzTothq36c50bvbSMvvj1z11ACsrbM=; b=snCmIbXagbnXTDyAFIVndt8+uHRYj74lD0XsVvt85QtKuu9fytY+iqdpo7IEF1Yy0X O/FoiQ7vwMGtKBzLOZg4wfEwpfxPlwNnlFyfR6DVx5Br77xLFmC+V9dMYarziUlO/PHD 0SU9eqQNgw5kZAFfVlSLvzLiiGjUquSSYJ3KI= 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=EWxNPyLCnh019TktB+KIdvjNo6V5/5NNHbJfTfMIyvOuoOVaDbaWetDm+MenfTOexf AV7F72qcsIDzmOuc2gjezfvkeK5C3yjylGIzOPXj/mJQ6pOGsYuZp7vVzp6UuQAansBc Nyr2Lea4p+4tK+SmZX5/+0KtfYEIjdgeJxkbc= Received: by 10.43.45.8 with SMTP id ui8mr709053icb.197.1302056880816; Tue, 05 Apr 2011 19:28:00 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id vx7sm14958icb.2.2011.04.05.19.27.58 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 19:27:59 -0700 (PDT) Message-ID: <4D9BCFE0.4000905@gmail.com> Date: Tue, 05 Apr 2011 19:28:48 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Izzy Alanis References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <20110405152025.26ba8f77@hikaru.localdomain> <4D9B4586.9080004@gmail.com> <4D9B73D5.4000809@gmail.com> <4D9B8ADA.9000106@gmail.com> <4D9B937C.1040403@gmail.com> <4D9B9D4A.7050006@gmail.com> <4D9BB342.7020607@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 06 Apr 2011 02:26:19 -0000 I'm interested in in implementation of the asset services, even completely fake, with mainly login like the simulators now. This is something just to give backbone to the current documents combined with implementations since then without any specific group behind the backbone. It doesn't have to support real simulator details, it could just forward proxy if it really want to turn into something. That's just the scrape for implementation sake. We need something like this, yet to justify it beyond people's agendas is... not productive. I mainly wanted asset services unitized in order to support the multi-point/multi-client perspective, yet, like last year, I'm tired of being harassed by... agendas. We could always fallback to the proxy being on the viewer-side. *sigh* On the documentation side, I think we could take the current proposed RFCs and simplify the type system into split documents instead one (that mainly reflects the monolithic design). That way we could come back later and easily update the more simplified versions. Just my 2 cents on the current state of them... Izzy Alanis wrote: > Along the lines of documentation... are we salvaging the last draft > intro doc or scrapping it? If we're scrapping it, what about it didn't > we like, what about it was good? The work on shoring up definitions is > directly applicable to the intro doc, but the minute details of asset > addressability and cacheability are leading us down a rat hole -- it's > interesting conversation, but just not productive right now. > > Toward Carlo's mission of 'flexibility first': how would a statement > about the flexibility of the protocol appear in such a document? > > - Izzy > > > On Tue, Apr 5, 2011 at 8:26 PM, Dzonatas Sol wrote: > >> We were and still are in discussion about VWRAP documents. >> >> As someone that implements, they don't want to read anything like "many >> orders of magnitude" or "the best idea" or such exaggerated adjectives. >> Don't expect your ideas ever to get implemented based on such language. >> >> Need just the facts, and the documents. Please, stop with how great you >> think your idea is and produce the documents! Please include specific use of >> the resources, LLIDL, DSD, etc. >> >> If this continues to be just discussion and neither documentation nor >> implementation than I'm with the chair(s) to disband. >> >> Morgaine wrote: >> >>> The asset fetch performance gain of a protocol in which asset identifiers >>> make cross-world assets cacheable versus a protocol whose asset identifiers >>> do not allow this is an extremely large factor of *many orders of magnitude* >>> on all but the first occurrence of an asset. For all intents and purposes, >>> avoiding the need to fetch an asset over the network represents a gain of >>> infinity, and this gain may be repeated many times over. >>> >>> I think it's pretty uncontestable that giving VWRAP an asset addressing >>> scheme which is orders of magnitude more efficient than any other scheme >>> that has yet been proposed would be an important benefit for the protocol, >>> and highly likely to make it popular. Conversely, if it lacks this benefit >>> then another protocol will use it and will hugely out-perform VWRAP. >>> >>> We were talking about designing for the future. Hash-based asset >>> addressing is a case in point, and how we handle this proposal is apparently >>> our first test case. >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> >>> =============================== >>> >>> >>> On Tue, Apr 5, 2011 at 11:52 PM, Dzonatas Sol >> > wrote: >>> >>> And... still local cache.. not vwrap. >>> >>> I think it would be more wise to go with the implementations of >>> Google's and/or Siemens object identification to RFID codes. At >>> least we know this part won't exploit content. >>> >>> It has further advantages than just that. I went into detail >>> awhile ago, yet with basic QM: >>> >>> http://icyspherical.blogspot.com/2010/07/optimizing-simulations-with-basic.html >>> >>> No, even given the possibilities presented, I don't think your >>> idea comes close to anything new in regards to the best. It's just >>> your preference. >>> >>> Morgaine wrote: >>> >>> On Tue, Apr 5, 2011 at 11:11 PM, Dzonatas Sol >>> >>> >> wrote: >>> >>> >>> Your approach, besides exploitations, has the typical >>> problem to >>> assume asset IDs are only needed and are hash-able. >>> >>> >>> >>> Asset IDs are not hash-able, it is the asset data that is >>> hashed. The asset identifier is the hash of the asset data >>> using a defined hash digest algorithm. The asset identifier >>> is not guessable unless you already have access to the asset. >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> ============================= >>> >>> >>> >>> ================== >>> >>> On Tue, Apr 5, 2011 at 10:34 PM, Dzonatas Sol >>> >>> > >>> >>> >>> wrote: >>> >>> Again Morgaine, your appeals alone don't support >>> themselves, and >>> your ridicule is unwelcome. If you can not honestly >>> make any >>> serious response, please move on and don't reply to my >>> posts just >>> to further ridicule. It's very RUDE. >>> >>> If you have any implementation of your hash-based >>> idea or >>> actual >>> technical detailed documentation ready for >>> implementation, then >>> introduce it. Until then, it's stuck in your head, >>> and sounds >>> other's ideas just with your name on it. Plus >>> security by >>> obscurity makes it as moot point. >>> >>> Documentation... ? >>> >>> Remember people tried to take one temp variable away >>> from the >>> JPEG2000 int multiple/divide routine because the >>> idea it looks >>> good (on paper) with one less variable. Actual >>> implementation >>> reveals, with timed tests, it is slower when anybody >>> takes away >>> that one temp variable. >>> >>> Morgaine wrote: >>> >>> Unfortunately your response was devoid of technical >>> content, >>> Dzonatas. >>> >>> If you have something technical to say about >>> hash-based >>> addressing, I would love to hear it. >>> >>> I have detailed in some depth the many benefits of >>> hash-based >>> addressing in the article I linked, and >>> subsequently. If >>> other good schemes exist, we should of course >>> analyze >>> them for >>> technical merit and compare their benefits >>> against those of >>> hash-based addressing. >>> >>> That's the engineering process for making VWRAP >>> as good >>> as it >>> can be. >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> ========================= >>> >>> On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol >>> >>> > >>> >>> >> >>> >> >> > >>> >>> >>>> wrote: >>> >>> Morgaine, we mooted your hash-based idea. >>> This does >>> nothing to >>> help implement asset services. The only >>> significant >>> point >>> you made >>> is some expression for optimization, not correct >>> functionality, >>> which is needed first >>> >>> As for your other two, we can summarize those >>> with >>> public >>> resources and flow (forward/reverse). Any more >>> specific network >>> topology than that only makes it harder to >>> address. The >>> only thing >>> to worry about is already custom resources >>> that overlap >>> with newer >>> public resources. >>> >>> Morgaine wrote: >>> >>> On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol >>> >> >> > >>> >>> >> >>> >> >> > >>> >>> >>> >>> >> >>> > >>> >>> >> >>> >> >> > >>> >>> >>>>> wrote: >>> >>> >>> Do you think we are ready to implement >>> some asset >>> services now, >>> with/without complete documentation? >>> >>> What more do you think is needed? >>> >>> >>> Two or three things seem to be needed: >>> >>> * Defining the asset addressing >>> concept is an >>> extremely >>> important >>> matter, almost certainly the most >>> important >>> matter >>> of all, >>> because that determines how robust and >>> scalable our >>> worlds will >>> be.� I've already examined >>> alternatives for >>> that >>> in some >>> depth, >>> and the design with the best engineering >>> properties so >>> far seems >>> to be universal hash-based >>> addressing.� I first >>> described >>> that >>> approach on the list here --- >>> >>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >>> , and referred to it in various >>> subsequent >>> discussions. >>> >>> * Defining the data flows between regions, >>> clients, >>> and asset >>> services and which parameters >>> control the flows >>> needs to >>> be done >>> before a test asset service can be >>> implemented.� >>> Without >>> that, >>> an asset service is just a >>> network-accessible storage >>> service, >>> not an asset service in the VWRAP >>> sense.� >>> Network >>> storage >>> services exist already, so just >>> implementing one >>> of those >>> would >>> not advance VWRAP. >>> >>> * We need to examine how various >>> deployment >>> patterns >>> will >>> use the >>> asset services, and how the >>> /multiple/ asset >>> services that >>> interop introduces are handled.� I am >>> working on this >>> currently. >>> >>> >>> None of the above is particularly hard.� >>> I think it >>> won't be >>> long before we have a scheme worked out >>> and are >>> ready >>> for some >>> implementation work. >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> _______________________________________________ >>> vwrap mailing list >>> vwrap@ietf.org >>> > >>> >>> >> >>> >>> > >>> >>> >>> >>> >>> >>> https://www.ietf.org/mailman/listinfo/vwrap >>> -- --- >>> https://twitter.com/Dzonatas_Sol --- >>> Web Development, Software Engineering, >>> Virtual Reality, >>> Consultant >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> vwrap mailing list >>> vwrap@ietf.org >>> > >>> >>> >> >>> https://www.ietf.org/mailman/listinfo/vwrap >>> >>> -- --- https://twitter.com/Dzonatas_Sol --- >>> Web Development, Software Engineering, Virtual Reality, >>> Consultant >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> vwrap mailing list >>> vwrap@ietf.org >>> > >>> https://www.ietf.org/mailman/listinfo/vwrap >>> >>> >>> -- --- https://twitter.com/Dzonatas_Sol --- >>> Web Development, Software Engineering, Virtual Reality, >>> Consultant >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> vwrap mailing list >>> vwrap@ietf.org >>> https://www.ietf.org/mailman/listinfo/vwrap >>> >>> >>> >>> -- --- https://twitter.com/Dzonatas_Sol --- >>> Web Development, Software Engineering, Virtual Reality, Consultant >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> vwrap mailing list >>> vwrap@ietf.org >>> https://www.ietf.org/mailman/listinfo/vwrap >>> >>> >> -- >> --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From izzyalanis@gmail.com Wed Apr 6 20:29:22 2011 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 2D5563A6978 for ; Wed, 6 Apr 2011 20:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.257 X-Spam-Level: X-Spam-Status: No, score=-1.257 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, 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 32ESCq06iqVa for ; Wed, 6 Apr 2011 20:29:17 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 196733A6809 for ; Wed, 6 Apr 2011 20:29:17 -0700 (PDT) Received: by qyk7 with SMTP id 7so1379045qyk.10 for ; Wed, 06 Apr 2011 20:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-type:message-id:content-transfer-encoding:cc:x-mailer:from :subject:date:to; bh=2Q6/e6Kr/JVbcVLBDnSe/2P0mTOYYTGpFGUdxYz7IDQ=; b=dmWF5C7tcobx8gR+IrJenHpIxmEZXgfLSrYs92Tpgsu6KeULAQoeGaZU5JuN+sKPXB QfdE/GptMc/0iWSWfNhNk6N+JgqjBprTS4gg/P6uXaPLh52PTr5cznIW7sEe7xSd/09z muKLSEg/LIvO5DkjP0rCGtz5QGrJku6k7VBQ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; b=V1yJ4jy3SiSzeutvJgNwETwGu7Y8sx/LlUQVZvU8whOgeQLyWC9iFGQEh97ow6d9TP 5BMHpeg5jJLnvrbaXPqSFWfT/bhlbw1AadM9STiUs7W6lRq6t9i+DUfPXpOItMv7wmxS Nb3xCJA23FpMHETzLffdsewV0hx+6mkhit/PY= Received: by 10.224.210.67 with SMTP id gj3mr272255qab.28.1302147060705; Wed, 06 Apr 2011 20:31:00 -0700 (PDT) Received: from [192.168.1.108] (c-75-68-52-200.hsd1.nh.comcast.net [75.68.52.200]) by mx.google.com with ESMTPS id f5sm886786qck.20.2011.04.06.20.30.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 20:30:58 -0700 (PDT) References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <20110405152025.26ba8f77@hikaru.localdomain> <4D9B4586.9080004@gmail.com> <4D9B73D5.4000809@gmail.com> <4D9B8ADA.9000106@gmail.com> <4D9B937C.1040403@gmail.com> <4D9B9D4A.7050006@gmail.com> <4D9BB342.7020607@gmail.com> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8C148) Content-Type: multipart/alternative; boundary=Apple-Mail-1--430177921 Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: iPad Mail (8C148) From: Izzy Alanis Date: Wed, 6 Apr 2011 23:30:47 -0400 To: Morgaine Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Statements of Consensus. Flexibity First. 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, 07 Apr 2011 03:29:22 -0000 --Apple-Mail-1--430177921 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes, yes, yes... The question was more about how you want those ideas reflec= ted in the documents. - Izzy On Apr 5, 2011, at 10:12 PM, Morgaine wrote= : > I'm not sure at what stage you joined us Izzy, but support for flexibility= and extensibility in the protocol has been preached by us regularly through= out the entire lifetime of the MMOX, OGPX and now VWRAP groups, so it's noth= ing new, really. It could be said to have been lip service before though, s= eeing as no new features ever materialized from it. >=20 > The only significant difference now is that Carlo has tried to turn that l= ip service into an agreed process for promoting proposals that are aimed at p= roviding extra flexibility and extensibility. The fact that this idea hasn'= t received much support is a bit worrying. >=20 > It wouldn't matter at all if the group was by its nature strongly focused o= n creating a protocol "designed for the future", eagerly selecting the ideas= with the best outlook for a massively scaled and buoyant metaverse, a proto= col that recognizes that virtual worlds will evolve rapidly once they gain s= ynergy from interoperation. Indeed, Carlo's a priori agreement would then b= e entirely superfluous. But instead of eagerly welcoming forward-looking pr= oposals with excellent engineering merits, the few we've had so far seem to b= e greeted with intense resistance and avoidance of technical discussion. It= 's an uphill struggle. >=20 > I can see why Carlo was so highly despondent in his last post. Conditions= aren't too encouraging at the moment for an advanced, extensible protocol. >=20 > And perhaps there is no solution. You can't make a horse drink, even when= there is plenty of water provided. >=20 >=20 > Morgaine. >=20 >=20 >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > On Wed, Apr 6, 2011 at 2:24 AM, Izzy Alanis wrote: > Along the lines of documentation... are we salvaging the last draft > intro doc or scrapping it? If we're scrapping it, what about it didn't > we like, what about it was good? The work on shoring up definitions is > directly applicable to the intro doc, but the minute details of asset > addressability and cacheability are leading us down a rat hole -- it's > interesting conversation, but just not productive right now. >=20 > Toward Carlo's mission of 'flexibility first': how would a statement > about the flexibility of the protocol appear in such a document? >=20 > - Izzy >=20 >=20 > On Tue, Apr 5, 2011 at 8:26 PM, Dzonatas Sol wrote: > > We were and still are in discussion about VWRAP documents. > > > > As someone that implements, they don't want to read anything like "many > > orders of magnitude" or "the best idea" or such exaggerated adjectives. > > Don't expect your ideas ever to get implemented based on such language. > > > > Need just the facts, and the documents. Please, stop with how great you > > think your idea is and produce the documents! Please include specific us= e of > > the resources, LLIDL, DSD, etc. > > > > If this continues to be just discussion and neither documentation nor > > implementation than I'm with the chair(s) to disband. > > > > Morgaine wrote: > >> > >> The asset fetch performance gain of a protocol in which asset identifie= rs > >> make cross-world assets cacheable versus a protocol whose asset identif= iers > >> do not allow this is an extremely large factor of *many orders of magni= tude* > >> on all but the first occurrence of an asset. For all intents and purpo= ses, > >> avoiding the need to fetch an asset over the network represents a gain o= f > >> infinity, and this gain may be repeated many times over. > >> > >> I think it's pretty uncontestable that giving VWRAP an asset addressing= > >> scheme which is orders of magnitude more efficient than any other schem= e > >> that has yet been proposed would be an important benefit for the protoc= ol, > >> and highly likely to make it popular. Conversely, if it lacks this ben= efit > >> then another protocol will use it and will hugely out-perform VWRAP. > >> > >> We were talking about designing for the future. Hash-based asset > >> addressing is a case in point, and how we handle this proposal is appar= ently > >> our first test case. > >> > >> > >> 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 > >> > >> > >> On Tue, Apr 5, 2011 at 11:52 PM, Dzonatas Sol >> > wrote: > >> > >> And... still local cache.. not vwrap. > >> > >> I think it would be more wise to go with the implementations of > >> Google's and/or Siemens object identification to RFID codes. At > >> least we know this part won't exploit content. > >> > >> It has further advantages than just that. I went into detail > >> awhile ago, yet with basic QM: > >> > >> http://icyspherical.blogspot.com/2010/07/optimizing-simulations-with-b= asic.html > >> > >> No, even given the possibilities presented, I don't think your > >> idea comes close to anything new in regards to the best. It's just > >> your preference. > >> > >> Morgaine wrote: > >> > >> On Tue, Apr 5, 2011 at 11:11 PM, Dzonatas Sol > >> > >> >> wrote: > >> > >> > >> Your approach, besides exploitations, has the typical > >> problem to > >> assume asset IDs are only needed and are hash-able. > >> > >> > >> > >> Asset IDs are not hash-able, it is the asset data that is > >> hashed. The asset identifier is the hash of the asset data > >> using a defined hash digest algorithm. The asset identifier > >> is not guessable unless you already have access to the asset. > >> > >> > >> 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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> On Tue, Apr 5, 2011 at 10:34 PM, Dzonatas Sol > >> > >> > > >> > >> >>> wrote:= > >> > >> Again Morgaine, your appeals alone don't support > >> themselves, and > >> your ridicule is unwelcome. If you can not honestly > >> make any > >> serious response, please move on and don't reply to my= > >> posts just > >> to further ridicule. It's very RUDE. > >> > >> If you have any implementation of your hash-based > >> idea or > >> actual > >> technical detailed documentation ready for > >> implementation, then > >> introduce it. Until then, it's stuck in your head, > >> and sounds > >> other's ideas just with your name on it. Plus > >> security by > >> obscurity makes it as moot point. > >> > >> Documentation... ? > >> > >> Remember people tried to take one temp variable away > >> from the > >> JPEG2000 int multiple/divide routine because the > >> idea it looks > >> good (on paper) with one less variable. Actual > >> implementation > >> reveals, with timed tests, it is slower when anybody > >> takes away > >> that one temp variable. > >> > >> Morgaine wrote: > >> > >> Unfortunately your response was devoid of technica= l > >> content, > >> Dzonatas. > >> > >> If you have something technical to say about > >> hash-based > >> addressing, I would love to hear it. > >> > >> I have detailed in some depth the many benefits of= > >> hash-based > >> addressing in the article I linked, and > >> subsequently. If > >> other good schemes exist, we should of course > >> analyze > >> them for > >> technical merit and compare their benefits > >> against those of > >> hash-based addressing. > >> > >> That's the engineering process for making VWRAP > >> as good > >> as it > >> can be. > >> > >> > >> 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 > >> > >> On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol > >> > >> > > >> > >> >> > >> >> >> > > >> > >> >>>> wrote= : > >> > >> Morgaine, we mooted your hash-based idea. > >> This does > >> nothing to > >> help implement asset services. The only > >> significant > >> point > >> you made > >> is some expression for optimization, not correc= t > >> functionality, > >> which is needed first > >> > >> As for your other two, we can summarize those > >> with > >> public > >> resources and flow (forward/reverse). Any more > >> specific network > >> topology than that only makes it harder to > >> address. The > >> only thing > >> to worry about is already custom resources > >> that overlap > >> with newer > >> public resources. > >> > >> Morgaine wrote: > >> > >> On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas So= l > >> >> >> > > >> > >> >> > >> >> >> > > >> > >> >>> > >> >> > >> > > >> > >> >> > >> >> >> > > >> > >> >>>>> wrot= e: > >> > >> > >> Do you think we are ready to implement > >> some asset > >> services now, > >> with/without complete documentation? > >> > >> What more do you think is needed? > >> > >> > >> Two or three things seem to be needed: > >> > >> * Defining the asset addressing > >> concept is an > >> extremely > >> important > >> matter, almost certainly the most > >> important > >> matter > >> of all, > >> because that determines how robust and= > >> scalable our > >> worlds will > >> be.=EF=BF=BD I've already examined > >> alternatives for > >> that > >> in some > >> depth, > >> and the design with the best engineeri= ng > >> properties so > >> far seems > >> to be universal hash-based > >> addressing.=EF=BF=BD I first > >> described > >> that > >> approach on the list here --- > >> > >> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html > >> , and referred to it in various > >> subsequent > >> discussions. > >> > >> * Defining the data flows between region= s, > >> clients, > >> and asset > >> services and which parameters > >> control the flows > >> needs to > >> be done > >> before a test asset service can be > >> implemented.=EF=BF=BD > >> Without > >> that, > >> an asset service is just a > >> network-accessible storage > >> service, > >> not an asset service in the VWRAP > >> sense.=EF=BF=BD > >> Network > >> storage > >> services exist already, so just > >> implementing one > >> of those > >> would > >> not advance VWRAP. > >> > >> * We need to examine how various > >> deployment > >> patterns > >> will > >> use the > >> asset services, and how the > >> /multiple/ asset > >> services that > >> interop introduces are handled.=EF=BF=BD= I am > >> working on this > >> currently. > >> > >> > >> None of the above is particularly hard.=EF=BF= =BD > >> I think it > >> won't be > >> long before we have a scheme worked out > >> and are > >> ready > >> for some > >> implementation work. > >> > >> > >> Morgaine. > >> > >> > >> > >> > >> > >> ----------------------------------------------------------------------= -- > >> > >> > >> > >> > >> _______________________________________________ > >> vwrap mailing list > >> vwrap@ietf.org > >> > > >> > >> >> > >> > >> > > >> > >> >>> > >> > >> > >> https://www.ietf.org/mailman/listinfo/vwrap= > >> -- --- > >> https://twitter.com/Dzonatas_Sol --- > >> Web Development, Software Engineering, > >> Virtual Reality, > >> Consultant > >> > >> > >> > >> ----------------------------------------------------------------------= -- > >> > >> _______________________________________________ > >> vwrap mailing list > >> vwrap@ietf.org > >> > > >> > >> >> > >> https://www.ietf.org/mailman/listinfo/vwrap > >> > >> -- --- https://twitter.com/Dzonatas_Sol --- > >> Web Development, Software Engineering, Virtual Reality= , > >> Consultant > >> > >> > >> > >> ----------------------------------------------------------------------= -- > >> > >> _______________________________________________ > >> vwrap mailing list > >> vwrap@ietf.org > >> > > >> https://www.ietf.org/mailman/listinfo/vwrap > >> > >> > >> -- --- https://twitter.com/Dzonatas_Sol --- > >> Web Development, Software Engineering, Virtual Reality, > >> Consultant > >> > >> > >> > >> ----------------------------------------------------------------------= -- > >> > >> _______________________________________________ > >> vwrap mailing list > >> vwrap@ietf.org > >> https://www.ietf.org/mailman/listinfo/vwrap > >> > >> > >> > >> -- --- https://twitter.com/Dzonatas_Sol --- > >> Web Development, Software Engineering, Virtual Reality, Consultant > >> > >> > >> -----------------------------------------------------------------------= - > >> > >> _______________________________________________ > >> vwrap mailing list > >> vwrap@ietf.org > >> https://www.ietf.org/mailman/listinfo/vwrap > >> > > > > > > -- > > --- 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 > > >=20 > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap --Apple-Mail-1--430177921 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    Yes, yes, yes... The question was more a= bout how you want those ideas reflected in the documents.

    - Izzy

    On Apr 5, 2011, at 10:12 PM, Morgaine <morgaine.dinova@googlemail.com> wrote:
    <= br>
    I'm not sure at what stag= e you joined us Izzy, but support for flexibility and extensibility in the p= rotocol has been preached by us regularly throughout the entire lifetime of t= he MMOX, OGPX and now VWRAP groups, so it's nothing new, really.  It co= uld be said to have been lip service before though, seeing as no new feature= s ever materialized from it.

    The only significant difference now is that Carlo has tried to turn that= lip service into an agreed process for promoting proposals that are aimed a= t providing extra flexibility and extensibility.  The fact that this id= ea hasn't received much support is a bit worrying.

    It wouldn't matter at all if the group was by its nature strongly focuse= d on creating a protocol "designed for the future", eagerly selecting the id= eas with the best outlook for a massively scaled and buoyant metaverse, a pr= otocol that recognizes that virtual worlds will evolve rapidly once they gai= n synergy from interoperation.  Indeed, Carlo's a priori agreement woul= d then be entirely superfluous.  But instead of eagerly welcoming forwa= rd-looking proposals with excellent engineering merits, the few we've had so= far seem to be greeted with intense resistance and avoidance of technical d= iscussion.  It's an uphill struggle.

    I can see why Carlo was so highly despondent in his last post.  Con= ditions aren't too encouraging at the moment for an advanced, extensible pro= tocol.

    And perhaps there is no solution.  You can't make a horse= drink, even when there is plenty of water provided.


    Morgaine.





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

    On Wed, A= pr 6, 2011 at 2:24 AM, Izzy Alanis <izzyalanis@gmai= l.com> wrote:
    Along the lines of d= ocumentation... are we salvaging the last draft
    intro doc or scrapping it? If we're scrapping it, what about it didn't
    we like, what about it was good? The work on shoring up definitions is
    directly applicable to the intro doc, but the minute details of asset
    addressability and cacheability are leading us down a rat hole -- it's
    interesting conversation, but just not productive right now.

    Toward Carlo's mission of 'flexibility first': how would a statement
    about the flexibility of the protocol appear in such a document?

    - Izzy


    On Tue, Apr 5, 2011 at 8:26 PM, Dzonatas Sol <dzonatas@gmail.com&= gt; wrote:
    > We were and still are in discussion about VWRAP documents.
    >
    > As someone that implements, they don't want to read anything like "many=
    > orders of magnitude" or "the best idea" or such exaggerated adjectives.=
    > Don't expect your ideas ever to get implemented based on such language.=
    >
    > Need just the facts, and the documents. Please, stop with how great you=
    > think your idea is and produce the documents! Please include specific u= se of
    > the resources, LLIDL, DSD, etc.
    >
    > If this continues to be just discussion and neither documentation nor > implementation than I'm with the chair(s) to disband.
    >
    > Morgaine wrote:
    >>
    >> The asset fetch performance gain of a protocol in which asset ident= ifiers
    >> make cross-world assets cacheable versus a protocol whose asset ide= ntifiers
    >> do not allow this is an extremely large factor of *many orders of m= agnitude*
    >> on all but the first occurrence of an asset.  For all intents a= nd purposes,
    >> avoiding the need to fetch an asset over the network represents a g= ain of
    >> infinity, and this gain may be repeated many times over.
    >>
    >> I think it's pretty uncontestable that giving VWRAP an asset addres= sing
    >> scheme which is orders of magnitude more efficient than any other s= cheme
    >> that has yet been proposed would be an important benefit for the pr= otocol,
    >> and highly likely to make it popular.  Conversely, if it lacks= this benefit
    >> then another protocol will use it and will hugely out-perform VWRAP= .
    >>
    >> We were talking about designing for the future.  Hash-based as= set
    >> addressing is a case in point, and how we handle this proposal is a= pparently
    >> our first test case.
    >>
    >>
    >> 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
    >>
    >>
    >> On Tue, Apr 5, 2011 at 11:52 PM, Dzonatas Sol <dzonatas@gmail.co= m
    >> <mailto:dzonatas@gmail.com>> wrote:
    >>
    >>    And... still local cache.. not vwrap.
    >>
    >>    I think it would be more wise to go with the implement= ations of
    >>    Google's and/or Siemens object identification to RFID c= odes. At
    >>    least we know this part won't exploit content.
    >>
    >>    It has further advantages than just that. I went into d= etail
    >>    awhile ago, yet with basic QM:
    >>
    >>  http://icys= pherical.blogspot.com/2010/07/optimizing-simulations-with-basic.html=
    >>
    >>    No, even given the possibilities presented, I don't th= ink your
    >>    idea comes close to anything new in regards to the bes= t. It's just
    >>    your preference.
    >>
    >>    Morgaine wrote:
    >>
    >>        On Tue, Apr 5, 2011 at 11:11 PM, Dzonata= s Sol
    >>        <dzonatas@gmail.com <mailt= o:dzonatas@gmail.com>
    >>        <mailto:dzonatas@gmail.com &l= t;mailto:dzonatas@gmail.com>>> wrote:
    >>
    >>
    >>           Your approach, besides exploitat= ions, has the typical
    >>        problem to
    >>           assume asset IDs are only needed= and are hash-able.
    >>
    >>
    >>
    >>        Asset IDs are not hash-able, it is the a= sset data that is
    >>        hashed.  The asset identifier is th= e hash of the asset data
    >>        using a defined hash digest algorithm. &= nbsp;The asset identifier
    >>        is not guessable unless you already have= access to the asset.
    >>
    >>
    >>        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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    >>
    >>               On Tue, Apr 5, 201= 1 at 10:34 PM, Dzonatas Sol
    >>               <dzonatas@gmail= .com <mailto:dzonatas@gmail.com>
    >>        <mailto:dzonatas@gmail.com &l= t;mailto:dzonatas@gmail.com>>
    >>               <mailto:dzonata= s@gmail.com <mailto:dzonatas@gmail.com>
    >>        <mailto:dzonatas@gmail.com &l= t;mailto:dzonatas@gmail.com>>>> wrote:
    >>
    >>                  Again= Morgaine, your appeals alone don't support
    >>               themselves, and >>                  your r= idicule is unwelcome. If you can not honestly
    >>        make any
    >>                  serio= us response, please move on and don't reply to my
    >>               posts just
    >>                  to fu= rther ridicule. It's very RUDE.
    >>
    >>                  If yo= u have any implementation of your hash-based
    >>        idea or
    >>               actual
    >>                  techn= ical detailed documentation ready for
    >>        implementation, then
    >>                  intro= duce it. Until then, it's stuck in your head,
    >>        and sounds
    >>                  other= 's ideas just with your name on it. Plus
    >>        security by
    >>                  obscu= rity makes it as moot point.
    >>
    >>                  Docum= entation... ?
    >>
    >>                  Remem= ber people tried to take one temp variable away
    >>        from the
    >>                  JPEG2= 000 int multiple/divide routine because the
    >>        idea it looks
    >>                  good (= on paper) with one less variable. Actual
    >>        implementation
    >>                  revea= ls, with timed tests, it is slower when anybody
    >>        takes away
    >>                  that o= ne temp variable.
    >>
    >>                  Morga= ine wrote:
    >>
    >>                   &nbs= p;  Unfortunately your response was devoid of technical
    >>               content,
    >>                   &nbs= p;  Dzonatas.
    >>
    >>                   &nbs= p;  If you have something technical to say about
    >>        hash-based
    >>                   &nbs= p;  addressing, I would love to hear it.
    >>
    >>                   &nbs= p;  I have detailed in some depth the many benefits of
    >>               hash-based
    >>                   &nbs= p;  addressing in the article I linked, and
    >>        subsequently.  If
    >>                   &nbs= p;  other good schemes exist, we should of course
    >>        analyze
    >>               them for
    >>                   &nbs= p;  technical merit and compare their benefits
    >>        against those of
    >>                   &nbs= p;  hash-based addressing.
    >>
    >>                   &nbs= p;  That's the engineering process for making VWRAP
    >>        as good
    >>               as it
    >>                   &nbs= p;  can be.
    >>
    >>
    >>                   &nbs= p;  Morgaine.
    >>
    >>
    >>
    >>
    >>                   &nbs= p;  =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
    >>
    >>                   &nbs= p;  On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol
    >>                   &nbs= p;  <dzonatas@gmail.com <mailto:dzonatas@gmail.com>
    >>        <mailto:dzonatas@gmail.com &l= t;mailto:dzonatas@gmail.com>>
    >>               <mailto:dzonata= s@gmail.com <mailto:dzonatas@gmail.com>
    >>        <mailto:dzonatas@gmail.com &l= t;mailto:dzonatas@gmail.com>>>
    >>                   &nbs= p;  <mailto:dzonatas@gmail.com
    >>        <mailto:dzonatas@gmail.com>= ; <mailto:dzonatas@gmail.com
    >>        <mailto:dzonatas@gmail.com>= ;>
    >>               <mailto:dzonata= s@gmail.com <mailto:dzonatas@gmail.com>
    >>        <mailto:dzonatas@gmail.com &l= t;mailto:dzonatas@gmail.com>>>>> wrote:
    >>
    >>                   &nbs= p;     Morgaine, we mooted your hash-based idea.
    >>        This does
    >>               nothing to
    >>                   &nbs= p;     help implement asset services. The only
    >>        significant
    >>               point
    >>                   &nbs= p;  you made
    >>                   &nbs= p;     is some expression for optimization, not correct
    >>               functionality,
    = >>                   &nbs= p;     which is needed first
    >>
    >>                   &nbs= p;     As for your other two, we can summarize those
    >>        with
    >>               public
    >>                   &nbs= p;     resources and flow (forward/reverse). Any more
    >>               specific network >>                   &nbs= p;     topology than that only makes it harder to
    >>        address. The
    >>                   &nbs= p;  only thing
    >>                   &nbs= p;     to worry about is already custom resources
    >>        that overlap
    >>                   &nbs= p;  with newer
    >>                   &nbs= p;     public resources.
    >>
    >>                   &nbs= p;     Morgaine wrote:
    >>
    >>                   &nbs= p;         On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol<= br> >>                   &nbs= p;         <dzonatas@gmail.com
    >>        <mailto:dzonatas@gmail.com>= ; <mailto:dzonatas@gmail.com
    >>        <mailto:dzonatas@gmail.com>= ;>
    >>               <mailto:dzonata= s@gmail.com <mailto:dzonatas@gmail.com>
    >>        <mailto:dzonatas@gmail.com &l= t;mailto:dzonatas@gmail.com>>>
    >>                   &nbs= p;  <mailto:dzonatas@gmail.com
    >>        <mailto:dzonatas@gmail.com>= ; <mailto:dzonatas@gmail.com
    >>        <mailto:dzonatas@gmail.com>= ;>
    >>               <mailto:dzonata= s@gmail.com <mailto:dzonatas@gmail.com>
    >>        <mailto:dzonatas@gmail.com &l= t;mailto:dzonatas@gmail.com>>>>
    >>                   &nbs= p;         <mailto:dzonatas@gmail.com
    >>        <mailto:dzonatas@gmail.com>= ;
    >>               <mailto:dzonata= s@gmail.com <mailto:dzonatas@gmail.com>>
    >>        <mailto:dzonatas@gmail.com &l= t;mailto:dzonatas@gmail.com>
    >>               <mailto:dzonata= s@gmail.com <mailto:dzonatas@gmail.com>>>
    >>                   &nbs= p;  <mailto:dzonatas@gmail.com
    >>        <mailto:dzonatas@gmail.com>= ; <mailto:dzonatas@gmail.com
    >>        <mailto:dzonatas@gmail.com>= ;>
    >>               <mailto:dzonata= s@gmail.com <mailto:dzonatas@gmail.com>
    >>        <mailto:dzonatas@gmail.com &l= t;mailto:dzonatas@gmail.com>>>>>> wrote:
    >>
    >>
    >>                   &nbs= p;            Do you think we are ready to imp= lement
    >>        some asset
    >>                   &nbs= p;  services now,
    >>                   &nbs= p;            with/without complete documentat= ion?
    >>
    >>                   &nbs= p;            What more do you think is needed= ?
    >>
    >>
    >>                   &nbs= p;         Two or three things seem to be needed:
    >>
    >>                   &nbs= p;            * Defining the asset addressing<= br> >>        concept is an
    >>               extremely
    >>                   &nbs= p;         important
    >>                   &nbs= p;              matter, almost certainly t= he most
    >>        important
    >>               matter
    >>                   &nbs= p;  of all,
    >>                   &nbs= p;              because that determines h= ow robust and
    >>               scalable our
    >>                   &nbs= p;         worlds will
    >>                   &nbs= p;              be.=EF=BF=BD I've already= examined
    >>        alternatives for
    >>               that
    >>                   &nbs= p;  in some
    >>                   &nbs= p;         depth,
    >>                   &nbs= p;              and the design with the b= est engineering
    >>               properties so
    >>                   &nbs= p;         far seems
    >>                   &nbs= p;              to be universal hash-base= d
    >>        addressing.=EF=BF=BD I first
    >>                   &nbs= p;  described
    >>                   &nbs= p;         that
    >>                   &nbs= p;              approach on the list here= ---
    >>
    >>  http://www.ietf.org/mail-archive/web/vwra= p/current/msg00463.html
    >>                   &nbs= p;              , and referred to it in v= arious
    >>        subsequent
    >>                   &nbs= p;  discussions.
    >>
    >>                   &nbs= p;            * Defining the data flows betwee= n regions,
    >>               clients,
    >>                   &nbs= p;  and asset
    >>                   &nbs= p;              services and which parame= ters
    >>        control the flows
    >>                   &nbs= p;  needs to
    >>                   &nbs= p;         be done
    >>                   &nbs= p;              before a test asset servi= ce can be
    >>               implemented.=EF=BF= =BD
    >>                   &nbs= p;  Without
    >>                   &nbs= p;         that,
    >>                   &nbs= p;              an asset service is just a=
    >>               network-accessible= storage
    >>                   &nbs= p;         service,
    >>                   &nbs= p;              not an asset service in t= he VWRAP
    >>        sense.=EF=BF=BD
    >>               Network
    >>                   &nbs= p;  storage
    >>                   &nbs= p;              services exist already, s= o just
    >>               implementing one >>                   &nbs= p;  of those
    >>                   &nbs= p;         would
    >>                   &nbs= p;              not advance VWRAP.
    >>
    >>                   &nbs= p;            * We need to examine how various=
    >>        deployment
    >>               patterns
    >>                   &nbs= p;  will
    >>                   &nbs= p;         use the
    >>                   &nbs= p;              asset services, and how t= he
    >>        /multiple/ asset
    >>                   &nbs= p;  services that
    >>                   &nbs= p;              interop introduces are ha= ndled.=EF=BF=BD I am
    >>               working on this >>                   &nbs= p;         currently.
    >>
    >>
    >>                   &nbs= p;         None of the above is particularly hard.=EF=BF= =BD
    >>        I think it
    >>                   &nbs= p;  won't be
    >>                   &nbs= p;         long before we have a scheme worked out
    >>        and are
    >>               ready
    >>                   &nbs= p;  for some
    >>                   &nbs= p;         implementation work.
    >>
    >>
    >>                   &nbs= p;         Morgaine.
    >>
    >>
    >>
    >>
    >>
    >>  -------------------------------------------------------------= -----------
    >>
    >>
    >>
    >>
    >>  _______________________________________________
    >>                   &nbs= p;         vwrap mailing list
    >>                   &nbs= p;         vwrap@ietf.org <mailto:vwrap@ietf.org><= br> >>        <mailto:vwrap@ietf.org <mailto:vwrap@ietf.o= rg>>
    >>               <mailto:vwrap@ietf.org<= /a> <mailto:vwrap@ietf.org>
    >>        <mailto:vwrap@ietf.org <mailto:vwrap@ietf.o= rg>>>
    >>                   &nbs= p;  <mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>
    >>        <mailto:vwrap@ietf.org <mailto:vwrap@ietf.o= rg>>
    >>               <mailto:vwrap@ietf.org<= /a> <mailto:vwrap@ietf.org>
    >>        <mailto:vwrap@ietf.org <mailto:vwrap@ietf.o= rg>>>>
    >>
    >>
    >>                   &nbs= p;         https://www.ietf.org/mailman/listinfo/vwrap
    >>                   &nbs= p;                     &nb= sp;          --     ---
    >> https://twitter.com/Dzonatas_Sol ---
    >>                   &nbs= p;     Web Development, Software Engineering,
    >>        Virtual Reality,
    >>                   &nbs= p;  Consultant
    >>
    >>
    >>
    >>  -------------------------------------------------------------= -----------
    >>
    >>                   &nbs= p;  _______________________________________________
    >>                   &nbs= p;  vwrap mailing list
    >>                   &nbs= p;  vwrap@ietf.org <mailto:vwrap@ietf.org>
    >>        <mailto:vwrap@ietf.org <mailto:vwrap@ietf.o= rg>>
    >>               <mailto:vwrap@ietf.org<= /a> <mailto:vwrap@ietf.org>
    >>        <mailto:vwrap@ietf.org <mailto:vwrap@ietf.o= rg>>>
    >>                   &nbs= p;  https://www.i= etf.org/mailman/listinfo/vwrap
    >>
    >>                  -- &n= bsp;   --- https://twitter.com/Dzonatas= _Sol ---
    >>                  Web D= evelopment, Software Engineering, Virtual Reality,
    >>               Consultant
    >>
    >>
    >>
    >>  -------------------------------------------------------------= -----------
    >>
    >>               __________________= _____________________________
    >>               vwrap mailing list=
    >>               vwrap@ietf.org <= ;mailto:= vwrap@ietf.org>
    >>        <mailto:vwrap@ietf.org <mailto:vwrap@ietf.o= rg>>
    >>               https://www.ietf.org/mailman/listinfo/vw= rap
    >>
    >>
    >>           --     --- https://twitter.com/Dzonatas_Sol ---
    >>           Web Development, Software Engine= ering, Virtual Reality,
    >>        Consultant
    >>
    >>
    >>
    >>  -------------------------------------------------------------= -----------
    >>
    >>        ________________________________________= _______
    >>        vwrap mailing list
    >>        vwrap@ietf.org <mailto:vwrap@ietf.org= >
    >>        https://www.ietf.org/mailman/listinfo/vwrap
    >>
    >>
    >>
    >>    --     --- h= ttps://twitter.com/Dzonatas_Sol ---
    >>    Web Development, Software Engineering, Virtual Reality= , Consultant
    >>
    >>
    >> -------------------------------------------------------------------= -----
    >>
    >> _______________________________________________
    >> vwrap mailing list
    >> vwrap@ietf.org
    >> https://www.i= etf.org/mailman/listinfo/vwrap
    >>
    >
    >
    > --
    > --- https://twitter.com/Dzonatas_Sol ---
    > Web Development, Software Engineering, Virtual Reality, Consultant
    >
    > _______________________________________________
    > vwrap mailing list
    > vwr= ap@ietf.org
    > https://www.ietf.= org/mailman/listinfo/vwrap
    >

    ____________________= ___________________________
    vwrap mailing list
    vwrap@ietf.org
    https://www.ietf.org/mai= lman/listinfo/vwrap
    = --Apple-Mail-1--430177921-- From vaughn.deluca@gmail.com Fri Apr 8 09:38:26 2011 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 0CFB03A694F for ; Fri, 8 Apr 2011 09:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=-1.635, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] 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 DR3aslWDAtOD for ; Fri, 8 Apr 2011 09:38:21 -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 38C213A6889 for ; Fri, 8 Apr 2011 09:38:20 -0700 (PDT) Received: by ewy19 with SMTP id 19so1347745ewy.31 for ; Fri, 08 Apr 2011 09:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=RGdP+SGaMn2HcxcaarfCwLq3C7f4GSSlztHS+vmaiCs=; b=HbJO/TC4s4w8tTtMcSYZ8Y1phVXtpuOTqe1tj/ltSFEyCNF5hMZCtRwvE5F7x+Tpeo uYZQCt0KyjZJg/Hl2f+l9jpTKm0NWzMZfeL8SAdKwd1sfHDKnJZtECOx9KF6BfymdXXH jxJl6jTOq0uF0yi8rPqLdWcmGjsy10L7EtvDU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=h27ZjpzWEwhrm0jtlrJoPSadCI/T4eFg88i/UGsdT6WmdCzI1dtRohUPiscfpiczzB RJdbpXNm4DBGE6fL3GpY1uHgIYVmcUTPi4zWyY8SgNbkUVVUdyKJXdj+MpAhNp3ca7Jk hDJFgBW2pWrcQFFlkGoCJJOGv8oG+A7qO8Zc0= MIME-Version: 1.0 Received: by 10.213.0.202 with SMTP id 10mr1074099ebc.79.1302280803636; Fri, 08 Apr 2011 09:40:03 -0700 (PDT) Received: by 10.213.17.17 with HTTP; Fri, 8 Apr 2011 09:40:03 -0700 (PDT) In-Reply-To: References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> Date: Fri, 8 Apr 2011 18:40:03 +0200 Message-ID: From: Vaughn Deluca To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cdfd9f8b2d5a604a06ae072 Subject: Re: [vwrap] [wvrap] Simulation consistency 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, 08 Apr 2011 16:38:26 -0000 --000e0cdfd9f8b2d5a604a06ae072 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable VWRAP services high level message flow (preliminary diagram draft) see http://trac.tools.ietf.org/wg/vwrap/trac/attachment/wiki/Diagrams/VWRAP_Flo= wExample_VD1.pdf The main reason that i am submitting this in spite of my lack of formal expertise is that the group in my view badly needs a solid basis for discussion and preventing endless repeating loops. This example is probably wrong in many ways, but its better than what we have publicly available on interop now (although Morgaine is working on something along the lines of the recent discussions here) I hope this diagram will give us a base for discussion. I could have done m= y homework better by researching the old OGP stuff in more depth, and i probably will do so in the future , but for now I just tried to followed the general principles as far as i understand them, to see what response that yields from the group. In other words,I try to let the group educate m= e :p Note that in my view all services are equal, in principle it does not matter in what "domain" they run, since trust and policy are fully localized. It is however very possible to have internal shortcuts in the services to speed up processing. In the example I opted for an external Agent service, but I could as well have incorporated that in the set of local services. As indicated above all services could also be run by different organisations, true to what VWRAP stands for. Its all up to the deployer, including a user at home who might want to run a full world for family and friends. Those friends might try to use that agent service to venture out in the virtual universe. I envision that the final identity provider is external, using OpenID and OAut or whatever other magic that I do not yet fully understand exists ou= t there. The example has 3 main purposes: - Provide a reference for discussion - Illustrates the use case of tourism, and *true* interop. - Illustrate consistency problems along the lines discussed here higher up in this tread, as well as the "slashdot" problem that Morgaine outlined so clearly. The message flow assumes an avatar already present in some region, (a small scale local home region in this case, but that is by no means essential, it could be a build in region in the viewer or a big commercial region). The user is preparing for a trip to immersive world, and after some outfit adjustments moves over. Finally i apologize for for the simplistic notation used here. I simply add the most relevant parameters passed in square brackets to a keyword specifying the nature of the message. Please improve on that where needed. So here we go, the avatar is prepare for a visit to "immersive world" 0) Viewer, here is an update of the state of the world your agent is in, please render. 1) Agent service, I will go in my Zodiac dress that i keep in the "Amazin= g assets" service. 2) Asset service A, please send a cap for Z, here are my credentials 3) Your fine, here is the cap 4) Local region, can you please put this on my agent, i included the cap. 5) Hello asset service A, i need Z, here is the cap 6) Cap is good, data coming up, have fun. 7) Agent service, your agent is now wearing Z 8) Viewer, your avatar is now wearing Z User: Hmm, amazing inventory has not been *that* amazing lately. 'll make a backup, just in case 9) Hello asset service A, please send me a cap for Z, here are my credentials 10) Your fine, here is the cap 11) Local asset storage, please store Z for me, here is the cap to get it 12) Hello asset service A, i want Z, here is the cap 13) Cap is good, data coming up, have fun. 14) Viewer, Z is now stored for you User: I am Ready!, Lets try to get to immersive world! 15) Hello immersive world, can i get in? Here are my credentials, and a lis= t of my stuff. 16) Asset service A, please send me a cap for X, here are my credentials (I want this cap for consistency) 17) Your fine, here is the cap 18) Asset service B, please send me a cap for Y, here are my credentials (I want this cap for consistency) 19) Very sorry, but your not one of us, you can't have Y 20) Asset service B, please send me a cap for Z, here are my credentials (I want a cap for consistency) [Region service: Timeout... amazing inventory must be overloaded.. oh well... ] 21) Agent service, you wanted to send somebody over, here are your permissions. 22) Viewer, you asked for a transfer try, here are your results User thinks: Crap! Big asset service does not allow me to take my yellow stockings! And Amazing assets failed to deliver my zodiac dress. At least i made a backup of that dress! 23) 'll take the yellow stockings off... 24) ... done ('ll trash them here and now, forever, who needs stuff you can't use!) 25) The zodiac dress was not delivered by Big assets service, but i have a local copy! 26) Local Asset service, please send me Z, here are my credentials 27) I dont know you, but I 'll trust you, here is the cap, but you better store the data, its single use, i need to protect myself. 28) Local region, can you please put this on my agent, i include the cap. 29) Local Asset service, i need Z, here is the cap 30) Cap is good, data coming up, have fun. 31) Cap was only good for one time, I made a copy, but my policy is to only grant you fair use rights, at a later time i might even tell you to replace the dress. 32) Viewer, you can wear Z for now, but the asset service granted only fair use, i might ask you to replace the dress at a later time. 33) Ready at last! Off to immersive world!, I hope its not to crowded there or 'll loose my dress... 34) Hello immersive world, here are my credentials, and a list of stuff i want to bring 35) Hello asset service A, please send me a cap for X, here are my credentials [darn, I should have kept that cap from last time..] 36) Your fine, here is the cap. [Region service finds fair-use warning on Z and decides to make its own copy] 37) Hello Local region, can i still have Z? Here is the cap 38) Cap is still good, data coming up, have fun. [Region service stores asset in private storage, providing a cap to replace the fair use one] 39) Agent service, you wanted to send somebody over, here are your permissions & info. 40) Hello immersive world, just get me there, and use what you can 41) Placement done, Z is currently buffered by us as wel, you need to get details for X, have fun. 42) You are now in immersive world, your dress is buffered there as well, but you need to get X! 43) Hello asset service A, i want X, here is the cap 44) Cap is good, data coming up, have fun. 45) Viewer, here is an update of the state of the world your agent is in, please render. As far as I can see this conforms fully to our charter, and i hope it is possible to use large portions of the existing code bases. However, as said above, i did not really try to capture the old thinking, and I also might have misconceptions about the way to do these things in general. Looking forward to constructive comments. -- Vaughn On Sun, Apr 3, 2011 at 8:38 PM, Vaughn Deluca wrot= e: > Thanks for the pointers. I have a busy week in RL in front of me, so i > wont have to much time to respond the next few days, however, i intend to > start doing the following things: > > - Produce a visual that reflects my thinking, i.e. an illustration of my > response to Morgaine's itemlist above. > - Read up on the older notes, as well as more reading in the list archiv= e > - Try to make a summary for the wiki > > Regarding the use of domain, I think services are eventually what counts, > but its all terminology. The way I read the AWG diagrams is that the agen= t > domain is actually a cluster of tightly integrated services. When the > functionality of each sub-service is described properly and with uniform > interfaces the domain will slowly dissolve. But let not get ahead of out > selfs. We should put up some clear descriptions on the wiki for our views= on > this, and *after* that we can decide what we need and what can go. > > Its been a very useful and illuminating weekend for me, and i am a lot mo= re > optimistic about the future of vwrap than two weeks ago. > > -- Vaughn > > > > On Sun, Apr 3, 2011 at 7:20 PM, Dzonatas Sol wrote: > >> Probably easy as suggested in other terms here on this list, as how the >> client contacts the asset services now in the regions. The newer issue i= s to >> unitize that asset services. Since their is proprietary (legacy) code th= en >> we can't expect that to change, and some form of proxy is of need. Whate= ver >> works best, I tried to narrow it down to suggestions here. >> >> Eventually, the agent domain is ideal to handle the direction of the ass= et >> services. This concept, unfortunately, ended support awhile ago with cha= nges >> in LL. >> Also see; http://wiki.secondlife.com/wiki/Agent_Domain >> And: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset (warn: >> unstructured collaborative notes, dumped on me and I tried to fix) >> >> I tried to find previous visuals. >> >> I'd imagine the agent domain could grow out of unitized versions of asse= t >> services. Despite that, I think that concept helps view where we were at= in >> discussion and what didn't happen. >> >> Vaughn Deluca wrote: >> >>> Hi=EF=BF=BDDzonatas >>> >>> Can you expand on that, what would be needed for legacy support in VWAP >>> terms=EF=BF=BD?, >>> If i want to read up on how the=EF=BF=BDasset server may proxy the simu= lator, >>> what would you recommend me to read? >>> >>> -- Vaughn >>> >>> On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol >> dzonatas@gmail.com>> wrote: >>> >>> Some stated the proxy-to-asset-server is built into the sim; >>> however, keep in mind possible legacy support where the asset >>> server may proxy the simulator. >>> >>> >>> Dzonatas Sol wrote: >>> >>> Somehow I feel the basic asset server being able to login and >>> download assets is now priority, yet I also wondered the best >>> way to patch this into the current mode of viewers. >>> >>> Maybe offer (1) by proxy (sim-side) and (2) by patch >>> (viewer-side) that either of these two are optional and >>> neither are mandatory for now. Thoughts? >>> >>> Israel Alanis wrote: >>> >>> >>> > when designing for scalability, the model to bear in >>> mind is ... >>> >>> Well, there are a lot of different models to keep in mind, >>> and many different use cases. One particular use case to >>> keep in mind is: "User acquires new outfit, and wants to >>> 'show it off' in a highly populated region". >>> >>> > Both worlds and asset services may include commercial, >>> community, and personal services >>> >>> Yes, yes and yes. I'm particularly concerned about how the >>> model affects the ability to host personal asset services. >>> >>> > a proxying region, which would get slammed for every >>> asset worn by every avatar present. >>> >>> Granted the collection of services that are provided by >>> the region need to be scaled to meet the demands of that >>> region. That's all part of capacity planning. >>> >>> > regions run many different CPU-intensive tasks, >>> including physics simulation and server-side scripting, >>> and absolutely cannot afford to serve assets too >>> Well... who said the same CPU's have to do proxying, >>> physics simulation and server-side scripting? Asset >>> proxying is a different service than physics simulation >>> and can be on separate hardware, could make use of >>> geographically distributed caching, and in certain >>> deployment patterns, the same caching services could be >>> shared by different regions. (Server-side scripting is a >>> discussion for another day). >>> >>> > This is why we have to go parallel... >>> >>> Totally agree, and a proxying model could and should also >>> take advantage of parallelism. >>> >>> > I think you're wrong that it has to cost much money. ?vs? >>> > It costs money to host a high performance and scalable >>> asset service and a high bandwidth network to handle the >>> traffic. =EF=BF=BDA *lot* of money. >>> I think what you're saying is: "It costs a lot of money to >>> build a scalable asset service, but if assets are spread >>> throughout the internet they don't have to be scalable." >>> But that's not quite right. You're opening up every asset >>> server to the VW equivalent of being slashdotted, so are >>> you sure you're not forcing *every* asset service to be >>> scalable and handle a lot of bandwith and network traffic? >>> It's the exact opposite of your intention, but I think >>> that's the result, all the same. >>> >>> This particular design decision has a big effect on the >>> economics of the VW infrastructure. I'd rather the >>> economics to work out such that a region provider who >>> wishes to build a region that supports a small population, >>> can do so economically. A region that wants to host a >>> *large* population has to bear that cost of providing that >>> scalable asset service. >>> I want the economics of hosting a small asset service to >>> be a non-issue (as to best promote creation and >>> creativity). Creating a high bar to provide asset services >>> will mean that service will cost money and people >>> shouldn't have to pay money just to create or own VW >>> objects (I'm using 'own' here to refer to maintaining >>> their existence, I'm not trying to make a >>> 'leftist'/'communist' statement about ownership ;) >>> >>> - Izzy >>> >>> >>> On Apr 2, 2011, at 3:58 PM, Morgaine wrote: >>> >>> Izzy, when designing for scalability, the model to >>> bear in mind is that of seasoned virtual world >>> travelers whose inventories contain assets from many >>> different worlds, those assets being served by many >>> different asset services. =EF=BF=BDBoth worlds and asset >>> services may include commercial, community, and >>> personal services, and as the metaverse grows, that >>> set is highly likely to become progressively less >>> clustered and more diverse. >>> >>> When those seasoned travelers click on an advertised >>> VW link and perform an inter-world teleport to one >>> particular world's region to share an experience, >>> their "worn" assets (the only ones of interest to the >>> region) will contain references to asset services >>> spread widely across the Internet. =EF=BF=BDThe fetches = by the >>> travelers' clients occur over many parallel paths from >>> clients to asset services, so one can reasonably >>> expect reduced network contention and reduced asset >>> server loading because they are both spread out over >>> however many asset services are being referenced by >>> the overall set of assets in the region. >>> >>> This is very different to the case of a proxying >>> region, which would get slammed for every asset worn >>> by every avatar present. =EF=BF=BDIn our current archite= cture, >>> regions run many different CPU-intensive tasks, >>> including physics simulation and server-side >>> scripting, and absolutely cannot afford to serve >>> assets too unless your scalability requirements are >>> very low indeed, ie. just a few dozen avatars of >>> today's kind. =EF=BF=BDWe've hit the ceiling already on = region >>> scalability done that way. =EF=BF=BDThere is nowhere to = go in >>> that direction at all beyond improving the code like >>> Intel demonstrated, and that work is subject to a law >>> of diminishing returns. >>> >>> This is why we have to go parallel, and I think you're >>> wrong that it has to cost much money. =EF=BF=BDAs we spr= ead >>> the load across more and more asset services, we are >>> simply better utilizing all the hardware that's >>> already out there on the Internet, at least in respect >>> of community and private resources. =EF=BF=BDBut add to = the >>> community and private resources the commercial asset >>> services that are likely to appear to exploit this >>> opportunity, and not only will the number of asset >>> services leap, but the power of each one will rocket >>> too, because, after all, these businesses will be >>> heavily optimized for the job. >>> >>> As to why a world would want clients to access >>> external asset services instead of providing its own >>> implementation, that's an easy question. =EF=BF=BDIt cos= ts >>> money to host a high performance and scalable asset >>> service and a high bandwidth network to handle the >>> traffic. =EF=BF=BDA *lot* of money. =EF=BF=BDIn contrast= , it costs a >>> world nothing to let others serve the assets to >>> clients. =EF=BF=BDAnd that matters to the bottom line. >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>> >>> On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis >>> >>> >> >>> >> wrote: >>> >>> =EF=BF=BD =EF=BF=BD> As always though, it's a trade-off,= since the >>> proxied design >>> =EF=BF=BD =EF=BF=BDhas very poor scalability compared to= the >>> distributed one. >>> >>> =EF=BF=BD =EF=BF=BDI don't agree with that... If a user = enters a >>> highly populated >>> =EF=BF=BD =EF=BF=BDregion, >>> =EF=BF=BD =EF=BF=BDevery other client is going to (could= and should be >>> trying to) >>> =EF=BF=BD =EF=BF=BDhit the >>> =EF=BF=BD =EF=BF=BDasset server(s) for the assets that t= he user is >>> wearing (assuming >>> =EF=BF=BD =EF=BF=BDthey're not cached locally). =EF=BF= =BDEvery asset server >>> has to be scaled up >>> =EF=BF=BD =EF=BF=BDto the point that it can handle that = load from all >>> over... >>> >>> =EF=BF=BD =EF=BF=BDIf I'm hosting a region that supports= 10s of >>> thousands of >>> =EF=BF=BD =EF=BF=BDsimultaneous >>> =EF=BF=BD =EF=BF=BDusers (thinking of the future), I alr= eady have to >>> scale to meet that >>> =EF=BF=BD =EF=BF=BDdemand. If the region is proxying the= assets, then, >>> yes the >>> =EF=BF=BD =EF=BF=BDregion has >>> =EF=BF=BD =EF=BF=BDto be scaled to meet that asset deman= d too, but it >>> already has to be >>> =EF=BF=BD =EF=BF=BDscaled to meet other demands of being= a region >>> server... and why is >>> =EF=BF=BD =EF=BF=BDscaling those asset proxy services ha= rd? =EF=BF=BDIt's >>> going to cost $, >>> =EF=BF=BD =EF=BF=BDbut is >>> =EF=BF=BD =EF=BF=BDnot technically challenging. So, if I= want to host >>> a region like >>> =EF=BF=BD =EF=BF=BDthat... sure it will cost me, but the= simulation >>> will be consistent >>> =EF=BF=BD =EF=BF=BDand users will be able to participate= equally, >>> regardless of the >>> =EF=BF=BD =EF=BF=BDcapabilities of their individual asse= t services. >>> >>> >>> >>> >>> =EF=BF=BD =EF=BF=BDOn Fri, Apr 1, 2011 at 11:55 PM, Morg= aine >>> =EF=BF=BD =EF=BF=BD>> >>> =EF=BF=BD =EF=BF=BD>> >>> >> wrote: >>> =EF=BF=BD =EF=BF=BD> Every design choice results in a tr= ade-off, >>> Vaughn, improving >>> =EF=BF=BD =EF=BF=BDone thing at >>> =EF=BF=BD =EF=BF=BD> the expense of something else. =EF= =BF=BDIf every time we >>> offered a >>> =EF=BF=BD =EF=BF=BDservice we had to >>> =EF=BF=BD =EF=BF=BD> inform its users about the downside= s of all the >>> trade-offs we >>> =EF=BF=BD =EF=BF=BDhave made, >>> =EF=BF=BD =EF=BF=BD> they would have an awful lot to rea= d. ;-) >>> =EF=BF=BD =EF=BF=BD> >>> =EF=BF=BD =EF=BF=BD> The specific trade-off that you are= discussing is no >>> =EF=BF=BD =EF=BF=BDdifferent. =EF=BF=BDA region >>> =EF=BF=BD =EF=BF=BD> that proxies all content has the "b= enefit" of >>> acquiring control >>> =EF=BF=BD =EF=BF=BDfrom the >>> =EF=BF=BD =EF=BF=BD> asset servers over the items in the= region, so >>> that it can >>> =EF=BF=BD =EF=BF=BDensure that >>> =EF=BF=BD =EF=BF=BD> everyone in the region not only obt= ains the items >>> but obtains >>> =EF=BF=BD =EF=BF=BDthe same items >>> =EF=BF=BD =EF=BF=BD> as everyone else. =EF=BF=BDThat doe= s indeed provide a >>> greater guarantee of >>> =EF=BF=BD =EF=BF=BD> consistency than a deployment in wh= ich the region >>> only passes >>> =EF=BF=BD =EF=BF=BDasset URIs to >>> =EF=BF=BD =EF=BF=BD> clients who then fetch the items fr= om asset services >>> =EF=BF=BD =EF=BF=BDseparately. =EF=BF=BDAs always >>> =EF=BF=BD =EF=BF=BD> though, it's a trade-off, since the= proxied >>> design has very >>> =EF=BF=BD =EF=BF=BDpoor scalability >>> =EF=BF=BD =EF=BF=BD> compared to the distributed one. >>> =EF=BF=BD =EF=BF=BD> >>> =EF=BF=BD =EF=BF=BD> If we're going to warn users of the= potential for >>> inconsistency >>> =EF=BF=BD =EF=BF=BDin the >>> =EF=BF=BD =EF=BF=BD> distributed deployment as you sugge= st, are we >>> also going to >>> =EF=BF=BD =EF=BF=BDwarn them of >>> =EF=BF=BD =EF=BF=BD> non-scalability in the proxied one?= =EF=BF=BDI really >>> don't see much >>> =EF=BF=BD =EF=BF=BDmerit in the >>> =EF=BF=BD =EF=BF=BD> idea of warning about design choice= s. =EF=BF=BDMany such >>> choices are >>> =EF=BF=BD =EF=BF=BDtechnical, and >>> =EF=BF=BD =EF=BF=BD> the issues are quite likely to be o= f little >>> interest to >>> =EF=BF=BD =EF=BF=BDnon-technical users >>> =EF=BF=BD =EF=BF=BD> anyway. =EF=BF=BDIn any case, the b= etter services are >>> likely to provide >>> =EF=BF=BD =EF=BF=BDsuch >>> =EF=BF=BD =EF=BF=BD> information in their online documen= tation, I >>> would guess. >>> =EF=BF=BD =EF=BF=BD> >>> =EF=BF=BD =EF=BF=BD> You mentioned users "voting with th= eir feet" or >>> choosing to >>> =EF=BF=BD =EF=BF=BDaccept the risk >>> =EF=BF=BD =EF=BF=BD> of inconsistency. =EF=BF=BDWell tha= t will happen anyway, >>> when services >>> =EF=BF=BD =EF=BF=BDfail and >>> =EF=BF=BD =EF=BF=BD> users get annoyed. =EF=BF=BDIf some= asset services refuse >>> to send the >>> =EF=BF=BD =EF=BF=BDrequested >>> =EF=BF=BD =EF=BF=BD> items to some users, those services= will get a >>> bad reputation >>> =EF=BF=BD =EF=BF=BDand people >>> =EF=BF=BD =EF=BF=BD> will choose different asset service= s instead. >>> =EF=BF=BDLikewise, if a >>> =EF=BF=BD =EF=BF=BDworld service >>> =EF=BF=BD =EF=BF=BD> proxies everything and so it can't = handle a large >>> number of >>> =EF=BF=BD =EF=BF=BDassets or of >>> =EF=BF=BD =EF=BF=BD> people, users will get annoyed at t= he lag and will go >>> =EF=BF=BD =EF=BF=BDelsewhere. =EF=BF=BDThis user >>> =EF=BF=BD =EF=BF=BD> evaluation and "voting with their f= eet" happens >>> already with >>> =EF=BF=BD =EF=BF=BDonline services >>> =EF=BF=BD =EF=BF=BD> all over the Internet, and I am sur= e that this >>> human process >>> =EF=BF=BD =EF=BF=BDwill continue >>> =EF=BF=BD =EF=BF=BD> to work when the services are asset= and region >>> services. >>> =EF=BF=BD =EF=BF=BD> >>> =EF=BF=BD =EF=BF=BD> Back in September 2010, I wrote thi= s post which >>> proposes that >>> =EF=BF=BD =EF=BF=BDwe use in >>> =EF=BF=BD =EF=BF=BD> VWRAP a form of asset addressing th= at provides >>> massive >>> =EF=BF=BD =EF=BF=BDscalability at the >>> =EF=BF=BD =EF=BF=BD> same time as a very high degree of = resilience -- >>> =EF=BF=BD =EF=BF=BD> >>> =EF=BF=BD >>> =EF=BF=BD >>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >>> =EF=BF=BD =EF=BF=BD. =EF=BF=BDIt is >>> =EF=BF=BD =EF=BF=BD> based on the concept of the URI con= taining a host >>> part and a >>> =EF=BF=BD =EF=BF=BDhash part, >>> =EF=BF=BD =EF=BF=BD> where the hash is generated (once, = at the time of >>> storage to >>> =EF=BF=BD =EF=BF=BDthe asset >>> =EF=BF=BD =EF=BF=BD> service) using a specified digest a= lgorithm over >>> the content of >>> =EF=BF=BD =EF=BF=BDthe asset >>> =EF=BF=BD =EF=BF=BD> being referenced. =EF=BF=BDYou may = wish to note that if >>> this design >>> =EF=BF=BD =EF=BF=BDwere used, the >>> =EF=BF=BD =EF=BF=BD> failure of an asset service to deli= ver a >>> requested item would >>> =EF=BF=BD =EF=BF=BDresult in a >>> =EF=BF=BD =EF=BF=BD> failover request for the item to on= e or more >>> backup services, >>> =EF=BF=BD =EF=BF=BDusing the same >>> =EF=BF=BD =EF=BF=BD> hash part but with a different host= address. >>> =EF=BF=BD =EF=BF=BD> >>> =EF=BF=BD =EF=BF=BD> This can go some way towards overco= ming the >>> problem that you >>> =EF=BF=BD =EF=BF=BDthink might >>> =EF=BF=BD =EF=BF=BD> occur when assets are fetched by cl= ients from >>> asset services >>> =EF=BF=BD =EF=BF=BDdirectly. >>> =EF=BF=BD =EF=BF=BD> Although it won't help when the mis= sing item is >>> available from >>> =EF=BF=BD =EF=BF=BDonly a single >>> =EF=BF=BD =EF=BF=BD> asset service, it will help in many= other cases, >>> and it will >>> =EF=BF=BD =EF=BF=BDcompensate for >>> =EF=BF=BD =EF=BF=BD> service failures and network outage= s >>> automatically at the same >>> =EF=BF=BD =EF=BF=BDtime. >>> =EF=BF=BD =EF=BF=BD> >>> =EF=BF=BD =EF=BF=BD> PS. This design for hash-based asse= t addressing >>> is already >>> =EF=BF=BD =EF=BF=BDbeing tested by >>> =EF=BF=BD =EF=BF=BD> Mojito Sorbet in her experimental w= orld and >>> client. =EF=BF=BDIt would give >>> =EF=BF=BD =EF=BF=BD> VWRAP-based worlds an improved leve= l of service >>> availability, >>> =EF=BF=BD =EF=BF=BDso I think it >>> =EF=BF=BD =EF=BF=BD> should be a core feature of our pro= tocol. >>> =EF=BF=BD =EF=BF=BD> >>> =EF=BF=BD =EF=BF=BD> >>> =EF=BF=BD =EF=BF=BD> Morgaine. >>> =EF=BF=BD =EF=BF=BD> >>> =EF=BF=BD =EF=BF=BD> >>> =EF=BF=BD =EF=BF=BD> >>> =EF=BF=BD =EF=BF=BD> >>> =EF=BF=BD =EF=BF=BD> =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 >>> =EF=BF=BD =EF=BF=BD> >>> =EF=BF=BD =EF=BF=BD> On Fri, Apr 1, 2011 at 11:17 PM, Va= ughn Deluca >>> =EF=BF=BD =EF=BF=BD>> >>> >> >> >>> =EF=BF=BD =EF=BF=BD> wrote: >>> =EF=BF=BD =EF=BF=BD>> >>> =EF=BF=BD =EF=BF=BD>> This is a question i discussed wit= h Morgaine >>> off-list a while >>> =EF=BF=BD =EF=BF=BDago (I >>> =EF=BF=BD =EF=BF=BD>> intended to send it to the list bu= t pushed the >>> wrong button...) I >>> =EF=BF=BD =EF=BF=BD>> think we need to address this prob= lem, and >>> decide how to deal >>> =EF=BF=BD =EF=BF=BDwith it. >>> =EF=BF=BD =EF=BF=BD>> >>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDIn Davids deployment draf= t, section 7.3.1.1 an >>> overview is >>> =EF=BF=BD =EF=BF=BDgiven van >>> =EF=BF=BD =EF=BF=BD>> ways to deliver content to the reg= ion. One way >>> is only passing a >>> =EF=BF=BD =EF=BF=BD>> capability that allows access to (= part of) the >>> resource: >>> =EF=BF=BD =EF=BF=BD>> >>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD 7.3.1.1. =EF=BF=BDContent delivery models >>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD A range of possible represenations can >>> be passed to >>> =EF=BF=BD =EF=BF=BDa region for >>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD simulation. [...] The other end of the >>> delivery spectrum >>> =EF=BF=BD =EF=BF=BD>> involves passing >>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD only a URI or capability used to >>> access the rendering >>> =EF=BF=BD =EF=BF=BD>> information and a >>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD collision mesh,and related data for >>> physical simulation. >>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD In such a model, the client is >>> responsible for >>> =EF=BF=BD =EF=BF=BDfetching the >>> =EF=BF=BD =EF=BF=BD>> additional >>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD information needed to render the >>> item's visual >>> =EF=BF=BD =EF=BF=BDpresence from a >>> =EF=BF=BD =EF=BF=BD>> separate >>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD service. =EF=BF=BDThis fetch can be done >>> *under the >>> =EF=BF=BD =EF=BF=BDcredentials of the >>> =EF=BF=BD =EF=BF=BD>> end user* >>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD viewing the material [my emphasis--VD] >>> , and >>> =EF=BF=BD =EF=BF=BDdivorces the >>> =EF=BF=BD =EF=BF=BD>> simulation from >>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD the trust chain needed to manage >>> content. =EF=BF=BDAny >>> =EF=BF=BD =EF=BF=BDautomation >>> =EF=BF=BD =EF=BF=BD>> is done on a >>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD separate host which the content >>> creator or owner trusts, >>> =EF=BF=BD =EF=BF=BD>> interacting with the >>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD object through remoted interfaces. >>> =EF=BF=BD =EF=BF=BD>> >>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDI can see the need for su= ch a setup, however, i >>> feel we are >>> =EF=BF=BD =EF=BF=BD>> unpleasantly close to a situation = were the >>> coherence of the >>> =EF=BF=BD =EF=BF=BDsimulation >>> =EF=BF=BD =EF=BF=BD>> falls apart. >>> =EF=BF=BD =EF=BF=BD>> In this deployment pattern the reg= ion advertises >>> the presence >>> =EF=BF=BD =EF=BF=BDof the >>> =EF=BF=BD =EF=BF=BD>> asset, and *some* clients will be = able to get it >>> as expected, >>> =EF=BF=BD =EF=BF=BDwhile >>> =EF=BF=BD =EF=BF=BD>> -based on the arbitrary whims of t= he asset >>> service- others >>> =EF=BF=BD =EF=BF=BDmight not. >>> =EF=BF=BD =EF=BF=BD>> >>> =EF=BF=BD =EF=BF=BD>> My hope would be that after the as= set server >>> provides the >>> =EF=BF=BD =EF=BF=BDregion with >>> =EF=BF=BD =EF=BF=BD>> the capability to get the asset, i= t gives up >>> control. That >>> =EF=BF=BD =EF=BF=BDwould mean >>> =EF=BF=BD =EF=BF=BD>> that if the client finds the inven= tory server is >>> unwilling to >>> =EF=BF=BD =EF=BF=BDserve >>> =EF=BF=BD =EF=BF=BD>> the content - in spire of the regi= on saying it >>> is present-, >>> =EF=BF=BD =EF=BF=BDthe client >>> =EF=BF=BD =EF=BF=BD>> should be able to turn around ask = the *region* >>> for the asset, >>> =EF=BF=BD =EF=BF=BD(and get >>> =EF=BF=BD =EF=BF=BD>> is after all). >>> =EF=BF=BD =EF=BF=BD>> >>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDIf that is not the case, = -and there are >>> probably good reasons >>> =EF=BF=BD =EF=BF=BDfor the >>> =EF=BF=BD =EF=BF=BD>> deployment pattern as described- = =EF=BF=BDshouldn't we >>> *warn* clients >>> =EF=BF=BD =EF=BF=BDthat the >>> =EF=BF=BD =EF=BF=BD>> region might be inconsistent, so t= he users >>> behind the client >>> =EF=BF=BD =EF=BF=BDcan vote >>> =EF=BF=BD =EF=BF=BD>> with their feet, (or take the risk= )? >>> =EF=BF=BD =EF=BF=BD>> >>> =EF=BF=BD =EF=BF=BD>> --Vaughn >>> =EF=BF=BD =EF=BF=BD>> __________________________________= _____________ >>> =EF=BF=BD =EF=BF=BD>> vwrap mailing list >>> =EF=BF=BD =EF=BF=BD>> vwrap@ietf.org >>> > >>> >>> =EF=BF=BD =EF=BF=BD>> https://www.ietf.org/mailman/listi= nfo/vwrap >>> =EF=BF=BD =EF=BF=BD> >>> =EF=BF=BD =EF=BF=BD> >>> =EF=BF=BD =EF=BF=BD> ___________________________________= ____________ >>> =EF=BF=BD =EF=BF=BD> vwrap mailing list >>> =EF=BF=BD =EF=BF=BD> vwrap@ietf.org >>> > >>> >>> =EF=BF=BD =EF=BF=BD> https://www.ietf.org/mailman/listin= fo/vwrap >>> =EF=BF=BD =EF=BF=BD> >>> =EF=BF=BD =EF=BF=BD> >>> >>> >>> >>> >>> ----------------------------------------------------------------------= -- >>> >>> _______________________________________________ >>> vwrap mailing list >>> vwrap@ietf.org >>> https://www.ietf.org/mailman/listinfo/vwrap >>> =EF=BF=BD >>> >>> >>> >>> >>> >>> -- --- https://twitter.com/Dzonatas_Sol --- >>> Web Development, Software Engineering, Virtual Reality, Consultant >>> >>> _______________________________________________ >>> vwrap mailing list >>> vwrap@ietf.org >>> https://www.ietf.org/mailman/listinfo/vwrap >>> >>> >>> >> >> -- >> --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> > --000e0cdfd9f8b2d5a604a06ae072 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj5WV1JBUCBzZXJ2aWNlcyBoaWdoIGxldmVsIG1lc3NhZ2UgZmxvdyAocHJlbGltaW5hcnkg ZGlhZ3JhbSBkcmFmdCkgc2VlPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YSBocmVmPSJodHRw Oi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy92d3JhcC90cmFjL2F0dGFjaG1lbnQvd2lraS9EaWFn cmFtcy9WV1JBUF9GbG93RXhhbXBsZV9WRDEucGRmIj5odHRwOi8vdHJhYy50b29scy5pZXRmLm9y Zy93Zy92d3JhcC90cmFjL2F0dGFjaG1lbnQvd2lraS9EaWFncmFtcy9WV1JBUF9GbG93RXhhbXBs ZV9WRDEucGRmPC9hPjxicj4KPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgbWFpbiByZWFz b24gdGhhdCBpIGFtIHN1Ym1pdHRpbmcgdGhpcyBpbiBzcGl0ZSBvZiBteSBsYWNrIG9mIGZvcm1h bCBleHBlcnRpc2UgaXMgdGhhdCB0aGUgZ3JvdXAgaW4gbXkgdmlldyBiYWRseSBuZWVkcyBhIHNv bGlkIGJhc2lzIGZvciBkaXNjdXNzaW9uIGFuZCBwcmV2ZW50aW5nIGVuZGxlc3MgcmVwZWF0aW5n IGxvb3BzLiBUaGlzIGV4YW1wbGUgaXMgcHJvYmFibHkgd3JvbmcgaW4gbWFueSB3YXlzLCBidXQg aXRzIGJldHRlciB0aGFuIHdoYXQgd2UgaGF2ZSBwdWJsaWNseSBhdmFpbGFibGUgb24gaW50ZXJv cCBub3cgKGFsdGhvdWdoIE1vcmdhaW5lIGlzIHdvcmtpbmcgb24gc29tZXRoaW5nIGFsb25nIHRo ZSBsaW5lcyBvZiB0aGUgcmVjZW50IGRpc2N1c3Npb25zIGhlcmUpwqA8L2Rpdj4KPGRpdj48YnI+ PC9kaXY+PGRpdj5JIGhvcGUgdGhpcyBkaWFncmFtIHdpbGwgZ2l2ZSB1cyBhIGJhc2UgZm9yIGRp c2N1c3Npb24uIEkgY291bGQgaGF2ZSBkb25lIG15IGhvbWV3b3JrIGJldHRlciBieSByZXNlYXJj aGluZyB0aGUgb2xkIE9HUCBzdHVmZiBpbiBtb3JlIGRlcHRoLCBhbmQgaSBwcm9iYWJseSDCoHdp bGwgZG8gc28gaW4gdGhlIGZ1dHVyZSAsIGJ1dCBmb3Igbm93IEkganVzdCB0cmllZCB0byBmb2xs b3dlZCB0aGUgZ2VuZXJhbCBwcmluY2lwbGVzIGFzIGZhciBhcyBpIHVuZGVyc3RhbmQgdGhlbSwg dG8gc2VlIHdoYXQgcmVzcG9uc2UgdGhhdCB5aWVsZHMgZnJvbSB0aGUgZ3JvdXAuIEluIG90aGVy IHdvcmRzLEkgdHJ5IHRvIGxldCB0aGUgZ3JvdXAgZWR1Y2F0ZSBtZSA6cDwvZGl2Pgo8ZGl2Pjxi cj48L2Rpdj48ZGl2Pk5vdGUgdGhhdCBpbiDCoG15IHZpZXcgYWxsIHNlcnZpY2VzIGFyZSBlcXVh bCwgaW4gcHJpbmNpcGxlIGl0IGRvZXMgbm90IG1hdHRlciBpbiB3aGF0ICZxdW90O2RvbWFpbiZx dW90OyB0aGV5IHJ1biwgc2luY2UgdHJ1c3QgYW5kIHBvbGljeSBhcmUgZnVsbHkgbG9jYWxpemVk LiBJdCBpcyBob3dldmVyIHZlcnkgcG9zc2libGUgdG8gaGF2ZSBpbnRlcm5hbCBzaG9ydGN1dHMg aW4gdGhlIHNlcnZpY2VzIHRvIHNwZWVkIHVwIHByb2Nlc3NpbmcuwqA8L2Rpdj4KPGRpdj48YnI+ PC9kaXY+PGRpdj5JbiB0aGUgZXhhbXBsZSBJIG9wdGVkIGZvciBhbiBleHRlcm5hbCBBZ2VudCBz ZXJ2aWNlLCBidXQgSSBjb3VsZCBhcyB3ZWxsIGhhdmUgaW5jb3Jwb3JhdGVkIHRoYXQgaW4gdGhl IHNldCBvZiBsb2NhbCBzZXJ2aWNlcy4gQXMgaW5kaWNhdGVkIGFib3ZlIGFsbCBzZXJ2aWNlcyBj b3VsZCBhbHNvIGJlIHJ1biBieSBkaWZmZXJlbnQgb3JnYW5pc2F0aW9ucywgdHJ1ZSB0byB3aGF0 IFZXUkFQIHN0YW5kcyBmb3IuIEl0cyBhbGwgdXAgdG8gdGhlIGRlcGxveWVyLCBpbmNsdWRpbmcg YSB1c2VyIGF0IGhvbWUgd2hvIG1pZ2h0IHdhbnQgdG8gcnVuIGEgZnVsbCB3b3JsZCBmb3IgZmFt aWx5IGFuZCBmcmllbmRzLiBUaG9zZSBmcmllbmRzIG1pZ2h0IHRyeSB0byB1c2UgdGhhdCBhZ2Vu dCBzZXJ2aWNlIHRvIHZlbnR1cmUgb3V0IGluIHRoZSB2aXJ0dWFsIHVuaXZlcnNlLsKgPC9kaXY+ CjxkaXY+SSBlbnZpc2lvbiB0aGF0IHRoZSBmaW5hbCBpZGVudGl0eSDCoHByb3ZpZGVyIGlzIGV4 dGVybmFsLCB1c2luZyBPcGVuSUQgYW5kIE9BdXQgwqBvciB3aGF0ZXZlciBvdGhlciDCoG1hZ2lj IHRoYXQgSSBkbyBub3QgeWV0IGZ1bGx5IHVuZGVyc3RhbmQgZXhpc3RzIG91dCB0aGVyZS48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZSDCoGV4YW1wbGUgaGFzIDMgbWFpbiBwdXJwb3Nlczo8 L2Rpdj4KPGRpdj4tIMKgUHJvdmlkZSBhIHJlZmVyZW5jZSBmb3IgZGlzY3Vzc2lvbsKgPC9kaXY+ PGRpdj4tIElsbHVzdHJhdGVzIHRoZSB1c2UgY2FzZSBvZiB0b3VyaXNtLCBhbmQgKnRydWUqIGlu dGVyb3AuPC9kaXY+PGRpdj4tIElsbHVzdHJhdGUgY29uc2lzdGVuY3kgcHJvYmxlbXMgYWxvbmcg dGhlIGxpbmVzIGRpc2N1c3NlZCDCoGhlcmUgaGlnaGVyIHVwIGluIHRoaXMgdHJlYWQsIGFzIHdl bGwgYXMgdGhlICZxdW90O3NsYXNoZG90JnF1b3Q7IHByb2JsZW0gdGhhdCBNb3JnYWluZSBvdXRs aW5lZCBzbyBjbGVhcmx5LjwvZGl2Pgo8ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZSBtZXNzYWdlIGZs b3cgYXNzdW1lcyBhbiBhdmF0YXIgYWxyZWFkeSBwcmVzZW50IGluIHNvbWUgcmVnaW9uLCAoYSBz bWFsbCBzY2FsZSBsb2NhbCBob21lIHJlZ2lvbiBpbiB0aGlzIGNhc2UsIGJ1dCB0aGF0IGlzIGJ5 IG5vIG1lYW5zIGVzc2VudGlhbCwgaXQgY291bGQgYmUgYSBidWlsZCBpbiByZWdpb24gaW4gdGhl IHZpZXdlciBvciBhIGJpZyBjb21tZXJjaWFsIHJlZ2lvbikuIFRoZSB1c2VyIGlzIHByZXBhcmlu ZyBmb3IgYSB0cmlwIHRvIGltbWVyc2l2ZSB3b3JsZCwgYW5kIGFmdGVyIHNvbWUgb3V0Zml0IGFk anVzdG1lbnRzIG1vdmVzIG92ZXIuwqA8L2Rpdj4KPGRpdj48YnI+PC9kaXY+PGRpdj5GaW5hbGx5 IGkgYXBvbG9naXplIGZvciBmb3IgdGhlIHNpbXBsaXN0aWMgbm90YXRpb24gdXNlZCBoZXJlLiBJ IHNpbXBseSBhZGQgdGhlIG1vc3QgcmVsZXZhbnQgcGFyYW1ldGVycyBwYXNzZWQgaW4gc3F1YXJl IGJyYWNrZXRzIHRvIGEga2V5d29yZCBzcGVjaWZ5aW5nIHRoZSBuYXR1cmUgb2YgdGhlIG1lc3Nh Z2UuIFBsZWFzZSBpbXByb3ZlIG9uIHRoYXQgd2hlcmUgbmVlZGVkLjwvZGl2Pgo8ZGl2Pjxicj48 L2Rpdj48ZGl2PlNvIGhlcmUgd2UgZ28sIHRoZSBhdmF0YXIgaXMgwqBwcmVwYXJlIGZvciBhIHZp c2l0IHRvICZxdW90O2ltbWVyc2l2ZSB3b3JsZCZxdW90OzwvZGl2PjxkaXY+MCkgwqBWaWV3ZXIs IGhlcmUgaXMgYW4gdXBkYXRlIG9mIHRoZSBzdGF0ZSBvZiB0aGUgd29ybGQgeW91ciBhZ2VudCBp cyBpbiwgcGxlYXNlIHJlbmRlci48L2Rpdj48ZGl2PjEpIMKgQWdlbnQgc2VydmljZSwgSSB3aWxs IGdvIGluIG15IFpvZGlhYyBkcmVzcyB0aGF0IGkga2VlcCBpbiB0aGUgwqAmcXVvdDtBbWF6aW5n IGFzc2V0cyZxdW90OyBzZXJ2aWNlLjwvZGl2Pgo8ZGl2PjIpIMKgQXNzZXQgc2VydmljZSBBLCBw bGVhc2Ugc2VuZCBhIGNhcCBmb3IgWiwgaGVyZSBhcmUgbXkgY3JlZGVudGlhbHM8L2Rpdj48ZGl2 PjMpIMKgWW91ciBmaW5lLCBoZXJlIGlzIHRoZSBjYXA8L2Rpdj48ZGl2PjQpIMKgTG9jYWwgcmVn aW9uLCBjYW4geW91IHBsZWFzZSBwdXQgdGhpcyBvbiBteSBhZ2VudCwgaSBpbmNsdWRlZCB0aGUg Y2FwLjwvZGl2PjxkaXY+NSkgwqBIZWxsbyBhc3NldCBzZXJ2aWNlIEEsIGkgbmVlZCBaLCBoZXJl IGlzIHRoZSBjYXA8L2Rpdj4KPGRpdj42KSDCoENhcCBpcyBnb29kLCBkYXRhIGNvbWluZyB1cCwg aGF2ZSBmdW4uPC9kaXY+PGRpdj43KSDCoEFnZW50IHNlcnZpY2UsIHlvdXIgYWdlbnQgaXMgbm93 IHdlYXJpbmcgWjwvZGl2PjxkaXY+OCkgwqBWaWV3ZXIsIHlvdXIgYXZhdGFyIGlzIG5vdyB3ZWFy aW5nIFo8L2Rpdj48ZGl2PsKgwqAgwqBVc2VyOiBIbW0sIGFtYXppbmcgaW52ZW50b3J5IGhhcyBu b3QgYmVlbiAqdGhhdCogYW1hemluZyBsYXRlbHkuICYjMzk7bGwgbWFrZSBhIGJhY2t1cCwganVz dCBpbiBjYXNlPC9kaXY+CjxkaXY+OSkgwqBIZWxsbyBhc3NldCBzZXJ2aWNlIEEsIHBsZWFzZSBz ZW5kIG1lIGEgY2FwIGZvciBaLCBoZXJlIGFyZSBteSBjcmVkZW50aWFsczwvZGl2PjxkaXY+MTAp IFlvdXIgZmluZSwgaGVyZSBpcyB0aGUgY2FwPC9kaXY+PGRpdj4xMSkgTG9jYWwgYXNzZXQgc3Rv cmFnZSwgcGxlYXNlIHN0b3JlIFogZm9yIG1lLCBoZXJlIGlzIHRoZSBjYXAgdG8gZ2V0IGl0PC9k aXY+PGRpdj4xMikgSGVsbG8gYXNzZXQgc2VydmljZSBBLCBpIHdhbnQgWiwgaGVyZSBpcyB0aGUg Y2FwPC9kaXY+CjxkaXY+MTMpIENhcCBpcyBnb29kLCBkYXRhIGNvbWluZyB1cCwgaGF2ZSBmdW4u PC9kaXY+PGRpdj4xNCkgVmlld2VyLCBaIGlzIG5vdyBzdG9yZWQgZm9yIHlvdcKgPC9kaXY+PGRp dj7CoMKgIMKgVXNlcjogSSBhbSBSZWFkeSEsIExldHMgdHJ5IHRvIGdldCB0byBpbW1lcnNpdmUg d29ybGQhPC9kaXY+PGRpdj4xNSkgSGVsbG8gaW1tZXJzaXZlIHdvcmxkLCBjYW4gaSBnZXQgaW4/ IEhlcmUgYXJlIG15IGNyZWRlbnRpYWxzLCBhbmQgYSBsaXN0IG9mIG15IHN0dWZmLjwvZGl2Pgo8 ZGl2PjE2KSBBc3NldCBzZXJ2aWNlIEEsIHBsZWFzZSBzZW5kIG1lIGEgY2FwIGZvciBYLCBoZXJl IGFyZSBteSBjcmVkZW50aWFscyAoSSB3YW50IHRoaXMgY2FwIGZvciBjb25zaXN0ZW5jeSk8L2Rp dj48ZGl2PjE3KSBZb3VyIGZpbmUsIGhlcmUgaXMgdGhlIGNhcDwvZGl2PjxkaXY+MTgpIEFzc2V0 IHNlcnZpY2UgQiwgcGxlYXNlIHNlbmQgbWUgYSBjYXAgZm9yIFksIGhlcmUgYXJlIG15IGNyZWRl bnRpYWxzIChJIHdhbnQgdGhpcyBjYXAgZm9yIGNvbnNpc3RlbmN5KTwvZGl2Pgo8ZGl2PjE5KSBW ZXJ5IHNvcnJ5LCBidXQgeW91ciBub3Qgb25lIG9mIHVzLCB5b3UgY2FuJiMzOTt0IGhhdmUgWTwv ZGl2PjxkaXY+MjApIEFzc2V0IHNlcnZpY2UgQiwgcGxlYXNlIHNlbmQgbWUgYSBjYXAgZm9yIFos IGhlcmUgYXJlIG15IGNyZWRlbnRpYWxzIChJIHdhbnQgYSBjYXAgZm9yIGNvbnNpc3RlbmN5KTwv ZGl2PjxkaXY+W1JlZ2lvbiBzZXJ2aWNlOiBUaW1lb3V0Li4uIGFtYXppbmcgaW52ZW50b3J5IG11 c3QgYmUgb3ZlcmxvYWRlZC4uIG9oIHdlbGwuLi4gXTwvZGl2Pgo8ZGl2PjIxKSBBZ2VudCBzZXJ2 aWNlLCB5b3Ugd2FudGVkIHRvIHNlbmQgc29tZWJvZHkgb3ZlciwgaGVyZSBhcmUgeW91ciBwZXJt aXNzaW9ucy48L2Rpdj48ZGl2PjIyKSBWaWV3ZXIsIHlvdSBhc2tlZCBmb3IgYSB0cmFuc2ZlciB0 cnksIGhlcmUgYXJlIHlvdXIgcmVzdWx0czwvZGl2PjxkaXY+wqDCoCDCoCBVc2VyIHRoaW5rczog wqBDcmFwISBCaWcgYXNzZXQgc2VydmljZSBkb2VzIG5vdCBhbGxvdyDCoG1lIHRvIHRha2UgbXkg eWVsbG93IHN0b2NraW5ncyEgQW5kIEFtYXppbmcgYXNzZXRzIMKgZmFpbGVkIHRvIGRlbGl2ZXIg bXkgem9kaWFjIGRyZXNzLiBBdCBsZWFzdCBpIG1hZGUgYSBiYWNrdXAgb2YgdGhhdCBkcmVzcyE8 L2Rpdj4KPGRpdj4yMykgJiMzOTtsbCB0YWtlIHRoZSB5ZWxsb3cgc3RvY2tpbmdzIG9mZi4uLjwv ZGl2PjxkaXY+MjQpIC4uLiBkb25lICgmIzM5O2xsIHRyYXNoIHRoZW0gaGVyZSBhbmQgbm93LCBm b3JldmVyLCB3aG8gbmVlZHMgc3R1ZmYgeW91IGNhbiYjMzk7dCB1c2UhKTwvZGl2PjxkaXY+MjUp IFRoZSB6b2RpYWMgZHJlc3Mgd2FzIG5vdCBkZWxpdmVyZWQgYnkgQmlnIGFzc2V0cyBzZXJ2aWNl LCBidXQgaSBoYXZlIGEgbG9jYWwgY29weSE8L2Rpdj4KPGRpdj4yNikgTG9jYWwgQXNzZXQgc2Vy dmljZSwgcGxlYXNlIHNlbmQgbWUgWiwgaGVyZSBhcmUgbXkgY3JlZGVudGlhbHM8L2Rpdj48ZGl2 PjI3KSBJIGRvbnQga25vdyB5b3UsIGJ1dCBJICYjMzk7bGwgdHJ1c3QgeW91LCBoZXJlIGlzIHRo ZSBjYXAsIGJ1dCB5b3UgYmV0dGVyIHN0b3JlIHRoZSBkYXRhLCBpdHMgc2luZ2xlIHVzZSwgaSBu ZWVkIHRvIHByb3RlY3QgbXlzZWxmLjwvZGl2Pgo8ZGl2PjI4KSBMb2NhbCByZWdpb24sIGNhbiB5 b3UgcGxlYXNlIHB1dCB0aGlzIG9uIG15IGFnZW50LCBpIGluY2x1ZGUgdGhlIGNhcC48L2Rpdj48 ZGl2PjI5KSBMb2NhbCBBc3NldCBzZXJ2aWNlLCBpIG5lZWQgWiwgaGVyZSBpcyB0aGUgY2FwPC9k aXY+PGRpdj4zMCkgQ2FwIGlzIGdvb2QsIGRhdGEgY29taW5nIHVwLCBoYXZlIGZ1bi48L2Rpdj48 ZGl2PjMxKSBDYXAgd2FzIG9ubHkgZ29vZCBmb3Igb25lIHRpbWUsIEkgbWFkZSBhIGNvcHksIGJ1 dCBteSBwb2xpY3kgaXMgdG8gb25seSBncmFudCB5b3UgZmFpciB1c2UgcmlnaHRzLCBhdCBhIGxh dGVyIHRpbWUgaSBtaWdodCBldmVuIHRlbGwgeW91IHRvIHJlcGxhY2UgdGhlIGRyZXNzLjwvZGl2 Pgo8ZGl2PjMyKSBWaWV3ZXIsIHlvdSBjYW4gd2VhciBaIGZvciBub3csIGJ1dCB0aGUgYXNzZXQg c2VydmljZSBncmFudGVkIG9ubHkgZmFpciB1c2UsIGkgbWlnaHQgYXNrIHlvdSB0byByZXBsYWNl IHRoZSBkcmVzcyBhdCBhIGxhdGVyIHRpbWUuPC9kaXY+PGRpdj4zMykgUmVhZHkgYXQgbGFzdCEg T2ZmIHRvIGltbWVyc2l2ZSB3b3JsZCEsIEkgaG9wZSBpdHMgbm90IHRvIGNyb3dkZWQgdGhlcmUg b3IgJiMzOTtsbCBsb29zZSBteSBkcmVzcy4uLjwvZGl2Pgo8ZGl2PjM0KSBIZWxsbyBpbW1lcnNp dmUgd29ybGQsIGhlcmUgYXJlIG15IGNyZWRlbnRpYWxzLCBhbmQgYSBsaXN0IG9mIHN0dWZmIGkg d2FudCB0byBicmluZzwvZGl2PjxkaXY+MzUpIEhlbGxvIGFzc2V0IHNlcnZpY2UgQSwgcGxlYXNl IHNlbmQgbWUgYSBjYXAgZm9yIFgsIGhlcmUgYXJlIG15IGNyZWRlbnRpYWxzwqA8L2Rpdj48ZGl2 PsKgwqAgwqBbZGFybiwgSSBzaG91bGQgaGF2ZSBrZXB0IHRoYXQgY2FwIGZyb20gbGFzdCB0aW1l Li5dPC9kaXY+CjxkaXY+MzYpIFlvdXIgZmluZSwgaGVyZSBpcyB0aGUgY2FwLjwvZGl2PjxkaXY+ wqDCoCBbUmVnaW9uIHNlcnZpY2UgZmluZHMgZmFpci11c2Ugd2FybmluZyBvbiBaIGFuZCBkZWNp ZGVzIHRvIG1ha2UgaXRzIG93biBjb3B5XTwvZGl2PjxkaXY+MzcpIEhlbGxvIExvY2FsIHJlZ2lv biwgY2FuIGkgc3RpbGwgaGF2ZSBaPyBIZXJlIGlzIHRoZSBjYXDCoDwvZGl2PjxkaXY+MzgpIENh cCBpcyBzdGlsbCBnb29kLCBkYXRhIGNvbWluZyB1cCwgaGF2ZSBmdW4uPC9kaXY+CjxkaXY+wqDC oCBbUmVnaW9uIHNlcnZpY2Ugc3RvcmVzIGFzc2V0IGluIHByaXZhdGUgc3RvcmFnZSwgcHJvdmlk aW5nIGEgY2FwIHRvIHJlcGxhY2UgdGhlIGZhaXIgdXNlIG9uZV08L2Rpdj48ZGl2PjM5KSBBZ2Vu dCBzZXJ2aWNlLCB5b3Ugd2FudGVkIHRvIHNlbmQgc29tZWJvZHkgb3ZlciwgaGVyZSBhcmUgeW91 ciBwZXJtaXNzaW9ucyAmYW1wOyBpbmZvLjwvZGl2PjxkaXY+NDApIEhlbGxvIGltbWVyc2l2ZSB3 b3JsZCwganVzdCDCoGdldCBtZSB0aGVyZSwgYW5kIHVzZSB3aGF0IHlvdSBjYW48L2Rpdj4KPGRp dj40MSkgUGxhY2VtZW50IGRvbmUsIFogaXMgY3VycmVudGx5IGJ1ZmZlcmVkIGJ5IHVzIGFzIHdl bCwgeW91IG5lZWQgdG8gZ2V0IGRldGFpbHMgZm9yIFgsIGhhdmUgZnVuLjwvZGl2PjxkaXY+NDIp IFlvdSBhcmUgbm93IGluIGltbWVyc2l2ZSB3b3JsZCwgeW91ciBkcmVzcyBpcyBidWZmZXJlZCB0 aGVyZSBhcyB3ZWxsLCBidXQgeW91IG5lZWQgdG8gZ2V0IFghPC9kaXY+PGRpdj4KNDMpIEhlbGxv IGFzc2V0IHNlcnZpY2UgQSwgaSB3YW50IFgsIGhlcmUgaXMgdGhlIGNhcDwvZGl2PjxkaXY+NDQp IENhcCBpcyBnb29kLCBkYXRhIGNvbWluZyB1cCwgaGF2ZSBmdW4uPC9kaXY+PGRpdj40NSkgVmll d2VyLCBoZXJlIGlzIGFuIHVwZGF0ZSBvZiB0aGUgc3RhdGUgb2YgdGhlIHdvcmxkIHlvdXIgYWdl bnQgaXMgaW4sIHBsZWFzZSByZW5kZXIuPC9kaXY+PGRpdj48YnI+PC9kaXY+CjxkaXY+QXMgZmFy IGFzIEkgY2FuIHNlZSB0aGlzIGNvbmZvcm1zIGZ1bGx5IHRvIG91ciBjaGFydGVyLCBhbmQgaSBo b3BlIGl0IGlzIHBvc3NpYmxlIHRvIHVzZSBsYXJnZSBwb3J0aW9ucyBvZiB0aGUgZXhpc3Rpbmcg Y29kZSBiYXNlcy4gSG93ZXZlciwgYXMgc2FpZCBhYm92ZSwgaSBkaWQgbm90IHJlYWxseSB0cnkg dG8gY2FwdHVyZSB0aGUgb2xkIHRoaW5raW5nLCBhbmQgSSBhbHNvIG1pZ2h0IGhhdmUgbWlzY29u Y2VwdGlvbnMgYWJvdXQgdGhlIHdheSB0byBkbyB0aGVzZSB0aGluZ3MgaW4gZ2VuZXJhbC48L2Rp dj4KPGRpdj5Mb29raW5nIGZvcndhcmQgdG8gY29uc3RydWN0aXZlIGNvbW1lbnRzLjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+LS0gVmF1Z2huPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBjbGFz cz0iZ21haWxfcXVvdGUiPk9uIFN1biwgQXByIDMsIDIwMTEgYXQgODozOCBQTSwgVmF1Z2huIERl bHVjYSA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzp2YXVnaG4uZGVsdWNhQGdt YWlsLmNvbSI+dmF1Z2huLmRlbHVjYUBnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJy Pgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhl eDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4OyI+VGhhbmtzIGZv ciB0aGUgcG9pbnRlcnMuIMKgSSBoYXZlIGEgwqBidXN5IHdlZWsgaW4gUkwgaW4gZnJvbnQgb2Yg bWUsIHNvIGkgd29udCBoYXZlIHRvIG11Y2ggdGltZSB0byByZXNwb25kIHRoZSBuZXh0IGZldyBk YXlzLCBob3dldmVyLCBpIGludGVuZCB0byBzdGFydCBkb2luZyB0aGUgZm9sbG93aW5nIHRoaW5n czo8ZGl2Pgo8YnI+PC9kaXY+PGRpdj4tIFByb2R1Y2UgYSB2aXN1YWwgdGhhdCByZWZsZWN0cyBt eSB0aGlua2luZywgaS5lLiBhbiBpbGx1c3RyYXRpb24gb2YgbXkgcmVzcG9uc2UgdG8gTW9yZ2Fp bmUmIzM5O3MgaXRlbWxpc3QgwqBhYm92ZS48YnI+CjwvZGl2PjxkaXY+PGRpdj4tIFJlYWQgdXAg b24gdGhlIG9sZGVyIG5vdGVzLCBhcyB3ZWxsIGFzIMKgbW9yZSByZWFkaW5nIGluIHRoZSBsaXN0 IGFyY2hpdmU8L2Rpdj48ZGl2Pi0gVHJ5IHRvIG1ha2UgYSBzdW1tYXJ5IGZvciB0aGUgd2lraTwv ZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2PjxkaXY+UmVnYXJkaW5nIHRoZSB1c2Ugb2YgZG9tYWlu LCBJIHRoaW5rIHNlcnZpY2VzIGFyZSBldmVudHVhbGx5IHdoYXQgY291bnRzLCBidXQgaXRzIGFs bCB0ZXJtaW5vbG9neS4gVGhlIHdheSBJIHJlYWQgdGhlIEFXRyBkaWFncmFtcyBpcyB0aGF0IHRo ZSBhZ2VudCBkb21haW4gaXMgYWN0dWFsbHkgYSBjbHVzdGVyIG9mIHRpZ2h0bHkgaW50ZWdyYXRl ZCBzZXJ2aWNlcy4gV2hlbiB0aGUgZnVuY3Rpb25hbGl0eSBvZiBlYWNoIHN1Yi1zZXJ2aWNlIGlz IGRlc2NyaWJlZCBwcm9wZXJseSBhbmQgd2l0aCB1bmlmb3JtIGludGVyZmFjZXMgdGhlIGRvbWFp biB3aWxsIHNsb3dseSBkaXNzb2x2ZS4gQnV0IGxldCBub3QgZ2V0IGFoZWFkIG9mIG91dCBzZWxm cy4gV2Ugc2hvdWxkIHB1dCB1cCBzb21lIGNsZWFyIGRlc2NyaXB0aW9ucyBvbiB0aGUgd2lraSBm b3Igb3VyIHZpZXdzIG9uIHRoaXMsIGFuZCAqYWZ0ZXIqIHRoYXQgd2UgY2FuIGRlY2lkZSB3aGF0 IHdlIG5lZWQgYW5kIHdoYXQgY2FuIGdvLjwvZGl2PgoKPGRpdj48YnI+PC9kaXY+PGRpdj5JdHMg YmVlbiBhIHZlcnkgdXNlZnVsIGFuZCBpbGx1bWluYXRpbmcgd2Vla2VuZCBmb3IgbWUsIGFuZCBp IGFtIGEgbG90IG1vcmUgb3B0aW1pc3RpYyBhYm91dCB0aGUgZnV0dXJlIG9mIHZ3cmFwIHRoYW4g dHdvIHdlZWtzIGFnby48L2Rpdj48ZGl2Pjxicj48L2Rpdj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+ PGRpdj4tLSBWYXVnaG48L2Rpdj48L2ZvbnQ+PGRpdj4KPGRpdj48L2Rpdj48ZGl2IGNsYXNzPSJo NSI+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+CjxkaXY+PGJyPjwvZGl2PjxkaXY+PGRp diBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFN1biwgQXByIDMsIDIwMTEgYXQgNzoyMCBQTSwgRHpv bmF0YXMgU29sIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmR6b25hdGFzQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmR6b25hdGFzQGdtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFu PiB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+ CgpQcm9iYWJseSBlYXN5IGFzIHN1Z2dlc3RlZCBpbiBvdGhlciB0ZXJtcyBoZXJlIG9uIHRoaXMg bGlzdCwgYXMgaG93IHRoZSBjbGllbnQgY29udGFjdHMgdGhlIGFzc2V0IHNlcnZpY2VzIG5vdyBp biB0aGUgcmVnaW9ucy4gVGhlIG5ld2VyIGlzc3VlIGlzIHRvIHVuaXRpemUgdGhhdCBhc3NldCBz ZXJ2aWNlcy4gU2luY2UgdGhlaXIgaXMgcHJvcHJpZXRhcnkgKGxlZ2FjeSkgY29kZSB0aGVuIHdl IGNhbiYjMzk7dCBleHBlY3QgdGhhdCB0byBjaGFuZ2UsIGFuZCBzb21lIGZvcm0gb2YgcHJveHkg aXMgb2YgbmVlZC4gV2hhdGV2ZXIgd29ya3MgYmVzdCwgSSB0cmllZCB0byBuYXJyb3cgaXQgZG93 biB0byBzdWdnZXN0aW9ucyBoZXJlLjxicj4KCgo8YnI+CkV2ZW50dWFsbHksIHRoZSBhZ2VudCBk b21haW4gaXMgaWRlYWwgdG8gaGFuZGxlIHRoZSBkaXJlY3Rpb24gb2YgdGhlIGFzc2V0IHNlcnZp Y2VzLiBUaGlzIGNvbmNlcHQsIHVuZm9ydHVuYXRlbHksIGVuZGVkIHN1cHBvcnQgYXdoaWxlIGFn byB3aXRoIGNoYW5nZXMgaW4gTEwuPGJyPgpBbHNvIHNlZTsgPGEgaHJlZj0iaHR0cDovL3dpa2ku c2Vjb25kbGlmZS5jb20vd2lraS9BZ2VudF9Eb21haW4iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8v d2lraS5zZWNvbmRsaWZlLmNvbS93aWtpL0FnZW50X0RvbWFpbjwvYT48YnI+CkFuZDogPGEgaHJl Zj0iaHR0cDovL3dpa2kuc2Vjb25kbGlmZS5jb20vd2lraS9Vc2VyOkR6b25hdGFzX1NvbC9BV0df QXNzZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd2lraS5zZWNvbmRsaWZlLmNvbS93aWtpL1Vz ZXI6RHpvbmF0YXNfU29sL0FXR19Bc3NldDwvYT4gKHdhcm46IHVuc3RydWN0dXJlZCBjb2xsYWJv cmF0aXZlIG5vdGVzLCBkdW1wZWQgb24gbWUgYW5kIEkgdHJpZWQgdG8gZml4KTxicj4KCgo8YnI+ CkkgdHJpZWQgdG8gZmluZCBwcmV2aW91cyB2aXN1YWxzLjxicj4KPGJyPgpJJiMzOTtkIGltYWdp bmUgdGhlIGFnZW50IGRvbWFpbiBjb3VsZCBncm93IG91dCBvZiB1bml0aXplZCB2ZXJzaW9ucyBv ZiBhc3NldCBzZXJ2aWNlcy4gRGVzcGl0ZSB0aGF0LCBJIHRoaW5rIHRoYXQgY29uY2VwdCBoZWxw cyB2aWV3IHdoZXJlIHdlIHdlcmUgYXQgaW4gZGlzY3Vzc2lvbiBhbmQgd2hhdCBkaWRuJiMzOTt0 IGhhcHBlbi48YnI+Cjxicj4KVmF1Z2huIERlbHVjYSB3cm90ZTo8YnI+CjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjxkaXY+Ckhp77+9RHpvbmF0YXM8YnI+Cjxi cj4KQ2FuIHlvdSBleHBhbmQgb24gdGhhdCwgd2hhdCB3b3VsZCBiZSBuZWVkZWQgZm9yIGxlZ2Fj eSBzdXBwb3J0IGluIFZXQVAgdGVybXPvv70/LDxicj4KSWYgaSB3YW50IHRvIHJlYWQgdXAgb24g aG93IHRoZe+/vWFzc2V0IHNlcnZlciBtYXkgcHJveHkgdGhlIHNpbXVsYXRvciwgd2hhdCB3b3Vs ZCB5b3UgcmVjb21tZW5kIG1lIHRvIHJlYWQ/PGJyPgo8YnI+Ci0tIFZhdWdobjxicj4KPGJyPjwv ZGl2PjxkaXY+PGRpdj48L2Rpdj48ZGl2PgpPbiBTdW4sIEFwciAzLCAyMDExIGF0IDU6NTEgQU0s IER6b25hdGFzIFNvbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmR6b25hdGFzQGdtYWlsLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86ZHpvbmF0YXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHpvbmF0YXNAZ21haWwu Y29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4KCgo8YnI+CiDCoCDCoFNvbWUgc3RhdGVkIHRoZSBw cm94eS10by1hc3NldC1zZXJ2ZXIgaXMgYnVpbHQgaW50byB0aGUgc2ltOzxicj4KIMKgIMKgaG93 ZXZlciwga2VlcCBpbiBtaW5kIHBvc3NpYmxlIGxlZ2FjeSBzdXBwb3J0IHdoZXJlIHRoZSBhc3Nl dDxicj4KIMKgIMKgc2VydmVyIG1heSBwcm94eSB0aGUgc2ltdWxhdG9yLjxicj4KPGJyPgo8YnI+ CiDCoCDCoER6b25hdGFzIFNvbCB3cm90ZTo8YnI+Cjxicj4KIMKgIMKgIMKgIMKgU29tZWhvdyBJ IGZlZWwgdGhlIGJhc2ljIGFzc2V0IHNlcnZlciBiZWluZyBhYmxlIHRvIGxvZ2luIGFuZDxicj4K IMKgIMKgIMKgIMKgZG93bmxvYWQgYXNzZXRzIGlzIG5vdyBwcmlvcml0eSwgeWV0IEkgYWxzbyB3 b25kZXJlZCB0aGUgYmVzdDxicj4KIMKgIMKgIMKgIMKgd2F5IHRvIHBhdGNoIHRoaXMgaW50byB0 aGUgY3VycmVudCBtb2RlIG9mIHZpZXdlcnMuPGJyPgo8YnI+CiDCoCDCoCDCoCDCoE1heWJlIG9m ZmVyICgxKSBieSBwcm94eSAoc2ltLXNpZGUpIGFuZCAoMikgYnkgcGF0Y2g8YnI+CiDCoCDCoCDC oCDCoCh2aWV3ZXItc2lkZSkgdGhhdCBlaXRoZXIgb2YgdGhlc2UgdHdvIGFyZSBvcHRpb25hbCBh bmQ8YnI+CiDCoCDCoCDCoCDCoG5laXRoZXIgYXJlIG1hbmRhdG9yeSBmb3Igbm93LiBUaG91Z2h0 cz88YnI+Cjxicj4KIMKgIMKgIMKgIMKgSXNyYWVsIEFsYW5pcyB3cm90ZTo8YnI+Cjxicj4KPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7IHdoZW4gZGVzaWduaW5nIGZvciBzY2FsYWJpbGl0eSwg dGhlIG1vZGVsIHRvIGJlYXIgaW48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoG1pbmQgaXMgLi4uPGJy Pgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoFdlbGwsIHRoZXJlIGFyZSBhIGxvdCBvZiBkaWZmZXJl bnQgbW9kZWxzIHRvIGtlZXAgaW4gbWluZCw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoGFuZCBtYW55 IGRpZmZlcmVudCB1c2UgY2FzZXMuIE9uZSBwYXJ0aWN1bGFyIHVzZSBjYXNlIHRvPGJyPgogwqAg wqAgwqAgwqAgwqAgwqBrZWVwIGluIG1pbmQgaXM6ICZxdW90O1VzZXIgYWNxdWlyZXMgbmV3IG91 dGZpdCwgYW5kIHdhbnRzIHRvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAmIzM5O3Nob3cgaXQgb2Zm JiMzOTsgaW4gYSBoaWdobHkgcG9wdWxhdGVkIHJlZ2lvbiZxdW90Oy48YnI+Cjxicj4KIMKgIMKg IMKgIMKgIMKgIMKgJmd0OyBCb3RoIHdvcmxkcyBhbmQgYXNzZXQgc2VydmljZXMgbWF5IGluY2x1 ZGUgY29tbWVyY2lhbCw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoGNvbW11bml0eSwgYW5kIHBlcnNv bmFsIHNlcnZpY2VzPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoFllcywgeWVzIGFuZCB5ZXMu IEkmIzM5O20gcGFydGljdWxhcmx5IGNvbmNlcm5lZCBhYm91dCBob3cgdGhlPGJyPgogwqAgwqAg wqAgwqAgwqAgwqBtb2RlbCBhZmZlY3RzIHRoZSBhYmlsaXR5IHRvIGhvc3QgcGVyc29uYWwgYXNz ZXQgc2VydmljZXMuPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCZndDsgYSBwcm94eWluZyBy ZWdpb24sIHdoaWNoIHdvdWxkIGdldCBzbGFtbWVkIGZvciBldmVyeTxicj4KIMKgIMKgIMKgIMKg IMKgIMKgYXNzZXQgd29ybiBieSBldmVyeSBhdmF0YXIgcHJlc2VudC48YnI+Cjxicj4KIMKgIMKg IMKgIMKgIMKgIMKgR3JhbnRlZCB0aGUgY29sbGVjdGlvbiBvZiBzZXJ2aWNlcyB0aGF0IGFyZSBw cm92aWRlZCBieTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgdGhlIHJlZ2lvbiBuZWVkIHRvIGJlIHNj YWxlZCB0byBtZWV0IHRoZSBkZW1hbmRzIG9mIHRoYXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoHJl Z2lvbi4gVGhhdCYjMzk7cyBhbGwgcGFydCBvZiBjYXBhY2l0eSBwbGFubmluZy48YnI+Cjxicj4K IMKgIMKgIMKgIMKgIMKgIMKgJmd0OyByZWdpb25zIHJ1biBtYW55IGRpZmZlcmVudCBDUFUtaW50 ZW5zaXZlIHRhc2tzLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgaW5jbHVkaW5nIHBoeXNpY3Mgc2lt dWxhdGlvbiBhbmQgc2VydmVyLXNpZGUgc2NyaXB0aW5nLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKg YW5kIGFic29sdXRlbHkgY2Fubm90IGFmZm9yZCB0byBzZXJ2ZSBhc3NldHMgdG9vPGJyPgogwqAg wqAgwqAgwqAgwqAgwqBXZWxsLi4uIHdobyBzYWlkIHRoZSBzYW1lIENQVSYjMzk7cyBoYXZlIHRv IGRvIHByb3h5aW5nLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgcGh5c2ljcyBzaW11bGF0aW9uIGFu ZCBzZXJ2ZXItc2lkZSBzY3JpcHRpbmc/IEFzc2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqBwcm94 eWluZyBpcyBhIGRpZmZlcmVudCBzZXJ2aWNlIHRoYW4gcGh5c2ljcyBzaW11bGF0aW9uPGJyPgog wqAgwqAgwqAgwqAgwqAgwqBhbmQgY2FuIGJlIG9uIHNlcGFyYXRlIGhhcmR3YXJlLCBjb3VsZCBt YWtlIHVzZSBvZjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgZ2VvZ3JhcGhpY2FsbHkgZGlzdHJpYnV0 ZWQgY2FjaGluZywgYW5kIGluIGNlcnRhaW48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoGRlcGxveW1l bnQgcGF0dGVybnMsIHRoZSBzYW1lIGNhY2hpbmcgc2VydmljZXMgY291bGQgYmU8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoHNoYXJlZCBieSBkaWZmZXJlbnQgcmVnaW9ucy4gKFNlcnZlci1zaWRlIHNj cmlwdGluZyBpcyBhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBkaXNjdXNzaW9uIGZvciBhbm90aGVy IGRheSkuPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCZndDsgVGhpcyBpcyB3aHkgd2UgaGF2 ZSB0byBnbyBwYXJhbGxlbC4uLjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBUb3RhbGx5IGFn cmVlLCBhbmQgYSBwcm94eWluZyBtb2RlbCBjb3VsZCBhbmQgc2hvdWxkIGFsc288YnI+CiDCoCDC oCDCoCDCoCDCoCDCoHRha2UgYWR2YW50YWdlIG9mIHBhcmFsbGVsaXNtLjxicj4KPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAmZ3Q7IEkgdGhpbmsgeW91JiMzOTtyZSB3cm9uZyB0aGF0IGl0IGhhcyB0 byBjb3N0IG11Y2ggbW9uZXkuID92cz88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCZndDsgSXQgY29z dHMgbW9uZXkgdG8gaG9zdCBhIGhpZ2ggcGVyZm9ybWFuY2UgYW5kIHNjYWxhYmxlPGJyPgogwqAg wqAgwqAgwqAgwqAgwqBhc3NldCBzZXJ2aWNlIGFuZCBhIGhpZ2ggYmFuZHdpZHRoIG5ldHdvcmsg dG8gaGFuZGxlIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgdHJhZmZpYy4g77+9QSAqbG90KiBv ZiBtb25leS48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoEkgdGhpbmsgd2hhdCB5b3UmIzM5O3JlIHNh eWluZyBpczogJnF1b3Q7SXQgY29zdHMgYSBsb3Qgb2YgbW9uZXkgdG88YnI+CiDCoCDCoCDCoCDC oCDCoCDCoGJ1aWxkIGEgc2NhbGFibGUgYXNzZXQgc2VydmljZSwgYnV0IGlmIGFzc2V0cyBhcmUg c3ByZWFkPGJyPgogwqAgwqAgwqAgwqAgwqAgwqB0aHJvdWdob3V0IHRoZSBpbnRlcm5ldCB0aGV5 IGRvbiYjMzk7dCBoYXZlIHRvIGJlIHNjYWxhYmxlLiZxdW90Ozxicj4KIMKgIMKgIMKgIMKgIMKg IMKgQnV0IHRoYXQmIzM5O3Mgbm90IHF1aXRlIHJpZ2h0LiBZb3UmIzM5O3JlIG9wZW5pbmcgdXAg ZXZlcnkgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoHNlcnZlciB0byB0aGUgVlcgZXF1aXZh bGVudCBvZiBiZWluZyBzbGFzaGRvdHRlZCwgc28gYXJlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqB5 b3Ugc3VyZSB5b3UmIzM5O3JlIG5vdCBmb3JjaW5nICpldmVyeSogYXNzZXQgc2VydmljZSB0byBi ZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgc2NhbGFibGUgYW5kIGhhbmRsZSBhIGxvdCBvZiBiYW5k d2l0aCBhbmQgbmV0d29yayB0cmFmZmljPzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgSXQmIzM5O3Mg dGhlIGV4YWN0IG9wcG9zaXRlIG9mIHlvdXIgaW50ZW50aW9uLCBidXQgSSB0aGluazxicj4KIMKg IMKgIMKgIMKgIMKgIMKgdGhhdCYjMzk7cyB0aGUgcmVzdWx0LCBhbGwgdGhlIHNhbWUuPGJyPgo8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoFRoaXMgcGFydGljdWxhciBkZXNpZ24gZGVjaXNpb24gaGFz IGEgYmlnIGVmZmVjdCBvbiB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoGVjb25vbWljcyBvZiB0 aGUgVlcgaW5mcmFzdHJ1Y3R1cmUuIEkmIzM5O2QgcmF0aGVyIHRoZTxicj4KIMKgIMKgIMKgIMKg IMKgIMKgZWNvbm9taWNzIHRvIHdvcmsgb3V0IHN1Y2ggdGhhdCBhIHJlZ2lvbiBwcm92aWRlciB3 aG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoHdpc2hlcyB0byBidWlsZCBhIHJlZ2lvbiB0aGF0IHN1 cHBvcnRzIGEgc21hbGwgcG9wdWxhdGlvbiw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoGNhbiBkbyBz byBlY29ub21pY2FsbHkuIEEgcmVnaW9uIHRoYXQgd2FudHMgdG8gaG9zdCBhPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAqbGFyZ2UqIHBvcHVsYXRpb24gaGFzIHRvIGJlYXIgdGhhdCBjb3N0IG9mIHBy b3ZpZGluZyB0aGF0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqBzY2FsYWJsZSBhc3NldCBzZXJ2aWNl Ljxicj4KIMKgIMKgIMKgIMKgIMKgIMKgSSB3YW50IHRoZSBlY29ub21pY3Mgb2YgaG9zdGluZyBh IHNtYWxsIGFzc2V0IHNlcnZpY2UgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoGJlIGEgbm9uLWlz c3VlIChhcyB0byBiZXN0IHByb21vdGUgY3JlYXRpb24gYW5kPGJyPgogwqAgwqAgwqAgwqAgwqAg wqBjcmVhdGl2aXR5KS4gQ3JlYXRpbmcgYSBoaWdoIGJhciB0byBwcm92aWRlIGFzc2V0IHNlcnZp Y2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqB3aWxsIG1lYW4gdGhhdCBzZXJ2aWNlIHdpbGwgY29z dCBtb25leSBhbmQgcGVvcGxlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBzaG91bGRuJiMzOTt0IGhh dmUgdG8gcGF5IG1vbmV5IGp1c3QgdG8gY3JlYXRlIG9yIG93biBWVzxicj4KIMKgIMKgIMKgIMKg IMKgIMKgb2JqZWN0cyAoSSYjMzk7bSB1c2luZyAmIzM5O293biYjMzk7IGhlcmUgdG8gcmVmZXIg dG8gbWFpbnRhaW5pbmc8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoHRoZWlyIGV4aXN0ZW5jZSwgSSYj Mzk7bSBub3QgdHJ5aW5nIHRvIG1ha2UgYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgJiMzOTtsZWZ0 aXN0JiMzOTsvJiMzOTtjb21tdW5pc3QmIzM5OyBzdGF0ZW1lbnQgYWJvdXQgb3duZXJzaGlwIDsp PGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoC0gSXp6eTxicj4KPGJyPgo8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoE9uIEFwciAyLCAyMDExLCBhdCAzOjU4IFBNLCBNb3JnYWluZSB3cm90ZTo8YnI+ Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgSXp6eSwgd2hlbiBkZXNpZ25pbmcgZm9yIHNj YWxhYmlsaXR5LCB0aGUgbW9kZWwgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJlYXIg aW4gbWluZCBpcyB0aGF0IG9mIHNlYXNvbmVkIHZpcnR1YWwgd29ybGQ8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoHRyYXZlbGVycyB3aG9zZSBpbnZlbnRvcmllcyBjb250YWluIGFzc2V0cyBm cm9tIG1hbnk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGRpZmZlcmVudCB3b3JsZHMsIHRo b3NlIGFzc2V0cyBiZWluZyBzZXJ2ZWQgYnkgbWFueTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgZGlmZmVyZW50IGFzc2V0IHNlcnZpY2VzLiDvv71Cb3RoIHdvcmxkcyBhbmQgYXNzZXQ8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNlcnZpY2VzIG1heSBpbmNsdWRlIGNvbW1lcmNpYWws IGNvbW11bml0eSwgYW5kPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBwZXJzb25hbCBzZXJ2 aWNlcywgYW5kIGFzIHRoZSBtZXRhdmVyc2UgZ3Jvd3MsIHRoYXQ8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHNldCBpcyBoaWdobHkgbGlrZWx5IHRvIGJlY29tZSBwcm9ncmVzc2l2ZWx5IGxl c3M8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNsdXN0ZXJlZCBhbmQgbW9yZSBkaXZlcnNl Ljxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBXaGVuIHRob3NlIHNlYXNvbmVkIHRy YXZlbGVycyBjbGljayBvbiBhbiBhZHZlcnRpc2VkPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqBWVyBsaW5rIGFuZCBwZXJmb3JtIGFuIGludGVyLXdvcmxkIHRlbGVwb3J0IHRvIG9uZTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcGFydGljdWxhciB3b3JsZCYjMzk7cyByZWdpb24gdG8g c2hhcmUgYW4gZXhwZXJpZW5jZSw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRoZWlyICZx dW90O3dvcm4mcXVvdDsgYXNzZXRzICh0aGUgb25seSBvbmVzIG9mIGludGVyZXN0IHRvIHRoZTxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcmVnaW9uKSB3aWxsIGNvbnRhaW4gcmVmZXJlbmNl cyB0byBhc3NldCBzZXJ2aWNlczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc3ByZWFkIHdp ZGVseSBhY3Jvc3MgdGhlIEludGVybmV0LiDvv71UaGUgZmV0Y2hlcyBieSB0aGU8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHRyYXZlbGVycyYjMzk7IGNsaWVudHMgb2NjdXIgb3ZlciBtYW55 IHBhcmFsbGVsIHBhdGhzIGZyb208YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNsaWVudHMg dG8gYXNzZXQgc2VydmljZXMsIHNvIG9uZSBjYW4gcmVhc29uYWJseTxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgZXhwZWN0IHJlZHVjZWQgbmV0d29yayBjb250ZW50aW9uIGFuZCByZWR1Y2Vk IGFzc2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzZXJ2ZXIgbG9hZGluZyBiZWNhdXNl IHRoZXkgYXJlIGJvdGggc3ByZWFkIG91dCBvdmVyPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqBob3dldmVyIG1hbnkgYXNzZXQgc2VydmljZXMgYXJlIGJlaW5nIHJlZmVyZW5jZWQgYnk8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRoZSBvdmVyYWxsIHNldCBvZiBhc3NldHMgaW4gdGhl IHJlZ2lvbi48YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgVGhpcyBpcyB2ZXJ5IGRp ZmZlcmVudCB0byB0aGUgY2FzZSBvZiBhIHByb3h5aW5nPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqByZWdpb24sIHdoaWNoIHdvdWxkIGdldCBzbGFtbWVkIGZvciBldmVyeSBhc3NldCB3b3Ju PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBieSBldmVyeSBhdmF0YXIgcHJlc2VudC4g77+9 SW4gb3VyIGN1cnJlbnQgYXJjaGl0ZWN0dXJlLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg cmVnaW9ucyBydW4gbWFueSBkaWZmZXJlbnQgQ1BVLWludGVuc2l2ZSB0YXNrcyw8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoGluY2x1ZGluZyBwaHlzaWNzIHNpbXVsYXRpb24gYW5kIHNlcnZl ci1zaWRlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzY3JpcHRpbmcsIGFuZCBhYnNvbHV0 ZWx5IGNhbm5vdCBhZmZvcmQgdG8gc2VydmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGFz c2V0cyB0b28gdW5sZXNzIHlvdXIgc2NhbGFiaWxpdHkgcmVxdWlyZW1lbnRzIGFyZTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgdmVyeSBsb3cgaW5kZWVkLCBpZS4ganVzdCBhIGZldyBkb3pl biBhdmF0YXJzIG9mPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0b2RheSYjMzk7cyBraW5k LiDvv71XZSYjMzk7dmUgaGl0IHRoZSBjZWlsaW5nIGFscmVhZHkgb24gcmVnaW9uPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBzY2FsYWJpbGl0eSBkb25lIHRoYXQgd2F5LiDvv71UaGVyZSBp cyBub3doZXJlIHRvIGdvIGluPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGF0IGRpcmVj dGlvbiBhdCBhbGwgYmV5b25kIGltcHJvdmluZyB0aGUgY29kZSBsaWtlPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqBJbnRlbCBkZW1vbnN0cmF0ZWQsIGFuZCB0aGF0IHdvcmsgaXMgc3ViamVj dCB0byBhIGxhdzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgb2YgZGltaW5pc2hpbmcgcmV0 dXJucy48YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgVGhpcyBpcyB3aHkgd2UgaGF2 ZSB0byBnbyBwYXJhbGxlbCwgYW5kIEkgdGhpbmsgeW91JiMzOTtyZTxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgd3JvbmcgdGhhdCBpdCBoYXMgdG8gY29zdCBtdWNoIG1vbmV5LiDvv71BcyB3 ZSBzcHJlYWQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRoZSBsb2FkIGFjcm9zcyBtb3Jl IGFuZCBtb3JlIGFzc2V0IHNlcnZpY2VzLCB3ZSBhcmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHNpbXBseSBiZXR0ZXIgdXRpbGl6aW5nIGFsbCB0aGUgaGFyZHdhcmUgdGhhdCYjMzk7czxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYWxyZWFkeSBvdXQgdGhlcmUgb24gdGhlIEludGVy bmV0LCBhdCBsZWFzdCBpbiByZXNwZWN0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBvZiBj b21tdW5pdHkgYW5kIHByaXZhdGUgcmVzb3VyY2VzLiDvv71CdXQgYWRkIHRvIHRoZTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgY29tbXVuaXR5IGFuZCBwcml2YXRlIHJlc291cmNlcyB0aGUg Y29tbWVyY2lhbCBhc3NldDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2VydmljZXMgdGhh dCBhcmUgbGlrZWx5IHRvIGFwcGVhciB0byBleHBsb2l0IHRoaXM8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoG9wcG9ydHVuaXR5LCBhbmQgbm90IG9ubHkgd2lsbCB0aGUgbnVtYmVyIG9mIGFz c2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzZXJ2aWNlcyBsZWFwLCBidXQgdGhlIHBv d2VyIG9mIGVhY2ggb25lIHdpbGwgcm9ja2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0 b28sIGJlY2F1c2UsIGFmdGVyIGFsbCwgdGhlc2UgYnVzaW5lc3NlcyB3aWxsIGJlPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBoZWF2aWx5IG9wdGltaXplZCBmb3IgdGhlIGpvYi48YnI+Cjxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgQXMgdG8gd2h5IGEgd29ybGQgd291bGQgd2FudCBj bGllbnRzIHRvIGFjY2Vzczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZXh0ZXJuYWwgYXNz ZXQgc2VydmljZXMgaW5zdGVhZCBvZiBwcm92aWRpbmcgaXRzIG93bjxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgaW1wbGVtZW50YXRpb24sIHRoYXQmIzM5O3MgYW4gZWFzeSBxdWVzdGlvbi4g 77+9SXQgY29zdHM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG1vbmV5IHRvIGhvc3QgYSBo aWdoIHBlcmZvcm1hbmNlIGFuZCBzY2FsYWJsZSBhc3NldDxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgc2VydmljZSBhbmQgYSBoaWdoIGJhbmR3aWR0aCBuZXR3b3JrIHRvIGhhbmRsZSB0aGU8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRyYWZmaWMuIO+/vUEgKmxvdCogb2YgbW9uZXku IO+/vUluIGNvbnRyYXN0LCBpdCBjb3N0cyBhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB3 b3JsZCBub3RoaW5nIHRvIGxldCBvdGhlcnMgc2VydmUgdGhlIGFzc2V0cyB0bzxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgY2xpZW50cy4g77+9QW5kIHRoYXQgbWF0dGVycyB0byB0aGUgYm90 dG9tIGxpbmUuPGJyPgo8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgTW9yZ2FpbmUu PGJyPgo8YnI+Cjxicj4KPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoD09PT09PT09 PT09PT09PT09PT09PT08YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgT24gU2F0LCBB cHIgMiwgMjAxMSBhdCA3OjA1IFBNLCBJenp5IEFsYW5pczxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgJmx0OzxhIGhyZWY9Im1haWx0bzppenp5YWxhbmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPml6enlhbGFuaXNAZ21haWwuY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0 bzppenp5YWxhbmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPml6enlhbGFuaXNAZ21haWwu Y29tPC9hPiZndDs8YnI+PC9kaXY+PC9kaXY+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOml6enlhbGFuaXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+aXp6eWFsYW5pc0BnbWFpbC5jb208L2E+PGRpdj48ZGl2PjwvZGl2PjxkaXY+PGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzppenp5YWxhbmlz QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPml6enlhbGFuaXNAZ21haWwuY29tPC9hPiZndDsm Z3Q7Jmd0OyB3cm90ZTo8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZn dDsgQXMgYWx3YXlzIHRob3VnaCwgaXQmIzM5O3MgYSB0cmFkZS1vZmYsIHNpbmNlIHRoZTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcHJveGllZCBkZXNpZ248YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoO+/vSDvv71oYXMgdmVyeSBwb29yIHNjYWxhYmlsaXR5IGNvbXBhcmVkIHRvIHRo ZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZGlzdHJpYnV0ZWQgb25lLjxicj4KPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9SSBkb24mIzM5O3QgYWdyZWUgd2l0aCB0aGF0 Li4uIElmIGEgdXNlciBlbnRlcnMgYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaGlnaGx5 IHBvcHVsYXRlZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXJlZ2lvbiw8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71ldmVyeSBvdGhlciBjbGllbnQgaXMgZ29p bmcgdG8gKGNvdWxkIGFuZCBzaG91bGQgYmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRy eWluZyB0byk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71oaXQgdGhlPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9YXNzZXQgc2VydmVyKHMpIGZvciB0aGUgYXNz ZXRzIHRoYXQgdGhlIHVzZXIgaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHdlYXJpbmcg KGFzc3VtaW5nPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dGhleSYjMzk7cmUg bm90IGNhY2hlZCBsb2NhbGx5KS4g77+9RXZlcnkgYXNzZXQgc2VydmVyPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqBoYXMgdG8gYmUgc2NhbGVkIHVwPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9dG8gdGhlIHBvaW50IHRoYXQgaXQgY2FuIGhhbmRsZSB0aGF0IGxvYWQgZnJv bSBhbGw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG92ZXIuLi48YnI+Cjxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vUlmIEkmIzM5O20gaG9zdGluZyBhIHJlZ2lvbiB0aGF0 IHN1cHBvcnRzIDEwcyBvZjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdGhvdXNhbmRzIG9m PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c2ltdWx0YW5lb3VzPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dXNlcnMgKHRoaW5raW5nIG9mIHRoZSBmdXR1cmUp LCBJIGFscmVhZHkgaGF2ZSB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2NhbGUgdG8g bWVldCB0aGF0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9ZGVtYW5kLiBJZiB0 aGUgcmVnaW9uIGlzIHByb3h5aW5nIHRoZSBhc3NldHMsIHRoZW4sPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqB5ZXMgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9cmVn aW9uIGhhczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXRvIGJlIHNjYWxlZCB0 byBtZWV0IHRoYXQgYXNzZXQgZGVtYW5kIHRvbywgYnV0IGl0PGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBhbHJlYWR5IGhhcyB0byBiZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vXNjYWxlZCB0byBtZWV0IG90aGVyIGRlbWFuZHMgb2YgYmVpbmcgYSByZWdpb248YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNlcnZlci4uLiBhbmQgd2h5IGlzPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqDvv70g77+9c2NhbGluZyB0aG9zZSBhc3NldCBwcm94eSBzZXJ2aWNlcyBo YXJkPyDvv71JdCYjMzk7czxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZ29pbmcgdG8gY29z dCAkLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWJ1dCBpczxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vW5vdCB0ZWNobmljYWxseSBjaGFsbGVuZ2luZy4gU28s IGlmIEkgd2FudCB0byBob3N0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhIHJlZ2lvbiBs aWtlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dGhhdC4uLiBzdXJlIGl0IHdp bGwgY29zdCBtZSwgYnV0IHRoZSBzaW11bGF0aW9uPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqB3aWxsIGJlIGNvbnNpc3RlbnQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71h bmQgdXNlcnMgd2lsbCBiZSBhYmxlIHRvIHBhcnRpY2lwYXRlIGVxdWFsbHksPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqByZWdhcmRsZXNzIG9mIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vWNhcGFiaWxpdGllcyBvZiB0aGVpciBpbmRpdmlkdWFsIGFzc2V0IHNlcnZp Y2VzLjxicj4KPGJyPgo8YnI+Cjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9T24gRnJpLCBBcHIgMSwgMjAxMSBhdCAxMTo1NSBQTSwgTW9yZ2FpbmU8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mbHQ7PGEgaHJlZj0ibWFpbHRvOm1vcmdhaW5lLmRpbm92 YUBnb29nbGVtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vcmdhaW5lLmRpbm92YUBnb29nbGVt YWlsLmNvbTwvYT48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOm1vcmdhaW5lLmRpbm92YUBnb29nbGVtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pm1vcmdhaW5lLmRpbm92YUBnb29nbGVtYWlsLmNvbTwvYT4mZ3Q7PGJyPjwvZGl2PjwvZGl2Pgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9yZ2FpbmUu ZGlub3ZhQGdvb2dsZW1haWwuY29tPC9hPjxkaXY+PGRpdj48L2Rpdj48ZGl2Pjxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9yZ2FpbmUuZGlu b3ZhQGdvb2dsZW1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9yZ2FpbmUuZGlub3ZhQGdvb2ds ZW1haWwuY29tPC9hPiZndDsmZ3Q7Jmd0OyB3cm90ZTo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv70mZ3Q7IEV2ZXJ5IGRlc2lnbiBjaG9pY2UgcmVzdWx0cyBpbiBhIHRyYWRlLW9m Ziw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFZhdWdobiwgaW1wcm92aW5nPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9b25lIHRoaW5nIGF0PGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqDvv70g77+9Jmd0OyB0aGUgZXhwZW5zZSBvZiBzb21ldGhpbmcgZWxzZS4g77+9 SWYgZXZlcnkgdGltZSB3ZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgb2ZmZXJlZCBhPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c2VydmljZSB3ZSBoYWQgdG88YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGluZm9ybSBpdHMgdXNlcnMgYWJvdXQg dGhlIGRvd25zaWRlcyBvZiBhbGwgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0cmFk ZS1vZmZzIHdlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9aGF2ZSBtYWRlLDxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgdGhleSB3b3VsZCBoYXZlIGFu IGF3ZnVsIGxvdCB0byByZWFkLiA7LSk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDv v70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBUaGUgc3BlY2lm aWMgdHJhZGUtb2ZmIHRoYXQgeW91IGFyZSBkaXNjdXNzaW5nIGlzIG5vPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqDvv70g77+9ZGlmZmVyZW50LiDvv71BIHJlZ2lvbjxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgdGhhdCBwcm94aWVzIGFsbCBjb250ZW50IGhhcyB0 aGUgJnF1b3Q7YmVuZWZpdCZxdW90OyBvZjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYWNx dWlyaW5nIGNvbnRyb2w8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71mcm9tIHRo ZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgYXNzZXQgc2VydmVycyBv dmVyIHRoZSBpdGVtcyBpbiB0aGUgcmVnaW9uLCBzbzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgdGhhdCBpdCBjYW48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71lbnN1cmUg dGhhdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgZXZlcnlvbmUgaW4g dGhlIHJlZ2lvbiBub3Qgb25seSBvYnRhaW5zIHRoZSBpdGVtczxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgYnV0IG9idGFpbnM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv710 aGUgc2FtZSBpdGVtczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgYXMg ZXZlcnlvbmUgZWxzZS4g77+9VGhhdCBkb2VzIGluZGVlZCBwcm92aWRlIGE8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoGdyZWF0ZXIgZ3VhcmFudGVlIG9mPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqDvv70g77+9Jmd0OyBjb25zaXN0ZW5jeSB0aGFuIGEgZGVwbG95bWVudCBpbiB3aGlj aCB0aGUgcmVnaW9uPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBvbmx5IHBhc3Nlczxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWFzc2V0IFVSSXMgdG88YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGNsaWVudHMgd2hvIHRoZW4gZmV0Y2ggdGhlIGl0 ZW1zIGZyb20gYXNzZXQgc2VydmljZXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDv v71zZXBhcmF0ZWx5LiDvv71BcyBhbHdheXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv70mZ3Q7IHRob3VnaCwgaXQmIzM5O3MgYSB0cmFkZS1vZmYsIHNpbmNlIHRoZSBwcm94aWVk PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkZXNpZ24gaGFzIHZlcnk8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv71wb29yIHNjYWxhYmlsaXR5PGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqDvv70g77+9Jmd0OyBjb21wYXJlZCB0byB0aGUgZGlzdHJpYnV0ZWQgb25lLjxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoO+/vSDvv70mZ3Q7IElmIHdlJiMzOTtyZSBnb2luZyB0byB3YXJuIHVzZXJzIG9m IHRoZSBwb3RlbnRpYWwgZm9yPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpbmNvbnNpc3Rl bmN5PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9aW4gdGhlPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBkaXN0cmlidXRlZCBkZXBsb3ltZW50IGFzIHlv dSBzdWdnZXN0LCBhcmUgd2U8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGFsc28gZ29pbmcg dG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv713YXJuIHRoZW0gb2Y8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IG5vbi1zY2FsYWJpbGl0eSBpbiB0aGUg cHJveGllZCBvbmU/IO+/vUkgcmVhbGx5PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkb24m IzM5O3Qgc2VlIG11Y2g8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71tZXJpdCBp biB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGlkZWEgb2Ygd2Fy bmluZyBhYm91dCBkZXNpZ24gY2hvaWNlcy4g77+9TWFueSBzdWNoPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBjaG9pY2VzIGFyZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vXRlY2huaWNhbCwgYW5kPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyB0 aGUgaXNzdWVzIGFyZSBxdWl0ZSBsaWtlbHkgdG8gYmUgb2YgbGl0dGxlPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqBpbnRlcmVzdCB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vW5vbi10ZWNobmljYWwgdXNlcnM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDv v70mZ3Q7IGFueXdheS4g77+9SW4gYW55IGNhc2UsIHRoZSBiZXR0ZXIgc2VydmljZXMgYXJlPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBsaWtlbHkgdG8gcHJvdmlkZTxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKg77+9IO+/vXN1Y2g8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv70mZ3Q7IGluZm9ybWF0aW9uIGluIHRoZWlyIG9ubGluZSBkb2N1bWVudGF0aW9uLCBJPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB3b3VsZCBndWVzcy48YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 Jmd0OyBZb3UgbWVudGlvbmVkIHVzZXJzICZxdW90O3ZvdGluZyB3aXRoIHRoZWlyIGZlZXQmcXVv dDsgb3I8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNob29zaW5nIHRvPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9YWNjZXB0IHRoZSByaXNrPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqDvv70g77+9Jmd0OyBvZiBpbmNvbnNpc3RlbmN5LiDvv71XZWxsIHRoYXQgd2ls bCBoYXBwZW4gYW55d2F5LDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgd2hlbiBzZXJ2aWNl czxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWZhaWwgYW5kPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyB1c2VycyBnZXQgYW5ub3llZC4g77+9SWYgc29t ZSBhc3NldCBzZXJ2aWNlcyByZWZ1c2U8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRvIHNl bmQgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9cmVxdWVzdGVkPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBpdGVtcyB0byBzb21lIHVzZXJzLCB0 aG9zZSBzZXJ2aWNlcyB3aWxsIGdldCBhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBiYWQg cmVwdXRhdGlvbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWFuZCBwZW9wbGU8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IHdpbGwgY2hvb3NlIGRpZmZl cmVudCBhc3NldCBzZXJ2aWNlcyBpbnN0ZWFkLjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9TGlrZXdpc2UsIGlmIGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv713b3Js ZCBzZXJ2aWNlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBwcm94aWVz IGV2ZXJ5dGhpbmcgYW5kIHNvIGl0IGNhbiYjMzk7dCBoYW5kbGUgYSBsYXJnZTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgbnVtYmVyIG9mPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDv v70g77+9YXNzZXRzIG9yIG9mPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0 OyBwZW9wbGUsIHVzZXJzIHdpbGwgZ2V0IGFubm95ZWQgYXQgdGhlIGxhZyBhbmQgd2lsbCBnbzxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWVsc2V3aGVyZS4g77+9VGhpcyB1c2Vy PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBldmFsdWF0aW9uIGFuZCAm cXVvdDt2b3Rpbmcgd2l0aCB0aGVpciBmZWV0JnF1b3Q7IGhhcHBlbnM8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoGFscmVhZHkgd2l0aDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vW9ubGluZSBzZXJ2aWNlczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZn dDsgYWxsIG92ZXIgdGhlIEludGVybmV0LCBhbmQgSSBhbSBzdXJlIHRoYXQgdGhpczxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgaHVtYW4gcHJvY2Vzczxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vXdpbGwgY29udGludWU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv70mZ3Q7IHRvIHdvcmsgd2hlbiB0aGUgc2VydmljZXMgYXJlIGFzc2V0IGFuZCByZWdpb248 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNlcnZpY2VzLjxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70m Z3Q7IEJhY2sgaW4gU2VwdGVtYmVyIDIwMTAsIEkgd3JvdGUgdGhpcyBwb3N0IHdoaWNoPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBwcm9wb3NlcyB0aGF0PGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqDvv70g77+9d2UgdXNlIGluPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9Jmd0OyBWV1JBUCBhIGZvcm0gb2YgYXNzZXQgYWRkcmVzc2luZyB0aGF0IHByb3ZpZGVzPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBtYXNzaXZlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9c2NhbGFiaWxpdHkgYXQgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqDvv70g77+9Jmd0OyBzYW1lIHRpbWUgYXMgYSB2ZXJ5IGhpZ2ggZGVncmVlIG9mIHJlc2lsaWVu Y2UgLS08YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv708YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vTxhIGhy ZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi92d3JhcC9jdXJyZW50L21z ZzAwNDYzLmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvdndyYXAvY3VycmVudC9tc2cwMDQ2My5odG1sPC9hPjxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vS4g77+9SXQgaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv70mZ3Q7IGJhc2VkIG9uIHRoZSBjb25jZXB0IG9mIHRoZSBVUkkgY29udGFpbmluZyBh IGhvc3Q8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHBhcnQgYW5kIGE8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv71oYXNoIHBhcnQsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Jmd0OyB3aGVyZSB0aGUgaGFzaCBpcyBnZW5lcmF0ZWQgKG9uY2UsIGF0IHRo ZSB0aW1lIG9mPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzdG9yYWdlIHRvPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dGhlIGFzc2V0PGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqDvv70g77+9Jmd0OyBzZXJ2aWNlKSB1c2luZyBhIHNwZWNpZmllZCBkaWdlc3QgYWxn b3JpdGhtIG92ZXI8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRoZSBjb250ZW50IG9mPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dGhlIGFzc2V0PGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBiZWluZyByZWZlcmVuY2VkLiDvv71Zb3UgbWF5IHdp c2ggdG8gbm90ZSB0aGF0IGlmPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGlzIGRlc2ln bjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXdlcmUgdXNlZCwgdGhlPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBmYWlsdXJlIG9mIGFuIGFzc2V0IHNl cnZpY2UgdG8gZGVsaXZlciBhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqByZXF1ZXN0ZWQg aXRlbSB3b3VsZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXJlc3VsdCBpbiBh PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBmYWlsb3ZlciByZXF1ZXN0 IGZvciB0aGUgaXRlbSB0byBvbmUgb3IgbW9yZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg YmFja3VwIHNlcnZpY2VzLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXVzaW5n IHRoZSBzYW1lPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBoYXNoIHBh cnQgYnV0IHdpdGggYSBkaWZmZXJlbnQgaG9zdCBhZGRyZXNzLjxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70m Z3Q7IFRoaXMgY2FuIGdvIHNvbWUgd2F5IHRvd2FyZHMgb3ZlcmNvbWluZyB0aGU8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHByb2JsZW0gdGhhdCB5b3U8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoO+/vSDvv710aGluayBtaWdodDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vSZndDsgb2NjdXIgd2hlbiBhc3NldHMgYXJlIGZldGNoZWQgYnkgY2xpZW50cyBmcm9tPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhc3NldCBzZXJ2aWNlczxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vWRpcmVjdGx5Ljxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vSZndDsgQWx0aG91Z2ggaXQgd29uJiMzOTt0IGhlbHAgd2hlbiB0aGUgbWlzc2luZyBp dGVtIGlzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhdmFpbGFibGUgZnJvbTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vW9ubHkgYSBzaW5nbGU8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGFzc2V0IHNlcnZpY2UsIGl0IHdpbGwgaGVscCBpbiBt YW55IG90aGVyIGNhc2VzLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYW5kIGl0IHdpbGw8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71jb21wZW5zYXRlIGZvcjxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgc2VydmljZSBmYWlsdXJlcyBhbmQgbmV0 d29yayBvdXRhZ2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhdXRvbWF0aWNhbGx5IGF0 IHRoZSBzYW1lPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dGltZS48YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Jmd0OyBQUy4gVGhpcyBkZXNpZ24gZm9yIGhhc2gtYmFzZWQgYXNzZXQgYWRk cmVzc2luZzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaXMgYWxyZWFkeTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWJlaW5nIHRlc3RlZCBieTxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vSZndDsgTW9qaXRvIFNvcmJldCBpbiBoZXIgZXhwZXJpbWVudGFs IHdvcmxkIGFuZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgY2xpZW50LiDvv71JdCB3b3Vs ZCBnaXZlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBWV1JBUC1iYXNl ZCB3b3JsZHMgYW4gaW1wcm92ZWQgbGV2ZWwgb2Ygc2VydmljZTxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgYXZhaWxhYmlsaXR5LDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vXNvIEkgdGhpbmsgaXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IHNo b3VsZCBiZSBhIGNvcmUgZmVhdHVyZSBvZiBvdXIgcHJvdG9jb2wuPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IE1vcmdhaW5lLjxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7ID09PT09PT09PT09PT09PT09PT09PT09PT09PTxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoO+/vSDvv70mZ3Q7IE9uIEZyaSwgQXByIDEsIDIwMTEgYXQgMTE6MTcgUE0sIFZh dWdobiBEZWx1Y2E8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mbHQ7PGEgaHJl Zj0ibWFpbHRvOnZhdWdobi5kZWx1Y2FAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmF1Z2hu LmRlbHVjYUBnbWFpbC5jb208L2E+PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7bWFp bHRvOjxhIGhyZWY9Im1haWx0bzp2YXVnaG4uZGVsdWNhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnZhdWdobi5kZWx1Y2FAZ21haWwuY29tPC9hPiZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZhdWdobi5kZWx1Y2FAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+dmF1Z2huLmRlbHVjYUBnbWFpbC5jb208L2E+PGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2YXVnaG4uZGVsdWNh QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZhdWdobi5kZWx1Y2FAZ21haWwuY29tPC9hPiZn dDsmZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgd3JvdGU6 PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDs8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBUaGlzIGlzIGEgcXVlc3Rpb24gaSBkaXNj dXNzZWQgd2l0aCBNb3JnYWluZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgb2ZmLWxpc3Qg YSB3aGlsZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWFnbyAoSTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IGludGVuZGVkIHRvIHNlbmQgaXQg dG8gdGhlIGxpc3QgYnV0IHB1c2hlZCB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHdy b25nIGJ1dHRvbi4uLikgSTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsm Z3Q7IHRoaW5rIHdlIG5lZWQgdG8gYWRkcmVzcyB0aGlzIHByb2JsZW0sIGFuZDxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgZGVjaWRlIGhvdyB0byBkZWFsPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqDvv70g77+9d2l0aCBpdC48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDv v70mZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/ vUluIERhdmlkcyBkZXBsb3ltZW50IGRyYWZ0LCBzZWN0aW9uIDcuMy4xLjEgYW48YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoG92ZXJ2aWV3IGlzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqDvv70g77+9Z2l2ZW4gdmFuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0 OyZndDsgd2F5cyB0byBkZWxpdmVyIGNvbnRlbnQgdG8gdGhlIHJlZ2lvbi4gT25lIHdheTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaXMgb25seSBwYXNzaW5nIGE8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBjYXBhYmlsaXR5IHRoYXQgYWxsb3dzIGFjY2Vz cyB0byAocGFydCBvZikgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqByZXNvdXJjZTo8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/vSDvv70g77+9IO+/vSDvv70gNy4zLjEu MS4g77+9Q29udGVudCBkZWxpdmVyeSBtb2RlbHM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/vSDvv70g77+9IEEgcmFuZ2Ugb2YgcG9zc2libGUg cmVwcmVzZW5hdGlvbnMgY2FuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBiZSBwYXNzZWQg dG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71hIHJlZ2lvbiBmb3I8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/vSDvv70g77+9 IHNpbXVsYXRpb24uIFsuLi5dIFRoZSBvdGhlciBlbmQgb2YgdGhlPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBkZWxpdmVyeSBzcGVjdHJ1bTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vSZndDsmZ3Q7IGludm9sdmVzIHBhc3Npbmc8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/vSDvv70g77+9IG9ubHkgYSBVUkkgb3IgY2Fw YWJpbGl0eSB1c2VkIHRvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhY2Nlc3MgdGhlIHJl bmRlcmluZzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IGluZm9y bWF0aW9uIGFuZCBhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsg 77+9IO+/vSDvv70g77+9IO+/vSBjb2xsaXNpb24gbWVzaCxhbmQgcmVsYXRlZCBkYXRhIGZvcjxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcGh5c2ljYWwgc2ltdWxhdGlvbi48YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/vSDvv70g77+9IElu IHN1Y2ggYSBtb2RlbCwgdGhlIGNsaWVudCBpczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg cmVzcG9uc2libGUgZm9yPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9ZmV0Y2hp bmcgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgYWRkaXRp b25hbDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/vSDvv70g 77+9IO+/vSDvv70gaW5mb3JtYXRpb24gbmVlZGVkIHRvIHJlbmRlciB0aGU8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoGl0ZW0mIzM5O3MgdmlzdWFsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9cHJlc2VuY2UgZnJvbSBhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDv v70g77+9Jmd0OyZndDsgc2VwYXJhdGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDv v70mZ3Q7Jmd0OyDvv70g77+9IO+/vSDvv70g77+9IHNlcnZpY2UuIO+/vVRoaXMgZmV0Y2ggY2Fu IGJlIGRvbmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCp1bmRlciB0aGU8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71jcmVkZW50aWFscyBvZiB0aGU8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBlbmQgdXNlcio8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/vSDvv70g77+9IHZpZXdpbmcg dGhlIG1hdGVyaWFsIFtteSBlbXBoYXNpcy0tVkRdPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAsIGFuZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWRpdm9yY2VzIHRoZTxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHNpbXVsYXRpb24gZnJv bTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/vSDvv70g77+9 IO+/vSDvv70gdGhlIHRydXN0IGNoYWluIG5lZWRlZCB0byBtYW5hZ2U8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoGNvbnRlbnQuIO+/vUFueTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vWF1dG9tYXRpb248YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7 Jmd0OyBpcyBkb25lIG9uIGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7 Jmd0OyDvv70g77+9IO+/vSDvv70g77+9IHNlcGFyYXRlIGhvc3Qgd2hpY2ggdGhlIGNvbnRlbnQ8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNyZWF0b3Igb3Igb3duZXIgdHJ1c3RzLDxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IGludGVyYWN0aW5nIHdpdGgg dGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsg77+9IO+/vSDv v70g77+9IO+/vSBvYmplY3QgdGhyb3VnaCByZW1vdGVkIGludGVyZmFjZXMuPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv71JIGNhbiBzZWUgdGhlIG5lZWQgZm9yIHN1Y2ggYSBzZXR1 cCwgaG93ZXZlciwgaTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZmVlbCB3ZSBhcmU8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyB1bnBsZWFzYW50bHkgY2xv c2UgdG8gYSBzaXR1YXRpb24gd2VyZSB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNv aGVyZW5jZSBvZiB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71zaW11bGF0 aW9uPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgZmFsbHMgYXBh cnQuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgSW4gdGhpcyBk ZXBsb3ltZW50IHBhdHRlcm4gdGhlIHJlZ2lvbiBhZHZlcnRpc2VzPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqB0aGUgcHJlc2VuY2U8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDv v71vZiB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBhc3Nl dCwgYW5kICpzb21lKiBjbGllbnRzIHdpbGwgYmUgYWJsZSB0byBnZXQgaXQ8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoGFzIGV4cGVjdGVkLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vXdoaWxlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsg LWJhc2VkIG9uIHRoZSBhcmJpdHJhcnkgd2hpbXMgb2YgdGhlIGFzc2V0PGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqBzZXJ2aWNlLSBvdGhlcnM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv71taWdodCBub3QuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0 OyZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBNeSBob3Bl IHdvdWxkIGJlIHRoYXQgYWZ0ZXIgdGhlIGFzc2V0IHNlcnZlcjxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgcHJvdmlkZXMgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 cmVnaW9uIHdpdGg8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyB0 aGUgY2FwYWJpbGl0eSB0byBnZXQgdGhlIGFzc2V0LCBpdCBnaXZlcyB1cDxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgY29udHJvbC4gVGhhdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vXdvdWxkIG1lYW48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7 Jmd0OyB0aGF0IGlmIHRoZSBjbGllbnQgZmluZHMgdGhlIGludmVudG9yeSBzZXJ2ZXIgaXM8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHVud2lsbGluZyB0bzxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vXNlcnZlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 Jmd0OyZndDsgdGhlIGNvbnRlbnQgLSBpbiBzcGlyZSBvZiB0aGUgcmVnaW9uIHNheWluZyBpdDxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaXMgcHJlc2VudC0sPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqDvv70g77+9dGhlIGNsaWVudDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vSZndDsmZ3Q7IHNob3VsZCBiZSBhYmxlIHRvIHR1cm4gYXJvdW5kIGFzayB0aGUgKnJl Z2lvbio8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGZvciB0aGUgYXNzZXQsPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9KGFuZCBnZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBpcyBhZnRlciBhbGwpLjxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9Jmd0OyZndDsg77+9SWYgdGhhdCBpcyBub3QgdGhlIGNhc2UsIC1hbmQgdGhlcmUgYXJlPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBwcm9iYWJseSBnb29kIHJlYXNvbnM8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71mb3IgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Jmd0OyZndDsgZGVwbG95bWVudCBwYXR0ZXJuIGFzIGRlc2NyaWJlZC0g77+9 c2hvdWxkbiYjMzk7dCB3ZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKndhcm4qIGNsaWVu dHM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv710aGF0IHRoZTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHJlZ2lvbiBtaWdodCBiZSBpbmNvbnNp c3RlbnQsIHNvIHRoZSB1c2Vyczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYmVoaW5kIHRo ZSBjbGllbnQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71jYW4gdm90ZTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHdpdGggdGhlaXIgZmVldCwg KG9yIHRha2UgdGhlIHJpc2spPzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZn dDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgLS1WYXVn aG48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHZ3cmFwIG1haWxpbmcgbGlzdDxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhy ZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3Jn PC9hPiZndDs8YnI+PC9kaXY+PC9kaXY+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZsdDttYWls dG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBA aWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+Jmd0OyZndDs8ZGl2Pjxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdndyYXAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Z3cmFwPC9hPjxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70m Z3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vSZndDsgdndyYXAgbWFpbGluZyBsaXN0PGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqDvv70g77+9Jmd0OyA8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7PGJy PjwvZGl2PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0 bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiAmbHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3 cmFwQGlldGYub3JnPC9hPiZndDsmZ3Q7PGRpdj48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv70mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdndyYXAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Z3cmFwPC9hPjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgo8YnI+Cjxicj4KPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Cjxicj4KIMKgIMKgIMKgIMKg IMKgIMKgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoHZ3cmFwIG1haWxpbmcgbGlzdDxicj4KIMKgIMKgIMKgIMKgIMKg IMKgPGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBA aWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKg IMKgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92d3JhcCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdndy YXA8L2E+PGJyPjwvZGl2PjxkaXY+CiDCoCDCoCDCoCDCoCDCoCDCoO+/vTxicj4KPGJyPgo8YnI+ Cjxicj4KPGJyPgo8YnI+CiDCoCDCoC0tIMKgIMKgIC0tLSA8YSBocmVmPSJodHRwczovL3R3aXR0 ZXIuY29tL0R6b25hdGFzX1NvbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdHdpdHRlci5jb20v RHpvbmF0YXNfU29sPC9hPiAtLS08YnI+CiDCoCDCoFdlYiBEZXZlbG9wbWVudCwgU29mdHdhcmUg RW5naW5lZXJpbmcsIFZpcnR1YWwgUmVhbGl0eSwgQ29uc3VsdGFudDxicj4KPGJyPgogwqAgwqBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KIMKgIMKg dndyYXAgbWFpbGluZyBsaXN0PGJyPjwvZGl2PjxkaXY+CiDCoCDCoDxhIGhyZWY9Im1haWx0bzp2 d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiAmbHQ7bWFp bHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFw QGlldGYub3JnPC9hPiZndDs8YnI+CiDCoCDCoDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdndyYXAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Z3cmFwPC9hPjxicj4KPGJyPgo8YnI+CjwvZGl2PjwvYmxv Y2txdW90ZT4KPGJyPjxkaXY+PGRpdj48L2Rpdj48ZGl2Pgo8YnI+Ci0tIDxicj4KLS0tIDxhIGhy ZWY9Imh0dHBzOi8vdHdpdHRlci5jb20vRHpvbmF0YXNfU29sIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly90d2l0dGVyLmNvbS9Eem9uYXRhc19Tb2w8L2E+IC0tLTxicj4KV2ViIERldmVsb3BtZW50 LCBTb2Z0d2FyZSBFbmdpbmVlcmluZywgVmlydHVhbCBSZWFsaXR5LCBDb25zdWx0YW50PGJyPgo8 YnI+CjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+CjwvZGl2PjwvZGl2 PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+Cg== --000e0cdfd9f8b2d5a604a06ae072-- From vaughn.deluca@gmail.com Fri Apr 8 11:56:02 2011 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 4C98B3A69CC for ; Fri, 8 Apr 2011 11:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.448 X-Spam-Level: X-Spam-Status: No, score=-1.448 tagged_above=-999 required=5 tests=[AWL=-1.650, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] 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 ob9tarRSmZ5a for ; Fri, 8 Apr 2011 11:55:57 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 959E03A6962 for ; Fri, 8 Apr 2011 11:55:56 -0700 (PDT) Received: by eye13 with SMTP id 13so1389771eye.31 for ; Fri, 08 Apr 2011 11:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=L4q27Mq75J/qSc2LqqAN9cDgtMfPAE9QuHJFKVku6os=; b=QBQhVCnfJLvwAQ1jQwZw6xUXhIA41yPyynvNvOCnlXLGmhURRhO1Jjky69a0+gckPr H5Mx+n+iWpj0F00mPNXMftGUkjAtnrSrdxaaXzO1sqXqldheAgijgRpK5NGPPArwAxWK iAqyOBrrrumkjNpE27RxghouWKmeEpSpqRCQU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=us+kcS0SHgtjs1nhcuSgq88W/8aY8ANNuHvby73mnrjA1M/HlQ0NlcRdTk9nstZ7zk 1ncLHwjwYvknrmKFFuW+tJBLOH4ajCqjuKkYK8ktNwNCqTPwU5oHdDYtlgPtPt2y7FlC Sd2vklZStC7iKCx7VHJ0brZXChtwRqxPqIv8U= MIME-Version: 1.0 Received: by 10.213.108.84 with SMTP id e20mr1170929ebp.3.1302289061422; Fri, 08 Apr 2011 11:57:41 -0700 (PDT) Received: by 10.213.17.17 with HTTP; Fri, 8 Apr 2011 11:57:41 -0700 (PDT) In-Reply-To: References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> Date: Fri, 8 Apr 2011 20:57:41 +0200 Message-ID: From: Vaughn Deluca To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0015174be714e6a64504a06cccc3 Subject: Re: [vwrap] [wvrap] Simulation consistency 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, 08 Apr 2011 18:56:02 -0000 --0015174be714e6a64504a06cccc3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Drat!, I already found two editing mistakes, step 20 should address A, not = B and should read: 20) Asset service A, please send me a cap for Z, here are my credentials (I want a cap for consistency) And the same mixup in step 25: "Amzing Assets" should be mentioned instead of "Big assets": 25) The zodiac dress was not delivered by Amzing assets, but i have a local copy! I will add an updated version of the description on the vwrap wiki -- Vaughn On Fri, Apr 8, 2011 at 6:40 PM, Vaughn Deluca wrot= e: > VWRAP services high level message flow (preliminary diagram draft) see > > > http://trac.tools.ietf.org/wg/vwrap/trac/attachment/wiki/Diagrams/VWRAP_F= lowExample_VD1.pdf > > The main reason that i am submitting this in spite of my lack of formal > expertise is that the group in my view badly needs a solid basis for > discussion and preventing endless repeating loops. This example is probab= ly > wrong in many ways, but its better than what we have publicly available o= n > interop now (although Morgaine is working on something along the lines of > the recent discussions here) > > I hope this diagram will give us a base for discussion. I could have done > my homework better by researching the old OGP stuff in more depth, and i > probably will do so in the future , but for now I just tried to followed > the general principles as far as i understand them, to see what response > that yields from the group. In other words,I try to let the group educate= me > :p > > Note that in my view all services are equal, in principle it does not > matter in what "domain" they run, since trust and policy are fully > localized. It is however very possible to have internal shortcuts in the > services to speed up processing. > > In the example I opted for an external Agent service, but I could as well > have incorporated that in the set of local services. As indicated above a= ll > services could also be run by different organisations, true to what VWRAP > stands for. Its all up to the deployer, including a user at home who migh= t > want to run a full world for family and friends. Those friends might try = to > use that agent service to venture out in the virtual universe. > I envision that the final identity provider is external, using OpenID an= d > OAut or whatever other magic that I do not yet fully understand exists = out > there. > > The example has 3 main purposes: > - Provide a reference for discussion > - Illustrates the use case of tourism, and *true* interop. > - Illustrate consistency problems along the lines discussed here higher = up > in this tread, as well as the "slashdot" problem that Morgaine outlined s= o > clearly. > > The message flow assumes an avatar already present in some region, (a sma= ll > scale local home region in this case, but that is by no means essential, = it > could be a build in region in the viewer or a big commercial region). The > user is preparing for a trip to immersive world, and after some outfit > adjustments moves over. > > Finally i apologize for for the simplistic notation used here. I simply a= dd > the most relevant parameters passed in square brackets to a keyword > specifying the nature of the message. Please improve on that where needed= . > > So here we go, the avatar is prepare for a visit to "immersive world" > 0) Viewer, here is an update of the state of the world your agent is in, > please render. > 1) Agent service, I will go in my Zodiac dress that i keep in the > "Amazing assets" service. > 2) Asset service A, please send a cap for Z, here are my credentials > 3) Your fine, here is the cap > 4) Local region, can you please put this on my agent, i included the cap= . > 5) Hello asset service A, i need Z, here is the cap > 6) Cap is good, data coming up, have fun. > 7) Agent service, your agent is now wearing Z > 8) Viewer, your avatar is now wearing Z > User: Hmm, amazing inventory has not been *that* amazing lately. 'll > make a backup, just in case > 9) Hello asset service A, please send me a cap for Z, here are my > credentials > 10) Your fine, here is the cap > 11) Local asset storage, please store Z for me, here is the cap to get it > 12) Hello asset service A, i want Z, here is the cap > 13) Cap is good, data coming up, have fun. > 14) Viewer, Z is now stored for you > User: I am Ready!, Lets try to get to immersive world! > 15) Hello immersive world, can i get in? Here are my credentials, and a > list of my stuff. > 16) Asset service A, please send me a cap for X, here are my credentials = (I > want this cap for consistency) > 17) Your fine, here is the cap > 18) Asset service B, please send me a cap for Y, here are my credentials = (I > want this cap for consistency) > 19) Very sorry, but your not one of us, you can't have Y > 20) Asset service B, please send me a cap for Z, here are my credentials = (I > want a cap for consistency) > [Region service: Timeout... amazing inventory must be overloaded.. oh > well... ] > 21) Agent service, you wanted to send somebody over, here are your > permissions. > 22) Viewer, you asked for a transfer try, here are your results > User thinks: Crap! Big asset service does not allow me to take my > yellow stockings! And Amazing assets failed to deliver my zodiac dress. = At > least i made a backup of that dress! > 23) 'll take the yellow stockings off... > 24) ... done ('ll trash them here and now, forever, who needs stuff you > can't use!) > 25) The zodiac dress was not delivered by Big assets service, but i have = a > local copy! > 26) Local Asset service, please send me Z, here are my credentials > 27) I dont know you, but I 'll trust you, here is the cap, but you better > store the data, its single use, i need to protect myself. > 28) Local region, can you please put this on my agent, i include the cap. > 29) Local Asset service, i need Z, here is the cap > 30) Cap is good, data coming up, have fun. > 31) Cap was only good for one time, I made a copy, but my policy is to on= ly > grant you fair use rights, at a later time i might even tell you to repla= ce > the dress. > 32) Viewer, you can wear Z for now, but the asset service granted only fa= ir > use, i might ask you to replace the dress at a later time. > 33) Ready at last! Off to immersive world!, I hope its not to crowded the= re > or 'll loose my dress... > 34) Hello immersive world, here are my credentials, and a list of stuff i > want to bring > 35) Hello asset service A, please send me a cap for X, here are my > credentials > [darn, I should have kept that cap from last time..] > 36) Your fine, here is the cap. > [Region service finds fair-use warning on Z and decides to make its ow= n > copy] > 37) Hello Local region, can i still have Z? Here is the cap > 38) Cap is still good, data coming up, have fun. > [Region service stores asset in private storage, providing a cap to > replace the fair use one] > 39) Agent service, you wanted to send somebody over, here are your > permissions & info. > 40) Hello immersive world, just get me there, and use what you can > 41) Placement done, Z is currently buffered by us as wel, you need to get > details for X, have fun. > 42) You are now in immersive world, your dress is buffered there as well, > but you need to get X! > 43) Hello asset service A, i want X, here is the cap > 44) Cap is good, data coming up, have fun. > 45) Viewer, here is an update of the state of the world your agent is in, > please render. > > As far as I can see this conforms fully to our charter, and i hope it is > possible to use large portions of the existing code bases. However, as sa= id > above, i did not really try to capture the old thinking, and I also might > have misconceptions about the way to do these things in general. > Looking forward to constructive comments. > > -- Vaughn > > On Sun, Apr 3, 2011 at 8:38 PM, Vaughn Deluca wr= ote: > >> Thanks for the pointers. I have a busy week in RL in front of me, so i >> wont have to much time to respond the next few days, however, i intend t= o >> start doing the following things: >> >> - Produce a visual that reflects my thinking, i.e. an illustration of my >> response to Morgaine's itemlist above. >> - Read up on the older notes, as well as more reading in the list archi= ve >> - Try to make a summary for the wiki >> >> Regarding the use of domain, I think services are eventually what counts= , >> but its all terminology. The way I read the AWG diagrams is that the age= nt >> domain is actually a cluster of tightly integrated services. When the >> functionality of each sub-service is described properly and with uniform >> interfaces the domain will slowly dissolve. But let not get ahead of out >> selfs. We should put up some clear descriptions on the wiki for our view= s on >> this, and *after* that we can decide what we need and what can go. >> >> Its been a very useful and illuminating weekend for me, and i am a lot >> more optimistic about the future of vwrap than two weeks ago. >> >> -- Vaughn >> >> >> >> On Sun, Apr 3, 2011 at 7:20 PM, Dzonatas Sol wrote: >> >>> Probably easy as suggested in other terms here on this list, as how the >>> client contacts the asset services now in the regions. The newer issue = is to >>> unitize that asset services. Since their is proprietary (legacy) code t= hen >>> we can't expect that to change, and some form of proxy is of need. What= ever >>> works best, I tried to narrow it down to suggestions here. >>> >>> Eventually, the agent domain is ideal to handle the direction of the >>> asset services. This concept, unfortunately, ended support awhile ago w= ith >>> changes in LL. >>> Also see; http://wiki.secondlife.com/wiki/Agent_Domain >>> And: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset (warn: >>> unstructured collaborative notes, dumped on me and I tried to fix) >>> >>> I tried to find previous visuals. >>> >>> I'd imagine the agent domain could grow out of unitized versions of ass= et >>> services. Despite that, I think that concept helps view where we were a= t in >>> discussion and what didn't happen. >>> >>> Vaughn Deluca wrote: >>> >>>> Hi=EF=BF=BDDzonatas >>>> >>>> Can you expand on that, what would be needed for legacy support in VWA= P >>>> terms=EF=BF=BD?, >>>> If i want to read up on how the=EF=BF=BDasset server may proxy the sim= ulator, >>>> what would you recommend me to read? >>>> >>>> -- Vaughn >>>> >>>> On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol >>> dzonatas@gmail.com>> wrote: >>>> >>>> Some stated the proxy-to-asset-server is built into the sim; >>>> however, keep in mind possible legacy support where the asset >>>> server may proxy the simulator. >>>> >>>> >>>> Dzonatas Sol wrote: >>>> >>>> Somehow I feel the basic asset server being able to login and >>>> download assets is now priority, yet I also wondered the best >>>> way to patch this into the current mode of viewers. >>>> >>>> Maybe offer (1) by proxy (sim-side) and (2) by patch >>>> (viewer-side) that either of these two are optional and >>>> neither are mandatory for now. Thoughts? >>>> >>>> Israel Alanis wrote: >>>> >>>> >>>> > when designing for scalability, the model to bear in >>>> mind is ... >>>> >>>> Well, there are a lot of different models to keep in mind, >>>> and many different use cases. One particular use case to >>>> keep in mind is: "User acquires new outfit, and wants to >>>> 'show it off' in a highly populated region". >>>> >>>> > Both worlds and asset services may include commercial, >>>> community, and personal services >>>> >>>> Yes, yes and yes. I'm particularly concerned about how the >>>> model affects the ability to host personal asset services. >>>> >>>> > a proxying region, which would get slammed for every >>>> asset worn by every avatar present. >>>> >>>> Granted the collection of services that are provided by >>>> the region need to be scaled to meet the demands of that >>>> region. That's all part of capacity planning. >>>> >>>> > regions run many different CPU-intensive tasks, >>>> including physics simulation and server-side scripting, >>>> and absolutely cannot afford to serve assets too >>>> Well... who said the same CPU's have to do proxying, >>>> physics simulation and server-side scripting? Asset >>>> proxying is a different service than physics simulation >>>> and can be on separate hardware, could make use of >>>> geographically distributed caching, and in certain >>>> deployment patterns, the same caching services could be >>>> shared by different regions. (Server-side scripting is a >>>> discussion for another day). >>>> >>>> > This is why we have to go parallel... >>>> >>>> Totally agree, and a proxying model could and should also >>>> take advantage of parallelism. >>>> >>>> > I think you're wrong that it has to cost much money. ?vs? >>>> > It costs money to host a high performance and scalable >>>> asset service and a high bandwidth network to handle the >>>> traffic. =EF=BF=BDA *lot* of money. >>>> I think what you're saying is: "It costs a lot of money to >>>> build a scalable asset service, but if assets are spread >>>> throughout the internet they don't have to be scalable." >>>> But that's not quite right. You're opening up every asset >>>> server to the VW equivalent of being slashdotted, so are >>>> you sure you're not forcing *every* asset service to be >>>> scalable and handle a lot of bandwith and network traffic? >>>> It's the exact opposite of your intention, but I think >>>> that's the result, all the same. >>>> >>>> This particular design decision has a big effect on the >>>> economics of the VW infrastructure. I'd rather the >>>> economics to work out such that a region provider who >>>> wishes to build a region that supports a small population, >>>> can do so economically. A region that wants to host a >>>> *large* population has to bear that cost of providing that >>>> scalable asset service. >>>> I want the economics of hosting a small asset service to >>>> be a non-issue (as to best promote creation and >>>> creativity). Creating a high bar to provide asset services >>>> will mean that service will cost money and people >>>> shouldn't have to pay money just to create or own VW >>>> objects (I'm using 'own' here to refer to maintaining >>>> their existence, I'm not trying to make a >>>> 'leftist'/'communist' statement about ownership ;) >>>> >>>> - Izzy >>>> >>>> >>>> On Apr 2, 2011, at 3:58 PM, Morgaine wrote: >>>> >>>> Izzy, when designing for scalability, the model to >>>> bear in mind is that of seasoned virtual world >>>> travelers whose inventories contain assets from many >>>> different worlds, those assets being served by many >>>> different asset services. =EF=BF=BDBoth worlds and asse= t >>>> services may include commercial, community, and >>>> personal services, and as the metaverse grows, that >>>> set is highly likely to become progressively less >>>> clustered and more diverse. >>>> >>>> When those seasoned travelers click on an advertised >>>> VW link and perform an inter-world teleport to one >>>> particular world's region to share an experience, >>>> their "worn" assets (the only ones of interest to the >>>> region) will contain references to asset services >>>> spread widely across the Internet. =EF=BF=BDThe fetches= by the >>>> travelers' clients occur over many parallel paths from >>>> clients to asset services, so one can reasonably >>>> expect reduced network contention and reduced asset >>>> server loading because they are both spread out over >>>> however many asset services are being referenced by >>>> the overall set of assets in the region. >>>> >>>> This is very different to the case of a proxying >>>> region, which would get slammed for every asset worn >>>> by every avatar present. =EF=BF=BDIn our current archit= ecture, >>>> regions run many different CPU-intensive tasks, >>>> including physics simulation and server-side >>>> scripting, and absolutely cannot afford to serve >>>> assets too unless your scalability requirements are >>>> very low indeed, ie. just a few dozen avatars of >>>> today's kind. =EF=BF=BDWe've hit the ceiling already on= region >>>> scalability done that way. =EF=BF=BDThere is nowhere to= go in >>>> that direction at all beyond improving the code like >>>> Intel demonstrated, and that work is subject to a law >>>> of diminishing returns. >>>> >>>> This is why we have to go parallel, and I think you're >>>> wrong that it has to cost much money. =EF=BF=BDAs we sp= read >>>> the load across more and more asset services, we are >>>> simply better utilizing all the hardware that's >>>> already out there on the Internet, at least in respect >>>> of community and private resources. =EF=BF=BDBut add to= the >>>> community and private resources the commercial asset >>>> services that are likely to appear to exploit this >>>> opportunity, and not only will the number of asset >>>> services leap, but the power of each one will rocket >>>> too, because, after all, these businesses will be >>>> heavily optimized for the job. >>>> >>>> As to why a world would want clients to access >>>> external asset services instead of providing its own >>>> implementation, that's an easy question. =EF=BF=BDIt co= sts >>>> money to host a high performance and scalable asset >>>> service and a high bandwidth network to handle the >>>> traffic. =EF=BF=BDA *lot* of money. =EF=BF=BDIn contras= t, it costs a >>>> world nothing to let others serve the assets to >>>> clients. =EF=BF=BDAnd that matters to the bottom line. >>>> >>>> >>>> Morgaine. >>>> >>>> >>>> >>>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>> >>>> On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis >>>> >>>> >>> >>>> >> wrote: >>>> >>>> =EF=BF=BD =EF=BF=BD> As always though, it's a trade-off= , since the >>>> proxied design >>>> =EF=BF=BD =EF=BF=BDhas very poor scalability compared t= o the >>>> distributed one. >>>> >>>> =EF=BF=BD =EF=BF=BDI don't agree with that... If a user= enters a >>>> highly populated >>>> =EF=BF=BD =EF=BF=BDregion, >>>> =EF=BF=BD =EF=BF=BDevery other client is going to (coul= d and should be >>>> trying to) >>>> =EF=BF=BD =EF=BF=BDhit the >>>> =EF=BF=BD =EF=BF=BDasset server(s) for the assets that = the user is >>>> wearing (assuming >>>> =EF=BF=BD =EF=BF=BDthey're not cached locally). =EF=BF= =BDEvery asset server >>>> has to be scaled up >>>> =EF=BF=BD =EF=BF=BDto the point that it can handle that= load from all >>>> over... >>>> >>>> =EF=BF=BD =EF=BF=BDIf I'm hosting a region that support= s 10s of >>>> thousands of >>>> =EF=BF=BD =EF=BF=BDsimultaneous >>>> =EF=BF=BD =EF=BF=BDusers (thinking of the future), I al= ready have to >>>> scale to meet that >>>> =EF=BF=BD =EF=BF=BDdemand. If the region is proxying th= e assets, then, >>>> yes the >>>> =EF=BF=BD =EF=BF=BDregion has >>>> =EF=BF=BD =EF=BF=BDto be scaled to meet that asset dema= nd too, but it >>>> already has to be >>>> =EF=BF=BD =EF=BF=BDscaled to meet other demands of bein= g a region >>>> server... and why is >>>> =EF=BF=BD =EF=BF=BDscaling those asset proxy services h= ard? =EF=BF=BDIt's >>>> going to cost $, >>>> =EF=BF=BD =EF=BF=BDbut is >>>> =EF=BF=BD =EF=BF=BDnot technically challenging. So, if = I want to host >>>> a region like >>>> =EF=BF=BD =EF=BF=BDthat... sure it will cost me, but th= e simulation >>>> will be consistent >>>> =EF=BF=BD =EF=BF=BDand users will be able to participat= e equally, >>>> regardless of the >>>> =EF=BF=BD =EF=BF=BDcapabilities of their individual ass= et services. >>>> >>>> >>>> >>>> >>>> =EF=BF=BD =EF=BF=BDOn Fri, Apr 1, 2011 at 11:55 PM, Mor= gaine >>>> =EF=BF=BD =EF=BF=BD>>> >>>> =EF=BF=BD =EF=BF=BD>>> >>>> >> wrote: >>>> =EF=BF=BD =EF=BF=BD> Every design choice results in a t= rade-off, >>>> Vaughn, improving >>>> =EF=BF=BD =EF=BF=BDone thing at >>>> =EF=BF=BD =EF=BF=BD> the expense of something else. =EF= =BF=BDIf every time we >>>> offered a >>>> =EF=BF=BD =EF=BF=BDservice we had to >>>> =EF=BF=BD =EF=BF=BD> inform its users about the downsid= es of all the >>>> trade-offs we >>>> =EF=BF=BD =EF=BF=BDhave made, >>>> =EF=BF=BD =EF=BF=BD> they would have an awful lot to re= ad. ;-) >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> The specific trade-off that you ar= e discussing is no >>>> =EF=BF=BD =EF=BF=BDdifferent. =EF=BF=BDA region >>>> =EF=BF=BD =EF=BF=BD> that proxies all content has the "= benefit" of >>>> acquiring control >>>> =EF=BF=BD =EF=BF=BDfrom the >>>> =EF=BF=BD =EF=BF=BD> asset servers over the items in th= e region, so >>>> that it can >>>> =EF=BF=BD =EF=BF=BDensure that >>>> =EF=BF=BD =EF=BF=BD> everyone in the region not only ob= tains the items >>>> but obtains >>>> =EF=BF=BD =EF=BF=BDthe same items >>>> =EF=BF=BD =EF=BF=BD> as everyone else. =EF=BF=BDThat do= es indeed provide a >>>> greater guarantee of >>>> =EF=BF=BD =EF=BF=BD> consistency than a deployment in w= hich the region >>>> only passes >>>> =EF=BF=BD =EF=BF=BDasset URIs to >>>> =EF=BF=BD =EF=BF=BD> clients who then fetch the items f= rom asset services >>>> =EF=BF=BD =EF=BF=BDseparately. =EF=BF=BDAs always >>>> =EF=BF=BD =EF=BF=BD> though, it's a trade-off, since th= e proxied >>>> design has very >>>> =EF=BF=BD =EF=BF=BDpoor scalability >>>> =EF=BF=BD =EF=BF=BD> compared to the distributed one. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> If we're going to warn users of th= e potential for >>>> inconsistency >>>> =EF=BF=BD =EF=BF=BDin the >>>> =EF=BF=BD =EF=BF=BD> distributed deployment as you sugg= est, are we >>>> also going to >>>> =EF=BF=BD =EF=BF=BDwarn them of >>>> =EF=BF=BD =EF=BF=BD> non-scalability in the proxied one= ? =EF=BF=BDI really >>>> don't see much >>>> =EF=BF=BD =EF=BF=BDmerit in the >>>> =EF=BF=BD =EF=BF=BD> idea of warning about design choic= es. =EF=BF=BDMany such >>>> choices are >>>> =EF=BF=BD =EF=BF=BDtechnical, and >>>> =EF=BF=BD =EF=BF=BD> the issues are quite likely to be = of little >>>> interest to >>>> =EF=BF=BD =EF=BF=BDnon-technical users >>>> =EF=BF=BD =EF=BF=BD> anyway. =EF=BF=BDIn any case, the = better services are >>>> likely to provide >>>> =EF=BF=BD =EF=BF=BDsuch >>>> =EF=BF=BD =EF=BF=BD> information in their online docume= ntation, I >>>> would guess. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> You mentioned users "voting with t= heir feet" or >>>> choosing to >>>> =EF=BF=BD =EF=BF=BDaccept the risk >>>> =EF=BF=BD =EF=BF=BD> of inconsistency. =EF=BF=BDWell th= at will happen anyway, >>>> when services >>>> =EF=BF=BD =EF=BF=BDfail and >>>> =EF=BF=BD =EF=BF=BD> users get annoyed. =EF=BF=BDIf som= e asset services refuse >>>> to send the >>>> =EF=BF=BD =EF=BF=BDrequested >>>> =EF=BF=BD =EF=BF=BD> items to some users, those service= s will get a >>>> bad reputation >>>> =EF=BF=BD =EF=BF=BDand people >>>> =EF=BF=BD =EF=BF=BD> will choose different asset servic= es instead. >>>> =EF=BF=BDLikewise, if a >>>> =EF=BF=BD =EF=BF=BDworld service >>>> =EF=BF=BD =EF=BF=BD> proxies everything and so it can't= handle a large >>>> number of >>>> =EF=BF=BD =EF=BF=BDassets or of >>>> =EF=BF=BD =EF=BF=BD> people, users will get annoyed at = the lag and will >>>> go >>>> =EF=BF=BD =EF=BF=BDelsewhere. =EF=BF=BDThis user >>>> =EF=BF=BD =EF=BF=BD> evaluation and "voting with their = feet" happens >>>> already with >>>> =EF=BF=BD =EF=BF=BDonline services >>>> =EF=BF=BD =EF=BF=BD> all over the Internet, and I am su= re that this >>>> human process >>>> =EF=BF=BD =EF=BF=BDwill continue >>>> =EF=BF=BD =EF=BF=BD> to work when the services are asse= t and region >>>> services. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> Back in September 2010, I wrote th= is post which >>>> proposes that >>>> =EF=BF=BD =EF=BF=BDwe use in >>>> =EF=BF=BD =EF=BF=BD> VWRAP a form of asset addressing t= hat provides >>>> massive >>>> =EF=BF=BD =EF=BF=BDscalability at the >>>> =EF=BF=BD =EF=BF=BD> same time as a very high degree of= resilience -- >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD >>>> =EF=BF=BD >>>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >>>> =EF=BF=BD =EF=BF=BD. =EF=BF=BDIt is >>>> =EF=BF=BD =EF=BF=BD> based on the concept of the URI co= ntaining a host >>>> part and a >>>> =EF=BF=BD =EF=BF=BDhash part, >>>> =EF=BF=BD =EF=BF=BD> where the hash is generated (once,= at the time of >>>> storage to >>>> =EF=BF=BD =EF=BF=BDthe asset >>>> =EF=BF=BD =EF=BF=BD> service) using a specified digest = algorithm over >>>> the content of >>>> =EF=BF=BD =EF=BF=BDthe asset >>>> =EF=BF=BD =EF=BF=BD> being referenced. =EF=BF=BDYou may= wish to note that if >>>> this design >>>> =EF=BF=BD =EF=BF=BDwere used, the >>>> =EF=BF=BD =EF=BF=BD> failure of an asset service to del= iver a >>>> requested item would >>>> =EF=BF=BD =EF=BF=BDresult in a >>>> =EF=BF=BD =EF=BF=BD> failover request for the item to o= ne or more >>>> backup services, >>>> =EF=BF=BD =EF=BF=BDusing the same >>>> =EF=BF=BD =EF=BF=BD> hash part but with a different hos= t address. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> This can go some way towards overc= oming the >>>> problem that you >>>> =EF=BF=BD =EF=BF=BDthink might >>>> =EF=BF=BD =EF=BF=BD> occur when assets are fetched by c= lients from >>>> asset services >>>> =EF=BF=BD =EF=BF=BDdirectly. >>>> =EF=BF=BD =EF=BF=BD> Although it won't help when the mi= ssing item is >>>> available from >>>> =EF=BF=BD =EF=BF=BDonly a single >>>> =EF=BF=BD =EF=BF=BD> asset service, it will help in man= y other cases, >>>> and it will >>>> =EF=BF=BD =EF=BF=BDcompensate for >>>> =EF=BF=BD =EF=BF=BD> service failures and network outag= es >>>> automatically at the same >>>> =EF=BF=BD =EF=BF=BDtime. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> PS. This design for hash-based ass= et addressing >>>> is already >>>> =EF=BF=BD =EF=BF=BDbeing tested by >>>> =EF=BF=BD =EF=BF=BD> Mojito Sorbet in her experimental = world and >>>> client. =EF=BF=BDIt would give >>>> =EF=BF=BD =EF=BF=BD> VWRAP-based worlds an improved lev= el of service >>>> availability, >>>> =EF=BF=BD =EF=BF=BDso I think it >>>> =EF=BF=BD =EF=BF=BD> should be a core feature of our pr= otocol. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> Morgaine. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> =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 >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> On Fri, Apr 1, 2011 at 11:17 PM, V= aughn Deluca >>>> =EF=BF=BD =EF=BF=BD>>> >>>> >>> >> >>>> =EF=BF=BD =EF=BF=BD> wrote: >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> This is a question i discussed wi= th Morgaine >>>> off-list a while >>>> =EF=BF=BD =EF=BF=BDago (I >>>> =EF=BF=BD =EF=BF=BD>> intended to send it to the list b= ut pushed the >>>> wrong button...) I >>>> =EF=BF=BD =EF=BF=BD>> think we need to address this pro= blem, and >>>> decide how to deal >>>> =EF=BF=BD =EF=BF=BDwith it. >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDIn Davids deployment dra= ft, section 7.3.1.1 an >>>> overview is >>>> =EF=BF=BD =EF=BF=BDgiven van >>>> =EF=BF=BD =EF=BF=BD>> ways to deliver content to the re= gion. One way >>>> is only passing a >>>> =EF=BF=BD =EF=BF=BD>> capability that allows access to = (part of) the >>>> resource: >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD 7.3.1.1. =EF=BF=BDContent delivery models >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD A range of possible represenations can >>>> be passed to >>>> =EF=BF=BD =EF=BF=BDa region for >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD simulation. [...] The other end of the >>>> delivery spectrum >>>> =EF=BF=BD =EF=BF=BD>> involves passing >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD only a URI or capability used to >>>> access the rendering >>>> =EF=BF=BD =EF=BF=BD>> information and a >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD collision mesh,and related data for >>>> physical simulation. >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD In such a model, the client is >>>> responsible for >>>> =EF=BF=BD =EF=BF=BDfetching the >>>> =EF=BF=BD =EF=BF=BD>> additional >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD information needed to render the >>>> item's visual >>>> =EF=BF=BD =EF=BF=BDpresence from a >>>> =EF=BF=BD =EF=BF=BD>> separate >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD service. =EF=BF=BDThis fetch can be done >>>> *under the >>>> =EF=BF=BD =EF=BF=BDcredentials of the >>>> =EF=BF=BD =EF=BF=BD>> end user* >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD viewing the material [my emphasis--VD] >>>> , and >>>> =EF=BF=BD =EF=BF=BDdivorces the >>>> =EF=BF=BD =EF=BF=BD>> simulation from >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD the trust chain needed to manage >>>> content. =EF=BF=BDAny >>>> =EF=BF=BD =EF=BF=BDautomation >>>> =EF=BF=BD =EF=BF=BD>> is done on a >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD separate host which the content >>>> creator or owner trusts, >>>> =EF=BF=BD =EF=BF=BD>> interacting with the >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD object through remoted interfaces. >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDI can see the need for s= uch a setup, however, i >>>> feel we are >>>> =EF=BF=BD =EF=BF=BD>> unpleasantly close to a situation= were the >>>> coherence of the >>>> =EF=BF=BD =EF=BF=BDsimulation >>>> =EF=BF=BD =EF=BF=BD>> falls apart. >>>> =EF=BF=BD =EF=BF=BD>> In this deployment pattern the re= gion advertises >>>> the presence >>>> =EF=BF=BD =EF=BF=BDof the >>>> =EF=BF=BD =EF=BF=BD>> asset, and *some* clients will be= able to get it >>>> as expected, >>>> =EF=BF=BD =EF=BF=BDwhile >>>> =EF=BF=BD =EF=BF=BD>> -based on the arbitrary whims of = the asset >>>> service- others >>>> =EF=BF=BD =EF=BF=BDmight not. >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> My hope would be that after the a= sset server >>>> provides the >>>> =EF=BF=BD =EF=BF=BDregion with >>>> =EF=BF=BD =EF=BF=BD>> the capability to get the asset, = it gives up >>>> control. That >>>> =EF=BF=BD =EF=BF=BDwould mean >>>> =EF=BF=BD =EF=BF=BD>> that if the client finds the inve= ntory server is >>>> unwilling to >>>> =EF=BF=BD =EF=BF=BDserve >>>> =EF=BF=BD =EF=BF=BD>> the content - in spire of the reg= ion saying it >>>> is present-, >>>> =EF=BF=BD =EF=BF=BDthe client >>>> =EF=BF=BD =EF=BF=BD>> should be able to turn around ask= the *region* >>>> for the asset, >>>> =EF=BF=BD =EF=BF=BD(and get >>>> =EF=BF=BD =EF=BF=BD>> is after all). >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDIf that is not the case,= -and there are >>>> probably good reasons >>>> =EF=BF=BD =EF=BF=BDfor the >>>> =EF=BF=BD =EF=BF=BD>> deployment pattern as described- = =EF=BF=BDshouldn't we >>>> *warn* clients >>>> =EF=BF=BD =EF=BF=BDthat the >>>> =EF=BF=BD =EF=BF=BD>> region might be inconsistent, so = the users >>>> behind the client >>>> =EF=BF=BD =EF=BF=BDcan vote >>>> =EF=BF=BD =EF=BF=BD>> with their feet, (or take the ris= k)? >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> --Vaughn >>>> =EF=BF=BD =EF=BF=BD>> _________________________________= ______________ >>>> =EF=BF=BD =EF=BF=BD>> vwrap mailing list >>>> =EF=BF=BD =EF=BF=BD>> vwrap@ietf.org >>>> > >>>> >>>> =EF=BF=BD =EF=BF=BD>> https://www.ietf.org/mailman/list= info/vwrap >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> __________________________________= _____________ >>>> =EF=BF=BD =EF=BF=BD> vwrap mailing list >>>> =EF=BF=BD =EF=BF=BD> vwrap@ietf.org >>>> > >>>> >>>> =EF=BF=BD =EF=BF=BD> https://www.ietf.org/mailman/listi= nfo/vwrap >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> >>>> >>>> >>>> >>>> >>>> ---------------------------------------------------------------------= --- >>>> >>>> _______________________________________________ >>>> vwrap mailing list >>>> vwrap@ietf.org >>>> https://www.ietf.org/mailman/listinfo/vwrap >>>> =EF=BF=BD >>>> >>>> >>>> >>>> >>>> >>>> -- --- https://twitter.com/Dzonatas_Sol --- >>>> Web Development, Software Engineering, Virtual Reality, Consultant >>>> >>>> _______________________________________________ >>>> vwrap mailing list >>>> vwrap@ietf.org >>>> https://www.ietf.org/mailman/listinfo/vwrap >>>> >>>> >>>> >>> >>> -- >>> --- https://twitter.com/Dzonatas_Sol --- >>> Web Development, Software Engineering, Virtual Reality, Consultant >>> >>> >> > --0015174be714e6a64504a06cccc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj5EcmF0ISwgSSBhbHJlYWR5IGZvdW5kIHR3byBlZGl0aW5nIG1pc3Rha2VzLCBzdGVwIDIw IHNob3VsZCBhZGRyZXNzIEEsIG5vdCBCIGFuZCBzaG91bGQgcmVhZDo8L2Rpdj48ZGl2PjIwKSBB c3NldCBzZXJ2aWNlIEEsIHBsZWFzZSBzZW5kIG1lIGEgY2FwIGZvciBaLCBoZXJlIGFyZSBteSBj cmVkZW50aWFscyAoSSB3YW50IGEgY2FwIGZvciBjb25zaXN0ZW5jeSk8L2Rpdj48ZGl2Pgo8YnI+ PC9kaXY+PGRpdj5BbmQgdGhlIHNhbWUgbWl4dXAgaW4gc3RlcCAyNTogJnF1b3Q7QW16aW5nIEFz c2V0cyZxdW90OyBzaG91bGQgYmUgbWVudGlvbmVkIGluc3RlYWQgb2YgJnF1b3Q7QmlnIGFzc2V0 cyZxdW90Ozo8L2Rpdj48ZGl2PjI1KSBUaGUgem9kaWFjIGRyZXNzIHdhcyBub3QgZGVsaXZlcmVk IGJ5IEFtemluZyBhc3NldHMsIGJ1dCBpIGhhdmUgYSBsb2NhbCBjb3B5ITwvZGl2Pgo8ZGl2Pjxi cj48L2Rpdj48ZGl2Pkkgd2lsbCBhZGQgYW4gdXBkYXRlZCB2ZXJzaW9uIG9mIHRoZSBkZXNjcmlw dGlvbiBvbiB0aGUgdndyYXAgd2lraTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+LS0gVmF1Z2hu PC9kaXY+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBGcmksIEFwciA4LCAyMDExIGF0 IDY6NDAgUE0sIFZhdWdobiBEZWx1Y2EgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWls dG86dmF1Z2huLmRlbHVjYUBnbWFpbC5jb20iPnZhdWdobi5kZWx1Y2FAZ21haWwuY29tPC9hPiZn dDs8L3NwYW4+IHdyb3RlOjxicj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1s ZWZ0OjFleDsiPjxkaXY+VldSQVAgc2VydmljZXMgaGlnaCBsZXZlbCBtZXNzYWdlIGZsb3cgKHBy ZWxpbWluYXJ5IGRpYWdyYW0gZHJhZnQpIHNlZTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGEg aHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvdndyYXAvdHJhYy9hdHRhY2htZW50 L3dpa2kvRGlhZ3JhbXMvVldSQVBfRmxvd0V4YW1wbGVfVkQxLnBkZiIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL3Z3cmFwL3RyYWMvYXR0YWNobWVudC93aWtp L0RpYWdyYW1zL1ZXUkFQX0Zsb3dFeGFtcGxlX1ZEMS5wZGY8L2E+PGJyPgoKPC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj5UaGUgbWFpbiByZWFzb24gdGhhdCBpIGFtIHN1Ym1pdHRpbmcgdGhpcyBp biBzcGl0ZSBvZiBteSBsYWNrIG9mIGZvcm1hbCBleHBlcnRpc2UgaXMgdGhhdCB0aGUgZ3JvdXAg aW4gbXkgdmlldyBiYWRseSBuZWVkcyBhIHNvbGlkIGJhc2lzIGZvciBkaXNjdXNzaW9uIGFuZCBw cmV2ZW50aW5nIGVuZGxlc3MgcmVwZWF0aW5nIGxvb3BzLiBUaGlzIGV4YW1wbGUgaXMgcHJvYmFi bHkgd3JvbmcgaW4gbWFueSB3YXlzLCBidXQgaXRzIGJldHRlciB0aGFuIHdoYXQgd2UgaGF2ZSBw dWJsaWNseSBhdmFpbGFibGUgb24gaW50ZXJvcCBub3cgKGFsdGhvdWdoIE1vcmdhaW5lIGlzIHdv cmtpbmcgb24gc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZiB0aGUgcmVjZW50IGRpc2N1c3Np b25zIGhlcmUpwqA8L2Rpdj4KCjxkaXY+PGJyPjwvZGl2PjxkaXY+SSBob3BlIHRoaXMgZGlhZ3Jh bSB3aWxsIGdpdmUgdXMgYSBiYXNlIGZvciBkaXNjdXNzaW9uLiBJIGNvdWxkIGhhdmUgZG9uZSBt eSBob21ld29yayBiZXR0ZXIgYnkgcmVzZWFyY2hpbmcgdGhlIG9sZCBPR1Agc3R1ZmYgaW4gbW9y ZSBkZXB0aCwgYW5kIGkgcHJvYmFibHkgwqB3aWxsIGRvIHNvIGluIHRoZSBmdXR1cmUgLCBidXQg Zm9yIG5vdyBJIGp1c3QgdHJpZWQgdG8gZm9sbG93ZWQgdGhlIGdlbmVyYWwgcHJpbmNpcGxlcyBh cyBmYXIgYXMgaSB1bmRlcnN0YW5kIHRoZW0sIHRvIHNlZSB3aGF0IHJlc3BvbnNlIHRoYXQgeWll bGRzIGZyb20gdGhlIGdyb3VwLiBJbiBvdGhlciB3b3JkcyxJIHRyeSB0byBsZXQgdGhlIGdyb3Vw IGVkdWNhdGUgbWUgOnA8L2Rpdj4KCjxkaXY+PGJyPjwvZGl2PjxkaXY+Tm90ZSB0aGF0IGluIMKg bXkgdmlldyBhbGwgc2VydmljZXMgYXJlIGVxdWFsLCBpbiBwcmluY2lwbGUgaXQgZG9lcyBub3Qg bWF0dGVyIGluIHdoYXQgJnF1b3Q7ZG9tYWluJnF1b3Q7IHRoZXkgcnVuLCBzaW5jZSB0cnVzdCBh bmQgcG9saWN5IGFyZSBmdWxseSBsb2NhbGl6ZWQuIEl0IGlzIGhvd2V2ZXIgdmVyeSBwb3NzaWJs ZSB0byBoYXZlIGludGVybmFsIHNob3J0Y3V0cyBpbiB0aGUgc2VydmljZXMgdG8gc3BlZWQgdXAg cHJvY2Vzc2luZy7CoDwvZGl2PgoKPGRpdj48YnI+PC9kaXY+PGRpdj5JbiB0aGUgZXhhbXBsZSBJ IG9wdGVkIGZvciBhbiBleHRlcm5hbCBBZ2VudCBzZXJ2aWNlLCBidXQgSSBjb3VsZCBhcyB3ZWxs IGhhdmUgaW5jb3Jwb3JhdGVkIHRoYXQgaW4gdGhlIHNldCBvZiBsb2NhbCBzZXJ2aWNlcy4gQXMg aW5kaWNhdGVkIGFib3ZlIGFsbCBzZXJ2aWNlcyBjb3VsZCBhbHNvIGJlIHJ1biBieSBkaWZmZXJl bnQgb3JnYW5pc2F0aW9ucywgdHJ1ZSB0byB3aGF0IFZXUkFQIHN0YW5kcyBmb3IuIEl0cyBhbGwg dXAgdG8gdGhlIGRlcGxveWVyLCBpbmNsdWRpbmcgYSB1c2VyIGF0IGhvbWUgd2hvIG1pZ2h0IHdh bnQgdG8gcnVuIGEgZnVsbCB3b3JsZCBmb3IgZmFtaWx5IGFuZCBmcmllbmRzLiBUaG9zZSBmcmll bmRzIG1pZ2h0IHRyeSB0byB1c2UgdGhhdCBhZ2VudCBzZXJ2aWNlIHRvIHZlbnR1cmUgb3V0IGlu IHRoZSB2aXJ0dWFsIHVuaXZlcnNlLsKgPC9kaXY+Cgo8ZGl2PkkgZW52aXNpb24gdGhhdCB0aGUg ZmluYWwgaWRlbnRpdHkgwqBwcm92aWRlciBpcyBleHRlcm5hbCwgdXNpbmcgT3BlbklEIGFuZCBP QXV0IMKgb3Igd2hhdGV2ZXIgb3RoZXIgwqBtYWdpYyB0aGF0IEkgZG8gbm90IHlldCBmdWxseSB1 bmRlcnN0YW5kIGV4aXN0cyBvdXQgdGhlcmUuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUg wqBleGFtcGxlIGhhcyAzIG1haW4gcHVycG9zZXM6PC9kaXY+Cgo8ZGl2Pi0gwqBQcm92aWRlIGEg cmVmZXJlbmNlIGZvciBkaXNjdXNzaW9uwqA8L2Rpdj48ZGl2Pi0gSWxsdXN0cmF0ZXMgdGhlIHVz ZSBjYXNlIG9mIHRvdXJpc20sIGFuZCAqdHJ1ZSogaW50ZXJvcC48L2Rpdj48ZGl2Pi0gSWxsdXN0 cmF0ZSBjb25zaXN0ZW5jeSBwcm9ibGVtcyBhbG9uZyB0aGUgbGluZXMgZGlzY3Vzc2VkIMKgaGVy ZSBoaWdoZXIgdXAgaW4gdGhpcyB0cmVhZCwgYXMgd2VsbCBhcyB0aGUgJnF1b3Q7c2xhc2hkb3Qm cXVvdDsgcHJvYmxlbSB0aGF0IE1vcmdhaW5lIG91dGxpbmVkIHNvIGNsZWFybHkuPC9kaXY+Cgo8 ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZSBtZXNzYWdlIGZsb3cgYXNzdW1lcyBhbiBhdmF0YXIgYWxy ZWFkeSBwcmVzZW50IGluIHNvbWUgcmVnaW9uLCAoYSBzbWFsbCBzY2FsZSBsb2NhbCBob21lIHJl Z2lvbiBpbiB0aGlzIGNhc2UsIGJ1dCB0aGF0IGlzIGJ5IG5vIG1lYW5zIGVzc2VudGlhbCwgaXQg Y291bGQgYmUgYSBidWlsZCBpbiByZWdpb24gaW4gdGhlIHZpZXdlciBvciBhIGJpZyBjb21tZXJj aWFsIHJlZ2lvbikuIFRoZSB1c2VyIGlzIHByZXBhcmluZyBmb3IgYSB0cmlwIHRvIGltbWVyc2l2 ZSB3b3JsZCwgYW5kIGFmdGVyIHNvbWUgb3V0Zml0IGFkanVzdG1lbnRzIG1vdmVzIG92ZXIuwqA8 L2Rpdj4KCjxkaXY+PGJyPjwvZGl2PjxkaXY+RmluYWxseSBpIGFwb2xvZ2l6ZSBmb3IgZm9yIHRo ZSBzaW1wbGlzdGljIG5vdGF0aW9uIHVzZWQgaGVyZS4gSSBzaW1wbHkgYWRkIHRoZSBtb3N0IHJl bGV2YW50IHBhcmFtZXRlcnMgcGFzc2VkIGluIHNxdWFyZSBicmFja2V0cyB0byBhIGtleXdvcmQg c3BlY2lmeWluZyB0aGUgbmF0dXJlIG9mIHRoZSBtZXNzYWdlLiBQbGVhc2UgaW1wcm92ZSBvbiB0 aGF0IHdoZXJlIG5lZWRlZC48L2Rpdj4KCjxkaXY+PGJyPjwvZGl2PjxkaXY+U28gaGVyZSB3ZSBn bywgdGhlIGF2YXRhciBpcyDCoHByZXBhcmUgZm9yIGEgdmlzaXQgdG8gJnF1b3Q7aW1tZXJzaXZl IHdvcmxkJnF1b3Q7PC9kaXY+PGRpdj4wKSDCoFZpZXdlciwgaGVyZSBpcyBhbiB1cGRhdGUgb2Yg dGhlIHN0YXRlIG9mIHRoZSB3b3JsZCB5b3VyIGFnZW50IGlzIGluLCBwbGVhc2UgcmVuZGVyLjwv ZGl2PjxkaXY+MSkgwqBBZ2VudCBzZXJ2aWNlLCBJIHdpbGwgZ28gaW4gbXkgWm9kaWFjIGRyZXNz IHRoYXQgaSBrZWVwIGluIHRoZSDCoCZxdW90O0FtYXppbmcgYXNzZXRzJnF1b3Q7IHNlcnZpY2Uu PC9kaXY+Cgo8ZGl2PjIpIMKgQXNzZXQgc2VydmljZSBBLCBwbGVhc2Ugc2VuZCBhIGNhcCBmb3Ig WiwgaGVyZSBhcmUgbXkgY3JlZGVudGlhbHM8L2Rpdj48ZGl2PjMpIMKgWW91ciBmaW5lLCBoZXJl IGlzIHRoZSBjYXA8L2Rpdj48ZGl2PjQpIMKgTG9jYWwgcmVnaW9uLCBjYW4geW91IHBsZWFzZSBw dXQgdGhpcyBvbiBteSBhZ2VudCwgaSBpbmNsdWRlZCB0aGUgY2FwLjwvZGl2PjxkaXY+NSkgwqBI ZWxsbyBhc3NldCBzZXJ2aWNlIEEsIGkgbmVlZCBaLCBoZXJlIGlzIHRoZSBjYXA8L2Rpdj4KCjxk aXY+NikgwqBDYXAgaXMgZ29vZCwgZGF0YSBjb21pbmcgdXAsIGhhdmUgZnVuLjwvZGl2PjxkaXY+ NykgwqBBZ2VudCBzZXJ2aWNlLCB5b3VyIGFnZW50IGlzIG5vdyB3ZWFyaW5nIFo8L2Rpdj48ZGl2 PjgpIMKgVmlld2VyLCB5b3VyIGF2YXRhciBpcyBub3cgd2VhcmluZyBaPC9kaXY+PGRpdj7CoMKg IMKgVXNlcjogSG1tLCBhbWF6aW5nIGludmVudG9yeSBoYXMgbm90IGJlZW4gKnRoYXQqIGFtYXpp bmcgbGF0ZWx5LiAmIzM5O2xsIG1ha2UgYSBiYWNrdXAsIGp1c3QgaW4gY2FzZTwvZGl2PgoKPGRp dj45KSDCoEhlbGxvIGFzc2V0IHNlcnZpY2UgQSwgcGxlYXNlIHNlbmQgbWUgYSBjYXAgZm9yIFos IGhlcmUgYXJlIG15IGNyZWRlbnRpYWxzPC9kaXY+PGRpdj4xMCkgWW91ciBmaW5lLCBoZXJlIGlz IHRoZSBjYXA8L2Rpdj48ZGl2PjExKSBMb2NhbCBhc3NldCBzdG9yYWdlLCBwbGVhc2Ugc3RvcmUg WiBmb3IgbWUsIGhlcmUgaXMgdGhlIGNhcCB0byBnZXQgaXQ8L2Rpdj48ZGl2PjEyKSBIZWxsbyBh c3NldCBzZXJ2aWNlIEEsIGkgd2FudCBaLCBoZXJlIGlzIHRoZSBjYXA8L2Rpdj4KCjxkaXY+MTMp IENhcCBpcyBnb29kLCBkYXRhIGNvbWluZyB1cCwgaGF2ZSBmdW4uPC9kaXY+PGRpdj4xNCkgVmll d2VyLCBaIGlzIG5vdyBzdG9yZWQgZm9yIHlvdcKgPC9kaXY+PGRpdj7CoMKgIMKgVXNlcjogSSBh bSBSZWFkeSEsIExldHMgdHJ5IHRvIGdldCB0byBpbW1lcnNpdmUgd29ybGQhPC9kaXY+PGRpdj4x NSkgSGVsbG8gaW1tZXJzaXZlIHdvcmxkLCBjYW4gaSBnZXQgaW4/IEhlcmUgYXJlIG15IGNyZWRl bnRpYWxzLCBhbmQgYSBsaXN0IG9mIG15IHN0dWZmLjwvZGl2PgoKPGRpdj4xNikgQXNzZXQgc2Vy dmljZSBBLCBwbGVhc2Ugc2VuZCBtZSBhIGNhcCBmb3IgWCwgaGVyZSBhcmUgbXkgY3JlZGVudGlh bHMgKEkgd2FudCB0aGlzIGNhcCBmb3IgY29uc2lzdGVuY3kpPC9kaXY+PGRpdj4xNykgWW91ciBm aW5lLCBoZXJlIGlzIHRoZSBjYXA8L2Rpdj48ZGl2PjE4KSBBc3NldCBzZXJ2aWNlIEIsIHBsZWFz ZSBzZW5kIG1lIGEgY2FwIGZvciBZLCBoZXJlIGFyZSBteSBjcmVkZW50aWFscyAoSSB3YW50IHRo aXMgY2FwIGZvciBjb25zaXN0ZW5jeSk8L2Rpdj4KCjxkaXY+MTkpIFZlcnkgc29ycnksIGJ1dCB5 b3VyIG5vdCBvbmUgb2YgdXMsIHlvdSBjYW4mIzM5O3QgaGF2ZSBZPC9kaXY+PGRpdj4yMCkgQXNz ZXQgc2VydmljZSBCLCBwbGVhc2Ugc2VuZCBtZSBhIGNhcCBmb3IgWiwgaGVyZSBhcmUgbXkgY3Jl ZGVudGlhbHMgKEkgd2FudCBhIGNhcCBmb3IgY29uc2lzdGVuY3kpPC9kaXY+PGRpdj5bUmVnaW9u IHNlcnZpY2U6IFRpbWVvdXQuLi4gYW1hemluZyBpbnZlbnRvcnkgbXVzdCBiZSBvdmVybG9hZGVk Li4gb2ggd2VsbC4uLiBdPC9kaXY+Cgo8ZGl2PjIxKSBBZ2VudCBzZXJ2aWNlLCB5b3Ugd2FudGVk IHRvIHNlbmQgc29tZWJvZHkgb3ZlciwgaGVyZSBhcmUgeW91ciBwZXJtaXNzaW9ucy48L2Rpdj48 ZGl2PjIyKSBWaWV3ZXIsIHlvdSBhc2tlZCBmb3IgYSB0cmFuc2ZlciB0cnksIGhlcmUgYXJlIHlv dXIgcmVzdWx0czwvZGl2PjxkaXY+wqDCoCDCoCBVc2VyIHRoaW5rczogwqBDcmFwISBCaWcgYXNz ZXQgc2VydmljZSBkb2VzIG5vdCBhbGxvdyDCoG1lIHRvIHRha2UgbXkgeWVsbG93IHN0b2NraW5n cyEgQW5kIEFtYXppbmcgYXNzZXRzIMKgZmFpbGVkIHRvIGRlbGl2ZXIgbXkgem9kaWFjIGRyZXNz LiBBdCBsZWFzdCBpIG1hZGUgYSBiYWNrdXAgb2YgdGhhdCBkcmVzcyE8L2Rpdj4KCjxkaXY+MjMp ICYjMzk7bGwgdGFrZSB0aGUgeWVsbG93IHN0b2NraW5ncyBvZmYuLi48L2Rpdj48ZGl2PjI0KSAu Li4gZG9uZSAoJiMzOTtsbCB0cmFzaCB0aGVtIGhlcmUgYW5kIG5vdywgZm9yZXZlciwgd2hvIG5l ZWRzIHN0dWZmIHlvdSBjYW4mIzM5O3QgdXNlISk8L2Rpdj48ZGl2PjI1KSBUaGUgem9kaWFjIGRy ZXNzIHdhcyBub3QgZGVsaXZlcmVkIGJ5IEJpZyBhc3NldHMgc2VydmljZSwgYnV0IGkgaGF2ZSBh IGxvY2FsIGNvcHkhPC9kaXY+Cgo8ZGl2PjI2KSBMb2NhbCBBc3NldCBzZXJ2aWNlLCBwbGVhc2Ug c2VuZCBtZSBaLCBoZXJlIGFyZSBteSBjcmVkZW50aWFsczwvZGl2PjxkaXY+MjcpIEkgZG9udCBr bm93IHlvdSwgYnV0IEkgJiMzOTtsbCB0cnVzdCB5b3UsIGhlcmUgaXMgdGhlIGNhcCwgYnV0IHlv dSBiZXR0ZXIgc3RvcmUgdGhlIGRhdGEsIGl0cyBzaW5nbGUgdXNlLCBpIG5lZWQgdG8gcHJvdGVj dCBteXNlbGYuPC9kaXY+Cgo8ZGl2PjI4KSBMb2NhbCByZWdpb24sIGNhbiB5b3UgcGxlYXNlIHB1 dCB0aGlzIG9uIG15IGFnZW50LCBpIGluY2x1ZGUgdGhlIGNhcC48L2Rpdj48ZGl2PjI5KSBMb2Nh bCBBc3NldCBzZXJ2aWNlLCBpIG5lZWQgWiwgaGVyZSBpcyB0aGUgY2FwPC9kaXY+PGRpdj4zMCkg Q2FwIGlzIGdvb2QsIGRhdGEgY29taW5nIHVwLCBoYXZlIGZ1bi48L2Rpdj48ZGl2PjMxKSBDYXAg d2FzIG9ubHkgZ29vZCBmb3Igb25lIHRpbWUsIEkgbWFkZSBhIGNvcHksIGJ1dCBteSBwb2xpY3kg aXMgdG8gb25seSBncmFudCB5b3UgZmFpciB1c2UgcmlnaHRzLCBhdCBhIGxhdGVyIHRpbWUgaSBt aWdodCBldmVuIHRlbGwgeW91IHRvIHJlcGxhY2UgdGhlIGRyZXNzLjwvZGl2PgoKPGRpdj4zMikg Vmlld2VyLCB5b3UgY2FuIHdlYXIgWiBmb3Igbm93LCBidXQgdGhlIGFzc2V0IHNlcnZpY2UgZ3Jh bnRlZCBvbmx5IGZhaXIgdXNlLCBpIG1pZ2h0IGFzayB5b3UgdG8gcmVwbGFjZSB0aGUgZHJlc3Mg YXQgYSBsYXRlciB0aW1lLjwvZGl2PjxkaXY+MzMpIFJlYWR5IGF0IGxhc3QhIE9mZiB0byBpbW1l cnNpdmUgd29ybGQhLCBJIGhvcGUgaXRzIG5vdCB0byBjcm93ZGVkIHRoZXJlIG9yICYjMzk7bGwg bG9vc2UgbXkgZHJlc3MuLi48L2Rpdj4KCjxkaXY+MzQpIEhlbGxvIGltbWVyc2l2ZSB3b3JsZCwg aGVyZSBhcmUgbXkgY3JlZGVudGlhbHMsIGFuZCBhIGxpc3Qgb2Ygc3R1ZmYgaSB3YW50IHRvIGJy aW5nPC9kaXY+PGRpdj4zNSkgSGVsbG8gYXNzZXQgc2VydmljZSBBLCBwbGVhc2Ugc2VuZCBtZSBh IGNhcCBmb3IgWCwgaGVyZSBhcmUgbXkgY3JlZGVudGlhbHPCoDwvZGl2PjxkaXY+wqDCoCDCoFtk YXJuLCBJIHNob3VsZCBoYXZlIGtlcHQgdGhhdCBjYXAgZnJvbSBsYXN0IHRpbWUuLl08L2Rpdj4K CjxkaXY+MzYpIFlvdXIgZmluZSwgaGVyZSBpcyB0aGUgY2FwLjwvZGl2PjxkaXY+wqDCoCBbUmVn aW9uIHNlcnZpY2UgZmluZHMgZmFpci11c2Ugd2FybmluZyBvbiBaIGFuZCBkZWNpZGVzIHRvIG1h a2UgaXRzIG93biBjb3B5XTwvZGl2PjxkaXY+MzcpIEhlbGxvIExvY2FsIHJlZ2lvbiwgY2FuIGkg c3RpbGwgaGF2ZSBaPyBIZXJlIGlzIHRoZSBjYXDCoDwvZGl2PjxkaXY+MzgpIENhcCBpcyBzdGls bCBnb29kLCBkYXRhIGNvbWluZyB1cCwgaGF2ZSBmdW4uPC9kaXY+Cgo8ZGl2PsKgwqAgW1JlZ2lv biBzZXJ2aWNlIHN0b3JlcyBhc3NldCBpbiBwcml2YXRlIHN0b3JhZ2UsIHByb3ZpZGluZyBhIGNh cCB0byByZXBsYWNlIHRoZSBmYWlyIHVzZSBvbmVdPC9kaXY+PGRpdj4zOSkgQWdlbnQgc2Vydmlj ZSwgeW91IHdhbnRlZCB0byBzZW5kIHNvbWVib2R5IG92ZXIsIGhlcmUgYXJlIHlvdXIgcGVybWlz c2lvbnMgJmFtcDsgaW5mby48L2Rpdj48ZGl2PjQwKSBIZWxsbyBpbW1lcnNpdmUgd29ybGQsIGp1 c3QgwqBnZXQgbWUgdGhlcmUsIGFuZCB1c2Ugd2hhdCB5b3UgY2FuPC9kaXY+Cgo8ZGl2PjQxKSBQ bGFjZW1lbnQgZG9uZSwgWiBpcyBjdXJyZW50bHkgYnVmZmVyZWQgYnkgdXMgYXMgd2VsLCB5b3Ug bmVlZCB0byBnZXQgZGV0YWlscyBmb3IgWCwgaGF2ZSBmdW4uPC9kaXY+PGRpdj40MikgWW91IGFy ZSBub3cgaW4gaW1tZXJzaXZlIHdvcmxkLCB5b3VyIGRyZXNzIGlzIGJ1ZmZlcmVkIHRoZXJlIGFz IHdlbGwsIGJ1dCB5b3UgbmVlZCB0byBnZXQgWCE8L2Rpdj48ZGl2PgoKNDMpIEhlbGxvIGFzc2V0 IHNlcnZpY2UgQSwgaSB3YW50IFgsIGhlcmUgaXMgdGhlIGNhcDwvZGl2PjxkaXY+NDQpIENhcCBp cyBnb29kLCBkYXRhIGNvbWluZyB1cCwgaGF2ZSBmdW4uPC9kaXY+PGRpdj40NSkgVmlld2VyLCBo ZXJlIGlzIGFuIHVwZGF0ZSBvZiB0aGUgc3RhdGUgb2YgdGhlIHdvcmxkIHlvdXIgYWdlbnQgaXMg aW4sIHBsZWFzZSByZW5kZXIuPC9kaXY+PGRpdj48YnI+PC9kaXY+Cgo8ZGl2PkFzIGZhciBhcyBJ IGNhbiBzZWUgdGhpcyBjb25mb3JtcyBmdWxseSB0byBvdXIgY2hhcnRlciwgYW5kIGkgaG9wZSBp dCBpcyBwb3NzaWJsZSB0byB1c2UgbGFyZ2UgcG9ydGlvbnMgb2YgdGhlIGV4aXN0aW5nIGNvZGUg YmFzZXMuIEhvd2V2ZXIsIGFzIHNhaWQgYWJvdmUsIGkgZGlkIG5vdCByZWFsbHkgdHJ5IHRvIGNh cHR1cmUgdGhlIG9sZCB0aGlua2luZywgYW5kIEkgYWxzbyBtaWdodCBoYXZlIG1pc2NvbmNlcHRp b25zIGFib3V0IHRoZSB3YXkgdG8gZG8gdGhlc2UgdGhpbmdzIGluIGdlbmVyYWwuPC9kaXY+Cgo8 ZGl2Pkxvb2tpbmcgZm9yd2FyZCB0byBjb25zdHJ1Y3RpdmUgY29tbWVudHMuPC9kaXY+PGRpdj48 YnI+PC9kaXY+PGZvbnQgY29sb3I9IiM4ODg4ODgiPjxkaXY+LS0gVmF1Z2huPC9kaXY+PC9mb250 PjxkaXY+PGRpdj48L2Rpdj48ZGl2IGNsYXNzPSJoNSI+PGRpdj48YnI+PC9kaXY+PGRpdiBjbGFz cz0iZ21haWxfcXVvdGUiPk9uIFN1biwgQXByIDMsIDIwMTEgYXQgODozOCBQTSwgVmF1Z2huIERl bHVjYSA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzp2YXVnaG4uZGVsdWNhQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZhdWdobi5kZWx1Y2FAZ21haWwuY29tPC9hPiZndDs8 L3NwYW4+IHdyb3RlOjxicj4KCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVm dDoxZXgiPlRoYW5rcyBmb3IgdGhlIHBvaW50ZXJzLiDCoEkgaGF2ZSBhIMKgYnVzeSB3ZWVrIGlu IFJMIGluIGZyb250IG9mIG1lLCBzbyBpIHdvbnQgaGF2ZSB0byBtdWNoIHRpbWUgdG8gcmVzcG9u ZCB0aGUgbmV4dCBmZXcgZGF5cywgaG93ZXZlciwgaSBpbnRlbmQgdG8gc3RhcnQgZG9pbmcgdGhl IGZvbGxvd2luZyB0aGluZ3M6PGRpdj4KCjxicj48L2Rpdj48ZGl2Pi0gUHJvZHVjZSBhIHZpc3Vh bCB0aGF0IHJlZmxlY3RzIG15IHRoaW5raW5nLCBpLmUuIGFuIGlsbHVzdHJhdGlvbiBvZiBteSBy ZXNwb25zZSB0byBNb3JnYWluZSYjMzk7cyBpdGVtbGlzdCDCoGFib3ZlLjxicj4KPC9kaXY+PGRp dj48ZGl2Pi0gUmVhZCB1cCBvbiB0aGUgb2xkZXIgbm90ZXMsIGFzIHdlbGwgYXMgwqBtb3JlIHJl YWRpbmcgaW4gdGhlIGxpc3QgYXJjaGl2ZTwvZGl2PjxkaXY+LSBUcnkgdG8gbWFrZSBhIHN1bW1h cnkgZm9yIHRoZSB3aWtpPC9kaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+PGRpdj5SZWdhcmRpbmcg dGhlIHVzZSBvZiBkb21haW4sIEkgdGhpbmsgc2VydmljZXMgYXJlIGV2ZW50dWFsbHkgd2hhdCBj b3VudHMsIGJ1dCBpdHMgYWxsIHRlcm1pbm9sb2d5LiBUaGUgd2F5IEkgcmVhZCB0aGUgQVdHIGRp YWdyYW1zIGlzIHRoYXQgdGhlIGFnZW50IGRvbWFpbiBpcyBhY3R1YWxseSBhIGNsdXN0ZXIgb2Yg dGlnaHRseSBpbnRlZ3JhdGVkIHNlcnZpY2VzLiBXaGVuIHRoZSBmdW5jdGlvbmFsaXR5IG9mIGVh Y2ggc3ViLXNlcnZpY2UgaXMgZGVzY3JpYmVkIHByb3Blcmx5IGFuZCB3aXRoIHVuaWZvcm0gaW50 ZXJmYWNlcyB0aGUgZG9tYWluIHdpbGwgc2xvd2x5IGRpc3NvbHZlLiBCdXQgbGV0IG5vdCBnZXQg YWhlYWQgb2Ygb3V0IHNlbGZzLiBXZSBzaG91bGQgcHV0IHVwIHNvbWUgY2xlYXIgZGVzY3JpcHRp b25zIG9uIHRoZSB3aWtpIGZvciBvdXIgdmlld3Mgb24gdGhpcywgYW5kICphZnRlciogdGhhdCB3 ZSBjYW4gZGVjaWRlIHdoYXQgd2UgbmVlZCBhbmQgd2hhdCBjYW4gZ28uPC9kaXY+CgoKPGRpdj48 YnI+PC9kaXY+PGRpdj5JdHMgYmVlbiBhIHZlcnkgdXNlZnVsIGFuZCBpbGx1bWluYXRpbmcgd2Vl a2VuZCBmb3IgbWUsIGFuZCBpIGFtIGEgbG90IG1vcmUgb3B0aW1pc3RpYyBhYm91dCB0aGUgZnV0 dXJlIG9mIHZ3cmFwIHRoYW4gdHdvIHdlZWtzIGFnby48L2Rpdj48ZGl2Pjxicj48L2Rpdj48Zm9u dCBjb2xvcj0iIzg4ODg4OCI+PGRpdj4tLSBWYXVnaG48L2Rpdj48L2ZvbnQ+PGRpdj4KCjxkaXY+ PC9kaXY+PGRpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj4KPGRpdj48YnI+PC9kaXY+ PGRpdj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gU3VuLCBBcHIgMywgMjAxMSBhdCA3OjIw IFBNLCBEem9uYXRhcyBTb2wgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86ZHpv bmF0YXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHpvbmF0YXNAZ21haWwuY29tPC9hPiZn dDs8L3NwYW4+IHdyb3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxl ZnQ6MWV4Ij4KCgpQcm9iYWJseSBlYXN5IGFzIHN1Z2dlc3RlZCBpbiBvdGhlciB0ZXJtcyBoZXJl IG9uIHRoaXMgbGlzdCwgYXMgaG93IHRoZSBjbGllbnQgY29udGFjdHMgdGhlIGFzc2V0IHNlcnZp Y2VzIG5vdyBpbiB0aGUgcmVnaW9ucy4gVGhlIG5ld2VyIGlzc3VlIGlzIHRvIHVuaXRpemUgdGhh dCBhc3NldCBzZXJ2aWNlcy4gU2luY2UgdGhlaXIgaXMgcHJvcHJpZXRhcnkgKGxlZ2FjeSkgY29k ZSB0aGVuIHdlIGNhbiYjMzk7dCBleHBlY3QgdGhhdCB0byBjaGFuZ2UsIGFuZCBzb21lIGZvcm0g b2YgcHJveHkgaXMgb2YgbmVlZC4gV2hhdGV2ZXIgd29ya3MgYmVzdCwgSSB0cmllZCB0byBuYXJy b3cgaXQgZG93biB0byBzdWdnZXN0aW9ucyBoZXJlLjxicj4KCgoKPGJyPgpFdmVudHVhbGx5LCB0 aGUgYWdlbnQgZG9tYWluIGlzIGlkZWFsIHRvIGhhbmRsZSB0aGUgZGlyZWN0aW9uIG9mIHRoZSBh c3NldCBzZXJ2aWNlcy4gVGhpcyBjb25jZXB0LCB1bmZvcnR1bmF0ZWx5LCBlbmRlZCBzdXBwb3J0 IGF3aGlsZSBhZ28gd2l0aCBjaGFuZ2VzIGluIExMLjxicj4KQWxzbyBzZWU7IDxhIGhyZWY9Imh0 dHA6Ly93aWtpLnNlY29uZGxpZmUuY29tL3dpa2kvQWdlbnRfRG9tYWluIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cDovL3dpa2kuc2Vjb25kbGlmZS5jb20vd2lraS9BZ2VudF9Eb21haW48L2E+PGJyPgpB bmQ6IDxhIGhyZWY9Imh0dHA6Ly93aWtpLnNlY29uZGxpZmUuY29tL3dpa2kvVXNlcjpEem9uYXRh c19Tb2wvQVdHX0Fzc2V0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3dpa2kuc2Vjb25kbGlmZS5j b20vd2lraS9Vc2VyOkR6b25hdGFzX1NvbC9BV0dfQXNzZXQ8L2E+ICh3YXJuOiB1bnN0cnVjdHVy ZWQgY29sbGFib3JhdGl2ZSBub3RlcywgZHVtcGVkIG9uIG1lIGFuZCBJIHRyaWVkIHRvIGZpeCk8 YnI+CgoKCjxicj4KSSB0cmllZCB0byBmaW5kIHByZXZpb3VzIHZpc3VhbHMuPGJyPgo8YnI+Ckkm IzM5O2QgaW1hZ2luZSB0aGUgYWdlbnQgZG9tYWluIGNvdWxkIGdyb3cgb3V0IG9mIHVuaXRpemVk IHZlcnNpb25zIG9mIGFzc2V0IHNlcnZpY2VzLiBEZXNwaXRlIHRoYXQsIEkgdGhpbmsgdGhhdCBj b25jZXB0IGhlbHBzIHZpZXcgd2hlcmUgd2Ugd2VyZSBhdCBpbiBkaXNjdXNzaW9uIGFuZCB3aGF0 IGRpZG4mIzM5O3QgaGFwcGVuLjxicj4KPGJyPgpWYXVnaG4gRGVsdWNhIHdyb3RlOjxicj4KPGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9y ZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdj4KSGnvv71Eem9u YXRhczxicj4KPGJyPgpDYW4geW91IGV4cGFuZCBvbiB0aGF0LCB3aGF0IHdvdWxkIGJlIG5lZWRl ZCBmb3IgbGVnYWN5IHN1cHBvcnQgaW4gVldBUCB0ZXJtc++/vT8sPGJyPgpJZiBpIHdhbnQgdG8g cmVhZCB1cCBvbiBob3cgdGhl77+9YXNzZXQgc2VydmVyIG1heSBwcm94eSB0aGUgc2ltdWxhdG9y LCB3aGF0IHdvdWxkIHlvdSByZWNvbW1lbmQgbWUgdG8gcmVhZD88YnI+Cjxicj4KLS0gVmF1Z2hu PGJyPgo8YnI+PC9kaXY+PGRpdj48ZGl2PjwvZGl2PjxkaXY+Ck9uIFN1biwgQXByIDMsIDIwMTEg YXQgNTo1MSBBTSwgRHpvbmF0YXMgU29sICZsdDs8YSBocmVmPSJtYWlsdG86ZHpvbmF0YXNAZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHpvbmF0YXNAZ21haWwuY29tPC9hPiAmbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzpkem9uYXRhc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kem9u YXRhc0BnbWFpbC5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPgoKCgo8YnI+CiDCoCDCoFNvbWUg c3RhdGVkIHRoZSBwcm94eS10by1hc3NldC1zZXJ2ZXIgaXMgYnVpbHQgaW50byB0aGUgc2ltOzxi cj4KIMKgIMKgaG93ZXZlciwga2VlcCBpbiBtaW5kIHBvc3NpYmxlIGxlZ2FjeSBzdXBwb3J0IHdo ZXJlIHRoZSBhc3NldDxicj4KIMKgIMKgc2VydmVyIG1heSBwcm94eSB0aGUgc2ltdWxhdG9yLjxi cj4KPGJyPgo8YnI+CiDCoCDCoER6b25hdGFzIFNvbCB3cm90ZTo8YnI+Cjxicj4KIMKgIMKgIMKg IMKgU29tZWhvdyBJIGZlZWwgdGhlIGJhc2ljIGFzc2V0IHNlcnZlciBiZWluZyBhYmxlIHRvIGxv Z2luIGFuZDxicj4KIMKgIMKgIMKgIMKgZG93bmxvYWQgYXNzZXRzIGlzIG5vdyBwcmlvcml0eSwg eWV0IEkgYWxzbyB3b25kZXJlZCB0aGUgYmVzdDxicj4KIMKgIMKgIMKgIMKgd2F5IHRvIHBhdGNo IHRoaXMgaW50byB0aGUgY3VycmVudCBtb2RlIG9mIHZpZXdlcnMuPGJyPgo8YnI+CiDCoCDCoCDC oCDCoE1heWJlIG9mZmVyICgxKSBieSBwcm94eSAoc2ltLXNpZGUpIGFuZCAoMikgYnkgcGF0Y2g8 YnI+CiDCoCDCoCDCoCDCoCh2aWV3ZXItc2lkZSkgdGhhdCBlaXRoZXIgb2YgdGhlc2UgdHdvIGFy ZSBvcHRpb25hbCBhbmQ8YnI+CiDCoCDCoCDCoCDCoG5laXRoZXIgYXJlIG1hbmRhdG9yeSBmb3Ig bm93LiBUaG91Z2h0cz88YnI+Cjxicj4KIMKgIMKgIMKgIMKgSXNyYWVsIEFsYW5pcyB3cm90ZTo8 YnI+Cjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7IHdoZW4gZGVzaWduaW5nIGZvciBz Y2FsYWJpbGl0eSwgdGhlIG1vZGVsIHRvIGJlYXIgaW48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoG1p bmQgaXMgLi4uPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoFdlbGwsIHRoZXJlIGFyZSBhIGxv dCBvZiBkaWZmZXJlbnQgbW9kZWxzIHRvIGtlZXAgaW4gbWluZCw8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoGFuZCBtYW55IGRpZmZlcmVudCB1c2UgY2FzZXMuIE9uZSBwYXJ0aWN1bGFyIHVzZSBjYXNl IHRvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBrZWVwIGluIG1pbmQgaXM6ICZxdW90O1VzZXIgYWNx dWlyZXMgbmV3IG91dGZpdCwgYW5kIHdhbnRzIHRvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAmIzM5 O3Nob3cgaXQgb2ZmJiMzOTsgaW4gYSBoaWdobHkgcG9wdWxhdGVkIHJlZ2lvbiZxdW90Oy48YnI+ Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyBCb3RoIHdvcmxkcyBhbmQgYXNzZXQgc2Vydmlj ZXMgbWF5IGluY2x1ZGUgY29tbWVyY2lhbCw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoGNvbW11bml0 eSwgYW5kIHBlcnNvbmFsIHNlcnZpY2VzPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoFllcywg eWVzIGFuZCB5ZXMuIEkmIzM5O20gcGFydGljdWxhcmx5IGNvbmNlcm5lZCBhYm91dCBob3cgdGhl PGJyPgogwqAgwqAgwqAgwqAgwqAgwqBtb2RlbCBhZmZlY3RzIHRoZSBhYmlsaXR5IHRvIGhvc3Qg cGVyc29uYWwgYXNzZXQgc2VydmljZXMuPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCZndDsg YSBwcm94eWluZyByZWdpb24sIHdoaWNoIHdvdWxkIGdldCBzbGFtbWVkIGZvciBldmVyeTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgYXNzZXQgd29ybiBieSBldmVyeSBhdmF0YXIgcHJlc2VudC48YnI+ Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgR3JhbnRlZCB0aGUgY29sbGVjdGlvbiBvZiBzZXJ2aWNl cyB0aGF0IGFyZSBwcm92aWRlZCBieTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgdGhlIHJlZ2lvbiBu ZWVkIHRvIGJlIHNjYWxlZCB0byBtZWV0IHRoZSBkZW1hbmRzIG9mIHRoYXQ8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoHJlZ2lvbi4gVGhhdCYjMzk7cyBhbGwgcGFydCBvZiBjYXBhY2l0eSBwbGFubmlu Zy48YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyByZWdpb25zIHJ1biBtYW55IGRpZmZl cmVudCBDUFUtaW50ZW5zaXZlIHRhc2tzLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgaW5jbHVkaW5n IHBoeXNpY3Mgc2ltdWxhdGlvbiBhbmQgc2VydmVyLXNpZGUgc2NyaXB0aW5nLDxicj4KIMKgIMKg IMKgIMKgIMKgIMKgYW5kIGFic29sdXRlbHkgY2Fubm90IGFmZm9yZCB0byBzZXJ2ZSBhc3NldHMg dG9vPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBXZWxsLi4uIHdobyBzYWlkIHRoZSBzYW1lIENQVSYj Mzk7cyBoYXZlIHRvIGRvIHByb3h5aW5nLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgcGh5c2ljcyBz aW11bGF0aW9uIGFuZCBzZXJ2ZXItc2lkZSBzY3JpcHRpbmc/IEFzc2V0PGJyPgogwqAgwqAgwqAg wqAgwqAgwqBwcm94eWluZyBpcyBhIGRpZmZlcmVudCBzZXJ2aWNlIHRoYW4gcGh5c2ljcyBzaW11 bGF0aW9uPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBhbmQgY2FuIGJlIG9uIHNlcGFyYXRlIGhhcmR3 YXJlLCBjb3VsZCBtYWtlIHVzZSBvZjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgZ2VvZ3JhcGhpY2Fs bHkgZGlzdHJpYnV0ZWQgY2FjaGluZywgYW5kIGluIGNlcnRhaW48YnI+CiDCoCDCoCDCoCDCoCDC oCDCoGRlcGxveW1lbnQgcGF0dGVybnMsIHRoZSBzYW1lIGNhY2hpbmcgc2VydmljZXMgY291bGQg YmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoHNoYXJlZCBieSBkaWZmZXJlbnQgcmVnaW9ucy4gKFNl cnZlci1zaWRlIHNjcmlwdGluZyBpcyBhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBkaXNjdXNzaW9u IGZvciBhbm90aGVyIGRheSkuPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCZndDsgVGhpcyBp cyB3aHkgd2UgaGF2ZSB0byBnbyBwYXJhbGxlbC4uLjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAg wqBUb3RhbGx5IGFncmVlLCBhbmQgYSBwcm94eWluZyBtb2RlbCBjb3VsZCBhbmQgc2hvdWxkIGFs c288YnI+CiDCoCDCoCDCoCDCoCDCoCDCoHRha2UgYWR2YW50YWdlIG9mIHBhcmFsbGVsaXNtLjxi cj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7IEkgdGhpbmsgeW91JiMzOTtyZSB3cm9uZyB0 aGF0IGl0IGhhcyB0byBjb3N0IG11Y2ggbW9uZXkuID92cz88YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCZndDsgSXQgY29zdHMgbW9uZXkgdG8gaG9zdCBhIGhpZ2ggcGVyZm9ybWFuY2UgYW5kIHNjYWxh YmxlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBhc3NldCBzZXJ2aWNlIGFuZCBhIGhpZ2ggYmFuZHdp ZHRoIG5ldHdvcmsgdG8gaGFuZGxlIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgdHJhZmZpYy4g 77+9QSAqbG90KiBvZiBtb25leS48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoEkgdGhpbmsgd2hhdCB5 b3UmIzM5O3JlIHNheWluZyBpczogJnF1b3Q7SXQgY29zdHMgYSBsb3Qgb2YgbW9uZXkgdG88YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoGJ1aWxkIGEgc2NhbGFibGUgYXNzZXQgc2VydmljZSwgYnV0IGlm IGFzc2V0cyBhcmUgc3ByZWFkPGJyPgogwqAgwqAgwqAgwqAgwqAgwqB0aHJvdWdob3V0IHRoZSBp bnRlcm5ldCB0aGV5IGRvbiYjMzk7dCBoYXZlIHRvIGJlIHNjYWxhYmxlLiZxdW90Ozxicj4KIMKg IMKgIMKgIMKgIMKgIMKgQnV0IHRoYXQmIzM5O3Mgbm90IHF1aXRlIHJpZ2h0LiBZb3UmIzM5O3Jl IG9wZW5pbmcgdXAgZXZlcnkgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoHNlcnZlciB0byB0 aGUgVlcgZXF1aXZhbGVudCBvZiBiZWluZyBzbGFzaGRvdHRlZCwgc28gYXJlPGJyPgogwqAgwqAg wqAgwqAgwqAgwqB5b3Ugc3VyZSB5b3UmIzM5O3JlIG5vdCBmb3JjaW5nICpldmVyeSogYXNzZXQg c2VydmljZSB0byBiZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgc2NhbGFibGUgYW5kIGhhbmRsZSBh IGxvdCBvZiBiYW5kd2l0aCBhbmQgbmV0d29yayB0cmFmZmljPzxicj4KIMKgIMKgIMKgIMKgIMKg IMKgSXQmIzM5O3MgdGhlIGV4YWN0IG9wcG9zaXRlIG9mIHlvdXIgaW50ZW50aW9uLCBidXQgSSB0 aGluazxicj4KIMKgIMKgIMKgIMKgIMKgIMKgdGhhdCYjMzk7cyB0aGUgcmVzdWx0LCBhbGwgdGhl IHNhbWUuPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoFRoaXMgcGFydGljdWxhciBkZXNpZ24g ZGVjaXNpb24gaGFzIGEgYmlnIGVmZmVjdCBvbiB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoGVj b25vbWljcyBvZiB0aGUgVlcgaW5mcmFzdHJ1Y3R1cmUuIEkmIzM5O2QgcmF0aGVyIHRoZTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgZWNvbm9taWNzIHRvIHdvcmsgb3V0IHN1Y2ggdGhhdCBhIHJlZ2lv biBwcm92aWRlciB3aG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoHdpc2hlcyB0byBidWlsZCBhIHJl Z2lvbiB0aGF0IHN1cHBvcnRzIGEgc21hbGwgcG9wdWxhdGlvbiw8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoGNhbiBkbyBzbyBlY29ub21pY2FsbHkuIEEgcmVnaW9uIHRoYXQgd2FudHMgdG8gaG9zdCBh PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAqbGFyZ2UqIHBvcHVsYXRpb24gaGFzIHRvIGJlYXIgdGhh dCBjb3N0IG9mIHByb3ZpZGluZyB0aGF0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqBzY2FsYWJsZSBh c3NldCBzZXJ2aWNlLjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgSSB3YW50IHRoZSBlY29ub21pY3Mg b2YgaG9zdGluZyBhIHNtYWxsIGFzc2V0IHNlcnZpY2UgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDC oGJlIGEgbm9uLWlzc3VlIChhcyB0byBiZXN0IHByb21vdGUgY3JlYXRpb24gYW5kPGJyPgogwqAg wqAgwqAgwqAgwqAgwqBjcmVhdGl2aXR5KS4gQ3JlYXRpbmcgYSBoaWdoIGJhciB0byBwcm92aWRl IGFzc2V0IHNlcnZpY2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqB3aWxsIG1lYW4gdGhhdCBzZXJ2 aWNlIHdpbGwgY29zdCBtb25leSBhbmQgcGVvcGxlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqBzaG91 bGRuJiMzOTt0IGhhdmUgdG8gcGF5IG1vbmV5IGp1c3QgdG8gY3JlYXRlIG9yIG93biBWVzxicj4K IMKgIMKgIMKgIMKgIMKgIMKgb2JqZWN0cyAoSSYjMzk7bSB1c2luZyAmIzM5O293biYjMzk7IGhl cmUgdG8gcmVmZXIgdG8gbWFpbnRhaW5pbmc8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoHRoZWlyIGV4 aXN0ZW5jZSwgSSYjMzk7bSBub3QgdHJ5aW5nIHRvIG1ha2UgYTxicj4KIMKgIMKgIMKgIMKgIMKg IMKgJiMzOTtsZWZ0aXN0JiMzOTsvJiMzOTtjb21tdW5pc3QmIzM5OyBzdGF0ZW1lbnQgYWJvdXQg b3duZXJzaGlwIDspPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoC0gSXp6eTxicj4KPGJyPgo8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoE9uIEFwciAyLCAyMDExLCBhdCAzOjU4IFBNLCBNb3JnYWlu ZSB3cm90ZTo8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgSXp6eSwgd2hlbiBkZXNp Z25pbmcgZm9yIHNjYWxhYmlsaXR5LCB0aGUgbW9kZWwgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoGJlYXIgaW4gbWluZCBpcyB0aGF0IG9mIHNlYXNvbmVkIHZpcnR1YWwgd29ybGQ8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRyYXZlbGVycyB3aG9zZSBpbnZlbnRvcmllcyBjb250 YWluIGFzc2V0cyBmcm9tIG1hbnk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGRpZmZlcmVu dCB3b3JsZHMsIHRob3NlIGFzc2V0cyBiZWluZyBzZXJ2ZWQgYnkgbWFueTxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgZGlmZmVyZW50IGFzc2V0IHNlcnZpY2VzLiDvv71Cb3RoIHdvcmxkcyBh bmQgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNlcnZpY2VzIG1heSBpbmNsdWRl IGNvbW1lcmNpYWwsIGNvbW11bml0eSwgYW5kPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBw ZXJzb25hbCBzZXJ2aWNlcywgYW5kIGFzIHRoZSBtZXRhdmVyc2UgZ3Jvd3MsIHRoYXQ8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNldCBpcyBoaWdobHkgbGlrZWx5IHRvIGJlY29tZSBwcm9n cmVzc2l2ZWx5IGxlc3M8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNsdXN0ZXJlZCBhbmQg bW9yZSBkaXZlcnNlLjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBXaGVuIHRob3Nl IHNlYXNvbmVkIHRyYXZlbGVycyBjbGljayBvbiBhbiBhZHZlcnRpc2VkPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqBWVyBsaW5rIGFuZCBwZXJmb3JtIGFuIGludGVyLXdvcmxkIHRlbGVwb3J0 IHRvIG9uZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcGFydGljdWxhciB3b3JsZCYjMzk7 cyByZWdpb24gdG8gc2hhcmUgYW4gZXhwZXJpZW5jZSw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHRoZWlyICZxdW90O3dvcm4mcXVvdDsgYXNzZXRzICh0aGUgb25seSBvbmVzIG9mIGludGVy ZXN0IHRvIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcmVnaW9uKSB3aWxsIGNvbnRh aW4gcmVmZXJlbmNlcyB0byBhc3NldCBzZXJ2aWNlczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgc3ByZWFkIHdpZGVseSBhY3Jvc3MgdGhlIEludGVybmV0LiDvv71UaGUgZmV0Y2hlcyBieSB0 aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRyYXZlbGVycyYjMzk7IGNsaWVudHMgb2Nj dXIgb3ZlciBtYW55IHBhcmFsbGVsIHBhdGhzIGZyb208YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoGNsaWVudHMgdG8gYXNzZXQgc2VydmljZXMsIHNvIG9uZSBjYW4gcmVhc29uYWJseTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZXhwZWN0IHJlZHVjZWQgbmV0d29yayBjb250ZW50aW9u IGFuZCByZWR1Y2VkIGFzc2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzZXJ2ZXIgbG9h ZGluZyBiZWNhdXNlIHRoZXkgYXJlIGJvdGggc3ByZWFkIG91dCBvdmVyPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqBob3dldmVyIG1hbnkgYXNzZXQgc2VydmljZXMgYXJlIGJlaW5nIHJlZmVy ZW5jZWQgYnk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRoZSBvdmVyYWxsIHNldCBvZiBh c3NldHMgaW4gdGhlIHJlZ2lvbi48YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgVGhp cyBpcyB2ZXJ5IGRpZmZlcmVudCB0byB0aGUgY2FzZSBvZiBhIHByb3h5aW5nPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqByZWdpb24sIHdoaWNoIHdvdWxkIGdldCBzbGFtbWVkIGZvciBldmVy eSBhc3NldCB3b3JuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBieSBldmVyeSBhdmF0YXIg cHJlc2VudC4g77+9SW4gb3VyIGN1cnJlbnQgYXJjaGl0ZWN0dXJlLDxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgcmVnaW9ucyBydW4gbWFueSBkaWZmZXJlbnQgQ1BVLWludGVuc2l2ZSB0YXNr cyw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGluY2x1ZGluZyBwaHlzaWNzIHNpbXVsYXRp b24gYW5kIHNlcnZlci1zaWRlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzY3JpcHRpbmcs IGFuZCBhYnNvbHV0ZWx5IGNhbm5vdCBhZmZvcmQgdG8gc2VydmU8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoGFzc2V0cyB0b28gdW5sZXNzIHlvdXIgc2NhbGFiaWxpdHkgcmVxdWlyZW1lbnRz IGFyZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdmVyeSBsb3cgaW5kZWVkLCBpZS4ganVz dCBhIGZldyBkb3plbiBhdmF0YXJzIG9mPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0b2Rh eSYjMzk7cyBraW5kLiDvv71XZSYjMzk7dmUgaGl0IHRoZSBjZWlsaW5nIGFscmVhZHkgb24gcmVn aW9uPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzY2FsYWJpbGl0eSBkb25lIHRoYXQgd2F5 LiDvv71UaGVyZSBpcyBub3doZXJlIHRvIGdvIGluPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqB0aGF0IGRpcmVjdGlvbiBhdCBhbGwgYmV5b25kIGltcHJvdmluZyB0aGUgY29kZSBsaWtlPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBJbnRlbCBkZW1vbnN0cmF0ZWQsIGFuZCB0aGF0IHdv cmsgaXMgc3ViamVjdCB0byBhIGxhdzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgb2YgZGlt aW5pc2hpbmcgcmV0dXJucy48YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgVGhpcyBp cyB3aHkgd2UgaGF2ZSB0byBnbyBwYXJhbGxlbCwgYW5kIEkgdGhpbmsgeW91JiMzOTtyZTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgd3JvbmcgdGhhdCBpdCBoYXMgdG8gY29zdCBtdWNoIG1v bmV5LiDvv71BcyB3ZSBzcHJlYWQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRoZSBsb2Fk IGFjcm9zcyBtb3JlIGFuZCBtb3JlIGFzc2V0IHNlcnZpY2VzLCB3ZSBhcmU8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoHNpbXBseSBiZXR0ZXIgdXRpbGl6aW5nIGFsbCB0aGUgaGFyZHdhcmUg dGhhdCYjMzk7czxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYWxyZWFkeSBvdXQgdGhlcmUg b24gdGhlIEludGVybmV0LCBhdCBsZWFzdCBpbiByZXNwZWN0PGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBvZiBjb21tdW5pdHkgYW5kIHByaXZhdGUgcmVzb3VyY2VzLiDvv71CdXQgYWRkIHRv IHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgY29tbXVuaXR5IGFuZCBwcml2YXRlIHJl c291cmNlcyB0aGUgY29tbWVyY2lhbCBhc3NldDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg c2VydmljZXMgdGhhdCBhcmUgbGlrZWx5IHRvIGFwcGVhciB0byBleHBsb2l0IHRoaXM8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoG9wcG9ydHVuaXR5LCBhbmQgbm90IG9ubHkgd2lsbCB0aGUg bnVtYmVyIG9mIGFzc2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzZXJ2aWNlcyBsZWFw LCBidXQgdGhlIHBvd2VyIG9mIGVhY2ggb25lIHdpbGwgcm9ja2V0PGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqB0b28sIGJlY2F1c2UsIGFmdGVyIGFsbCwgdGhlc2UgYnVzaW5lc3NlcyB3aWxs IGJlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBoZWF2aWx5IG9wdGltaXplZCBmb3IgdGhl IGpvYi48YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgQXMgdG8gd2h5IGEgd29ybGQg d291bGQgd2FudCBjbGllbnRzIHRvIGFjY2Vzczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg ZXh0ZXJuYWwgYXNzZXQgc2VydmljZXMgaW5zdGVhZCBvZiBwcm92aWRpbmcgaXRzIG93bjxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaW1wbGVtZW50YXRpb24sIHRoYXQmIzM5O3MgYW4gZWFz eSBxdWVzdGlvbi4g77+9SXQgY29zdHM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG1vbmV5 IHRvIGhvc3QgYSBoaWdoIHBlcmZvcm1hbmNlIGFuZCBzY2FsYWJsZSBhc3NldDxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgc2VydmljZSBhbmQgYSBoaWdoIGJhbmR3aWR0aCBuZXR3b3JrIHRv IGhhbmRsZSB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRyYWZmaWMuIO+/vUEgKmxv dCogb2YgbW9uZXkuIO+/vUluIGNvbnRyYXN0LCBpdCBjb3N0cyBhPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqB3b3JsZCBub3RoaW5nIHRvIGxldCBvdGhlcnMgc2VydmUgdGhlIGFzc2V0cyB0 bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgY2xpZW50cy4g77+9QW5kIHRoYXQgbWF0dGVy cyB0byB0aGUgYm90dG9tIGxpbmUuPGJyPgo8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgTW9yZ2FpbmUuPGJyPgo8YnI+Cjxicj4KPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoD09PT09PT09PT09PT09PT09PT09PT08YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgT24gU2F0LCBBcHIgMiwgMjAxMSBhdCA3OjA1IFBNLCBJenp5IEFsYW5pczxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgJmx0OzxhIGhyZWY9Im1haWx0bzppenp5YWxhbmlzQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPml6enlhbGFuaXNAZ21haWwuY29tPC9hPiAmbHQ7bWFpbHRvOjxh IGhyZWY9Im1haWx0bzppenp5YWxhbmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPml6enlh bGFuaXNAZ21haWwuY29tPC9hPiZndDs8YnI+PC9kaXY+PC9kaXY+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOml6enlhbGFuaXNAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+aXp6eWFsYW5pc0BnbWFpbC5jb208L2E+PGRpdj48ZGl2PjwvZGl2Pjxk aXY+PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0 bzppenp5YWxhbmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPml6enlhbGFuaXNAZ21haWwu Y29tPC9hPiZndDsmZ3Q7Jmd0OyB3cm90ZTo8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKg77+9IO+/vSZndDsgQXMgYWx3YXlzIHRob3VnaCwgaXQmIzM5O3MgYSB0cmFkZS1vZmYsIHNp bmNlIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcHJveGllZCBkZXNpZ248YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71oYXMgdmVyeSBwb29yIHNjYWxhYmlsaXR5IGNv bXBhcmVkIHRvIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZGlzdHJpYnV0ZWQgb25l Ljxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9SSBkb24mIzM5O3QgYWdy ZWUgd2l0aCB0aGF0Li4uIElmIGEgdXNlciBlbnRlcnMgYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgaGlnaGx5IHBvcHVsYXRlZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vXJlZ2lvbiw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71ldmVyeSBvdGhlciBj bGllbnQgaXMgZ29pbmcgdG8gKGNvdWxkIGFuZCBzaG91bGQgYmU8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHRyeWluZyB0byk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71o aXQgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9YXNzZXQgc2VydmVyKHMp IGZvciB0aGUgYXNzZXRzIHRoYXQgdGhlIHVzZXIgaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHdlYXJpbmcgKGFzc3VtaW5nPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 dGhleSYjMzk7cmUgbm90IGNhY2hlZCBsb2NhbGx5KS4g77+9RXZlcnkgYXNzZXQgc2VydmVyPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBoYXMgdG8gYmUgc2NhbGVkIHVwPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dG8gdGhlIHBvaW50IHRoYXQgaXQgY2FuIGhhbmRsZSB0 aGF0IGxvYWQgZnJvbSBhbGw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG92ZXIuLi48YnI+ Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vUlmIEkmIzM5O20gaG9zdGluZyBh IHJlZ2lvbiB0aGF0IHN1cHBvcnRzIDEwcyBvZjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg dGhvdXNhbmRzIG9mPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c2ltdWx0YW5l b3VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dXNlcnMgKHRoaW5raW5nIG9m IHRoZSBmdXR1cmUpLCBJIGFscmVhZHkgaGF2ZSB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgc2NhbGUgdG8gbWVldCB0aGF0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 ZGVtYW5kLiBJZiB0aGUgcmVnaW9uIGlzIHByb3h5aW5nIHRoZSBhc3NldHMsIHRoZW4sPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB5ZXMgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqDvv70g77+9cmVnaW9uIGhhczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXRv IGJlIHNjYWxlZCB0byBtZWV0IHRoYXQgYXNzZXQgZGVtYW5kIHRvbywgYnV0IGl0PGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBhbHJlYWR5IGhhcyB0byBiZTxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vXNjYWxlZCB0byBtZWV0IG90aGVyIGRlbWFuZHMgb2YgYmVpbmcgYSBy ZWdpb248YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNlcnZlci4uLiBhbmQgd2h5IGlzPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c2NhbGluZyB0aG9zZSBhc3NldCBwcm94 eSBzZXJ2aWNlcyBoYXJkPyDvv71JdCYjMzk7czxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg Z29pbmcgdG8gY29zdCAkLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWJ1dCBp czxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vW5vdCB0ZWNobmljYWxseSBjaGFs bGVuZ2luZy4gU28sIGlmIEkgd2FudCB0byBob3N0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqBhIHJlZ2lvbiBsaWtlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dGhhdC4u LiBzdXJlIGl0IHdpbGwgY29zdCBtZSwgYnV0IHRoZSBzaW11bGF0aW9uPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqB3aWxsIGJlIGNvbnNpc3RlbnQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv71hbmQgdXNlcnMgd2lsbCBiZSBhYmxlIHRvIHBhcnRpY2lwYXRlIGVxdWFsbHks PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqByZWdhcmRsZXNzIG9mIHRoZTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWNhcGFiaWxpdGllcyBvZiB0aGVpciBpbmRpdmlkdWFs IGFzc2V0IHNlcnZpY2VzLjxicj4KPGJyPgo8YnI+Cjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqDvv70g77+9T24gRnJpLCBBcHIgMSwgMjAxMSBhdCAxMTo1NSBQTSwgTW9yZ2FpbmU8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mbHQ7PGEgaHJlZj0ibWFpbHRvOm1v cmdhaW5lLmRpbm92YUBnb29nbGVtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vcmdhaW5lLmRp bm92YUBnb29nbGVtYWlsLmNvbTwvYT48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vcmdhaW5lLmRpbm92YUBnb29nbGVtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPm1vcmdhaW5lLmRpbm92YUBnb29nbGVtYWlsLmNvbTwvYT4mZ3Q7PGJyPjwv ZGl2PjwvZGl2PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tPC9hPjxkaXY+PGRpdj48L2Rpdj48ZGl2 Pjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9yZ2FpbmUu ZGlub3ZhQGdvb2dsZW1haWwuY29tPC9hPiZndDsmZ3Q7Jmd0OyB3cm90ZTo8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IEV2ZXJ5IGRlc2lnbiBjaG9pY2UgcmVzdWx0cyBp biBhIHRyYWRlLW9mZiw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFZhdWdobiwgaW1wcm92 aW5nPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9b25lIHRoaW5nIGF0PGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyB0aGUgZXhwZW5zZSBvZiBzb21ldGhp bmcgZWxzZS4g77+9SWYgZXZlcnkgdGltZSB3ZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg b2ZmZXJlZCBhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c2VydmljZSB3ZSBo YWQgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGluZm9ybSBpdHMg dXNlcnMgYWJvdXQgdGhlIGRvd25zaWRlcyBvZiBhbGwgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqB0cmFkZS1vZmZzIHdlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 aGF2ZSBtYWRlLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgdGhleSB3 b3VsZCBoYXZlIGFuIGF3ZnVsIGxvdCB0byByZWFkLiA7LSk8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0 OyBUaGUgc3BlY2lmaWMgdHJhZGUtb2ZmIHRoYXQgeW91IGFyZSBkaXNjdXNzaW5nIGlzIG5vPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9ZGlmZmVyZW50LiDvv71BIHJlZ2lvbjxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgdGhhdCBwcm94aWVzIGFsbCBj b250ZW50IGhhcyB0aGUgJnF1b3Q7YmVuZWZpdCZxdW90OyBvZjxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgYWNxdWlyaW5nIGNvbnRyb2w8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv71mcm9tIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgYXNz ZXQgc2VydmVycyBvdmVyIHRoZSBpdGVtcyBpbiB0aGUgcmVnaW9uLCBzbzxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgdGhhdCBpdCBjYW48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv71lbnN1cmUgdGhhdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsg ZXZlcnlvbmUgaW4gdGhlIHJlZ2lvbiBub3Qgb25seSBvYnRhaW5zIHRoZSBpdGVtczxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgYnV0IG9idGFpbnM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv710aGUgc2FtZSBpdGVtczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vSZndDsgYXMgZXZlcnlvbmUgZWxzZS4g77+9VGhhdCBkb2VzIGluZGVlZCBwcm92aWRlIGE8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGdyZWF0ZXIgZ3VhcmFudGVlIG9mPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBjb25zaXN0ZW5jeSB0aGFuIGEgZGVwbG95 bWVudCBpbiB3aGljaCB0aGUgcmVnaW9uPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBvbmx5 IHBhc3Nlczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWFzc2V0IFVSSXMgdG88 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGNsaWVudHMgd2hvIHRoZW4g ZmV0Y2ggdGhlIGl0ZW1zIGZyb20gYXNzZXQgc2VydmljZXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoO+/vSDvv71zZXBhcmF0ZWx5LiDvv71BcyBhbHdheXM8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoO+/vSDvv70mZ3Q7IHRob3VnaCwgaXQmIzM5O3MgYSB0cmFkZS1vZmYsIHNpbmNl IHRoZSBwcm94aWVkPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkZXNpZ24gaGFzIHZlcnk8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71wb29yIHNjYWxhYmlsaXR5PGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBjb21wYXJlZCB0byB0aGUgZGlzdHJp YnV0ZWQgb25lLjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IElmIHdlJiMzOTtyZSBnb2luZyB0byB3 YXJuIHVzZXJzIG9mIHRoZSBwb3RlbnRpYWwgZm9yPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqBpbmNvbnNpc3RlbmN5PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9aW4gdGhl PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBkaXN0cmlidXRlZCBkZXBs b3ltZW50IGFzIHlvdSBzdWdnZXN0LCBhcmUgd2U8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oGFsc28gZ29pbmcgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv713YXJuIHRo ZW0gb2Y8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IG5vbi1zY2FsYWJp bGl0eSBpbiB0aGUgcHJveGllZCBvbmU/IO+/vUkgcmVhbGx5PGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBkb24mIzM5O3Qgc2VlIG11Y2g8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv71tZXJpdCBpbiB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7 IGlkZWEgb2Ygd2FybmluZyBhYm91dCBkZXNpZ24gY2hvaWNlcy4g77+9TWFueSBzdWNoPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBjaG9pY2VzIGFyZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vXRlY2huaWNhbCwgYW5kPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDv v70g77+9Jmd0OyB0aGUgaXNzdWVzIGFyZSBxdWl0ZSBsaWtlbHkgdG8gYmUgb2YgbGl0dGxlPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpbnRlcmVzdCB0bzxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vW5vbi10ZWNobmljYWwgdXNlcnM8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoO+/vSDvv70mZ3Q7IGFueXdheS4g77+9SW4gYW55IGNhc2UsIHRoZSBiZXR0ZXIgc2Vy dmljZXMgYXJlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBsaWtlbHkgdG8gcHJvdmlkZTxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXN1Y2g8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGluZm9ybWF0aW9uIGluIHRoZWlyIG9ubGluZSBkb2N1bWVu dGF0aW9uLCBJPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB3b3VsZCBndWVzcy48YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Jmd0OyBZb3UgbWVudGlvbmVkIHVzZXJzICZxdW90O3ZvdGluZyB3aXRoIHRo ZWlyIGZlZXQmcXVvdDsgb3I8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNob29zaW5nIHRv PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9YWNjZXB0IHRoZSByaXNrPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBvZiBpbmNvbnNpc3RlbmN5LiDvv71X ZWxsIHRoYXQgd2lsbCBoYXBwZW4gYW55d2F5LDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg d2hlbiBzZXJ2aWNlczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWZhaWwgYW5k PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyB1c2VycyBnZXQgYW5ub3ll ZC4g77+9SWYgc29tZSBhc3NldCBzZXJ2aWNlcyByZWZ1c2U8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoHRvIHNlbmQgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9cmVx dWVzdGVkPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBpdGVtcyB0byBz b21lIHVzZXJzLCB0aG9zZSBzZXJ2aWNlcyB3aWxsIGdldCBhPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBiYWQgcmVwdXRhdGlvbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vWFuZCBwZW9wbGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IHdpbGwg Y2hvb3NlIGRpZmZlcmVudCBhc3NldCBzZXJ2aWNlcyBpbnN0ZWFkLjxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9TGlrZXdpc2UsIGlmIGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv713b3JsZCBzZXJ2aWNlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 Jmd0OyBwcm94aWVzIGV2ZXJ5dGhpbmcgYW5kIHNvIGl0IGNhbiYjMzk7dCBoYW5kbGUgYSBsYXJn ZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbnVtYmVyIG9mPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqDvv70g77+9YXNzZXRzIG9yIG9mPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqDvv70g77+9Jmd0OyBwZW9wbGUsIHVzZXJzIHdpbGwgZ2V0IGFubm95ZWQgYXQgdGhlIGxhZyBh bmQgd2lsbCBnbzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWVsc2V3aGVyZS4g 77+9VGhpcyB1c2VyPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBldmFs dWF0aW9uIGFuZCAmcXVvdDt2b3Rpbmcgd2l0aCB0aGVpciBmZWV0JnF1b3Q7IGhhcHBlbnM8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGFscmVhZHkgd2l0aDxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vW9ubGluZSBzZXJ2aWNlczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKg77+9IO+/vSZndDsgYWxsIG92ZXIgdGhlIEludGVybmV0LCBhbmQgSSBhbSBzdXJlIHRoYXQg dGhpczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaHVtYW4gcHJvY2Vzczxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXdpbGwgY29udGludWU8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoO+/vSDvv70mZ3Q7IHRvIHdvcmsgd2hlbiB0aGUgc2VydmljZXMgYXJlIGFzc2V0 IGFuZCByZWdpb248YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNlcnZpY2VzLjxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv70mZ3Q7IEJhY2sgaW4gU2VwdGVtYmVyIDIwMTAsIEkgd3JvdGUgdGhpcyBwb3N0 IHdoaWNoPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBwcm9wb3NlcyB0aGF0PGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9d2UgdXNlIGluPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqDvv70g77+9Jmd0OyBWV1JBUCBhIGZvcm0gb2YgYXNzZXQgYWRkcmVzc2luZyB0aGF0 IHByb3ZpZGVzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBtYXNzaXZlPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c2NhbGFiaWxpdHkgYXQgdGhlPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBzYW1lIHRpbWUgYXMgYSB2ZXJ5IGhpZ2ggZGVncmVl IG9mIHJlc2lsaWVuY2UgLS08YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7 PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv708YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vTxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi92d3Jh cC9jdXJyZW50L21zZzAwNDYzLmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvdndyYXAvY3VycmVudC9tc2cwMDQ2My5odG1sPC9hPjxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vS4g77+9SXQgaXM8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGJhc2VkIG9uIHRoZSBjb25jZXB0IG9mIHRoZSBVUkkg Y29udGFpbmluZyBhIGhvc3Q8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHBhcnQgYW5kIGE8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71oYXNoIHBhcnQsPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyB3aGVyZSB0aGUgaGFzaCBpcyBnZW5lcmF0ZWQg KG9uY2UsIGF0IHRoZSB0aW1lIG9mPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzdG9yYWdl IHRvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dGhlIGFzc2V0PGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBzZXJ2aWNlKSB1c2luZyBhIHNwZWNpZmll ZCBkaWdlc3QgYWxnb3JpdGhtIG92ZXI8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRoZSBj b250ZW50IG9mPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dGhlIGFzc2V0PGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBiZWluZyByZWZlcmVuY2VkLiDv v71Zb3UgbWF5IHdpc2ggdG8gbm90ZSB0aGF0IGlmPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqB0aGlzIGRlc2lnbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXdlcmUgdXNl ZCwgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBmYWlsdXJlIG9m IGFuIGFzc2V0IHNlcnZpY2UgdG8gZGVsaXZlciBhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqByZXF1ZXN0ZWQgaXRlbSB3b3VsZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vXJlc3VsdCBpbiBhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBmYWls b3ZlciByZXF1ZXN0IGZvciB0aGUgaXRlbSB0byBvbmUgb3IgbW9yZTxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgYmFja3VwIHNlcnZpY2VzLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vXVzaW5nIHRoZSBzYW1lPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 Jmd0OyBoYXNoIHBhcnQgYnV0IHdpdGggYSBkaWZmZXJlbnQgaG9zdCBhZGRyZXNzLjxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv70mZ3Q7IFRoaXMgY2FuIGdvIHNvbWUgd2F5IHRvd2FyZHMgb3ZlcmNvbWluZyB0 aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHByb2JsZW0gdGhhdCB5b3U8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv710aGluayBtaWdodDxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vSZndDsgb2NjdXIgd2hlbiBhc3NldHMgYXJlIGZldGNoZWQgYnkgY2xp ZW50cyBmcm9tPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhc3NldCBzZXJ2aWNlczxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWRpcmVjdGx5Ljxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vSZndDsgQWx0aG91Z2ggaXQgd29uJiMzOTt0IGhlbHAgd2hlbiB0 aGUgbWlzc2luZyBpdGVtIGlzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhdmFpbGFibGUg ZnJvbTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vW9ubHkgYSBzaW5nbGU8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGFzc2V0IHNlcnZpY2UsIGl0IHdp bGwgaGVscCBpbiBtYW55IG90aGVyIGNhc2VzLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg YW5kIGl0IHdpbGw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71jb21wZW5zYXRl IGZvcjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgc2VydmljZSBmYWls dXJlcyBhbmQgbmV0d29yayBvdXRhZ2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhdXRv bWF0aWNhbGx5IGF0IHRoZSBzYW1lPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 dGltZS48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBQUy4gVGhpcyBkZXNpZ24gZm9yIGhhc2gtYmFz ZWQgYXNzZXQgYWRkcmVzc2luZzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaXMgYWxyZWFk eTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWJlaW5nIHRlc3RlZCBieTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgTW9qaXRvIFNvcmJldCBpbiBoZXIg ZXhwZXJpbWVudGFsIHdvcmxkIGFuZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgY2xpZW50 LiDvv71JdCB3b3VsZCBnaXZlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0 OyBWV1JBUC1iYXNlZCB3b3JsZHMgYW4gaW1wcm92ZWQgbGV2ZWwgb2Ygc2VydmljZTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgYXZhaWxhYmlsaXR5LDxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vXNvIEkgdGhpbmsgaXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv70mZ3Q7IHNob3VsZCBiZSBhIGNvcmUgZmVhdHVyZSBvZiBvdXIgcHJvdG9jb2wuPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7 IE1vcmdhaW5lLjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7ID09PT09PT09PT09PT09PT09 PT09PT09PT09PTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IE9uIEZyaSwgQXByIDEsIDIwMTEgYXQg MTE6MTcgUE0sIFZhdWdobiBEZWx1Y2E8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDv v70mbHQ7PGEgaHJlZj0ibWFpbHRvOnZhdWdobi5kZWx1Y2FAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+dmF1Z2huLmRlbHVjYUBnbWFpbC5jb208L2E+PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2YXVnaG4uZGVsdWNhQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnZhdWdobi5kZWx1Y2FAZ21haWwuY29tPC9hPiZndDs8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZhdWdobi5kZWx1 Y2FAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmF1Z2huLmRlbHVjYUBnbWFpbC5jb208L2E+ PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2 YXVnaG4uZGVsdWNhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZhdWdobi5kZWx1Y2FAZ21h aWwuY29tPC9hPiZndDsmZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vSZndDsgd3JvdGU6PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDs8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBUaGlzIGlzIGEgcXVl c3Rpb24gaSBkaXNjdXNzZWQgd2l0aCBNb3JnYWluZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgb2ZmLWxpc3QgYSB3aGlsZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWFn byAoSTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IGludGVuZGVk IHRvIHNlbmQgaXQgdG8gdGhlIGxpc3QgYnV0IHB1c2hlZCB0aGU8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHdyb25nIGJ1dHRvbi4uLikgSTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vSZndDsmZ3Q7IHRoaW5rIHdlIG5lZWQgdG8gYWRkcmVzcyB0aGlzIHByb2JsZW0sIGFu ZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZGVjaWRlIGhvdyB0byBkZWFsPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9d2l0aCBpdC48YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoO+/vSDvv70mZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vSZndDsmZ3Q7IO+/vUluIERhdmlkcyBkZXBsb3ltZW50IGRyYWZ0LCBzZWN0aW9uIDcuMy4xLjEg YW48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG92ZXJ2aWV3IGlzPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqDvv70g77+9Z2l2ZW4gdmFuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqDvv70g77+9Jmd0OyZndDsgd2F5cyB0byBkZWxpdmVyIGNvbnRlbnQgdG8gdGhlIHJlZ2lvbi4g T25lIHdheTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaXMgb25seSBwYXNzaW5nIGE8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBjYXBhYmlsaXR5IHRoYXQg YWxsb3dzIGFjY2VzcyB0byAocGFydCBvZikgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqByZXNvdXJjZTo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0Ozxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/vSDvv70g77+9IO+/ vSDvv70gNy4zLjEuMS4g77+9Q29udGVudCBkZWxpdmVyeSBtb2RlbHM8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/vSDvv70g77+9IEEgcmFuZ2Ug b2YgcG9zc2libGUgcmVwcmVzZW5hdGlvbnMgY2FuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqBiZSBwYXNzZWQgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71hIHJlZ2lv biBmb3I8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv70g77+9 IO+/vSDvv70g77+9IHNpbXVsYXRpb24uIFsuLi5dIFRoZSBvdGhlciBlbmQgb2YgdGhlPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkZWxpdmVyeSBzcGVjdHJ1bTxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IGludm9sdmVzIHBhc3Npbmc8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/vSDvv70g77+9IG9ubHkg YSBVUkkgb3IgY2FwYWJpbGl0eSB1c2VkIHRvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBh Y2Nlc3MgdGhlIHJlbmRlcmluZzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZn dDsmZ3Q7IGluZm9ybWF0aW9uIGFuZCBhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9Jmd0OyZndDsg77+9IO+/vSDvv70g77+9IO+/vSBjb2xsaXNpb24gbWVzaCxhbmQgcmVsYXRl ZCBkYXRhIGZvcjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcGh5c2ljYWwgc2ltdWxhdGlv bi48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/ vSDvv70g77+9IEluIHN1Y2ggYSBtb2RlbCwgdGhlIGNsaWVudCBpczxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgcmVzcG9uc2libGUgZm9yPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDv v70g77+9ZmV0Y2hpbmcgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0 OyZndDsgYWRkaXRpb25hbDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsm Z3Q7IO+/vSDvv70g77+9IO+/vSDvv70gaW5mb3JtYXRpb24gbmVlZGVkIHRvIHJlbmRlciB0aGU8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGl0ZW0mIzM5O3MgdmlzdWFsPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9cHJlc2VuY2UgZnJvbSBhPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgc2VwYXJhdGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/vSDvv70g77+9IHNlcnZpY2UuIO+/vVRo aXMgZmV0Y2ggY2FuIGJlIGRvbmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCp1bmRlciB0 aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71jcmVkZW50aWFscyBvZiB0aGU8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBlbmQgdXNlcio8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/vSDvv70g 77+9IHZpZXdpbmcgdGhlIG1hdGVyaWFsIFtteSBlbXBoYXNpcy0tVkRdPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAsIGFuZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWRp dm9yY2VzIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHNp bXVsYXRpb24gZnJvbTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7 IO+/vSDvv70g77+9IO+/vSDvv70gdGhlIHRydXN0IGNoYWluIG5lZWRlZCB0byBtYW5hZ2U8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNvbnRlbnQuIO+/vUFueTxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vWF1dG9tYXRpb248YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv70mZ3Q7Jmd0OyBpcyBkb25lIG9uIGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/vSDvv70g77+9IHNlcGFyYXRlIGhvc3Qgd2hpY2gg dGhlIGNvbnRlbnQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNyZWF0b3Igb3Igb3duZXIg dHJ1c3RzLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IGludGVy YWN0aW5nIHdpdGggdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZn dDsg77+9IO+/vSDvv70g77+9IO+/vSBvYmplY3QgdGhyb3VnaCByZW1vdGVkIGludGVyZmFjZXMu PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDs8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv71JIGNhbiBzZWUgdGhlIG5lZWQgZm9y IHN1Y2ggYSBzZXR1cCwgaG93ZXZlciwgaTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZmVl bCB3ZSBhcmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyB1bnBs ZWFzYW50bHkgY2xvc2UgdG8gYSBzaXR1YXRpb24gd2VyZSB0aGU8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoGNvaGVyZW5jZSBvZiB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv71zaW11bGF0aW9uPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZn dDsgZmFsbHMgYXBhcnQuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZn dDsgSW4gdGhpcyBkZXBsb3ltZW50IHBhdHRlcm4gdGhlIHJlZ2lvbiBhZHZlcnRpc2VzPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGUgcHJlc2VuY2U8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoO+/vSDvv71vZiB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70m Z3Q7Jmd0OyBhc3NldCwgYW5kICpzb21lKiBjbGllbnRzIHdpbGwgYmUgYWJsZSB0byBnZXQgaXQ8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGFzIGV4cGVjdGVkLDxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vXdoaWxlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9Jmd0OyZndDsgLWJhc2VkIG9uIHRoZSBhcmJpdHJhcnkgd2hpbXMgb2YgdGhlIGFzc2V0PGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzZXJ2aWNlLSBvdGhlcnM8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv71taWdodCBub3QuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqDvv70g77+9Jmd0OyZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7 Jmd0OyBNeSBob3BlIHdvdWxkIGJlIHRoYXQgYWZ0ZXIgdGhlIGFzc2V0IHNlcnZlcjxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgcHJvdmlkZXMgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9cmVnaW9uIHdpdGg8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDv v70mZ3Q7Jmd0OyB0aGUgY2FwYWJpbGl0eSB0byBnZXQgdGhlIGFzc2V0LCBpdCBnaXZlcyB1cDxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgY29udHJvbC4gVGhhdDxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vXdvdWxkIG1lYW48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv70mZ3Q7Jmd0OyB0aGF0IGlmIHRoZSBjbGllbnQgZmluZHMgdGhlIGludmVudG9yeSBz ZXJ2ZXIgaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHVud2lsbGluZyB0bzxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXNlcnZlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Jmd0OyZndDsgdGhlIGNvbnRlbnQgLSBpbiBzcGlyZSBvZiB0aGUgcmVnaW9u IHNheWluZyBpdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaXMgcHJlc2VudC0sPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dGhlIGNsaWVudDxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHNob3VsZCBiZSBhYmxlIHRvIHR1cm4gYXJvdW5k IGFzayB0aGUgKnJlZ2lvbio8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGZvciB0aGUgYXNz ZXQsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9KGFuZCBnZXQ8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBpcyBhZnRlciBhbGwpLjxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqDvv70g77+9Jmd0OyZndDsg77+9SWYgdGhhdCBpcyBub3QgdGhlIGNhc2UsIC1hbmQg dGhlcmUgYXJlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBwcm9iYWJseSBnb29kIHJlYXNv bnM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71mb3IgdGhlPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgZGVwbG95bWVudCBwYXR0ZXJuIGFzIGRl c2NyaWJlZC0g77+9c2hvdWxkbiYjMzk7dCB3ZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg Kndhcm4qIGNsaWVudHM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv710aGF0IHRo ZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHJlZ2lvbiBtaWdo dCBiZSBpbmNvbnNpc3RlbnQsIHNvIHRoZSB1c2Vyczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgYmVoaW5kIHRoZSBjbGllbnQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71j YW4gdm90ZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHdpdGgg dGhlaXIgZmVldCwgKG9yIHRha2UgdGhlIHJpc2spPzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKg77+9IO+/vSZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0 OyZndDsgLS1WYXVnaG48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHZ3cmFwIG1haWxpbmcgbGlzdDxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0 bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiAmbHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3 cmFwQGlldGYub3JnPC9hPiZndDs8YnI+PC9kaXY+PC9kaXY+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFw QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+Jmd0OyZndDs8ZGl2 Pjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdndyYXAiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Z3cmFwPC9hPjxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgdndyYXAgbWFpbGluZyBsaXN0PGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyA8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9y ZzwvYT4mZ3Q7PGJyPjwvZGl2PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxh IGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYu b3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiZndDsmZ3Q7PGRpdj48YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdndyYXAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Z3cmFwPC9hPjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgo8 YnI+Cjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Cjxicj4K IMKgIMKgIMKgIMKgIMKgIMKgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+CiDCoCDCoCDCoCDCoCDCoCDCoHZ3cmFwIG1haWxpbmcgbGlzdDxicj4KIMKg IMKgIMKgIMKgIMKgIMKgPGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFw QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4KIMKg IMKgIMKgIMKgIMKgIMKgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby92d3JhcCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdndyYXA8L2E+PGJyPjwvZGl2PjxkaXY+CiDCoCDCoCDCoCDCoCDCoCDCoO+/vTxi cj4KPGJyPgo8YnI+Cjxicj4KPGJyPgo8YnI+CiDCoCDCoC0tIMKgIMKgIC0tLSA8YSBocmVmPSJo dHRwczovL3R3aXR0ZXIuY29tL0R6b25hdGFzX1NvbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v dHdpdHRlci5jb20vRHpvbmF0YXNfU29sPC9hPiAtLS08YnI+CiDCoCDCoFdlYiBEZXZlbG9wbWVu dCwgU29mdHdhcmUgRW5naW5lZXJpbmcsIFZpcnR1YWwgUmVhbGl0eSwgQ29uc3VsdGFudDxicj4K PGJyPgogwqAgwqBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4KIMKgIMKgdndyYXAgbWFpbGluZyBsaXN0PGJyPjwvZGl2PjxkaXY+CiDCoCDCoDxhIGhy ZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3Jn PC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiZndDs8YnI+CiDCoCDCoDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdndyYXAiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Z3cmFwPC9hPjxicj4KPGJyPgo8YnI+ CjwvZGl2PjwvYmxvY2txdW90ZT4KPGJyPjxkaXY+PGRpdj48L2Rpdj48ZGl2Pgo8YnI+Ci0tIDxi cj4KLS0tIDxhIGhyZWY9Imh0dHBzOi8vdHdpdHRlci5jb20vRHpvbmF0YXNfU29sIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly90d2l0dGVyLmNvbS9Eem9uYXRhc19Tb2w8L2E+IC0tLTxicj4KV2Vi IERldmVsb3BtZW50LCBTb2Z0d2FyZSBFbmdpbmVlcmluZywgVmlydHVhbCBSZWFsaXR5LCBDb25z dWx0YW50PGJyPgo8YnI+CjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+ CjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+CjwvZGl2PjwvZGl2PjwvYmxvY2tx dW90ZT48L2Rpdj48YnI+Cg== --0015174be714e6a64504a06cccc3-- From dzonatas@gmail.com Fri Apr 8 11:58:35 2011 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 0C7073A6967 for ; Fri, 8 Apr 2011 11:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=-1.530, BAYES_20=-0.74, J_CHICKENPOX_43=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] 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 n9XeQTP5UkK5 for ; Fri, 8 Apr 2011 11:58:32 -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 12A603A6962 for ; Fri, 8 Apr 2011 11:58:32 -0700 (PDT) Received: by pvh1 with SMTP id 1so1657168pvh.31 for ; Fri, 08 Apr 2011 12:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BhxFeGkQmGzjPIL8QJJBO/Gp6cGiSM6X9Fh0M6Zomlk=; b=m6gJWcejj0PQc9/u9EqK6nuXhOkUihF+54xcCBKN7fvwDCXxvBruyLkOSCoOvdbpaS gg0cCyAC+Zy3dI522WwUJOYI/YBFP/tAXiBhdHzzc52LRmHW+O2jS6gqwKLkVICKawiZ mT5mfjvlz5i7iVRvzY0oUr5h8rg88e680vVEU= 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=Nos6M3kOrr9TptpmGXpwJaULYTkpJwpT3PKMdd50GX/tkJz3R66Ag3+s401fqDKuYs Z+kUEWKNV0+mbiU68//oYofZGxQ7TvNpHmDfuMI8u0kzGpXvSNqdsunLt/xs8xRkmuJa s3qvHpBsnaS2MsGs3h1PnKxabo58GJ/9117as= Received: by 10.142.162.6 with SMTP id k6mr2032695wfe.80.1302289217511; Fri, 08 Apr 2011 12:00:17 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id z10sm3983016wfj.3.2011.04.08.12.00.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2011 12:00:16 -0700 (PDT) Message-ID: <4D9F5B5F.2060401@gmail.com> Date: Fri, 08 Apr 2011 12:00:47 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Vaughn Deluca References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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, 08 Apr 2011 18:58:35 -0000 I've read it, and off hand I would say the "flow" needs further definition. Not that you did anything wrong, it just something that happens more at the transfer layer from ReST and lower. All the arrows you have that go from the Local to External let's consider those "forward flow" and those that from from external to local as "reverse flow." This becomes more obvious for reasons why when firewalls and proxies are in the way and connections may need to exist in opposite of the flow. Between unidirectional and bidirectional flows is were this discussion digresses to vanilla HTTP/caps and not fully ReSTful as desired. See also this doc on "forward/reverse" how Icesphere handles the implementation of bidirectional resources: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Interface I think you already see the higher-level request to begin capability, end capability, and determine if it needs to request capabilities. With bidirectional resources, there are less requests for capabilities and mainly need for digests of capabilities that begin and end. With unidirectional resources, there are needs to request capabilities, that (currently on servers) begin as private capabilities. Also with unidirectional resources, there are keep-alives and long-poll requirements on the resources, which isn't mandatory on bidirectional resources. Bidirectional resources can use more ReSTful credentials, so there would be no need to request capabilities (only need to know they are capable by the digests). I imagine two big polygons around the Local and External areas on the diagrams, yet to further image the arrows on actual flow might not be so trivial as the desired flow noted. Then again, split the viewer out for local agent services and maybe it will appear trivial. Vaughn Deluca wrote: > VWRAP services high level message flow (preliminary diagram draft) see > > http://trac.tools.ietf.org/wg/vwrap/trac/attachment/wiki/Diagrams/VWRAP_FlowExample_VD1.pdf > > The main reason that i am submitting this in spite of my lack of > formal expertise is that the group in my view badly needs a solid > basis for discussion and preventing endless repeating loops. This > example is probably wrong in many ways, but its better than what we > have publicly available on interop now (although Morgaine is working > on something along the lines of the recent discussions here) > > I hope this diagram will give us a base for discussion. I could have > done my homework better by researching the old OGP stuff in more > depth, and i probably will do so in the future , but for now I just > tried to followed the general principles as far as i understand them, > to see what response that yields from the group. In other words,I try > to let the group educate me :p > > Note that in my view all services are equal, in principle it does not > matter in what "domain" they run, since trust and policy are fully > localized. It is however very possible to have internal shortcuts in > the services to speed up processing. > > In the example I opted for an external Agent service, but I could as > well have incorporated that in the set of local services. As indicated > above all services could also be run by different organisations, true > to what VWRAP stands for. Its all up to the deployer, including a user > at home who might want to run a full world for family and friends. > Those friends might try to use that agent service to venture out in > the virtual universe. > I envision that the final identity provider is external, using OpenID > and OAut or whatever other magic that I do not yet fully understand > exists out there. > > The example has 3 main purposes: > - Provide a reference for discussion > - Illustrates the use case of tourism, and *true* interop. > - Illustrate consistency problems along the lines discussed here > higher up in this tread, as well as the "slashdot" problem that > Morgaine outlined so clearly. > > The message flow assumes an avatar already present in some region, (a > small scale local home region in this case, but that is by no means > essential, it could be a build in region in the viewer or a big > commercial region). The user is preparing for a trip to immersive > world, and after some outfit adjustments moves over. > > Finally i apologize for for the simplistic notation used here. I > simply add the most relevant parameters passed in square brackets to a > keyword specifying the nature of the message. Please improve on that > where needed. > > So here we go, the avatar is prepare for a visit to "immersive world" > 0) Viewer, here is an update of the state of the world your agent is > in, please render. > 1) Agent service, I will go in my Zodiac dress that i keep in the > "Amazing assets" service. > 2) Asset service A, please send a cap for Z, here are my credentials > 3) Your fine, here is the cap > 4) Local region, can you please put this on my agent, i included the cap. > 5) Hello asset service A, i need Z, here is the cap > 6) Cap is good, data coming up, have fun. > 7) Agent service, your agent is now wearing Z > 8) Viewer, your avatar is now wearing Z > User: Hmm, amazing inventory has not been *that* amazing lately. > 'll make a backup, just in case > 9) Hello asset service A, please send me a cap for Z, here are my > credentials > 10) Your fine, here is the cap > 11) Local asset storage, please store Z for me, here is the cap to get it > 12) Hello asset service A, i want Z, here is the cap > 13) Cap is good, data coming up, have fun. > 14) Viewer, Z is now stored for you > User: I am Ready!, Lets try to get to immersive world! > 15) Hello immersive world, can i get in? Here are my credentials, and > a list of my stuff. > 16) Asset service A, please send me a cap for X, here are my > credentials (I want this cap for consistency) > 17) Your fine, here is the cap > 18) Asset service B, please send me a cap for Y, here are my > credentials (I want this cap for consistency) > 19) Very sorry, but your not one of us, you can't have Y > 20) Asset service B, please send me a cap for Z, here are my > credentials (I want a cap for consistency) > [Region service: Timeout... amazing inventory must be overloaded.. oh > well... ] > 21) Agent service, you wanted to send somebody over, here are your > permissions. > 22) Viewer, you asked for a transfer try, here are your results > User thinks: Crap! Big asset service does not allow me to take > my yellow stockings! And Amazing assets failed to deliver my zodiac > dress. At least i made a backup of that dress! > 23) 'll take the yellow stockings off... > 24) ... done ('ll trash them here and now, forever, who needs stuff > you can't use!) > 25) The zodiac dress was not delivered by Big assets service, but i > have a local copy! > 26) Local Asset service, please send me Z, here are my credentials > 27) I dont know you, but I 'll trust you, here is the cap, but you > better store the data, its single use, i need to protect myself. > 28) Local region, can you please put this on my agent, i include the cap. > 29) Local Asset service, i need Z, here is the cap > 30) Cap is good, data coming up, have fun. > 31) Cap was only good for one time, I made a copy, but my policy is to > only grant you fair use rights, at a later time i might even tell you > to replace the dress. > 32) Viewer, you can wear Z for now, but the asset service granted only > fair use, i might ask you to replace the dress at a later time. > 33) Ready at last! Off to immersive world!, I hope its not to crowded > there or 'll loose my dress... > 34) Hello immersive world, here are my credentials, and a list of > stuff i want to bring > 35) Hello asset service A, please send me a cap for X, here are my > credentials > [darn, I should have kept that cap from last time..] > 36) Your fine, here is the cap. > [Region service finds fair-use warning on Z and decides to make its > own copy] > 37) Hello Local region, can i still have Z? Here is the cap > 38) Cap is still good, data coming up, have fun. > [Region service stores asset in private storage, providing a cap to > replace the fair use one] > 39) Agent service, you wanted to send somebody over, here are your > permissions & info. > 40) Hello immersive world, just get me there, and use what you can > 41) Placement done, Z is currently buffered by us as wel, you need to > get details for X, have fun. > 42) You are now in immersive world, your dress is buffered there as > well, but you need to get X! > 43) Hello asset service A, i want X, here is the cap > 44) Cap is good, data coming up, have fun. > 45) Viewer, here is an update of the state of the world your agent is > in, please render. > > As far as I can see this conforms fully to our charter, and i hope it > is possible to use large portions of the existing code bases. However, > as said above, i did not really try to capture the old thinking, and I > also might have misconceptions about the way to do these things in > general. > Looking forward to constructive comments. > > -- Vaughn > > On Sun, Apr 3, 2011 at 8:38 PM, Vaughn Deluca > wrote: > > Thanks for the pointers. I have a busy week in RL in front of > me, so i wont have to much time to respond the next few days, > however, i intend to start doing the following things: > > - Produce a visual that reflects my thinking, i.e. an illustration > of my response to Morgaine's itemlist above. > - Read up on the older notes, as well as more reading in the list > archive > - Try to make a summary for the wiki > > Regarding the use of domain, I think services are eventually what > counts, but its all terminology. The way I read the AWG diagrams > is that the agent domain is actually a cluster of tightly > integrated services. When the functionality of each sub-service is > described properly and with uniform interfaces the domain will > slowly dissolve. But let not get ahead of out selfs. We should put > up some clear descriptions on the wiki for our views on this, and > *after* that we can decide what we need and what can go. > > Its been a very useful and illuminating weekend for me, and i am a > lot more optimistic about the future of vwrap than two weeks ago. > > -- Vaughn > > > > On Sun, Apr 3, 2011 at 7:20 PM, Dzonatas Sol > wrote: > > Probably easy as suggested in other terms here on this list, > as how the client contacts the asset services now in the > regions. The newer issue is to unitize that asset services. > Since their is proprietary (legacy) code then we can't expect > that to change, and some form of proxy is of need. Whatever > works best, I tried to narrow it down to suggestions here. > > Eventually, the agent domain is ideal to handle the direction > of the asset services. This concept, unfortunately, ended > support awhile ago with changes in LL. > Also see; http://wiki.secondlife.com/wiki/Agent_Domain > And: > http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset > (warn: unstructured collaborative notes, dumped on me and I > tried to fix) > > I tried to find previous visuals. > > I'd imagine the agent domain could grow out of unitized > versions of asset services. Despite that, I think that concept > helps view where we were at in discussion and what didn't happen. > > Vaughn Deluca wrote: > > Hi�Dzonatas > > Can you expand on that, what would be needed for legacy > support in VWAP terms�?, > If i want to read up on how the�asset server may proxy the > simulator, what would you recommend me to read? > > -- Vaughn > > On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol > > >> > wrote: > > Some stated the proxy-to-asset-server is built into the > sim; > however, keep in mind possible legacy support where the > asset > server may proxy the simulator. > > > Dzonatas Sol wrote: > > Somehow I feel the basic asset server being able to > login and > download assets is now priority, yet I also > wondered the best > way to patch this into the current mode of viewers. > > Maybe offer (1) by proxy (sim-side) and (2) by patch > (viewer-side) that either of these two are optional and > neither are mandatory for now. Thoughts? > > Israel Alanis wrote: > > > > when designing for scalability, the model to > bear in > mind is ... > > Well, there are a lot of different models to > keep in mind, > and many different use cases. One particular > use case to > keep in mind is: "User acquires new outfit, and > wants to > 'show it off' in a highly populated region". > > > Both worlds and asset services may include > commercial, > community, and personal services > > Yes, yes and yes. I'm particularly concerned > about how the > model affects the ability to host personal > asset services. > > > a proxying region, which would get slammed > for every > asset worn by every avatar present. > > Granted the collection of services that are > provided by > the region need to be scaled to meet the > demands of that > region. That's all part of capacity planning. > > > regions run many different CPU-intensive tasks, > including physics simulation and server-side > scripting, > and absolutely cannot afford to serve assets too > Well... who said the same CPU's have to do > proxying, > physics simulation and server-side scripting? Asset > proxying is a different service than physics > simulation > and can be on separate hardware, could make use of > geographically distributed caching, and in certain > deployment patterns, the same caching services > could be > shared by different regions. (Server-side > scripting is a > discussion for another day). > > > This is why we have to go parallel... > > Totally agree, and a proxying model could and > should also > take advantage of parallelism. > > > I think you're wrong that it has to cost much > money. ?vs? > > It costs money to host a high performance and > scalable > asset service and a high bandwidth network to > handle the > traffic. �A *lot* of money. > I think what you're saying is: "It costs a lot > of money to > build a scalable asset service, but if assets > are spread > throughout the internet they don't have to be > scalable." > But that's not quite right. You're opening up > every asset > server to the VW equivalent of being > slashdotted, so are > you sure you're not forcing *every* asset > service to be > scalable and handle a lot of bandwith and > network traffic? > It's the exact opposite of your intention, but > I think > that's the result, all the same. > > This particular design decision has a big > effect on the > economics of the VW infrastructure. I'd rather the > economics to work out such that a region > provider who > wishes to build a region that supports a small > population, > can do so economically. A region that wants to > host a > *large* population has to bear that cost of > providing that > scalable asset service. > I want the economics of hosting a small asset > service to > be a non-issue (as to best promote creation and > creativity). Creating a high bar to provide > asset services > will mean that service will cost money and people > shouldn't have to pay money just to create or > own VW > objects (I'm using 'own' here to refer to > maintaining > their existence, I'm not trying to make a > 'leftist'/'communist' statement about ownership ;) > > - Izzy > > > On Apr 2, 2011, at 3:58 PM, Morgaine wrote: > > Izzy, when designing for scalability, the > model to > bear in mind is that of seasoned virtual world > travelers whose inventories contain assets > from many > different worlds, those assets being served > by many > different asset services. �Both worlds and > asset > services may include commercial, community, and > personal services, and as the metaverse > grows, that > set is highly likely to become > progressively less > clustered and more diverse. > > When those seasoned travelers click on an > advertised > VW link and perform an inter-world teleport > to one > particular world's region to share an > experience, > their "worn" assets (the only ones of > interest to the > region) will contain references to asset > services > spread widely across the Internet. �The > fetches by the > travelers' clients occur over many parallel > paths from > clients to asset services, so one can > reasonably > expect reduced network contention and > reduced asset > server loading because they are both spread > out over > however many asset services are being > referenced by > the overall set of assets in the region. > > This is very different to the case of a > proxying > region, which would get slammed for every > asset worn > by every avatar present. �In our current > architecture, > regions run many different CPU-intensive tasks, > including physics simulation and server-side > scripting, and absolutely cannot afford to > serve > assets too unless your scalability > requirements are > very low indeed, ie. just a few dozen > avatars of > today's kind. �We've hit the ceiling > already on region > scalability done that way. �There is > nowhere to go in > that direction at all beyond improving the > code like > Intel demonstrated, and that work is > subject to a law > of diminishing returns. > > This is why we have to go parallel, and I > think you're > wrong that it has to cost much money. �As > we spread > the load across more and more asset > services, we are > simply better utilizing all the hardware that's > already out there on the Internet, at least > in respect > of community and private resources. �But > add to the > community and private resources the > commercial asset > services that are likely to appear to > exploit this > opportunity, and not only will the number > of asset > services leap, but the power of each one > will rocket > too, because, after all, these businesses > will be > heavily optimized for the job. > > As to why a world would want clients to access > external asset services instead of > providing its own > implementation, that's an easy question. > �It costs > money to host a high performance and > scalable asset > service and a high bandwidth network to > handle the > traffic. �A *lot* of money. �In contrast, > it costs a > world nothing to let others serve the assets to > clients. �And that matters to the bottom line. > > > Morgaine. > > > > > ====================== > > On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis > > > > > >>> wrote: > > � �> As always though, it's a trade-off, > since the > proxied design > � �has very poor scalability compared to the > distributed one. > > � �I don't agree with that... If a user > enters a > highly populated > � �region, > � �every other client is going to (could > and should be > trying to) > � �hit the > � �asset server(s) for the assets that the > user is > wearing (assuming > � �they're not cached locally). �Every > asset server > has to be scaled up > � �to the point that it can handle that > load from all > over... > > � �If I'm hosting a region that supports 10s of > thousands of > � �simultaneous > � �users (thinking of the future), I > already have to > scale to meet that > � �demand. If the region is proxying the > assets, then, > yes the > � �region has > � �to be scaled to meet that asset demand > too, but it > already has to be > � �scaled to meet other demands of being a > region > server... and why is > � �scaling those asset proxy services hard? > �It's > going to cost $, > � �but is > � �not technically challenging. So, if I > want to host > a region like > � �that... sure it will cost me, but the > simulation > will be consistent > � �and users will be able to participate > equally, > regardless of the > � �capabilities of their individual asset > services. > > > > > � �On Fri, Apr 1, 2011 at 11:55 PM, Morgaine > � � > > > � � > > >>> wrote: > � �> Every design choice results in a > trade-off, > Vaughn, improving > � �one thing at > � �> the expense of something else. �If > every time we > offered a > � �service we had to > � �> inform its users about the downsides > of all the > trade-offs we > � �have made, > � �> they would have an awful lot to read. ;-) > � �> > � �> The specific trade-off that you are > discussing is no > � �different. �A region > � �> that proxies all content has the > "benefit" of > acquiring control > � �from the > � �> asset servers over the items in the > region, so > that it can > � �ensure that > � �> everyone in the region not only > obtains the items > but obtains > � �the same items > � �> as everyone else. �That does indeed > provide a > greater guarantee of > � �> consistency than a deployment in which > the region > only passes > � �asset URIs to > � �> clients who then fetch the items from > asset services > � �separately. �As always > � �> though, it's a trade-off, since the > proxied > design has very > � �poor scalability > � �> compared to the distributed one. > � �> > � �> If we're going to warn users of the > potential for > inconsistency > � �in the > � �> distributed deployment as you suggest, > are we > also going to > � �warn them of > � �> non-scalability in the proxied one? �I > really > don't see much > � �merit in the > � �> idea of warning about design choices. > �Many such > choices are > � �technical, and > � �> the issues are quite likely to be of > little > interest to > � �non-technical users > � �> anyway. �In any case, the better > services are > likely to provide > � �such > � �> information in their online > documentation, I > would guess. > � �> > � �> You mentioned users "voting with their > feet" or > choosing to > � �accept the risk > � �> of inconsistency. �Well that will > happen anyway, > when services > � �fail and > � �> users get annoyed. �If some asset > services refuse > to send the > � �requested > � �> items to some users, those services > will get a > bad reputation > � �and people > � �> will choose different asset services > instead. > �Likewise, if a > � �world service > � �> proxies everything and so it can't > handle a large > number of > � �assets or of > � �> people, users will get annoyed at the > lag and will go > � �elsewhere. �This user > � �> evaluation and "voting with their > feet" happens > already with > � �online services > � �> all over the Internet, and I am sure > that this > human process > � �will continue > � �> to work when the services are asset > and region > services. > � �> > � �> Back in September 2010, I wrote this > post which > proposes that > � �we use in > � �> VWRAP a form of asset addressing that > provides > massive > � �scalability at the > � �> same time as a very high degree of > resilience -- > � �> > � > > �http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html > � �. �It is > � �> based on the concept of the URI > containing a host > part and a > � �hash part, > � �> where the hash is generated (once, at > the time of > storage to > � �the asset > � �> service) using a specified digest > algorithm over > the content of > � �the asset > � �> being referenced. �You may wish to > note that if > this design > � �were used, the > � �> failure of an asset service to deliver a > requested item would > � �result in a > � �> failover request for the item to one > or more > backup services, > � �using the same > � �> hash part but with a different host > address. > � �> > � �> This can go some way towards > overcoming the > problem that you > � �think might > � �> occur when assets are fetched by > clients from > asset services > � �directly. > � �> Although it won't help when the > missing item is > available from > � �only a single > � �> asset service, it will help in many > other cases, > and it will > � �compensate for > � �> service failures and network outages > automatically at the same > � �time. > � �> > � �> PS. This design for hash-based asset > addressing > is already > � �being tested by > � �> Mojito Sorbet in her experimental > world and > client. �It would give > � �> VWRAP-based worlds an improved level > of service > availability, > � �so I think it > � �> should be a core feature of our protocol. > � �> > � �> > � �> Morgaine. > � �> > � �> > � �> > � �> > � �> =========================== > � �> > � �> On Fri, Apr 1, 2011 at 11:17 PM, > Vaughn Deluca > � � > > > > >>> > � �> wrote: > � �>> > � �>> This is a question i discussed with > Morgaine > off-list a while > � �ago (I > � �>> intended to send it to the list but > pushed the > wrong button...) I > � �>> think we need to address this > problem, and > decide how to deal > � �with it. > � �>> > � �>> �In Davids deployment draft, section > 7.3.1.1 an > overview is > � �given van > � �>> ways to deliver content to the > region. One way > is only passing a > � �>> capability that allows access to > (part of) the > resource: > � �>> > � �>> � � � � � 7.3.1.1. �Content delivery > models > � �>> � � � � � A range of possible > represenations can > be passed to > � �a region for > � �>> � � � � � simulation. [...] The other > end of the > delivery spectrum > � �>> involves passing > � �>> � � � � � only a URI or capability > used to > access the rendering > � �>> information and a > � �>> � � � � � collision mesh,and related > data for > physical simulation. > � �>> � � � � � In such a model, the client is > responsible for > � �fetching the > � �>> additional > � �>> � � � � � information needed to > render the > item's visual > � �presence from a > � �>> separate > � �>> � � � � � service. �This fetch can be > done > *under the > � �credentials of the > � �>> end user* > � �>> � � � � � viewing the material [my > emphasis--VD] > , and > � �divorces the > � �>> simulation from > � �>> � � � � � the trust chain needed to > manage > content. �Any > � �automation > � �>> is done on a > � �>> � � � � � separate host which the content > creator or owner trusts, > � �>> interacting with the > � �>> � � � � � object through remoted > interfaces. > � �>> > � �>> �I can see the need for such a setup, > however, i > feel we are > � �>> unpleasantly close to a situation > were the > coherence of the > � �simulation > � �>> falls apart. > � �>> In this deployment pattern the region > advertises > the presence > � �of the > � �>> asset, and *some* clients will be > able to get it > as expected, > � �while > � �>> -based on the arbitrary whims of the > asset > service- others > � �might not. > � �>> > � �>> My hope would be that after the asset > server > provides the > � �region with > � �>> the capability to get the asset, it > gives up > control. That > � �would mean > � �>> that if the client finds the > inventory server is > unwilling to > � �serve > � �>> the content - in spire of the region > saying it > is present-, > � �the client > � �>> should be able to turn around ask the > *region* > for the asset, > � �(and get > � �>> is after all). > � �>> > � �>> �If that is not the case, -and there are > probably good reasons > � �for the > � �>> deployment pattern as described- > �shouldn't we > *warn* clients > � �that the > � �>> region might be inconsistent, so the > users > behind the client > � �can vote > � �>> with their feet, (or take the risk)? > � �>> > � �>> --Vaughn > � �>> > _______________________________________________ > � �>> vwrap mailing list > � �>> vwrap@ietf.org > > > >> > > � �>> > https://www.ietf.org/mailman/listinfo/vwrap > � �> > � �> > � �> > _______________________________________________ > � �> vwrap mailing list > � �> vwrap@ietf.org > > > >> > > � �> > https://www.ietf.org/mailman/listinfo/vwrap > � �> > � �> > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > https://www.ietf.org/mailman/listinfo/vwrap > � > > > > > > -- --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, > Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > https://www.ietf.org/mailman/listinfo/vwrap > > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From carlo@alinoe.com Fri Apr 8 13:32:21 2011 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 5ECD43A696D for ; Fri, 8 Apr 2011 13:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 i0pvUA1Tx9l7 for ; Fri, 8 Apr 2011 13:32:20 -0700 (PDT) Received: from fep11.mx.upcmail.net (fep11.mx.upcmail.net [62.179.121.31]) by core3.amsl.com (Postfix) with ESMTP id 3E7E23A68CB for ; Fri, 8 Apr 2011 13:32:19 -0700 (PDT) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep11-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110408203404.NHWO17007.viefep11-int.chello.at@edge03.upcmail.net> for ; Fri, 8 Apr 2011 22:34:04 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge03.upcmail.net with edge id V8a21g02m0FlQed038a3zB; Fri, 08 Apr 2011 22:34:04 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q8INW-0005zl-H0 for vwrap@ietf.org; Fri, 08 Apr 2011 22:34:02 +0200 Date: Fri, 8 Apr 2011 22:34:02 +0200 From: Carlo Wood To: vwrap@ietf.org Message-ID: <20110408223402.36ae68a9@hikaru.localdomain> In-Reply-To: References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=vUpxTctd+kpWCBtSXXIkt5ll4Z8E5Qu9nLREXC/hfIo= c=1 sm=0 a=0X824X2hA4gA:10 a=_kSIUADMT0YA:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=BjFOTwK7AAAA:8 a=EJ7jBPDziFDvfpK0hCoA:9 a=Zvop8yFD0XLNKSG0BAIA:7 a=CjuIK1q_8ugA:10 a=bW3kdApBr58A:10 a=8EP8rFNXNEnfsmQk:21 a=xNZGKhOZSySOtt_M:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: [vwrap] Is 'Data Z' immutable (like a git snapshot)? 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, 08 Apr 2011 20:32:21 -0000 This is very nice work and I think it clarifies a lot. I have a few very basic questions. I see that you request Z from two different Asset servers (originally A, but also C when a backup has been stored there). No matter how you look at it, that is distributed storage: compare it with git or mercurial; if Z on A could be changed then the backup would be out dated, and that is not what we want. So, I conclude that 'Z' (or rather, then handle used to refer to Z when asking for it) therefore refers to a unmodifiable data (compare git's hex ID's that point to a snapshot). 1) Is that correct? If it is correct and the handle for Z used in messages like "give me a cap for Z" refer to immutable data, then the most logical thing to do would be to use a (large) hash value of the data (ie, md5) or an UUID that was generated when the data was last changed (which is less good because it would cause duplicated data when something is changed back to what it was before), or to use an ID that is less large, but whose uniqueness would be guaranteed by including a (for that authority unique) ID of the authority that made the last change. The advantage of the latter is less bandwidth (smaller ID's) and knowledge of the authority right into the ID of something (handy for routing). Disadvantages are: it suffers from the same as the UUID in that it will duplicate data whenever the same data is generated and it requires administration to make sure that every authority has a unique ID (compare giving people unique IP addresses). 2) Which of those is used? has, UUID or smaller specially crafted ID? 3) What would happen if someone gets a cap for Z, a modifiable object; then the object is modified and then the cap is used? Does the cap have a guaranteed life time? 4) If not every previous state of an object is kept eternally and after changing some object old caps (and their static data) disappear - then how will the asset servers that contain copies know that? They are not necessarily aware that anything changed at all for that object, so they can't know what the life time is. It seems that once you make a copy you are doomed to keep it forever or do garbage collection for assets that are never accessed anymore. 5) I can image that at SOME TIME in the future we want a few bit (or more) that ARE mutable-- despite that the asset ID (Z) refers to snapshot (immutable) data. Are we going to build into the protocol a provision for such mutable bits? This would mean, in the case that the ID is a hash (ie md5) that the asset Data exists of a payload that the hash is taken over plus a mutable part that is not considered for the hash. Obviously, such data then could get desynced between assets servers with copies. -- Carlo Wood From morgaine.dinova@googlemail.com Fri Apr 8 16:16:33 2011 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 C32793A6905 for ; Fri, 8 Apr 2011 16:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.988 X-Spam-Level: X-Spam-Status: No, score=-0.988 tagged_above=-999 required=5 tests=[AWL=-1.626, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] 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 R844+DN3Khmx for ; Fri, 8 Apr 2011 16:16:27 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id DAC4A3A67CC for ; Fri, 8 Apr 2011 16:16:26 -0700 (PDT) Received: by qwc23 with SMTP id 23so2907597qwc.31 for ; Fri, 08 Apr 2011 16:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IoQx3ucOG7Vx2CZGzvse0ahZ5mTE5Yn5DXW6s3MMpT0=; b=ITTitbZdX9mMBqCYOQ3CJL7R+9zH91Jm5yAXQPNNQrW8vsM8ofsUdl++JIiWfv/tk/ TTlI+m4z/VYjpPXfe6DtH3+d7pbd0r84YV/otyCDIWUqLWldU2ZLcEV729KMqCvQYvJo OL8azOl69mGlGz75ZA7sOQC2iWCxOiLmbTvI4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HXRB5Wbpi0+ae7UibUFw/gP6MatLHW9UjGerlQtrffFe1djl76qyEmWdx0JicuWuge 4dCr0BslnQOE+CAF2iXI7ZzTJTwnEtzOngI0khH+20oZwraM/mCAYPgHcQIz2dZ9HoNR i30Eox55RmWJGUrugwe8D+p6hfeh5LeOj3UxY= MIME-Version: 1.0 Received: by 10.229.105.82 with SMTP id s18mr2364170qco.109.1302304691830; Fri, 08 Apr 2011 16:18:11 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Fri, 8 Apr 2011 16:18:11 -0700 (PDT) In-Reply-To: References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> Date: Sat, 9 Apr 2011 00:18:11 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=002354470e608bc08c04a07070ab Subject: Re: [vwrap] [wvrap] Simulation consistency 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, 08 Apr 2011 23:16:34 -0000 --002354470e608bc08c04a07070ab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Excellent work, Vaughn! You're right, I am working on something related to this, specifically a design study for the Tourism use case. It happens to end with a protocol sequence diagram presented as a table of text, so I was very pleased to see your highly relevant diagram. Yours captures part of my use case, and it's a lot prettier than my text format. :P I was particularly impressed by the way you start off with completely separable services right from the start. Since separable services can be put together under a single administrative domain very easily, whereas separating conjoined services is not easy at all, I think you've started this off perfectly for the VWRAP approach to services. Because you have separated the services so well, your suggested protocol flow could be said to to be targeting some kind of "*superset of all VWRAP deployments*" deployment. :-) Although it's logically structured, it's a sort of worst-case scenario (or lawyer's delight) in which everyone has to ask everyone else for permission to do anything, regardless of whether permission is actually required or not. That's viable, but less than optimal. Specifically, you are working to the principle of "The heaviest burden required by anyone must be borne by everyone." I have been trying to stick to the opposite principle of "A burden should be borne only by those whose use case requires it", which is both fairer and more efficient. To illustrate this, consider the case of an asset service which serves (by choice) only Creative Commons licensed assets --- an extremely important us= e case which could well become the dominant one in an open metaverse of community worlds. Who knows, it could be operated by Debian, or Blender, o= r OSgrid, or even Google Warehouse. :P In such a scenario, because the license on all the assets in the asset service permits unchecked distribution to all destinations in perpetuity, the vast majority of all the request-grant protocol flows in your diagram are superfluous when the assets come from this repository. By using a protocol which understands *WHEN* it needs to ask a question, a large amoun= t of cumulative round-trip time latency (and its resulting lag) can be avoide= d entirely. This is also true on a per-asset basis if an asset service serve= s a mixture of encumbered and freely distributable assets, except that then the difference would be seen per-asset instead of per asset service. For such freely distributable assets, the agent service doesn't need to do anything at all beyond recording the addresses of assets which are currentl= y being worn by the agent. Since you start off your trip (sensibly) by checking your clothing at home before you leave, you'll notice a broken asset service locally anyway since your viewer will be trying to fetch it for local viewing. The agent service need do nothing at all, beyond record the addresses of top level items. (In my design study, I refer to a *Worn Assets List *which is held by the user's agent service, and which is entirely separate from any concept of inventory.) Likewise, region services don't need to fetch the graphic assets normally either (unless they opt to proxy them), but only pass the addresses of thos= e assets around to all the other agents in the corresponding region, so the request-grant exchanges between regions and asset services can be avoided i= n this case. (Regions will be requesting other server-side data though, for example the bounding box information or collision mesh of an asset, which typically the viewer would not be fetching.) That's not the end of the "*no unnecessary burden*" issue yet though, because even if you removed all the unnecessary request-grant protocol flows, you're still making the incorrect assumption that assets *ALL NEED T= O BE RESTRICTED* by the mere fact of asking for caps to everything. This itself is wrong. The logic need to first determine whether a cap is needed for fetching a given asset, and if it's not needed then the fetch can be done by the viewer or region without this protocol burden at all. So you see, there is a fundamental assumption in your nicely laid out flows that all assets must be tied up in heavy red tape by the needs of the most burdensome use case. I don't agree with that, neither on principle nor on engineering grounds. Many of the flows you have shown are exactly what we need for securing access to proprietary resources, but not all resources have that burden, an= d I would want to elide a number of the flows away entirely when an asset service allows it. To put it another way, the data is king, and protocol flows should reflect the requirements imposed by data, not the other way around. I need this expressed in your flows, possibly as asset requirement annotations. PS. Great work Vaughn, I think this gives us a wonderful launching point! Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Fri, Apr 8, 2011 at 5:40 PM, Vaughn Deluca wrot= e: > VWRAP services high level message flow (preliminary diagram draft) see > > > http://trac.tools.ietf.org/wg/vwrap/trac/attachment/wiki/Diagrams/VWRAP_F= lowExample_VD1.pdf > > The main reason that i am submitting this in spite of my lack of formal > expertise is that the group in my view badly needs a solid basis for > discussion and preventing endless repeating loops. This example is probab= ly > wrong in many ways, but its better than what we have publicly available o= n > interop now (although Morgaine is working on something along the lines of > the recent discussions here) > > I hope this diagram will give us a base for discussion. I could have done > my homework better by researching the old OGP stuff in more depth, and i > probably will do so in the future , but for now I just tried to followed > the general principles as far as i understand them, to see what response > that yields from the group. In other words,I try to let the group educate= me > :p > > Note that in my view all services are equal, in principle it does not > matter in what "domain" they run, since trust and policy are fully > localized. It is however very possible to have internal shortcuts in the > services to speed up processing. > > In the example I opted for an external Agent service, but I could as well > have incorporated that in the set of local services. As indicated above a= ll > services could also be run by different organisations, true to what VWRAP > stands for. Its all up to the deployer, including a user at home who migh= t > want to run a full world for family and friends. Those friends might try = to > use that agent service to venture out in the virtual universe. > I envision that the final identity provider is external, using OpenID an= d > OAut or whatever other magic that I do not yet fully understand exists = out > there. > > The example has 3 main purposes: > - Provide a reference for discussion > - Illustrates the use case of tourism, and *true* interop. > - Illustrate consistency problems along the lines discussed here higher = up > in this tread, as well as the "slashdot" problem that Morgaine outlined s= o > clearly. > > The message flow assumes an avatar already present in some region, (a sma= ll > scale local home region in this case, but that is by no means essential, = it > could be a build in region in the viewer or a big commercial region). The > user is preparing for a trip to immersive world, and after some outfit > adjustments moves over. > > Finally i apologize for for the simplistic notation used here. I simply a= dd > the most relevant parameters passed in square brackets to a keyword > specifying the nature of the message. Please improve on that where needed= . > > So here we go, the avatar is prepare for a visit to "immersive world" > 0) Viewer, here is an update of the state of the world your agent is in, > please render. > 1) Agent service, I will go in my Zodiac dress that i keep in the > "Amazing assets" service. > 2) Asset service A, please send a cap for Z, here are my credentials > 3) Your fine, here is the cap > 4) Local region, can you please put this on my agent, i included the cap= . > 5) Hello asset service A, i need Z, here is the cap > 6) Cap is good, data coming up, have fun. > 7) Agent service, your agent is now wearing Z > 8) Viewer, your avatar is now wearing Z > User: Hmm, amazing inventory has not been *that* amazing lately. 'll > make a backup, just in case > 9) Hello asset service A, please send me a cap for Z, here are my > credentials > 10) Your fine, here is the cap > 11) Local asset storage, please store Z for me, here is the cap to get it > 12) Hello asset service A, i want Z, here is the cap > 13) Cap is good, data coming up, have fun. > 14) Viewer, Z is now stored for you > User: I am Ready!, Lets try to get to immersive world! > 15) Hello immersive world, can i get in? Here are my credentials, and a > list of my stuff. > 16) Asset service A, please send me a cap for X, here are my credentials = (I > want this cap for consistency) > 17) Your fine, here is the cap > 18) Asset service B, please send me a cap for Y, here are my credentials = (I > want this cap for consistency) > 19) Very sorry, but your not one of us, you can't have Y > 20) Asset service B, please send me a cap for Z, here are my credentials = (I > want a cap for consistency) > [Region service: Timeout... amazing inventory must be overloaded.. oh > well... ] > 21) Agent service, you wanted to send somebody over, here are your > permissions. > 22) Viewer, you asked for a transfer try, here are your results > User thinks: Crap! Big asset service does not allow me to take my > yellow stockings! And Amazing assets failed to deliver my zodiac dress. = At > least i made a backup of that dress! > 23) 'll take the yellow stockings off... > 24) ... done ('ll trash them here and now, forever, who needs stuff you > can't use!) > 25) The zodiac dress was not delivered by Big assets service, but i have = a > local copy! > 26) Local Asset service, please send me Z, here are my credentials > 27) I dont know you, but I 'll trust you, here is the cap, but you better > store the data, its single use, i need to protect myself. > 28) Local region, can you please put this on my agent, i include the cap. > 29) Local Asset service, i need Z, here is the cap > 30) Cap is good, data coming up, have fun. > 31) Cap was only good for one time, I made a copy, but my policy is to on= ly > grant you fair use rights, at a later time i might even tell you to repla= ce > the dress. > 32) Viewer, you can wear Z for now, but the asset service granted only fa= ir > use, i might ask you to replace the dress at a later time. > 33) Ready at last! Off to immersive world!, I hope its not to crowded the= re > or 'll loose my dress... > 34) Hello immersive world, here are my credentials, and a list of stuff i > want to bring > 35) Hello asset service A, please send me a cap for X, here are my > credentials > [darn, I should have kept that cap from last time..] > 36) Your fine, here is the cap. > [Region service finds fair-use warning on Z and decides to make its ow= n > copy] > 37) Hello Local region, can i still have Z? Here is the cap > 38) Cap is still good, data coming up, have fun. > [Region service stores asset in private storage, providing a cap to > replace the fair use one] > 39) Agent service, you wanted to send somebody over, here are your > permissions & info. > 40) Hello immersive world, just get me there, and use what you can > 41) Placement done, Z is currently buffered by us as wel, you need to get > details for X, have fun. > 42) You are now in immersive world, your dress is buffered there as well, > but you need to get X! > 43) Hello asset service A, i want X, here is the cap > 44) Cap is good, data coming up, have fun. > 45) Viewer, here is an update of the state of the world your agent is in, > please render. > > As far as I can see this conforms fully to our charter, and i hope it is > possible to use large portions of the existing code bases. However, as sa= id > above, i did not really try to capture the old thinking, and I also might > have misconceptions about the way to do these things in general. > Looking forward to constructive comments. > > -- Vaughn > > On Sun, Apr 3, 2011 at 8:38 PM, Vaughn Deluca wr= ote: > >> Thanks for the pointers. I have a busy week in RL in front of me, so i >> wont have to much time to respond the next few days, however, i intend t= o >> start doing the following things: >> >> - Produce a visual that reflects my thinking, i.e. an illustration of my >> response to Morgaine's itemlist above. >> - Read up on the older notes, as well as more reading in the list archi= ve >> - Try to make a summary for the wiki >> >> Regarding the use of domain, I think services are eventually what counts= , >> but its all terminology. The way I read the AWG diagrams is that the age= nt >> domain is actually a cluster of tightly integrated services. When the >> functionality of each sub-service is described properly and with uniform >> interfaces the domain will slowly dissolve. But let not get ahead of out >> selfs. We should put up some clear descriptions on the wiki for our view= s on >> this, and *after* that we can decide what we need and what can go. >> >> Its been a very useful and illuminating weekend for me, and i am a lot >> more optimistic about the future of vwrap than two weeks ago. >> >> -- Vaughn >> >> >> >> On Sun, Apr 3, 2011 at 7:20 PM, Dzonatas Sol wrote: >> >>> Probably easy as suggested in other terms here on this list, as how the >>> client contacts the asset services now in the regions. The newer issue = is to >>> unitize that asset services. Since their is proprietary (legacy) code t= hen >>> we can't expect that to change, and some form of proxy is of need. What= ever >>> works best, I tried to narrow it down to suggestions here. >>> >>> Eventually, the agent domain is ideal to handle the direction of the >>> asset services. This concept, unfortunately, ended support awhile ago w= ith >>> changes in LL. >>> Also see; http://wiki.secondlife.com/wiki/Agent_Domain >>> And: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset (warn: >>> unstructured collaborative notes, dumped on me and I tried to fix) >>> >>> I tried to find previous visuals. >>> >>> I'd imagine the agent domain could grow out of unitized versions of ass= et >>> services. Despite that, I think that concept helps view where we were a= t in >>> discussion and what didn't happen. >>> >>> Vaughn Deluca wrote: >>> >>>> Hi=EF=BF=BDDzonatas >>>> >>>> Can you expand on that, what would be needed for legacy support in VWA= P >>>> terms=EF=BF=BD?, >>>> If i want to read up on how the=EF=BF=BDasset server may proxy the sim= ulator, >>>> what would you recommend me to read? >>>> >>>> -- Vaughn >>>> >>>> On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol >>> dzonatas@gmail.com>> wrote: >>>> >>>> Some stated the proxy-to-asset-server is built into the sim; >>>> however, keep in mind possible legacy support where the asset >>>> server may proxy the simulator. >>>> >>>> >>>> Dzonatas Sol wrote: >>>> >>>> Somehow I feel the basic asset server being able to login and >>>> download assets is now priority, yet I also wondered the best >>>> way to patch this into the current mode of viewers. >>>> >>>> Maybe offer (1) by proxy (sim-side) and (2) by patch >>>> (viewer-side) that either of these two are optional and >>>> neither are mandatory for now. Thoughts? >>>> >>>> Israel Alanis wrote: >>>> >>>> >>>> > when designing for scalability, the model to bear in >>>> mind is ... >>>> >>>> Well, there are a lot of different models to keep in mind, >>>> and many different use cases. One particular use case to >>>> keep in mind is: "User acquires new outfit, and wants to >>>> 'show it off' in a highly populated region". >>>> >>>> > Both worlds and asset services may include commercial, >>>> community, and personal services >>>> >>>> Yes, yes and yes. I'm particularly concerned about how the >>>> model affects the ability to host personal asset services. >>>> >>>> > a proxying region, which would get slammed for every >>>> asset worn by every avatar present. >>>> >>>> Granted the collection of services that are provided by >>>> the region need to be scaled to meet the demands of that >>>> region. That's all part of capacity planning. >>>> >>>> > regions run many different CPU-intensive tasks, >>>> including physics simulation and server-side scripting, >>>> and absolutely cannot afford to serve assets too >>>> Well... who said the same CPU's have to do proxying, >>>> physics simulation and server-side scripting? Asset >>>> proxying is a different service than physics simulation >>>> and can be on separate hardware, could make use of >>>> geographically distributed caching, and in certain >>>> deployment patterns, the same caching services could be >>>> shared by different regions. (Server-side scripting is a >>>> discussion for another day). >>>> >>>> > This is why we have to go parallel... >>>> >>>> Totally agree, and a proxying model could and should also >>>> take advantage of parallelism. >>>> >>>> > I think you're wrong that it has to cost much money. ?vs? >>>> > It costs money to host a high performance and scalable >>>> asset service and a high bandwidth network to handle the >>>> traffic. =EF=BF=BDA *lot* of money. >>>> I think what you're saying is: "It costs a lot of money to >>>> build a scalable asset service, but if assets are spread >>>> throughout the internet they don't have to be scalable." >>>> But that's not quite right. You're opening up every asset >>>> server to the VW equivalent of being slashdotted, so are >>>> you sure you're not forcing *every* asset service to be >>>> scalable and handle a lot of bandwith and network traffic? >>>> It's the exact opposite of your intention, but I think >>>> that's the result, all the same. >>>> >>>> This particular design decision has a big effect on the >>>> economics of the VW infrastructure. I'd rather the >>>> economics to work out such that a region provider who >>>> wishes to build a region that supports a small population, >>>> can do so economically. A region that wants to host a >>>> *large* population has to bear that cost of providing that >>>> scalable asset service. >>>> I want the economics of hosting a small asset service to >>>> be a non-issue (as to best promote creation and >>>> creativity). Creating a high bar to provide asset services >>>> will mean that service will cost money and people >>>> shouldn't have to pay money just to create or own VW >>>> objects (I'm using 'own' here to refer to maintaining >>>> their existence, I'm not trying to make a >>>> 'leftist'/'communist' statement about ownership ;) >>>> >>>> - Izzy >>>> >>>> >>>> On Apr 2, 2011, at 3:58 PM, Morgaine wrote: >>>> >>>> Izzy, when designing for scalability, the model to >>>> bear in mind is that of seasoned virtual world >>>> travelers whose inventories contain assets from many >>>> different worlds, those assets being served by many >>>> different asset services. =EF=BF=BDBoth worlds and asse= t >>>> services may include commercial, community, and >>>> personal services, and as the metaverse grows, that >>>> set is highly likely to become progressively less >>>> clustered and more diverse. >>>> >>>> When those seasoned travelers click on an advertised >>>> VW link and perform an inter-world teleport to one >>>> particular world's region to share an experience, >>>> their "worn" assets (the only ones of interest to the >>>> region) will contain references to asset services >>>> spread widely across the Internet. =EF=BF=BDThe fetches= by the >>>> travelers' clients occur over many parallel paths from >>>> clients to asset services, so one can reasonably >>>> expect reduced network contention and reduced asset >>>> server loading because they are both spread out over >>>> however many asset services are being referenced by >>>> the overall set of assets in the region. >>>> >>>> This is very different to the case of a proxying >>>> region, which would get slammed for every asset worn >>>> by every avatar present. =EF=BF=BDIn our current archit= ecture, >>>> regions run many different CPU-intensive tasks, >>>> including physics simulation and server-side >>>> scripting, and absolutely cannot afford to serve >>>> assets too unless your scalability requirements are >>>> very low indeed, ie. just a few dozen avatars of >>>> today's kind. =EF=BF=BDWe've hit the ceiling already on= region >>>> scalability done that way. =EF=BF=BDThere is nowhere to= go in >>>> that direction at all beyond improving the code like >>>> Intel demonstrated, and that work is subject to a law >>>> of diminishing returns. >>>> >>>> This is why we have to go parallel, and I think you're >>>> wrong that it has to cost much money. =EF=BF=BDAs we sp= read >>>> the load across more and more asset services, we are >>>> simply better utilizing all the hardware that's >>>> already out there on the Internet, at least in respect >>>> of community and private resources. =EF=BF=BDBut add to= the >>>> community and private resources the commercial asset >>>> services that are likely to appear to exploit this >>>> opportunity, and not only will the number of asset >>>> services leap, but the power of each one will rocket >>>> too, because, after all, these businesses will be >>>> heavily optimized for the job. >>>> >>>> As to why a world would want clients to access >>>> external asset services instead of providing its own >>>> implementation, that's an easy question. =EF=BF=BDIt co= sts >>>> money to host a high performance and scalable asset >>>> service and a high bandwidth network to handle the >>>> traffic. =EF=BF=BDA *lot* of money. =EF=BF=BDIn contras= t, it costs a >>>> world nothing to let others serve the assets to >>>> clients. =EF=BF=BDAnd that matters to the bottom line. >>>> >>>> >>>> Morgaine. >>>> >>>> >>>> >>>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>> >>>> On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis >>>> >>>> >>> >>>> >> wrote: >>>> >>>> =EF=BF=BD =EF=BF=BD> As always though, it's a trade-off= , since the >>>> proxied design >>>> =EF=BF=BD =EF=BF=BDhas very poor scalability compared t= o the >>>> distributed one. >>>> >>>> =EF=BF=BD =EF=BF=BDI don't agree with that... If a user= enters a >>>> highly populated >>>> =EF=BF=BD =EF=BF=BDregion, >>>> =EF=BF=BD =EF=BF=BDevery other client is going to (coul= d and should be >>>> trying to) >>>> =EF=BF=BD =EF=BF=BDhit the >>>> =EF=BF=BD =EF=BF=BDasset server(s) for the assets that = the user is >>>> wearing (assuming >>>> =EF=BF=BD =EF=BF=BDthey're not cached locally). =EF=BF= =BDEvery asset server >>>> has to be scaled up >>>> =EF=BF=BD =EF=BF=BDto the point that it can handle that= load from all >>>> over... >>>> >>>> =EF=BF=BD =EF=BF=BDIf I'm hosting a region that support= s 10s of >>>> thousands of >>>> =EF=BF=BD =EF=BF=BDsimultaneous >>>> =EF=BF=BD =EF=BF=BDusers (thinking of the future), I al= ready have to >>>> scale to meet that >>>> =EF=BF=BD =EF=BF=BDdemand. If the region is proxying th= e assets, then, >>>> yes the >>>> =EF=BF=BD =EF=BF=BDregion has >>>> =EF=BF=BD =EF=BF=BDto be scaled to meet that asset dema= nd too, but it >>>> already has to be >>>> =EF=BF=BD =EF=BF=BDscaled to meet other demands of bein= g a region >>>> server... and why is >>>> =EF=BF=BD =EF=BF=BDscaling those asset proxy services h= ard? =EF=BF=BDIt's >>>> going to cost $, >>>> =EF=BF=BD =EF=BF=BDbut is >>>> =EF=BF=BD =EF=BF=BDnot technically challenging. So, if = I want to host >>>> a region like >>>> =EF=BF=BD =EF=BF=BDthat... sure it will cost me, but th= e simulation >>>> will be consistent >>>> =EF=BF=BD =EF=BF=BDand users will be able to participat= e equally, >>>> regardless of the >>>> =EF=BF=BD =EF=BF=BDcapabilities of their individual ass= et services. >>>> >>>> >>>> >>>> >>>> =EF=BF=BD =EF=BF=BDOn Fri, Apr 1, 2011 at 11:55 PM, Mor= gaine >>>> =EF=BF=BD =EF=BF=BD>>> >>>> =EF=BF=BD =EF=BF=BD>>> >>>> >> wrote: >>>> =EF=BF=BD =EF=BF=BD> Every design choice results in a t= rade-off, >>>> Vaughn, improving >>>> =EF=BF=BD =EF=BF=BDone thing at >>>> =EF=BF=BD =EF=BF=BD> the expense of something else. =EF= =BF=BDIf every time we >>>> offered a >>>> =EF=BF=BD =EF=BF=BDservice we had to >>>> =EF=BF=BD =EF=BF=BD> inform its users about the downsid= es of all the >>>> trade-offs we >>>> =EF=BF=BD =EF=BF=BDhave made, >>>> =EF=BF=BD =EF=BF=BD> they would have an awful lot to re= ad. ;-) >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> The specific trade-off that you ar= e discussing is no >>>> =EF=BF=BD =EF=BF=BDdifferent. =EF=BF=BDA region >>>> =EF=BF=BD =EF=BF=BD> that proxies all content has the "= benefit" of >>>> acquiring control >>>> =EF=BF=BD =EF=BF=BDfrom the >>>> =EF=BF=BD =EF=BF=BD> asset servers over the items in th= e region, so >>>> that it can >>>> =EF=BF=BD =EF=BF=BDensure that >>>> =EF=BF=BD =EF=BF=BD> everyone in the region not only ob= tains the items >>>> but obtains >>>> =EF=BF=BD =EF=BF=BDthe same items >>>> =EF=BF=BD =EF=BF=BD> as everyone else. =EF=BF=BDThat do= es indeed provide a >>>> greater guarantee of >>>> =EF=BF=BD =EF=BF=BD> consistency than a deployment in w= hich the region >>>> only passes >>>> =EF=BF=BD =EF=BF=BDasset URIs to >>>> =EF=BF=BD =EF=BF=BD> clients who then fetch the items f= rom asset services >>>> =EF=BF=BD =EF=BF=BDseparately. =EF=BF=BDAs always >>>> =EF=BF=BD =EF=BF=BD> though, it's a trade-off, since th= e proxied >>>> design has very >>>> =EF=BF=BD =EF=BF=BDpoor scalability >>>> =EF=BF=BD =EF=BF=BD> compared to the distributed one. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> If we're going to warn users of th= e potential for >>>> inconsistency >>>> =EF=BF=BD =EF=BF=BDin the >>>> =EF=BF=BD =EF=BF=BD> distributed deployment as you sugg= est, are we >>>> also going to >>>> =EF=BF=BD =EF=BF=BDwarn them of >>>> =EF=BF=BD =EF=BF=BD> non-scalability in the proxied one= ? =EF=BF=BDI really >>>> don't see much >>>> =EF=BF=BD =EF=BF=BDmerit in the >>>> =EF=BF=BD =EF=BF=BD> idea of warning about design choic= es. =EF=BF=BDMany such >>>> choices are >>>> =EF=BF=BD =EF=BF=BDtechnical, and >>>> =EF=BF=BD =EF=BF=BD> the issues are quite likely to be = of little >>>> interest to >>>> =EF=BF=BD =EF=BF=BDnon-technical users >>>> =EF=BF=BD =EF=BF=BD> anyway. =EF=BF=BDIn any case, the = better services are >>>> likely to provide >>>> =EF=BF=BD =EF=BF=BDsuch >>>> =EF=BF=BD =EF=BF=BD> information in their online docume= ntation, I >>>> would guess. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> You mentioned users "voting with t= heir feet" or >>>> choosing to >>>> =EF=BF=BD =EF=BF=BDaccept the risk >>>> =EF=BF=BD =EF=BF=BD> of inconsistency. =EF=BF=BDWell th= at will happen anyway, >>>> when services >>>> =EF=BF=BD =EF=BF=BDfail and >>>> =EF=BF=BD =EF=BF=BD> users get annoyed. =EF=BF=BDIf som= e asset services refuse >>>> to send the >>>> =EF=BF=BD =EF=BF=BDrequested >>>> =EF=BF=BD =EF=BF=BD> items to some users, those service= s will get a >>>> bad reputation >>>> =EF=BF=BD =EF=BF=BDand people >>>> =EF=BF=BD =EF=BF=BD> will choose different asset servic= es instead. >>>> =EF=BF=BDLikewise, if a >>>> =EF=BF=BD =EF=BF=BDworld service >>>> =EF=BF=BD =EF=BF=BD> proxies everything and so it can't= handle a large >>>> number of >>>> =EF=BF=BD =EF=BF=BDassets or of >>>> =EF=BF=BD =EF=BF=BD> people, users will get annoyed at = the lag and will >>>> go >>>> =EF=BF=BD =EF=BF=BDelsewhere. =EF=BF=BDThis user >>>> =EF=BF=BD =EF=BF=BD> evaluation and "voting with their = feet" happens >>>> already with >>>> =EF=BF=BD =EF=BF=BDonline services >>>> =EF=BF=BD =EF=BF=BD> all over the Internet, and I am su= re that this >>>> human process >>>> =EF=BF=BD =EF=BF=BDwill continue >>>> =EF=BF=BD =EF=BF=BD> to work when the services are asse= t and region >>>> services. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> Back in September 2010, I wrote th= is post which >>>> proposes that >>>> =EF=BF=BD =EF=BF=BDwe use in >>>> =EF=BF=BD =EF=BF=BD> VWRAP a form of asset addressing t= hat provides >>>> massive >>>> =EF=BF=BD =EF=BF=BDscalability at the >>>> =EF=BF=BD =EF=BF=BD> same time as a very high degree of= resilience -- >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD >>>> =EF=BF=BD >>>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >>>> =EF=BF=BD =EF=BF=BD. =EF=BF=BDIt is >>>> =EF=BF=BD =EF=BF=BD> based on the concept of the URI co= ntaining a host >>>> part and a >>>> =EF=BF=BD =EF=BF=BDhash part, >>>> =EF=BF=BD =EF=BF=BD> where the hash is generated (once,= at the time of >>>> storage to >>>> =EF=BF=BD =EF=BF=BDthe asset >>>> =EF=BF=BD =EF=BF=BD> service) using a specified digest = algorithm over >>>> the content of >>>> =EF=BF=BD =EF=BF=BDthe asset >>>> =EF=BF=BD =EF=BF=BD> being referenced. =EF=BF=BDYou may= wish to note that if >>>> this design >>>> =EF=BF=BD =EF=BF=BDwere used, the >>>> =EF=BF=BD =EF=BF=BD> failure of an asset service to del= iver a >>>> requested item would >>>> =EF=BF=BD =EF=BF=BDresult in a >>>> =EF=BF=BD =EF=BF=BD> failover request for the item to o= ne or more >>>> backup services, >>>> =EF=BF=BD =EF=BF=BDusing the same >>>> =EF=BF=BD =EF=BF=BD> hash part but with a different hos= t address. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> This can go some way towards overc= oming the >>>> problem that you >>>> =EF=BF=BD =EF=BF=BDthink might >>>> =EF=BF=BD =EF=BF=BD> occur when assets are fetched by c= lients from >>>> asset services >>>> =EF=BF=BD =EF=BF=BDdirectly. >>>> =EF=BF=BD =EF=BF=BD> Although it won't help when the mi= ssing item is >>>> available from >>>> =EF=BF=BD =EF=BF=BDonly a single >>>> =EF=BF=BD =EF=BF=BD> asset service, it will help in man= y other cases, >>>> and it will >>>> =EF=BF=BD =EF=BF=BDcompensate for >>>> =EF=BF=BD =EF=BF=BD> service failures and network outag= es >>>> automatically at the same >>>> =EF=BF=BD =EF=BF=BDtime. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> PS. This design for hash-based ass= et addressing >>>> is already >>>> =EF=BF=BD =EF=BF=BDbeing tested by >>>> =EF=BF=BD =EF=BF=BD> Mojito Sorbet in her experimental = world and >>>> client. =EF=BF=BDIt would give >>>> =EF=BF=BD =EF=BF=BD> VWRAP-based worlds an improved lev= el of service >>>> availability, >>>> =EF=BF=BD =EF=BF=BDso I think it >>>> =EF=BF=BD =EF=BF=BD> should be a core feature of our pr= otocol. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> Morgaine. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> =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 >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> On Fri, Apr 1, 2011 at 11:17 PM, V= aughn Deluca >>>> =EF=BF=BD =EF=BF=BD>>> >>>> >>> >> >>>> =EF=BF=BD =EF=BF=BD> wrote: >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> This is a question i discussed wi= th Morgaine >>>> off-list a while >>>> =EF=BF=BD =EF=BF=BDago (I >>>> =EF=BF=BD =EF=BF=BD>> intended to send it to the list b= ut pushed the >>>> wrong button...) I >>>> =EF=BF=BD =EF=BF=BD>> think we need to address this pro= blem, and >>>> decide how to deal >>>> =EF=BF=BD =EF=BF=BDwith it. >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDIn Davids deployment dra= ft, section 7.3.1.1 an >>>> overview is >>>> =EF=BF=BD =EF=BF=BDgiven van >>>> =EF=BF=BD =EF=BF=BD>> ways to deliver content to the re= gion. One way >>>> is only passing a >>>> =EF=BF=BD =EF=BF=BD>> capability that allows access to = (part of) the >>>> resource: >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD 7.3.1.1. =EF=BF=BDContent delivery models >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD A range of possible represenations can >>>> be passed to >>>> =EF=BF=BD =EF=BF=BDa region for >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD simulation. [...] The other end of the >>>> delivery spectrum >>>> =EF=BF=BD =EF=BF=BD>> involves passing >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD only a URI or capability used to >>>> access the rendering >>>> =EF=BF=BD =EF=BF=BD>> information and a >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD collision mesh,and related data for >>>> physical simulation. >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD In such a model, the client is >>>> responsible for >>>> =EF=BF=BD =EF=BF=BDfetching the >>>> =EF=BF=BD =EF=BF=BD>> additional >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD information needed to render the >>>> item's visual >>>> =EF=BF=BD =EF=BF=BDpresence from a >>>> =EF=BF=BD =EF=BF=BD>> separate >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD service. =EF=BF=BDThis fetch can be done >>>> *under the >>>> =EF=BF=BD =EF=BF=BDcredentials of the >>>> =EF=BF=BD =EF=BF=BD>> end user* >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD viewing the material [my emphasis--VD] >>>> , and >>>> =EF=BF=BD =EF=BF=BDdivorces the >>>> =EF=BF=BD =EF=BF=BD>> simulation from >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD the trust chain needed to manage >>>> content. =EF=BF=BDAny >>>> =EF=BF=BD =EF=BF=BDautomation >>>> =EF=BF=BD =EF=BF=BD>> is done on a >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD separate host which the content >>>> creator or owner trusts, >>>> =EF=BF=BD =EF=BF=BD>> interacting with the >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF= =BF=BD =EF=BF=BD object through remoted interfaces. >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDI can see the need for s= uch a setup, however, i >>>> feel we are >>>> =EF=BF=BD =EF=BF=BD>> unpleasantly close to a situation= were the >>>> coherence of the >>>> =EF=BF=BD =EF=BF=BDsimulation >>>> =EF=BF=BD =EF=BF=BD>> falls apart. >>>> =EF=BF=BD =EF=BF=BD>> In this deployment pattern the re= gion advertises >>>> the presence >>>> =EF=BF=BD =EF=BF=BDof the >>>> =EF=BF=BD =EF=BF=BD>> asset, and *some* clients will be= able to get it >>>> as expected, >>>> =EF=BF=BD =EF=BF=BDwhile >>>> =EF=BF=BD =EF=BF=BD>> -based on the arbitrary whims of = the asset >>>> service- others >>>> =EF=BF=BD =EF=BF=BDmight not. >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> My hope would be that after the a= sset server >>>> provides the >>>> =EF=BF=BD =EF=BF=BDregion with >>>> =EF=BF=BD =EF=BF=BD>> the capability to get the asset, = it gives up >>>> control. That >>>> =EF=BF=BD =EF=BF=BDwould mean >>>> =EF=BF=BD =EF=BF=BD>> that if the client finds the inve= ntory server is >>>> unwilling to >>>> =EF=BF=BD =EF=BF=BDserve >>>> =EF=BF=BD =EF=BF=BD>> the content - in spire of the reg= ion saying it >>>> is present-, >>>> =EF=BF=BD =EF=BF=BDthe client >>>> =EF=BF=BD =EF=BF=BD>> should be able to turn around ask= the *region* >>>> for the asset, >>>> =EF=BF=BD =EF=BF=BD(and get >>>> =EF=BF=BD =EF=BF=BD>> is after all). >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDIf that is not the case,= -and there are >>>> probably good reasons >>>> =EF=BF=BD =EF=BF=BDfor the >>>> =EF=BF=BD =EF=BF=BD>> deployment pattern as described- = =EF=BF=BDshouldn't we >>>> *warn* clients >>>> =EF=BF=BD =EF=BF=BDthat the >>>> =EF=BF=BD =EF=BF=BD>> region might be inconsistent, so = the users >>>> behind the client >>>> =EF=BF=BD =EF=BF=BDcan vote >>>> =EF=BF=BD =EF=BF=BD>> with their feet, (or take the ris= k)? >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> --Vaughn >>>> =EF=BF=BD =EF=BF=BD>> _________________________________= ______________ >>>> =EF=BF=BD =EF=BF=BD>> vwrap mailing list >>>> =EF=BF=BD =EF=BF=BD>> vwrap@ietf.org >>>> > >>>> >>>> =EF=BF=BD =EF=BF=BD>> https://www.ietf.org/mailman/list= info/vwrap >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> __________________________________= _____________ >>>> =EF=BF=BD =EF=BF=BD> vwrap mailing list >>>> =EF=BF=BD =EF=BF=BD> vwrap@ietf.org >>>> > >>>> >>>> =EF=BF=BD =EF=BF=BD> https://www.ietf.org/mailman/listi= nfo/vwrap >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> >>>> >>>> >>>> >>>> >>>> ---------------------------------------------------------------------= --- >>>> >>>> _______________________________________________ >>>> vwrap mailing list >>>> vwrap@ietf.org >>>> https://www.ietf.org/mailman/listinfo/vwrap >>>> =EF=BF=BD >>>> >>>> >>>> >>>> >>>> >>>> -- --- https://twitter.com/Dzonatas_Sol --- >>>> Web Development, Software Engineering, Virtual Reality, Consultant >>>> >>>> _______________________________________________ >>>> vwrap mailing list >>>> vwrap@ietf.org >>>> https://www.ietf.org/mailman/listinfo/vwrap >>>> >>>> >>>> >>> >>> -- >>> --- https://twitter.com/Dzonatas_Sol --- >>> Web Development, Software Engineering, Virtual Reality, Consultant >>> >>> >> > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > --002354470e608bc08c04a07070ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Excellent work, Vaughn!

    You're right, I am working on something = related to this, specifically a design study for the Tourism use case.=C2= =A0 It happens to end with a protocol sequence diagram presented as a table= of text, so I was very pleased to see your highly relevant diagram.=C2=A0 = Yours captures part of my use case, and it's a lot prettier than my tex= t format. :P

    I was particularly impressed by the way you start off with completely s= eparable services right from the start.=C2=A0 Since separable services can = be put together under a single administrative domain very easily, whereas s= eparating conjoined services is not easy at all, I think you've started= this off perfectly for the VWRAP approach to services.

    Because you have separated the services so well, your suggested protoco= l flow could be said to to be targeting some kind of "superset of a= ll VWRAP deployments" deployment. :-)=C2=A0 Although it's logi= cally structured, it's a sort of worst-case scenario (or lawyer's d= elight) in which everyone has to ask everyone else for permission to do any= thing, regardless of whether permission is actually required or not.

    That's viable, but less than optimal.=C2=A0 Specifically, you are w= orking to the principle of "The heaviest burden required by anyone mus= t be borne by everyone."=C2=A0 I have been trying to stick to the oppo= site principle of "A burden should be borne only by those whose use ca= se requires it", which is both fairer and more efficient.

    To illustrate this, consider the case of an asset service which serves = (by choice) only Creative Commons licensed assets --- an extremely importan= t use case which could well become the dominant one in an open metaverse of= community worlds.=C2=A0 Who knows, it could be operated by Debian, or Blen= der, or OSgrid, or even Google Warehouse. :P

    In such a scenario, because the license on all the assets in the asset = service permits unchecked distribution to all destinations in perpetuity, t= he vast majority of all the request-grant protocol flows in your diagram ar= e superfluous when the assets come from this repository.=C2=A0 By using a p= rotocol which understands WHEN it needs to ask a question, a large a= mount of cumulative round-trip time latency (and its resulting lag) can be = avoided entirely.=C2=A0 This is also true on a per-asset basis if an asset = service serves a mixture of encumbered and freely distributable assets, exc= ept that then the difference would be seen per-asset instead of per asset s= ervice.

    For such freely distributable assets, the agent service doesn't nee= d to do anything at all beyond recording the addresses of assets which are = currently being worn by the agent.=C2=A0 Since you start off your trip (sen= sibly) by checking your clothing at home before you leave, you'll notic= e a broken asset service locally anyway since your viewer will be trying to= fetch it for local viewing.=C2=A0 The agent service need do nothing at all= , beyond record the addresses of top level items.=C2=A0 (In my design study= , I refer to a Worn Assets List which is held by the user's agen= t service, and which is entirely separate from any concept of inventory.)
    Likewise, region services don't need to fetch the graphic assets no= rmally either (unless they opt to proxy them), but only pass the addresses = of those assets around to all the other agents in the corresponding region,= so the request-grant exchanges between regions and asset services can be a= voided in this case.=C2=A0 (Regions will be requesting other server-side da= ta though, for example the bounding box information or collision mesh of an= asset, which typically the viewer would not be fetching.)

    That's not the end of the "no unnecessary burden" = issue yet though, because even if you removed all the unnecessary request-g= rant protocol flows, you're still making the incorrect assumption that = assets ALL NEED TO BE RESTRICTED by the mere fact of asking for caps= to everything.=C2=A0 This itself is wrong.=C2=A0 The logic need to first d= etermine whether a cap is needed for fetching a given asset, and if it'= s not needed then the fetch can be done by the viewer or region without thi= s protocol burden at all.

    So you see, there is a fundamental assumption in your nicely laid out f= lows that all assets must be tied up in heavy red tape by the needs of the = most burdensome use case.=C2=A0 I don't agree with that, neither on pri= nciple nor on engineering grounds.

    Many of the flows you have shown are exactly what we need for securing = access to proprietary resources, but not all resources have that burden, an= d I would want to elide a number of the flows away entirely when an asset s= ervice allows it.

    To put it another way, the data is king, and protocol flows should refl= ect the requirements imposed by data, not the other way around.

    I ne= ed this expressed in your flows, possibly as asset requirement annotations.=


    PS.=C2=A0 Great work Vaughn, I think this gives us a wonderful laun= ching point!


    Morgaine.




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


    On Fri, Apr 8, 2011 at 5:40 PM, Vaughn Deluca &l= t;vaughn.deluca@gmail.com>= ; wrote:
    VWRAP servic= es high level message flow (preliminary diagram draft) see


    The main reason that i am submitting this in spit= e of my lack of formal expertise is that the group in my view badly needs a= solid basis for discussion and preventing endless repeating loops. This ex= ample is probably wrong in many ways, but its better than what we have publ= icly available on interop now (although Morgaine is working on something al= ong the lines of the recent discussions here)=C2=A0

    I hope this diagram will give us a base for discussion.= I could have done my homework better by researching the old OGP stuff in m= ore depth, and i probably =C2=A0will do so in the future , but for now I ju= st tried to followed the general principles as far as i understand them, to= see what response that yields from the group. In other words,I try to let = the group educate me :p

    Note that in =C2=A0my view all services are equal, in p= rinciple it does not matter in what "domain" they run, since trus= t and policy are fully localized. It is however very possible to have inter= nal shortcuts in the services to speed up processing.=C2=A0

    In the example I opted for an external Agent service, b= ut I could as well have incorporated that in the set of local services. As = indicated above all services could also be run by different organisations, = true to what VWRAP stands for. Its all up to the deployer, including a user= at home who might want to run a full world for family and friends. Those f= riends might try to use that agent service to venture out in the virtual un= iverse.=C2=A0
    I envision that the final identity =C2=A0provider is external, using O= penID and OAut =C2=A0or whatever other =C2=A0magic that I do not yet fully = understand exists out there.

    The =C2=A0example has= 3 main purposes:
    - =C2=A0Provide a reference for discussion=C2=A0
    - Illustrat= es the use case of tourism, and *true* interop.
    - Illustrate cons= istency problems along the lines discussed =C2=A0here higher up in this tre= ad, as well as the "slashdot" problem that Morgaine outlined so c= learly.

    The message flow assumes an avatar already present in s= ome region, (a small scale local home region in this case, but that is by n= o means essential, it could be a build in region in the viewer or a big com= mercial region). The user is preparing for a trip to immersive world, and a= fter some outfit adjustments moves over.=C2=A0

    Finally i apologize for for the simplistic notation use= d here. I simply add the most relevant parameters passed in square brackets= to a keyword specifying the nature of the message. Please improve on that = where needed.

    So here we go, the avatar is =C2=A0prepare for a visit = to "immersive world"
    0) =C2=A0Viewer, here is an update= of the state of the world your agent is in, please render.
    1) = =C2=A0Agent service, I will go in my Zodiac dress that i keep in the =C2=A0= "Amazing assets" service.
    2) =C2=A0Asset service A, please send a cap for Z, here are my credent= ials
    3) =C2=A0Your fine, here is the cap
    4) =C2=A0Local= region, can you please put this on my agent, i included the cap.
    5) =C2=A0Hello asset service A, i need Z, here is the cap
    6) =C2=A0Cap is good, data coming up, have fun.
    7) =C2=A0Age= nt service, your agent is now wearing Z
    8) =C2=A0Viewer, your ava= tar is now wearing Z
    =C2=A0=C2=A0 =C2=A0User: Hmm, amazing invent= ory has not been *that* amazing lately. 'll make a backup, just in case=
    9) =C2=A0Hello asset service A, please send me a cap for Z, here are m= y credentials
    10) Your fine, here is the cap
    11) Local = asset storage, please store Z for me, here is the cap to get it
    1= 2) Hello asset service A, i want Z, here is the cap
    13) Cap is good, data coming up, have fun.
    14) Viewer, Z is = now stored for you=C2=A0
    =C2=A0=C2=A0 =C2=A0User: I am Ready!, Le= ts try to get to immersive world!
    15) Hello immersive world, can = i get in? Here are my credentials, and a list of my stuff.
    16) Asset service A, please send me a cap for X, here are my credentia= ls (I want this cap for consistency)
    17) Your fine, here is the c= ap
    18) Asset service B, please send me a cap for Y, here are my c= redentials (I want this cap for consistency)
    19) Very sorry, but your not one of us, you can't have Y
    20) Asset service B, please send me a cap for Z, here are my credentials (= I want a cap for consistency)
    [Region service: Timeout... amazing= inventory must be overloaded.. oh well... ]
    21) Agent service, you wanted to send somebody over, here are your per= missions.
    22) Viewer, you asked for a transfer try, here are your= results
    =C2=A0=C2=A0 =C2=A0 User thinks: =C2=A0Crap! Big asset s= ervice does not allow =C2=A0me to take my yellow stockings! And Amazing ass= ets =C2=A0failed to deliver my zodiac dress. At least i made a backup of th= at dress!
    23) 'll take the yellow stockings off...
    24) ... done (&= #39;ll trash them here and now, forever, who needs stuff you can't use!= )
    25) The zodiac dress was not delivered by Big assets service, b= ut i have a local copy!
    26) Local Asset service, please send me Z, here are my credentials
    27) I dont know you, but I 'll trust you, here is the cap, but y= ou better store the data, its single use, i need to protect myself.
    28) Local region, can you please put this on my agent, i include the c= ap.
    29) Local Asset service, i need Z, here is the cap
    = 30) Cap is good, data coming up, have fun.
    31) Cap was only good = for one time, I made a copy, but my policy is to only grant you fair use ri= ghts, at a later time i might even tell you to replace the dress.
    32) Viewer, you can wear Z for now, but the asset service granted only= fair use, i might ask you to replace the dress at a later time.
    = 33) Ready at last! Off to immersive world!, I hope its not to crowded there= or 'll loose my dress...
    34) Hello immersive world, here are my credentials, and a list of stuf= f i want to bring
    35) Hello asset service A, please send me a cap= for X, here are my credentials=C2=A0
    =C2=A0=C2=A0 =C2=A0[darn, I= should have kept that cap from last time..]
    36) Your fine, here is the cap.
    =C2=A0=C2=A0 [Region service= finds fair-use warning on Z and decides to make its own copy]
    37= ) Hello Local region, can i still have Z? Here is the cap=C2=A0
    3= 8) Cap is still good, data coming up, have fun.
    =C2=A0=C2=A0 [Region service stores asset in private storage, providin= g a cap to replace the fair use one]
    39) Agent service, you wante= d to send somebody over, here are your permissions & info.
    40= ) Hello immersive world, just =C2=A0get me there, and use what you can
    41) Placement done, Z is currently buffered by us as wel, you need to = get details for X, have fun.
    42) You are now in immersive world, = your dress is buffered there as well, but you need to get X!
    43) Hello asset service A, i want X, here is the cap
    44) Cap is g= ood, data coming up, have fun.
    45) Viewer, here is an update of t= he state of the world your agent is in, please render.

    As far as I can see this conforms fully to our charter, and i hope it = is possible to use large portions of the existing code bases. However, as s= aid above, i did not really try to capture the old thinking, and I also mig= ht have misconceptions about the way to do these things in general.
    Looking forward to constructive comments.

    -- Vaughn

    On Sun, Apr 3, 2011 at 8:38 PM,= Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
    Thanks for the po= inters. =C2=A0I have a =C2=A0busy week in RL in front of me, so i wont have= to much time to respond the next few days, however, i intend to start doin= g the following things:

    - Produce a visual that reflects my thinking, i.e. an illust= ration of my response to Morgaine's itemlist =C2=A0above.
    - Read up on the older notes, as well as =C2=A0more reading= in the list archive
    - Try to make a summary for the wiki

    Regarding the use of domain, I think services are e= ventually what counts, but its all terminology. The way I read the AWG diag= rams is that the agent domain is actually a cluster of tightly integrated s= ervices. When the functionality of each sub-service is described properly a= nd with uniform interfaces the domain will slowly dissolve. But let not get= ahead of out selfs. We should put up some clear descriptions on the wiki f= or our views on this, and *after* that we can decide what we need and what = can go.

    Its been a very useful and illuminating weekend for me,= and i am a lot more optimistic about the future of vwrap than two weeks ag= o.

    -- Vaughn
    <= div>



    On Sun, Apr 3, 2011 at 7:20 = PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
    Probably easy as suggested in other terms here on this list, as how the cli= ent contacts the asset services now in the regions. The newer issue is to u= nitize that asset services. Since their is proprietary (legacy) code then w= e can't expect that to change, and some form of proxy is of need. Whate= ver works best, I tried to narrow it down to suggestions here.

    Eventually, the agent domain is ideal to handle the direction of the asset = services. This concept, unfortunately, ended support awhile ago with change= s in LL.
    Also see; http://wiki.secondlife.com/wiki/Agent_Domain
    And: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_A= sset (warn: unstructured collaborative notes, dumped on me and I tried = to fix)

    I tried to find previous visuals.

    I'd imagine the agent domain could grow out of unitized versions of ass= et services. Despite that, I think that concept helps view where we were at= in discussion and what didn't happen.

    Vaughn Deluca wrote:
    Hi=EF=BF=BDDzonatas

    Can you expand on that, what would be needed for legacy support in VWAP ter= ms=EF=BF=BD?,
    If i want to read up on how the=EF=BF=BDasset server may proxy the simulato= r, what would you recommend me to read?

    -- Vaughn

    On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol <dzonatas@gmail.com <mailto:dzonatas@gmail.com>>= wrote:

    =C2=A0 =C2=A0Some stated the proxy-to-asset-server is built into the sim;<= br> =C2=A0 =C2=A0however, keep in mind possible legacy support where the asset=
    =C2=A0 =C2=A0server may proxy the simulator.


    =C2=A0 =C2=A0Dzonatas Sol wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0Somehow I feel the basic asset server being abl= e to login and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0download assets is now priority, yet I also won= dered the best
    =C2=A0 =C2=A0 =C2=A0 =C2=A0way to patch this into the current mode of view= ers.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0Maybe offer (1) by proxy (sim-side) and (2) by = patch
    =C2=A0 =C2=A0 =C2=A0 =C2=A0(viewer-side) that either of these two are opti= onal and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0neither are mandatory for now. Thoughts?

    =C2=A0 =C2=A0 =C2=A0 =C2=A0Israel Alanis wrote:


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> when designing for scalabili= ty, the model to bear in
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mind is ...

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Well, there are a lot of differen= t models to keep in mind,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and many different use cases. One= particular use case to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0keep in mind is: "User acqui= res new outfit, and wants to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'show it off' in a highly= populated region".

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Both worlds and asset servic= es may include commercial,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0community, and personal services<= br>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, yes and yes. I'm particu= larly concerned about how the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0model affects the ability to host= personal asset services.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> a proxying region, which wou= ld get slammed for every
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0asset worn by every avatar presen= t.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Granted the collection of service= s that are provided by
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the region need to be scaled to m= eet the demands of that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0region. That's all part of ca= pacity planning.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> regions run many different C= PU-intensive tasks,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0including physics simulation and = server-side scripting,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and absolutely cannot afford to s= erve assets too
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Well... who said the same CPU'= ;s have to do proxying,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0physics simulation and server-sid= e scripting? Asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proxying is a different service t= han physics simulation
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and can be on separate hardware, = could make use of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0geographically distributed cachin= g, and in certain
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0deployment patterns, the same cac= hing services could be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0shared by different regions. (Ser= ver-side scripting is a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discussion for another day).

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> This is why we have to go pa= rallel...

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Totally agree, and a proxying mod= el could and should also
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0take advantage of parallelism.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I think you're wrong tha= t it has to cost much money. ?vs?
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> It costs money to host a hig= h performance and scalable
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0asset service and a high bandwidt= h network to handle the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0traffic. =EF=BF=BDA *lot* of mone= y.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I think what you're saying is= : "It costs a lot of money to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0build a scalable asset service, b= ut if assets are spread
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0throughout the internet they don&= #39;t have to be scalable."
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0But that's not quite right. Y= ou're opening up every asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server to the VW equivalent of be= ing slashdotted, so are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0you sure you're not forcing *= every* asset service to be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scalable and handle a lot of band= with and network traffic?
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It's the exact opposite of yo= ur intention, but I think
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that's the result, all the sa= me.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This particular design decision h= as a big effect on the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0economics of the VW infrastructur= e. I'd rather the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0economics to work out such that a= region provider who
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wishes to build a region that sup= ports a small population,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0can do so economically. A region = that wants to host a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*large* population has to bear th= at cost of providing that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scalable asset service.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I want the economics of hosting a= small asset service to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be a non-issue (as to best promot= e creation and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0creativity). Creating a high bar = to provide asset services
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0will mean that service will cost = money and people
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0shouldn't have to pay money j= ust to create or own VW
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0objects (I'm using 'own&#= 39; here to refer to maintaining
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0their existence, I'm not tryi= ng to make a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'leftist'/'communist&= #39; statement about ownership ;)

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Izzy


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Apr 2, 2011, at 3:58 PM, Morga= ine wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Izzy, when designin= g for scalability, the model to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bear in mind is tha= t of seasoned virtual world
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0travelers whose inv= entories contain assets from many
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0different worlds, t= hose assets being served by many
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0different asset ser= vices. =EF=BF=BDBoth worlds and asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0services may includ= e commercial, community, and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0personal services, = and as the metaverse grows, that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0set is highly likel= y to become progressively less
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clustered and more = diverse.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0When those seasoned= travelers click on an advertised
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0VW link and perform= an inter-world teleport to one
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0particular world= 9;s region to share an experience,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0their "worn&qu= ot; assets (the only ones of interest to the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0region) will contai= n references to asset services
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spread widely acros= s the Internet. =EF=BF=BDThe fetches by the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0travelers' clie= nts occur over many parallel paths from
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clients to asset se= rvices, so one can reasonably
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0expect reduced netw= ork contention and reduced asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server loading beca= use they are both spread out over
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0however many asset = services are being referenced by
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the overall set of = assets in the region.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This is very differ= ent to the case of a proxying
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0region, which would= get slammed for every asset worn
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by every avatar pre= sent. =EF=BF=BDIn our current architecture,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0regions run many di= fferent CPU-intensive tasks,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0including physics s= imulation and server-side
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scripting, and abso= lutely cannot afford to serve
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0assets too unless y= our scalability requirements are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0very low indeed, ie= . just a few dozen avatars of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0today's kind. = =EF=BF=BDWe've hit the ceiling already on region
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scalability done th= at way. =EF=BF=BDThere is nowhere to go in
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that direction at a= ll beyond improving the code like
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Intel demonstrated,= and that work is subject to a law
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of diminishing retu= rns.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This is why we have= to go parallel, and I think you're
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrong that it has t= o cost much money. =EF=BF=BDAs we spread
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the load across mor= e and more asset services, we are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0simply better utili= zing all the hardware that's
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0already out there o= n the Internet, at least in respect
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of community and pr= ivate resources. =EF=BF=BDBut add to the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0community and priva= te resources the commercial asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0services that are l= ikely to appear to exploit this
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opportunity, and no= t only will the number of asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0services leap, but = the power of each one will rocket
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0too, because, after= all, these businesses will be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0heavily optimized f= or the job.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As to why a world w= ould want clients to access
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0external asset serv= ices instead of providing its own
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implementation, tha= t's an easy question. =EF=BF=BDIt costs
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0money to host a hig= h performance and scalable asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0service and a high = bandwidth network to handle the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0traffic. =EF=BF=BDA= *lot* of money. =EF=BF=BDIn contrast, it costs a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0world nothing to le= t others serve the assets to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clients. =EF=BF=BDA= nd that matters to the bottom line.


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Morgaine.




    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, Apr 2, 2011= at 7:05 PM, Izzy Alanis
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<izzyalanis@gmail.com <mai= lto:izzyalanis@gm= ail.com>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:izzyalanis@gmail.com=

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:izzyalanis@gmail.com= >>> wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > As always though, it's a trade-off, since the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proxied design
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= has very poor scalability compared to the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0distributed one.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= I don't agree with that... If a user enters a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0highly populated =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= region,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= every other client is going to (could and should be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0trying to)
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= hit the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= asset server(s) for the assets that the user is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wearing (assuming =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= they're not cached locally). =EF=BF=BDEvery asset server
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has to be scaled up=
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= to the point that it can handle that load from all
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0over...

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= If I'm hosting a region that supports 10s of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0thousands of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= simultaneous
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= users (thinking of the future), I already have to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scale to meet that<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= demand. If the region is proxying the assets, then,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yes the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= region has
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= to be scaled to meet that asset demand too, but it
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0already has to be =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= scaled to meet other demands of being a region
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server... and why i= s
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= scaling those asset proxy services hard? =EF=BF=BDIt's
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0going to cost $, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= but is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= not technically challenging. So, if I want to host
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a region like
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= that... sure it will cost me, but the simulation
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0will be consistent<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= and users will be able to participate equally,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0regardless of the =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= capabilities of their individual asset services.




    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= On Fri, Apr 1, 2011 at 11:55 PM, Morgaine
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= <mor= gaine.dinova@googlemail.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:morgaine.dinov= a@googlemail.com>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= <mailto:morgaine.dinova@googlemail.com

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:morgaine.dinov= a@googlemail.com>>> wrote:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > Every design choice results in a trade-off,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vaughn, improving =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= one thing at
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > the expense of something else. =EF=BF=BDIf every time we
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0offered a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= service we had to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > inform its users about the downsides of all the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0trade-offs we
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= have made,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > they would have an awful lot to read. ;-)
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > The specific trade-off that you are discussing is no
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= different. =EF=BF=BDA region
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > that proxies all content has the "benefit" of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0acquiring control =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= from the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > asset servers over the items in the region, so
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that it can
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= ensure that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > everyone in the region not only obtains the items
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0but obtains
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= the same items
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > as everyone else. =EF=BF=BDThat does indeed provide a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0greater guarantee o= f
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > consistency than a deployment in which the region
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0only passes
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= asset URIs to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > clients who then fetch the items from asset services
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= separately. =EF=BF=BDAs always
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > though, it's a trade-off, since the proxied
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0design has very
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= poor scalability
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > compared to the distributed one.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > If we're going to warn users of the potential for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inconsistency
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= in the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > distributed deployment as you suggest, are we
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0also going to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= warn them of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > non-scalability in the proxied one? =EF=BF=BDI really
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0don't see much<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= merit in the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > idea of warning about design choices. =EF=BF=BDMany such
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0choices are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= technical, and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > the issues are quite likely to be of little
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interest to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= non-technical users
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > anyway. =EF=BF=BDIn any case, the better services are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0likely to provide =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= such
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > information in their online documentation, I
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0would guess.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > You mentioned users "voting with their feet" or
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0choosing to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= accept the risk
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > of inconsistency. =EF=BF=BDWell that will happen anyway,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0when services
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= fail and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > users get annoyed. =EF=BF=BDIf some asset services refuse
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to send the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= requested
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > items to some users, those services will get a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bad reputation
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= and people
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > will choose different asset services instead.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BDLikewise, = if a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= world service
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > proxies everything and so it can't handle a large
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0number of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= assets or of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > people, users will get annoyed at the lag and will go
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= elsewhere. =EF=BF=BDThis user
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > evaluation and "voting with their feet" happens
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0already with
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= online services
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > all over the Internet, and I am sure that this
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0human process
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= will continue
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > to work when the services are asset and region
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0services.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > Back in September 2010, I wrote this post which
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proposes that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= we use in
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > VWRAP a form of asset addressing that provides
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0massive
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= scalability at the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > same time as a very high degree of resilience --
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BDhttp://www.ietf.org/mail-archive/web/vwrap/current/msg00463.htm= l
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= . =EF=BF=BDIt is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > based on the concept of the URI containing a host
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0part and a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= hash part,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > where the hash is generated (once, at the time of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0storage to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= the asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > service) using a specified digest algorithm over
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the content of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= the asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > being referenced. =EF=BF=BDYou may wish to note that if
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this design
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= were used, the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > failure of an asset service to deliver a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0requested item woul= d
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= result in a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > failover request for the item to one or more
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0backup services, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= using the same
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > hash part but with a different host address.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > This can go some way towards overcoming the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0problem that you =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= think might
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > occur when assets are fetched by clients from
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0asset services
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= directly.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > Although it won't help when the missing item is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0available from
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= only a single
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > asset service, it will help in many other cases,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and it will
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= compensate for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > service failures and network outages
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0automatically at th= e same
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= time.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > PS. This design for hash-based asset addressing
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is already
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= being tested by
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > Mojito Sorbet in her experimental world and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0client. =EF=BF=BDIt= would give
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > VWRAP-based worlds an improved level of service
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0availability,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= so I think it
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > should be a core feature of our protocol.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > Morgaine.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > =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
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= <vaughn.del= uca@gmail.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vaughn.deluca@gmail.c= om>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vaughn.deluca@gmail.c= om
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vaughn.deluca@gmail.c= om>>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > wrote:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> This is a question i discussed with Morgaine
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0off-list a while =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= ago (I
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> intended to send it to the list but pushed the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrong button...) I<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> think we need to address this problem, and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0decide how to deal<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= with it.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BDIn Davids deployment draft, section 7.3.1.1 an
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0overview is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= given van
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> ways to deliver content to the region. One way
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is only passing a =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> capability that allows access to (part of) the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0resource:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD 7.3.1.1. =EF=BF= =BDContent delivery models
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD A range of possi= ble represenations can
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be passed to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= a region for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD simulation. [...= ] The other end of the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0delivery spectrum =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> involves passing
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD only a URI or ca= pability used to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0access the renderin= g
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> information and a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD collision mesh,a= nd related data for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0physical simulation= .
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD In such a model,= the client is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0responsible for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= fetching the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> additional
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD information need= ed to render the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0item's visual =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= presence from a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> separate
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD service. =EF=BF= =BDThis fetch can be done
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*under the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= credentials of the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> end user*
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD viewing the mate= rial [my emphasis--VD]
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0, and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= divorces the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> simulation from
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD the trust chain = needed to manage
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0content. =EF=BF=BDA= ny
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= automation
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> is done on a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD separate host wh= ich the content
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0creator or owner tr= usts,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> interacting with the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD object through r= emoted interfaces.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BDI can see the need for such a setup, however, i
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0feel we are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> unpleasantly close to a situation were the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0coherence of the =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= simulation
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> falls apart.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> In this deployment pattern the region advertises
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the presence
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= of the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> asset, and *some* clients will be able to get it
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as expected,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= while
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> -based on the arbitrary whims of the asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0service- others
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= might not.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> My hope would be that after the asset server
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0provides the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= region with
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> the capability to get the asset, it gives up
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0control. That
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= would mean
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> that if the client finds the inventory server is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unwilling to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= serve
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> the content - in spire of the region saying it
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is present-,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= the client
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> should be able to turn around ask the *region*
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for the asset,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= (and get
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> is after all).
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BDIf that is not the case, -and there are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0probably good reaso= ns
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= for the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> deployment pattern as described- =EF=BF=BDshouldn't we
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*warn* clients
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= that the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> region might be inconsistent, so the users
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0behind the client =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= can vote
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> with their feet, (or take the risk)?
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> --Vaughn
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> _______________________________________________
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> vwrap mailing list
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> vwrap@ietf.org= <mailto:vwrap@i= etf.org>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:= vwrap@ietf.org>&= gt;

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> https://www.ietf.org/mailman/listinfo/vwrap
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > _______________________________________________
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > vwrap mailing list
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > vwrap@ietf.org= <mailto:vwrap@ietf.= org>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:= vwrap@ietf.org>&= gt;

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > https://www.ietf.org/mailman/listinfo/vwrap
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >



    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------------------------------= ---------------------------------------

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_________________________________= ______________
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vwrap mailing list
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vwrap@ietf.org <mailto:vwrap@ietf.org>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listi= nfo/vwrap
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD





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

    =C2=A0 =C2=A0_______________________________________________
    =C2=A0 =C2=A0vwrap mailing list


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


    --002354470e608bc08c04a07070ab-- From morgaine.dinova@googlemail.com Fri Apr 8 18:09:18 2011 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 285B83A6A20 for ; Fri, 8 Apr 2011 18:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.767 X-Spam-Level: X-Spam-Status: No, score=-2.767 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZIWr59U20-6 for ; Fri, 8 Apr 2011 18:09:15 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 56AB13A698E for ; Fri, 8 Apr 2011 18:09:15 -0700 (PDT) Received: by qwc23 with SMTP id 23so2942513qwc.31 for ; Fri, 08 Apr 2011 18:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=UWaUYmMvpFDxqyFgtd0V0OBxXiAv9jnjJqU1ZVakZIE=; b=bFCjre2xLs+zH784HVf02IZGn7G+cbGwl8Ce06g0g3xy1IFH10Q99q6+LrTjzXebw4 fdMvCKhj1JI3/43kdvlIj3SE6b9uJXr0qmgc8YfPfS4mulJJdYRVaA0UhunTdqG2HgeF cRPmfAig+nmWGsz/QzpX3AGJ55bLlt1a8K71U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=FElU0Sxh+1Fj2NkrHoezNFMgeax0Uo720J+Y4pyLGjcsO73KT2M+OMjHKxpA7ONEXg BNdhtH3aCtlNaYVKd8hT/Ef9nFex+CwdlkXWKHokd2CoCXAqiAfczqcDzUarvSsOYvGV W9f5AcDHRsauufmXsCQZSDao42LNw8GYaeIXg= MIME-Version: 1.0 Received: by 10.229.62.6 with SMTP id v6mr2344901qch.223.1302311460604; Fri, 08 Apr 2011 18:11:00 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Fri, 8 Apr 2011 18:11:00 -0700 (PDT) In-Reply-To: <20110408223402.36ae68a9@hikaru.localdomain> References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> <20110408223402.36ae68a9@hikaru.localdomain> Date: Sat, 9 Apr 2011 02:11:00 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=90e6ba180d9aff0c1204a0720377 Subject: Re: [vwrap] Is 'Data Z' immutable (like a git snapshot)? 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: Sat, 09 Apr 2011 01:09:18 -0000 --90e6ba180d9aff0c1204a0720377 Content-Type: text/plain; charset=ISO-8859-1 Carlo, I too would like to hear what Vaughn had in mind in the areas you mention, although it's perfectly possible that he was trying to keep the issues of mutability and addressing out of the initial picture entirely, just to keep things simple. They are important issues though, and I'm glad that you pointed them out. Here I'll provide my views about this general area. First of all, mutability breaks caching entirely, so it needs to be approached with great caution. Caching can make the difference between a great service and a totally unusable one (or at least one that doesn't work very well), so if mutability is allowed then things need to be designed in such a way that caching still works *most of the time*, namely in between mutations. This is an issue which has occupied many minds for decades, and I think it can be distilled into the widely accepted notion that cached objects should never be overwritten, but only joined by updated versions. At a stroke this lets highly concurrent asset services avoid the thorny issue of writing in the presence of concurrent readers, and at the same time it lets caches have very simple update semantics since nothing is mutable from their perspective. The only cost is some loss of disk space to hold old versions, which is rarely significant given disk sizes and costs today. While that is good for asset services and caches, it does place the burden of achieving mutability on the parties who require it. And that of course is how burdens should be borne. What this means for virtual worlds is that a mutator becomes responsible for notifying endpoints that something has mutated, so that they can fetch the new versions. This needn't be an onerous requirement, and it may not even need to be wrapped up in security tape, since having had access once probably qualifies you for an unconditional update. In any case, the original item is still in its asset service (as well as in users' terabyte caches), so one very useful property of this approach is that a simulation can't be broken for long by a poor update since reverting is always possible. That's a an engineering plus point. In respect of addressing, you mentioned using hashes as item addresses, and this is of course my preferred strategy, which I have described and advocated several times this week, and back in September. Hash-based addressing has numerous excellent engineering properties that put it head and shoulders above other schemes. I say go with that approach. In any event, when we pit alternative schemes against each other on merit, I bet nothing will come close to hash-based. On the issue of caps, I think that keeping their semantics simple has great merit, because heavyweight schemes are less likely to be accepted, and complex ones are unlikely to be implemented uniformly. But in any case, as I described to Vaughn, caps should be *optional* anyway (ie. asset dependent). Having to acquire a cap in order to fetch a Creative Commons licensed asset is unnecessary, and indeed it is rather comic. A cap only needs to be requested when the asset requires it, and only those assets that need it should bear the burden. The issue of flag bits (or more generally, property fields) for assets is one that interests me a lot, as it relates to the above. As I described to Vaughn, it is the assets that impose requirements on the protocol, not vice versa, so it is the assets that should carry the properties that control the protocol. Morgaine. ============================== On Fri, Apr 8, 2011 at 9:34 PM, Carlo Wood wrote: > This is very nice work and I think it clarifies a lot. > > I have a few very basic questions. > > I see that you request Z from two different Asset servers > (originally A, but also C when a backup has been stored there). > > No matter how you look at it, that is distributed storage: > compare it with git or mercurial; if Z on A could be changed > then the backup would be out dated, and that is not what > we want. So, I conclude that 'Z' (or rather, then handle > used to refer to Z when asking for it) therefore refers to > a unmodifiable data (compare git's hex ID's that point to > a snapshot). > > 1) Is that correct? > > If it is correct and the handle for Z used in messages > like "give me a cap for Z" refer to immutable data, then > the most logical thing to do would be to use a (large) > hash value of the data (ie, md5) or an UUID that was > generated when the data was last changed (which is less > good because it would cause duplicated data when something > is changed back to what it was before), or to use an > ID that is less large, but whose uniqueness would be > guaranteed by including a (for that authority unique) ID > of the authority that made the last change. The advantage > of the latter is less bandwidth (smaller ID's) and knowledge > of the authority right into the ID of something (handy > for routing). Disadvantages are: it suffers from the same > as the UUID in that it will duplicate data whenever the > same data is generated and it requires administration to > make sure that every authority has a unique ID (compare > giving people unique IP addresses). > > 2) Which of those is used? has, UUID or smaller specially > crafted ID? > > 3) What would happen if someone gets a cap for Z, a > modifiable object; then the object is modified and then > the cap is used? Does the cap have a guaranteed life time? > > 4) If not every previous state of an object is kept > eternally and after changing some object old caps (and > their static data) disappear - then how will the asset > servers that contain copies know that? They are not > necessarily aware that anything changed at all for > that object, so they can't know what the life time > is. It seems that once you make a copy you are doomed > to keep it forever or do garbage collection for assets > that are never accessed anymore. > > 5) I can image that at SOME TIME in the future we want > a few bit (or more) that ARE mutable-- despite that the > asset ID (Z) refers to snapshot (immutable) data. > Are we going to build into the protocol a provision for > such mutable bits? > > This would mean, in the case that the ID is a hash (ie md5) > that the asset Data exists of a payload that the hash is > taken over plus a mutable part that is not considered for > the hash. Obviously, such data then could get desynced > between assets servers with copies. > > -- > Carlo Wood > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --90e6ba180d9aff0c1204a0720377 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Carlo, I too would like to hear what Vaughn had in mind in the areas you me= ntion, although it's perfectly possible that he was trying to keep the = issues of mutability and addressing out of the initial picture entirely, ju= st to keep things simple.=A0 They are important issues though, and I'm = glad that you pointed them out.

    Here I'll provide my views about this general area.

    First of= all, mutability breaks caching entirely, so it needs to be approached with= great caution.=A0 Caching can make the difference between a great service = and a totally unusable one (or at least one that doesn't work very well= ), so if mutability is allowed then things need to be designed in such a wa= y that caching still works most of the time, namely in between mutat= ions.

    This is an issue which has occupied many minds for decades, and I think= it can be distilled into the widely accepted notion that cached objects sh= ould never be overwritten, but only joined by updated versions.=A0 At a str= oke this lets highly concurrent asset services avoid the thorny issue of wr= iting in the presence of concurrent readers, and at the same time it lets c= aches have very simple update semantics since nothing is mutable from their= perspective.=A0 The only cost is some loss of disk space to hold old versi= ons, which is rarely significant given disk sizes and costs today.

    While that is good for asset services and caches, it does place the bur= den of achieving mutability on the parties who require it.=A0 And that of c= ourse is how burdens should be borne.

    What this means for virtual wo= rlds is that a mutator becomes responsible for notifying endpoints that som= ething has mutated, so that they can fetch the new versions.=A0 This needn&= #39;t be an onerous requirement, and it may not even need to be wrapped up = in security tape, since having had access once probably qualifies you for a= n unconditional update.=A0 In any case, the original item is still in its a= sset service (as well as in users' terabyte caches), so one very useful= property of this approach is that a simulation can't be broken for lon= g by a poor update since reverting is always possible.=A0 That's a an e= ngineering plus point.

    In respect of addressing, you mentioned using hashes as item addresses,= and this is of course my preferred strategy, which I have described and ad= vocated several times this week, and back in September.=A0 Hash-based addre= ssing has numerous excellent engineering properties that put it head and sh= oulders above other schemes.=A0 I say go with that approach.=A0 In any even= t, when we pit alternative schemes against each other on merit, I bet nothi= ng will come close to hash-based.

    On the issue of caps, I think that keeping their semantics simple has g= reat merit, because heavyweight schemes are less likely to be accepted, and= complex ones are unlikely to be implemented uniformly.=A0 But in any case,= as I described to Vaughn, caps should be optional anyway (ie. asset= dependent).=A0 Having to acquire a cap in order to fetch a Creative Common= s licensed asset is unnecessary, and indeed it is rather comic.=A0 A cap on= ly needs to be requested when the asset requires it, and only those assets = that need it should bear the burden.

    The issue of flag bits (or more generally, property fields) for assets = is one that interests me a lot, as it relates to the above.=A0 As I describ= ed to Vaughn, it is the assets that impose requirements on the protocol, no= t vice versa, so it is the assets that should carry the properties that con= trol the protocol.


    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


    On Fri, Apr 8, 2011 at 9:34 PM, Carlo Wood <carlo@alinoe.com> wrote:
    This is very nice= work and I think it clarifies a lot.

    I have a few very basic questions.

    I see that you request Z from two different Asset servers
    (originally A, but also C when a backup has been stored there).

    No matter how you look at it, that is distributed storage:
    compare it with git or mercurial; if Z on A could be changed
    then the backup would be out dated, and that is not what
    we want. So, I conclude that 'Z' (or rather, then handle
    used to refer to Z when asking for it) therefore refers to
    a unmodifiable data (compare git's hex ID's that point to
    a snapshot).

    1) Is that correct?

    If it is correct and the handle for Z used in messages
    like "give me a cap for Z" refer to immutable data, then
    the most logical thing to do would be to use a (large)
    hash value of the data (ie, md5) or an UUID that was
    generated when the data was last changed (which is less
    good because it would cause duplicated data when something
    is changed back to what it was before), or to use an
    ID that is less large, but whose uniqueness would be
    guaranteed by including a (for that authority unique) ID
    of the authority that made the last change. The advantage
    of the latter is less bandwidth (smaller ID's) and knowledge
    of the authority right into the ID of something (handy
    for routing). Disadvantages are: it suffers from the same
    as the UUID in that it will duplicate data whenever the
    same data is generated and it requires administration to
    make sure that every authority has a unique ID (compare
    giving people unique IP addresses).

    2) Which of those is used? has, UUID or smaller specially
    crafted ID?

    3) What would happen if someone gets a cap for Z, a
    modifiable object; then the object is modified and then
    the cap is used? Does the cap have a guaranteed life time?

    4) If not every previous state of an object is kept
    eternally and after changing some object old caps (and
    their static data) disappear - then how will the asset
    servers that contain copies know that? They are not
    necessarily aware that anything changed at all for
    that object, so they can't know what the life time
    is. It seems that once you make a copy you are doomed
    to keep it forever or do garbage collection for assets
    that are never accessed anymore.

    5) I can image that at SOME TIME in the future we want
    a few bit (or more) that ARE mutable-- despite that the
    asset ID (Z) refers to snapshot (immutable) data.
    Are we going to build into the protocol a provision for
    such mutable bits?

    This would mean, in the case that the ID is a hash (ie md5)
    that the asset Data exists of a payload that the hash is
    taken over plus a mutable part that is not considered for
    the hash. Obviously, such data then could get desynced
    between assets servers with copies.

    --
    Carlo Wood <carlo@alinoe.com>=
    _______________________________________________
    vwrap mailing list
    vwrap@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/vwrap

    --90e6ba180d9aff0c1204a0720377-- From carlo@alinoe.com Fri Apr 8 18:56:57 2011 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 7C1263A699D for ; Fri, 8 Apr 2011 18:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_51=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 ph8imJhgzEqo for ; Fri, 8 Apr 2011 18:56:55 -0700 (PDT) Received: from fep15.mx.upcmail.net (fep15.mx.upcmail.net [62.179.121.35]) by core3.amsl.com (Postfix) with ESMTP id A8CED3A699A for ; Fri, 8 Apr 2011 18:56:54 -0700 (PDT) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep15-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110409015839.YUZP1633.viefep15-int.chello.at@edge04.upcmail.net> for ; Sat, 9 Apr 2011 03:58:39 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upcmail.net with edge id VDyd1g00U0FlQed04DyeRi; Sat, 09 Apr 2011 03:58:38 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q8NRd-0008D3-Fo for vwrap@ietf.org; Sat, 09 Apr 2011 03:58:37 +0200 Date: Sat, 9 Apr 2011 03:58:37 +0200 From: Carlo Wood To: vwrap@ietf.org Message-ID: <20110409035837.0d324940@hikaru.localdomain> In-Reply-To: References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> <20110408223402.36ae68a9@hikaru.localdomain> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=JvXQbuMnWGQeb488dJ7w43Du7THgE+O7ieb9U20/rjk= c=1 sm=0 a=qqZHnfQHanQA:10 a=_kSIUADMT0YA:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=mK_AVkanAAAA:8 a=BjFOTwK7AAAA:8 a=Sa3eJpGXMqus4QJOihAA:9 a=gQbShc3wivGYef4LyzcA:7 a=CjuIK1q_8ugA:10 a=9xyTavCNlvEA:10 a=bW3kdApBr58A:10 a=WzUMvy_nK2BO-88J:21 a=_8XUjsOAaciI1ZC1:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [vwrap] Is 'Data Z' immutable (like a git snapshot)? 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: Sat, 09 Apr 2011 01:56:57 -0000 On Sat, 9 Apr 2011 02:11:00 +0100 Morgaine wrote: > First of all, mutability breaks caching entirely, so it needs to be > approached with great caution. Caching can make the difference > between a great service and a totally unusable one (or at least one > that doesn't work very well), so if mutability is allowed then things > need to be designed in such a way that caching still works *most of > the time*, namely in between mutations. Yup, I totally agree. As you might know I've been working a lot on improving the IRC protocol at the time. IRC works with handles (nicks and channel names) and everything else is mutable (ie, the channel topic, the channel modes, etc). This turned out to be an unsolvable horror (and trust me on that please, I worked 7 years on this topic). What I did was change nick names into numerics that are *unmutable*, so at least the bloody handle wasn't changing all the time, heheh (channel names are already unmutable) and then assigned authortities for the nick names (namely those servers where the users are connected to). Authorities have the nice property to have exclusively an outwards message stream: from the authority away, and therefore for streamable: if every mutating operation is kept in order than everything remains synched in the end. This requires that one always ASKS the authority to change something and not tell it that you changed something. For example, I changed it that when you KICK someone from a channel, then a request is sent to the server where that person is connected to and that server actually sends out the message that this user is removed from the channel. Making an authority for channels was never done, there I have tried to solve this problem with timestamps. I don't think we should go this route (using time stamps). Also, the authority "solution" has a the major disadvantage that it only works in a non-cyclic routing tree; and and as soon as any rerouting takes place you get into MAJOR problems for messages that were still under way. The ONLY way to really avoid all those nightmares is to adopt how git and mercurial work: immutable data that some hash ID refers to, which, as you said is, "never" deleted. > This is an issue which has occupied many minds for decades, and I > think it can be distilled into the widely accepted notion that cached > objects should never be overwritten, but only joined by updated > versions. At a stroke this lets highly concurrent asset services > avoid the thorny issue of writing in the presence of concurrent > readers, and at the same time it lets caches have very simple update > semantics since nothing is mutable from their perspective. The only > cost is some loss of disk space to hold old versions, which is rarely > significant given disk sizes and costs today. You totally convinced me :). And for the others: note that I tried it in other ways for YEARS. So, it means something that now I'm convinced that wasn't right and we should avoid it. > While that is good for asset services and caches, it does place the > burden of achieving mutability on the parties who require it. And > that of course is how burdens should be borne. Also very true. > What this means for virtual worlds is that a mutator becomes > responsible for notifying endpoints that something has mutated, so > that they can fetch the new versions. This sound like an 'authority' however: one entity and one alone can issue the out going message that something has changed... That is not how it should work though. I can't wrap my finger around the difference yet though :/... If we go for immutability then why suddenly are we talking about having to notify others that something changed? Of course, things DO change in-world. For example, someone could detach something - and attach something else. Then the Agent of that avatar is the authority I'd think: the viewer requests the Agent to make a change, and if approved then the Agent tells the viewer and everyone else that the change was made. I guess that the big difference is that in those outgoing messages is no large 'data'.. no ASSET data. The Asset servers themselves would never do this. Only work-tied (location tied) things will do this: avatars and rezzed objects, with respectively the Agent and the Region as authority/source of the mutating messages. Routing probably goes all through the Region server: if someone changes an attachment while they are 4000 meter away (in the same sim) then that STILL has to be routed to everyone else in the sim, and not later. Basically at least, the Agent *tells* the Region server that the avatars appears has changed and the Region sends outward messages of that fact to everyone who is connected. As long as all mutating messages go in one direction: away from the authority (the Agent in this case) and there are no RE-routing issues (which is not the case here) then there are no problems with this model. > This needn't be an onerous > requirement, and it may not even need to be wrapped up in security > tape, since having had access once probably qualifies you for an > unconditional update. In any case, the original item is still in its > asset service (as well as in users' terabyte caches), so one very > useful property of this approach is that a simulation can't be broken > for long by a poor update since reverting is always possible. That's > a an engineering plus point. If all things are well, then the outgoing 'mutation' message from the Agent/Region only contains new asset ID's, not the data itself. And people will get the new data using the new ID. This sound perfectly ok for textures (which aren't even mutatable in-world), but what about a little change to the shape of a prim of an object? An object (existing of many prims) is an asset: you can get store it in an asset server and later retrieve it again. Hence, we have to realize that such objects are NOT mutable. Only once they are rezzed they are mutable. This is a requirement for things to work. A rezzed object is therefore not an asset: it's world-data that can change (with the Region as authority? or the owner/viewer maybe, when they are online). Only once an object is taken back into inventory is the data send to an asset server and a new ID is created. Until that point all the data for such objects is exclusively stored in the region and people obtain the data for the shape of objects (not the textures, but for which texture ID is used on what face) from the region, not from an asset server. This follows from the mutablity argument (not from the fact that this how it works in SL too). > In respect of addressing, you mentioned using hashes as item > addresses, and this is of course my preferred strategy, which I have > described and advocated several times this week, and back in > September. Hash-based addressing has numerous excellent engineering > properties that put it head and shoulders above other schemes. I say > go with that approach. In any event, when we pit alternative schemes > against each other on merit, I bet nothing will come close to > hash-based. I can't think of any disadvantages. The hash has to have a large size of course, comparable to UUID's. Still,I'm willing to assume that with a lot of effort it would be possible to create an asset with a given hash that in fact is different... Would that be a problem? Once you know the data, you can reconstruct the item anyway. You also know the ID (hash or not). You can only know the hash if you already know the data anyway, or when you have access to it (of course). Being able to then create an asset that has the same hash, but in fact is white noise (I definitely can't think of any other way to construct a known hash) should simply result in the white noise being discarded: someone "uploads" data that has an already existing hash, then discard the uploaded data and use the old data. The result is the uploader/hacker didn't gain anything at all. > On the issue of caps, I think that keeping their semantics simple has > great merit, because heavyweight schemes are less likely to be > accepted, and complex ones are unlikely to be implemented uniformly. > But in any case, as I described to Vaughn, caps should be *optional* > anyway (ie. asset dependent). Having to acquire a cap in order to > fetch a Creative Commons licensed asset is unnecessary, and indeed it > is rather comic. A cap only needs to be requested when the asset > requires it, and only those assets that need it should bear the > burden. Hear hear! I like this idea very much :). But it is unrelated to the ID / unmutable data of course. This is just about how easy it is to get a cap for something. I guess that what you mean is that a free asset should have a cap that exists of it's hash. So that if you know the ID/hash (ie 'Z') you know immediately where to get it. > The issue of flag bits (or more generally, property fields) for > assets is one that interests me a lot, as it relates to the above. > As I described to Vaughn, it is the assets that impose requirements > on the protocol, not vice versa, so it is the assets that should > carry the properties that control the protocol. I've often desired mutable bit in no-modify objects in SL. There are numerous applications for it! The idea is that you have a no modify object but as owner still can change certain bits that define how it is used AND that are stored when you take it back into your inventory (are preserved when next time you rez it again). However, 'no modify' and the immutability that we talked about are different things of course! If we assume that such bits are simple changes to the object that are allowed by the owner at all times, then the only disadvantage is that (apparently) all data of the object needs to be stored multiple times: if their are 4 bits and the users "plays" with them until they had all 16 possibilities once in their inventory then we'd have 16 times the same data in the asset server. This however is just a way to look at it (compare with the way how we look at how a git server works: that view is highly inefficient too, though easy to grasp). The real implementation can of course make it so that it doesn't store that data 16 times... -- Carlo Wood From morgaine.dinova@googlemail.com Fri Apr 8 20:27:21 2011 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 A3D213A6A2A for ; Fri, 8 Apr 2011 20:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] 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 cqZlZB3jlimP for ; Fri, 8 Apr 2011 20:27:18 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by core3.amsl.com (Postfix) with ESMTP id C6E853A69E6 for ; Fri, 8 Apr 2011 20:27:18 -0700 (PDT) Received: by pxi20 with SMTP id 20so2338797pxi.27 for ; Fri, 08 Apr 2011 20:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=d2AkzZv/YrzaP0+aTXKeFwWJMjyXn+8810xMoAo7ZGM=; b=o1ZZxl5HinKYkudgQiVnv82OJqCWkyFJqPrgk7zaqkF3DR6kOqoB4QS7RhNQGQX6WG WDL+8v3xX8pzvrvpsb/a66LEMGCbXZ78l0X27B0sBrlUJd9Y8KLlXdH8fh88wRY7Ljtm 0XNnbt899+x843adFKMtFZOsiWQWzcN4YSLow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=B8O/j1g2nWi5UBAOUMAvc1uo4s2y4mUcJupn+b+0Gkm+3QAxtg6/TVd6YSaZws/wX6 bJ1r6oLvgbNpkPLLKl7NQw5xJYLGSgGHK85yMV8zP/Chd+8nh1MEK2LDDG1HPlMc49GX /bzwKKRNtT953zqlrDOf+1BDdI+ZCbKLQ54g8= MIME-Version: 1.0 Received: by 10.142.247.2 with SMTP id u2mr2492827wfh.107.1302319743190; Fri, 08 Apr 2011 20:29:03 -0700 (PDT) Received: by 10.142.246.6 with HTTP; Fri, 8 Apr 2011 20:29:03 -0700 (PDT) In-Reply-To: <20110409035837.0d324940@hikaru.localdomain> References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> <20110408223402.36ae68a9@hikaru.localdomain> <20110409035837.0d324940@hikaru.localdomain> Date: Sat, 9 Apr 2011 04:29:03 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00504502c5d2ad5c1904a073f1bd Subject: Re: [vwrap] Is 'Data Z' immutable (like a git snapshot)? 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: Sat, 09 Apr 2011 03:27:22 -0000 --00504502c5d2ad5c1904a073f1bd Content-Type: text/plain; charset=ISO-8859-1 I agree with virtually everything you've written here, Carlo. (And your observations about how this even applied to your experience with IRC were interesting too, and unexpected.) I'll just add a couple of small decorations. First, on the issue of "authorities" that control mutation, there is another way of looking at this, a way which any practitioner of Functional Programming would find very natural: a "mutating" object can be thought of as an infinite sequence of immutable timestamped object states. And while traditional imperative computing tends to consider FP as "odd", there is nothing at all odd about an incoming stream of events. There's your "mutation authority" for you --- it's merely the event stream generator, each event being immutable. :P This fits in perfectly with event-driven programming of course. The second point I'd like to make refers to your section about assets versus objects. As you say, there is a distinction to be made, and the semantic gap seems to open very wide between them when objects are changing rapidly. However, there is also an important way in which the two are related, which again could be considered the "FP viewpoint". Assets are really just immutable *STATES* of an object. In SL and in Opensim currently, assets provide the *initial* state of an object when it is brought into a region (rezzing), and new assets can subsequently be *generated* from it by taking a snapshot of the live object ("Take Copy"), or by saving the object on finally removing it from the world (derezzing). The "asset as an immutable object state" paradigm is very easy to see. All this seems to fit together rather nicely, and since it is the model that underlies Second Life, I think Linden Lab deserve kudos for a core data model that makes sense both conceptually and also for practical cacheability. Of course one can't just rest there, but it's a good starting place. :-) Going beyond where we are currently, the ability of active objects to deliver events to viewers is extremely weak in our current model, with an almost total lack of usable communications other than via repurposed chat streams. Other open world systems have a much stronger object communication model. For example objects in OpenWonderLand have two parts, one in-world and one in-client, and these two halves can talk to each other directly to implement any arbitrary complex behavior. And in OpenCobalt, although there are no "servers" in the peer-to-peer implementation of islands (but there are "router" hosts), the states of the fully programmable objects in one client's scenegraph automatically propagate to the scenegraphs in all other clients present. So again, there is a very powerful model of interaction between participants. Although we haven't placed object communications within our scope, if VWRAP succeeds then one day someone will need to extend it to region-client and inter-VW object communications as well. Morgaine. ======================= On Sat, Apr 9, 2011 at 2:58 AM, Carlo Wood wrote: > On Sat, 9 Apr 2011 02:11:00 +0100 > Morgaine wrote: > > > First of all, mutability breaks caching entirely, so it needs to be > > approached with great caution. Caching can make the difference > > between a great service and a totally unusable one (or at least one > > that doesn't work very well), so if mutability is allowed then things > > need to be designed in such a way that caching still works *most of > > the time*, namely in between mutations. > > Yup, I totally agree. As you might know I've been working a lot > on improving the IRC protocol at the time. IRC works with handles > (nicks and channel names) and everything else is mutable (ie, > the channel topic, the channel modes, etc). This turned out to > be an unsolvable horror (and trust me on that please, I worked > 7 years on this topic). What I did was change nick names into > numerics that are *unmutable*, so at least the bloody handle > wasn't changing all the time, heheh (channel names are already > unmutable) and then assigned authortities for the nick names > (namely those servers where the users are connected to). Authorities > have the nice property to have exclusively an outwards message > stream: from the authority away, and therefore for streamable: > if every mutating operation is kept in order than everything > remains synched in the end. This requires that one always ASKS > the authority to change something and not tell it that you > changed something. For example, I changed it that when you KICK > someone from a channel, then a request is sent to the server > where that person is connected to and that server actually > sends out the message that this user is removed from the channel. > Making an authority for channels was never done, there I have > tried to solve this problem with timestamps. > > I don't think we should go this route (using time stamps). > Also, the authority "solution" has a the major disadvantage > that it only works in a non-cyclic routing tree; and and > as soon as any rerouting takes place you get into MAJOR problems > for messages that were still under way. > > The ONLY way to really avoid all those nightmares is to adopt > how git and mercurial work: immutable data that some hash ID > refers to, which, as you said is, "never" deleted. > > > This is an issue which has occupied many minds for decades, and I > > think it can be distilled into the widely accepted notion that cached > > objects should never be overwritten, but only joined by updated > > versions. At a stroke this lets highly concurrent asset services > > avoid the thorny issue of writing in the presence of concurrent > > readers, and at the same time it lets caches have very simple update > > semantics since nothing is mutable from their perspective. The only > > cost is some loss of disk space to hold old versions, which is rarely > > significant given disk sizes and costs today. > > You totally convinced me :). And for the others: note that I tried > it in other ways for YEARS. So, it means something that now I'm > convinced that wasn't right and we should avoid it. > > > While that is good for asset services and caches, it does place the > > burden of achieving mutability on the parties who require it. And > > that of course is how burdens should be borne. > > Also very true. > > > What this means for virtual worlds is that a mutator becomes > > responsible for notifying endpoints that something has mutated, so > > that they can fetch the new versions. > > This sound like an 'authority' however: one entity and one alone > can issue the out going message that something has changed... > That is not how it should work though. I can't wrap my finger > around the difference yet though :/... If we go for immutability > then why suddenly are we talking about having to notify others > that something changed? > > Of course, things DO change in-world. For example, someone could > detach something - and attach something else. Then the Agent of > that avatar is the authority I'd think: the viewer requests the > Agent to make a change, and if approved then the Agent tells the > viewer and everyone else that the change was made. > > I guess that the big difference is that in those outgoing messages > is no large 'data'.. no ASSET data. The Asset servers themselves > would never do this. Only work-tied (location tied) things will do > this: avatars and rezzed objects, with respectively the Agent > and the Region as authority/source of the mutating messages. > > Routing probably goes all through the Region server: if someone > changes an attachment while they are 4000 meter away (in the same > sim) then that STILL has to be routed to everyone else in the sim, > and not later. Basically at least, the Agent *tells* the Region > server that the avatars appears has changed and the Region sends > outward messages of that fact to everyone who is connected. > > As long as all mutating messages go in one direction: away from > the authority (the Agent in this case) and there are no RE-routing > issues (which is not the case here) then there are no problems > with this model. > > > This needn't be an onerous > > requirement, and it may not even need to be wrapped up in security > > tape, since having had access once probably qualifies you for an > > unconditional update. In any case, the original item is still in its > > asset service (as well as in users' terabyte caches), so one very > > useful property of this approach is that a simulation can't be broken > > for long by a poor update since reverting is always possible. That's > > a an engineering plus point. > > If all things are well, then the outgoing 'mutation' message from > the Agent/Region only contains new asset ID's, not the data itself. > And people will get the new data using the new ID. > > This sound perfectly ok for textures (which aren't even mutatable > in-world), but what about a little change to the shape of a prim > of an object? An object (existing of many prims) is an asset: > you can get store it in an asset server and later retrieve it > again. Hence, we have to realize that such objects are NOT > mutable. Only once they are rezzed they are mutable. This is a > requirement for things to work. A rezzed object is therefore > not an asset: it's world-data that can change (with the Region > as authority? or the owner/viewer maybe, when they are online). > Only once an object is taken back into inventory is the data > send to an asset server and a new ID is created. Until that point > all the data for such objects is exclusively stored in the region > and people obtain the data for the shape of objects (not the textures, > but for which texture ID is used on what face) from the region, > not from an asset server. > > This follows from the mutablity argument (not from the fact that > this how it works in SL too). > > > In respect of addressing, you mentioned using hashes as item > > addresses, and this is of course my preferred strategy, which I have > > described and advocated several times this week, and back in > > September. Hash-based addressing has numerous excellent engineering > > properties that put it head and shoulders above other schemes. I say > > go with that approach. In any event, when we pit alternative schemes > > against each other on merit, I bet nothing will come close to > > hash-based. > > I can't think of any disadvantages. The hash has to have a large size > of course, comparable to UUID's. Still,I'm willing to assume that > with a lot of effort it would be possible to create an asset with > a given hash that in fact is different... Would that be a problem? > > Once you know the data, you can reconstruct the item anyway. You > also know the ID (hash or not). You can only know the hash if you > already know the data anyway, or when you have access to it (of course). > Being able to then create an asset that has the same hash, but in > fact is white noise (I definitely can't think of any other way > to construct a known hash) should simply result in the white noise > being discarded: someone "uploads" data that has an already existing > hash, then discard the uploaded data and use the old data. The result > is the uploader/hacker didn't gain anything at all. > > > On the issue of caps, I think that keeping their semantics simple has > > great merit, because heavyweight schemes are less likely to be > > accepted, and complex ones are unlikely to be implemented uniformly. > > But in any case, as I described to Vaughn, caps should be *optional* > > anyway (ie. asset dependent). Having to acquire a cap in order to > > fetch a Creative Commons licensed asset is unnecessary, and indeed it > > is rather comic. A cap only needs to be requested when the asset > > requires it, and only those assets that need it should bear the > > burden. > > Hear hear! I like this idea very much :). > But it is unrelated to the ID / unmutable data of course. > This is just about how easy it is to get a cap for something. > I guess that what you mean is that a free asset should have a > cap that exists of it's hash. So that if you know the ID/hash > (ie 'Z') you know immediately where to get it. > > > The issue of flag bits (or more generally, property fields) for > > assets is one that interests me a lot, as it relates to the above. > > As I described to Vaughn, it is the assets that impose requirements > > on the protocol, not vice versa, so it is the assets that should > > carry the properties that control the protocol. > > I've often desired mutable bit in no-modify objects in SL. > There are numerous applications for it! The idea is that > you have a no modify object but as owner still can change > certain bits that define how it is used AND that are > stored when you take it back into your inventory (are preserved > when next time you rez it again). However, 'no modify' and > the immutability that we talked about are different things > of course! If we assume that such bits are simple changes > to the object that are allowed by the owner at all times, > then the only disadvantage is that (apparently) all data > of the object needs to be stored multiple times: if their > are 4 bits and the users "plays" with them until they had > all 16 possibilities once in their inventory then we'd have > 16 times the same data in the asset server. > > This however is just a way to look at it (compare with > the way how we look at how a git server works: that view > is highly inefficient too, though easy to grasp). > > The real implementation can of course make it so that it > doesn't store that data 16 times... > > -- > Carlo Wood > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --00504502c5d2ad5c1904a073f1bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with virtually everything you've written here, Carlo.

    (A= nd your observations about how this even applied to your experience with IR= C were interesting too, and unexpected.)

    I'll just add a couple = of small decorations.

    First, on the issue of=A0 "authorities" that control mutation= , there is another way of looking at this, a way which any practitioner of = Functional Programming would find very natural:=A0 a "mutating" o= bject can be thought of as an infinite sequence of immutable timestamped ob= ject states.=A0 And while traditional imperative computing tends to conside= r FP as "odd", there is nothing at all odd about an incoming stre= am of events.=A0 There's your "mutation authority" for you --= - it's merely the event stream generator, each event being immutable. := P=A0 This fits in perfectly with event-driven programming of course.

    The second point I'd like to make refers to your section about asse= ts versus objects.=A0 As you say, there is a distinction to be made, and th= e semantic gap seems to open very wide between them when objects are changi= ng rapidly.

    However, there is also an important way in which the two are related, w= hich again could be considered the "FP viewpoint".=A0 Assets are = really just immutable STATES of an object.=A0 In SL and in Opensim c= urrently, assets provide the initial state of an object when it is b= rought into a region (rezzing), and new assets can subsequently be gener= ated from it by taking a snapshot of the live object ("Take Copy&q= uot;), or by saving the object on finally removing it from the world (derez= zing).=A0 The "asset as an immutable object state" paradigm is ve= ry easy to see.

    All this seems to fit together rather nicely, and since it is the model= that underlies Second Life, I think Linden Lab deserve kudos for a core da= ta model that makes sense both conceptually and also for practical cacheabi= lity.=A0 Of course one can't just rest there, but it's a good start= ing place. :-)

    Going beyond where we are currently, the ability of active objects to d= eliver events to viewers is extremely weak in our current model, with an al= most total lack of usable communications other than via repurposed chat str= eams.

    Other open world systems have a much stronger object communication mode= l.=A0 For example objects in OpenWonderLand have two parts, one in-world an= d one in-client, and these two halves can talk to each other directly to im= plement any arbitrary complex behavior.=A0 And in OpenCobalt, although ther= e are no "servers" in the peer-to-peer implementation of islands = (but there are "router" hosts), the states of the fully programma= ble objects in one client's scenegraph automatically propagate to the s= cenegraphs in all other clients present.=A0 So again, there is a very power= ful model of interaction between participants.

    Although we haven't placed object communications=A0 within our scop= e, if VWRAP succeeds then one day someone will need to extend it to region-= client and inter-VW object communications as well.


    Morgaine.




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

    On Sat, Apr 9, 2011 at 2:58 = AM, Carlo Wood <ca= rlo@alinoe.com> wrote:
    On Sat, 9 Apr 2011 02:11:00 +0100
    Morgaine <morgaine.din= ova@googlemail.com> wrote:

    > First of all, mutability breaks caching entirely, so it needs to be > approached with great caution. =A0Caching can make the difference
    > between a great service and a totally unusable one (or at least one > that doesn't work very well), so if mutability is allowed then thi= ngs
    > need to be designed in such a way that caching still works *most of > the time*, namely in between mutations.

    Yup, I totally agree. As you might know I've been working a lot on improving the IRC protocol at the time. IRC works with handles
    (nicks and channel names) and everything else is mutable (ie,
    the channel topic, the channel modes, etc). This turned out to
    be an unsolvable horror (and trust me on that please, I worked
    7 years on this topic). What I did was change nick names into
    numerics that are *unmutable*, so at least the bloody handle
    wasn't changing all the time, heheh (channel names are already
    unmutable) and then assigned authortities for the nick names
    (namely those servers where the users are connected to). Authorities
    have the nice property to have exclusively an outwards message
    stream: from the authority away, and therefore for streamable:
    if every mutating operation is kept in order than everything
    remains synched in the end. This requires that one always ASKS
    the authority to change something and not tell it that you
    changed something. For example, I changed it that when you KICK
    someone from a channel, then a request is sent to the server
    where that person is connected to and that server actually
    sends out the message that this user is removed from the channel.
    Making an authority for channels was never done, there I have
    tried to solve this problem with timestamps.

    I don't think we should go this route (using time stamps).
    Also, the authority "solution" has a the major disadvantage
    that it only works in a non-cyclic routing tree; and and
    as soon as any rerouting takes place you get into MAJOR problems
    for messages that were still under way.

    The ONLY way to really avoid all those nightmares is to adopt
    how git and mercurial work: immutable data that some hash ID
    refers to, which, as you said is, "never" deleted.

    > This is an issue which has occupied many minds for decades, and I
    > think it can be distilled into the widely accepted notion that cached<= br> > objects should never be overwritten, but only joined by updated
    > versions. =A0At a stroke this lets highly concurrent asset services > avoid the thorny issue of writing in the presence of concurrent
    > readers, and at the same time it lets caches have very simple update > semantics since nothing is mutable from their perspective. =A0The only=
    > cost is some loss of disk space to hold old versions, which is rarely<= br> > significant given disk sizes and costs today.

    You totally convinced me :). And for the others: note that I tried it in other ways for YEARS. So, it means something that now I'm
    convinced that wasn't right and we should avoid it.

    > While that is good for asset services and caches, it does place the > burden of achieving mutability on the parties who require it. =A0And > that of course is how burdens should be borne.

    Also very true.

    > What this means for virtual worlds is that a mutator becomes
    > responsible for notifying endpoints that something has mutated, so
    > that they can fetch the new versions.

    This sound like an 'authority' however: one entity and one al= one
    can issue the out going message that something has changed...
    That is not how it should work though. I can't wrap my finger
    around the difference yet though :/... If we go for immutability
    then why suddenly are we talking about having to notify others
    that something changed?

    Of course, things DO change in-world. For example, someone could
    detach something - and attach something else. Then the Agent of
    that avatar is the authority I'd think: the viewer requests the
    Agent to make a change, and if approved then the Agent tells the
    viewer and everyone else that the change was made.

    I guess that the big difference is that in those outgoing messages
    is no large 'data'.. no ASSET data. =A0The Asset servers themselves=
    would never do this. Only work-tied (location tied) things will do
    this: avatars and rezzed objects, with respectively the Agent
    and the Region as authority/source of the mutating messages.

    Routing probably goes all through the Region server: if someone
    changes an attachment while they are 4000 meter away (in the same
    sim) then that STILL has to be routed to everyone else in the sim,
    and not later. Basically at least, the Agent *tells* the Region
    server that the avatars appears has changed and the Region sends
    outward messages of that fact to everyone who is connected.

    As long as all mutating messages go in one direction: away from
    the authority (the Agent in this case) and there are no RE-routing
    issues (which is not the case here) then there are no problems
    with this model.

    > =A0This needn't be an onerous
    > requirement, and it may not even need to be wrapped up in security
    > tape, since having had access once probably qualifies you for an
    > unconditional update. =A0In any case, the original item is still in it= s
    > asset service (as well as in users' terabyte caches), so one very<= br> > useful property of this approach is that a simulation can't be bro= ken
    > for long by a poor update since reverting is always possible. =A0That&= #39;s
    > a an engineering plus point.

    If all things are well, then the outgoing 'mutation' message = from
    the Agent/Region only contains new asset ID's, not the data itself.
    And people will get the new data using the new ID.

    This sound perfectly ok for textures (which aren't even mutatable
    in-world), but what about a little change to the shape of a prim
    of an object? =A0An object (existing of many prims) is an asset:
    you can get store it in an asset server and later retrieve it
    again. =A0Hence, we have to realize that such objects are NOT
    mutable. Only once they are rezzed they are mutable. This is a
    requirement for things to work. A rezzed object is therefore
    not an asset: it's world-data that can change (with the Region
    as authority? or the owner/viewer maybe, when they are online).
    Only once an object is taken back into inventory is the data
    send to an asset server and a new ID is created. Until that point
    all the data for such objects is exclusively stored in the region
    and people obtain the data for the shape of objects (not the textures,
    but for which texture ID is used on what face) from the region,
    not from an asset server.

    This follows from the mutablity argument (not from the fact that
    this how it works in SL too).

    > In respect of addressing, you mentioned using hashes as item
    > addresses, and this is of course my preferred strategy, which I have > described and advocated several times this week, and back in
    > September. =A0Hash-based addressing has numerous excellent engineering=
    > properties that put it head and shoulders above other schemes. =A0I sa= y
    > go with that approach. =A0In any event, when we pit alternative scheme= s
    > against each other on merit, I bet nothing will come close to
    > hash-based.

    I can't think of any disadvantages. The hash has to have a large = size
    of course, comparable to UUID's. Still,I'm willing to assume that with a lot of effort it would be possible to create an asset with
    a given hash that in fact is different... Would that be a problem?

    Once you know the data, you can reconstruct the item anyway. You
    also know the ID (hash or not). You can only know the hash if you
    already know the data anyway, or when you have access to it (of course). Being able to then create an asset that has the same hash, but in
    fact is white noise (I definitely can't think of any other way
    to construct a known hash) should simply result in the white noise
    being discarded: someone "uploads" data that has an already exist= ing
    hash, then discard the uploaded data and use the old data. The result
    is the uploader/hacker didn't gain anything at all.

    > On the issue of caps, I think that keeping their semantics simple has<= br> > great merit, because heavyweight schemes are less likely to be
    > accepted, and complex ones are unlikely to be implemented uniformly. > But in any case, as I described to Vaughn, caps should be *optional* > anyway (ie. asset dependent). =A0Having to acquire a cap in order to > fetch a Creative Commons licensed asset is unnecessary, and indeed it<= br> > is rather comic. =A0A cap only needs to be requested when the asset > requires it, and only those assets that need it should bear the
    > burden.

    Hear hear! I like this idea very much :).
    But it is unrelated to the ID / unmutable data of course.
    This is just about how easy it is to get a cap for something.
    I guess that what you mean is that a free asset should have a
    cap that exists of it's hash. So that if you know the ID/hash
    (ie 'Z') you know immediately where to get it.

    > The issue of flag bits (or more generally, property fields) for
    > assets is one that interests me a lot, as it relates to the above.
    > As I described to Vaughn, it is the assets that impose requirements > on the protocol, not vice versa, so it is the assets that should
    > carry the properties that control the protocol.

    I've often desired mutable bit in no-modify objects in SL.
    There are numerous applications for it! The idea is that
    you have a no modify object but as owner still can change
    certain bits that define how it is used AND that are
    stored when you take it back into your inventory (are preserved
    when next time you rez it again). However, 'no modify' and
    the immutability that we talked about are different things
    of course! If we assume that such bits are simple changes
    to the object that are allowed by the owner at all times,
    then the only disadvantage is that (apparently) all data
    of the object needs to be stored multiple times: if their
    are 4 bits and the users "plays" with them until they had
    all 16 possibilities once in their inventory then we'd have
    16 times the same data in the asset server.

    This however is just a way to look at it (compare with
    the way how we look at how a git server works: that view
    is highly inefficient too, though easy to grasp).

    The real implementation can of course make it so that it
    doesn't store that data 16 times...

    --
    Carlo Wood <carlo@alinoe.com>
    _______________________________________________
    vwrap mailing list
    vwrap@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/vwrap

    --00504502c5d2ad5c1904a073f1bd-- From djshag@hotmail.com Sat Apr 9 02:36:40 2011 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 7F9843A68D1 for ; Sat, 9 Apr 2011 02:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, STOX_REPLY_TYPE=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 nnK0VrNzngtk for ; Sat, 9 Apr 2011 02:36:38 -0700 (PDT) Received: from blu0-omc2-s1.blu0.hotmail.com (blu0-omc2-s1.blu0.hotmail.com [65.55.111.76]) by core3.amsl.com (Postfix) with ESMTP id DA6623A68CD for ; Sat, 9 Apr 2011 02:36:37 -0700 (PDT) Received: from BLU159-DS12 ([65.55.111.73]) by blu0-omc2-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 9 Apr 2011 02:38:23 -0700 X-Originating-IP: [74.58.130.10] X-Originating-Email: [djshag@hotmail.com] Message-ID: From: "Patnad Babii" To: References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com><4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com><4D98AC5F.70501@gmail.com><20110408223402.36ae68a9@hikaru.localdomain> <20110409035837.0d324940@hikaru.localdomain> In-Reply-To: <20110409035837.0d324940@hikaru.localdomain> Date: Sat, 9 Apr 2011 05:38:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3508.1109 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3508.1109 X-OriginalArrivalTime: 09 Apr 2011 09:38:23.0964 (UTC) FILETIME=[DEDCE9C0:01CBF699] Subject: Re: [vwrap] Is 'Data Z' immutable (like a git snapshot)? 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: Sat, 09 Apr 2011 09:36:40 -0000 While reading through this email, I've got an idea, that i don't think we spoke about before but I really think it could become handy. We have to allow some kind of synchronisation to take place on some assets. Let me describe you the use case i see where it fits. I make a vendor's server lets say, that i'm going to use on GRID A and GRID B. I don't visit GRID B very often, but on the other hand i'm connecting on GRID A alot. I do some modification on my server's code in GRID A and I'd like the GRID B to have the exact same modifications without having to log there and start to code again. So, what would be really useful is if in a way I could say to GRID B to refresh my server without having to log in there. That's it, that was my idea, not sure it fits right here right now, but might be to take in consideration while designing the protocol. Thanks -----Message d'origine----- From: Carlo Wood Sent: Friday, April 08, 2011 9:58 PM To: vwrap@ietf.org Subject: Re: [vwrap] Is 'Data Z' immutable (like a git snapshot)? On Sat, 9 Apr 2011 02:11:00 +0100 Morgaine wrote: > First of all, mutability breaks caching entirely, so it needs to be > approached with great caution. Caching can make the difference > between a great service and a totally unusable one (or at least one > that doesn't work very well), so if mutability is allowed then things > need to be designed in such a way that caching still works *most of > the time*, namely in between mutations. Yup, I totally agree. As you might know I've been working a lot on improving the IRC protocol at the time. IRC works with handles (nicks and channel names) and everything else is mutable (ie, the channel topic, the channel modes, etc). This turned out to be an unsolvable horror (and trust me on that please, I worked 7 years on this topic). What I did was change nick names into numerics that are *unmutable*, so at least the bloody handle wasn't changing all the time, heheh (channel names are already unmutable) and then assigned authortities for the nick names (namely those servers where the users are connected to). Authorities have the nice property to have exclusively an outwards message stream: from the authority away, and therefore for streamable: if every mutating operation is kept in order than everything remains synched in the end. This requires that one always ASKS the authority to change something and not tell it that you changed something. For example, I changed it that when you KICK someone from a channel, then a request is sent to the server where that person is connected to and that server actually sends out the message that this user is removed from the channel. Making an authority for channels was never done, there I have tried to solve this problem with timestamps. I don't think we should go this route (using time stamps). Also, the authority "solution" has a the major disadvantage that it only works in a non-cyclic routing tree; and and as soon as any rerouting takes place you get into MAJOR problems for messages that were still under way. The ONLY way to really avoid all those nightmares is to adopt how git and mercurial work: immutable data that some hash ID refers to, which, as you said is, "never" deleted. > This is an issue which has occupied many minds for decades, and I > think it can be distilled into the widely accepted notion that cached > objects should never be overwritten, but only joined by updated > versions. At a stroke this lets highly concurrent asset services > avoid the thorny issue of writing in the presence of concurrent > readers, and at the same time it lets caches have very simple update > semantics since nothing is mutable from their perspective. The only > cost is some loss of disk space to hold old versions, which is rarely > significant given disk sizes and costs today. You totally convinced me :). And for the others: note that I tried it in other ways for YEARS. So, it means something that now I'm convinced that wasn't right and we should avoid it. > While that is good for asset services and caches, it does place the > burden of achieving mutability on the parties who require it. And > that of course is how burdens should be borne. Also very true. > What this means for virtual worlds is that a mutator becomes > responsible for notifying endpoints that something has mutated, so > that they can fetch the new versions. This sound like an 'authority' however: one entity and one alone can issue the out going message that something has changed... That is not how it should work though. I can't wrap my finger around the difference yet though :/... If we go for immutability then why suddenly are we talking about having to notify others that something changed? Of course, things DO change in-world. For example, someone could detach something - and attach something else. Then the Agent of that avatar is the authority I'd think: the viewer requests the Agent to make a change, and if approved then the Agent tells the viewer and everyone else that the change was made. I guess that the big difference is that in those outgoing messages is no large 'data'.. no ASSET data. The Asset servers themselves would never do this. Only work-tied (location tied) things will do this: avatars and rezzed objects, with respectively the Agent and the Region as authority/source of the mutating messages. Routing probably goes all through the Region server: if someone changes an attachment while they are 4000 meter away (in the same sim) then that STILL has to be routed to everyone else in the sim, and not later. Basically at least, the Agent *tells* the Region server that the avatars appears has changed and the Region sends outward messages of that fact to everyone who is connected. As long as all mutating messages go in one direction: away from the authority (the Agent in this case) and there are no RE-routing issues (which is not the case here) then there are no problems with this model. > This needn't be an onerous > requirement, and it may not even need to be wrapped up in security > tape, since having had access once probably qualifies you for an > unconditional update. In any case, the original item is still in its > asset service (as well as in users' terabyte caches), so one very > useful property of this approach is that a simulation can't be broken > for long by a poor update since reverting is always possible. That's > a an engineering plus point. If all things are well, then the outgoing 'mutation' message from the Agent/Region only contains new asset ID's, not the data itself. And people will get the new data using the new ID. This sound perfectly ok for textures (which aren't even mutatable in-world), but what about a little change to the shape of a prim of an object? An object (existing of many prims) is an asset: you can get store it in an asset server and later retrieve it again. Hence, we have to realize that such objects are NOT mutable. Only once they are rezzed they are mutable. This is a requirement for things to work. A rezzed object is therefore not an asset: it's world-data that can change (with the Region as authority? or the owner/viewer maybe, when they are online). Only once an object is taken back into inventory is the data send to an asset server and a new ID is created. Until that point all the data for such objects is exclusively stored in the region and people obtain the data for the shape of objects (not the textures, but for which texture ID is used on what face) from the region, not from an asset server. This follows from the mutablity argument (not from the fact that this how it works in SL too). > In respect of addressing, you mentioned using hashes as item > addresses, and this is of course my preferred strategy, which I have > described and advocated several times this week, and back in > September. Hash-based addressing has numerous excellent engineering > properties that put it head and shoulders above other schemes. I say > go with that approach. In any event, when we pit alternative schemes > against each other on merit, I bet nothing will come close to > hash-based. I can't think of any disadvantages. The hash has to have a large size of course, comparable to UUID's. Still,I'm willing to assume that with a lot of effort it would be possible to create an asset with a given hash that in fact is different... Would that be a problem? Once you know the data, you can reconstruct the item anyway. You also know the ID (hash or not). You can only know the hash if you already know the data anyway, or when you have access to it (of course). Being able to then create an asset that has the same hash, but in fact is white noise (I definitely can't think of any other way to construct a known hash) should simply result in the white noise being discarded: someone "uploads" data that has an already existing hash, then discard the uploaded data and use the old data. The result is the uploader/hacker didn't gain anything at all. > On the issue of caps, I think that keeping their semantics simple has > great merit, because heavyweight schemes are less likely to be > accepted, and complex ones are unlikely to be implemented uniformly. > But in any case, as I described to Vaughn, caps should be *optional* > anyway (ie. asset dependent). Having to acquire a cap in order to > fetch a Creative Commons licensed asset is unnecessary, and indeed it > is rather comic. A cap only needs to be requested when the asset > requires it, and only those assets that need it should bear the > burden. Hear hear! I like this idea very much :). But it is unrelated to the ID / unmutable data of course. This is just about how easy it is to get a cap for something. I guess that what you mean is that a free asset should have a cap that exists of it's hash. So that if you know the ID/hash (ie 'Z') you know immediately where to get it. > The issue of flag bits (or more generally, property fields) for > assets is one that interests me a lot, as it relates to the above. > As I described to Vaughn, it is the assets that impose requirements > on the protocol, not vice versa, so it is the assets that should > carry the properties that control the protocol. I've often desired mutable bit in no-modify objects in SL. There are numerous applications for it! The idea is that you have a no modify object but as owner still can change certain bits that define how it is used AND that are stored when you take it back into your inventory (are preserved when next time you rez it again). However, 'no modify' and the immutability that we talked about are different things of course! If we assume that such bits are simple changes to the object that are allowed by the owner at all times, then the only disadvantage is that (apparently) all data of the object needs to be stored multiple times: if their are 4 bits and the users "plays" with them until they had all 16 possibilities once in their inventory then we'd have 16 times the same data in the asset server. This however is just a way to look at it (compare with the way how we look at how a git server works: that view is highly inefficient too, though easy to grasp). The real implementation can of course make it so that it doesn't store that data 16 times... -- Carlo Wood _______________________________________________ vwrap mailing list vwrap@ietf.org https://www.ietf.org/mailman/listinfo/vwrap From morgaine.dinova@googlemail.com Sat Apr 9 09:04:08 2011 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 BC9673A68FD for ; Sat, 9 Apr 2011 09:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] 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 bC0XNhPsl8zI for ; Sat, 9 Apr 2011 09:04:05 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 4073D3A6876 for ; Sat, 9 Apr 2011 09:04:05 -0700 (PDT) Received: by qyk7 with SMTP id 7so2859830qyk.10 for ; Sat, 09 Apr 2011 09:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TxFrMEPodgta7l6Jin0nlEsc/MXflo1A+k3Hpy4icSY=; b=E82ejZEcfMOiY0TyfomiGFefZCZeD9cvWYhnOuw6cK/zaUjqKiV2Tf/kMNAI0AGnfd Vt7i2JEGFzAArBShyJA+BbbxkNsrTLNwcKPFpxCOILG6IRTBVkXtxi73Eh4Hpxlo1Dkq cpF04lVS27iPYwgjpKPQwaqTs6IVLnsSiJ2KQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=p3q9qh2h0IrS/5gSUanayFV7jaIXE1yGvUdx8uylI9k3Gb2f9dhcEBPCnlwECiZSLC m7rwAF3LLEywK3wesMNKH3VBCgfKwrLunI7otKoC9Er/OLP22aXXY4b29fM5jUwr0M9k t3yl/MXz1HUc0E/+dNG/9mtrAT+M/Qo5M0Qu4= MIME-Version: 1.0 Received: by 10.229.37.130 with SMTP id x2mr2810458qcd.147.1302365150819; Sat, 09 Apr 2011 09:05:50 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sat, 9 Apr 2011 09:05:50 -0700 (PDT) In-Reply-To: References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> <20110408223402.36ae68a9@hikaru.localdomain> <20110409035837.0d324940@hikaru.localdomain> Date: Sat, 9 Apr 2011 17:05:50 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016368340c02eb75204a07e8419 Subject: Re: [vwrap] Is 'Data Z' immutable (like a git snapshot)? 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: Sat, 09 Apr 2011 16:04:08 -0000 --0016368340c02eb75204a07e8419 Content-Type: text/plain; charset=ISO-8859-1 Patnad, if you mean synchronized updates of objects, then yes, this is what Carlo and I were discussing in the emails of this thread. That's the "mutability" of an object to which we were referring. However, it shouldn't happen through actual mutation of an asset in the asset services (in our view), because as we discussed earlier, this would have bad consequences for the cacheability of assets, it would complicate asset services and make them less concurrently scalable, and there would be no means of fault isolation when an update delivers bad data and propagates to everyone automatically. Instead, we were envisaging all assets in asset services being completely immutable, always. Then an "update" would consist of adding another newer asset to the asset service, and signaling that an update exists only to the desired endpoints. This would allow control over the breadth of update effect, since endpoints that are not notified would not automatically sync up, so you can select your own target set for your update trial. Although we haven't discussed the following mechanism yet, the way I envisage updates being propagated is through an optional subscription path in the protocol, which has the merit that the burden of updateability rests only on those assets that require it, and not on all assets. I mentioned "property fields" (ie. bits or flags) in a response to Carlo yestereday, and this is one place where the notion of "asset properties" can be put to good use. If an asset is marked as being "*Updateable*" through a property bit, it is still entirely immutable in asset services and remains valid in all caches. However, at the point where a client (or a region server in the case of a bounding-box / collision mesh asset) receives the asset, when it notices the "*Updateable*" property bit on the asset then it has the option of availing itself of the update when it becomes available. The way this would work in my subscription-based approach is very simple. On noticing the *Updateable*" bit being set in an attribute for asset A, the receiving endpoint E would send off a protocol message which says "*This endpoint E wishes to subscribe to notifications for updates on asset A*", which would be a protocol message type defined in our protocol. Notice that this makes the update process "*opt-in*", which is a very desirable trait especially in regards to privacy and security. But where would the recipient endpoint send this message? I propose that specifying the target should be kept flexible and extensible by placing that information in yet another asset, which the asset service can give the recipient upon request. This can work as follows, although there are many possible variations on this theme: The party that offers updateability of asset A also stores an "*UpdateInfo*" asset in the same asset service, a tuple structured like this: *UpdateInfo:{A, UpdateSubscriptionURI, Description}* When the asset service receives this *UpdateInfo* asset, it creates a local binding between asset A and the URI of this* *UpdateInfo asset, such that if an endpoint subsequently requests *fetchUpdateInfo(A)* then the URI of the UpdateInfo asset is returned. The requester can then use that URI to fetch the UpdateInfo asset using the standard asset fetch mechanism, and can then use the URI held in the received *UpdateSubscriptionURI* field to send a subscription request to the party offering updates. There are many possible variations on this idea, but the key to flexibility is holding the update information in a new asset. This introduces many benefits: - Ordinary assets do not carry the burden of any update machinery. - Updateable assets that the user does not wish to update do not carry the burden of any update machinery either (the "*Updateable*" property is just ignored at the time the asset is received). - If a recipient that did not initially subscribe to updates changes its mind later, nothing is lost, because the update contact information is securely stored in the asset service and can be requested at any time. - It also allows endpoints to choose not to subscribe to updates at the time of asset receipt but as a scheduled background activity instead. - Asset services can continue to do what they do best, namely just stream immutable assets at blue light speeds. The separate binding service (a simple hashed lookup keyed on the same asset address as normal asset fetches) is a side facility, and doesn't impact on the asset service at all. - The update mechanism is opt-in, which is a benefit for privacy and security. - The party offering the update can easily store a new *UpdateInfo* asset if the *UpdateSubscriptionURI* changes, which the asset service can either use to replace its previous binding, or else just add it to a list of *UpdateInfo* offers. - The *UpdateInfo* assets themselves are immutably stored in the asset service, so the bindings are recoverable even if lost. - Caching works normally for all assets, even the updateable ones. - The updater retains full control over to whom to offer updates out of the opt-ins, and can reduce the set of endpoints updated to suit its policy or resources. - The *UpdateInfo* assets don't even need to be stored in the same asset service as the assets to which they are bound. It's perfectly possible to have asset sites dedicated to update notifications alone. This would require clients to have knowledge of such sites so that they request update notifications to them instead of to the original asset services, but it's not particularly hard. How updates are actually offered later, once they become available, is a separate issue. The above just handles subscribing to notifications about updates. It's pretty easy to see how the circle could be made complete though --- the updater notifies opt-ins that an update is available, upon which they can fetch the new asset from an asset service and save it as an asset replacement in their cache. How the notification is sent by the updater should be flexible. I have implied that the user's agent service is online and so direct notification is possible, as this will probably become much more common tomorrow under IPv6 which does not hide clients behind NAT. Other means by which updaters can send update notifications should be provided too though. Alternatively, regions could subscribe to be notified of updates to client assets, and when the region is sending the asset URIs to its attached clients, it could pass any notifications about updates along to these clients too. Giving regions more work is not a very good idea though. There are lots of possible alternatives in this area. I've described only one or two. Morgaine. =========================== On Sat, Apr 9, 2011 at 10:38 AM, Patnad Babii wrote: > While reading through this email, I've got an idea, that i don't think we > spoke about before but I really think it could become handy. > > We have to allow some kind of synchronisation to take place on some assets. > > Let me describe you the use case i see where it fits. > > I make a vendor's server lets say, that i'm going to use on GRID A and GRID > B. > > I don't visit GRID B very often, but on the other hand i'm connecting on > GRID A alot. > > I do some modification on my server's code in GRID A and I'd like the GRID > B to have the exact same modifications without having to log there and start > to code again. > > So, what would be really useful is if in a way I could say to GRID B to > refresh my server without having to log in there. > > That's it, that was my idea, not sure it fits right here right now, but > might be to take in consideration while designing the protocol. > > Thanks > > -----Message d'origine----- From: Carlo Wood > Sent: Friday, April 08, 2011 9:58 PM > To: vwrap@ietf.org > Subject: Re: [vwrap] Is 'Data Z' immutable (like a git snapshot)? > > > On Sat, 9 Apr 2011 02:11:00 +0100 > Morgaine wrote: > > First of all, mutability breaks caching entirely, so it needs to be >> approached with great caution. Caching can make the difference >> between a great service and a totally unusable one (or at least one >> that doesn't work very well), so if mutability is allowed then things >> need to be designed in such a way that caching still works *most of >> the time*, namely in between mutations. >> > > Yup, I totally agree. As you might know I've been working a lot > on improving the IRC protocol at the time. IRC works with handles > (nicks and channel names) and everything else is mutable (ie, > the channel topic, the channel modes, etc). This turned out to > be an unsolvable horror (and trust me on that please, I worked > 7 years on this topic). What I did was change nick names into > numerics that are *unmutable*, so at least the bloody handle > wasn't changing all the time, heheh (channel names are already > unmutable) and then assigned authortities for the nick names > (namely those servers where the users are connected to). Authorities > have the nice property to have exclusively an outwards message > stream: from the authority away, and therefore for streamable: > if every mutating operation is kept in order than everything > remains synched in the end. This requires that one always ASKS > the authority to change something and not tell it that you > changed something. For example, I changed it that when you KICK > someone from a channel, then a request is sent to the server > where that person is connected to and that server actually > sends out the message that this user is removed from the channel. > Making an authority for channels was never done, there I have > tried to solve this problem with timestamps. > > I don't think we should go this route (using time stamps). > Also, the authority "solution" has a the major disadvantage > that it only works in a non-cyclic routing tree; and and > as soon as any rerouting takes place you get into MAJOR problems > for messages that were still under way. > > The ONLY way to really avoid all those nightmares is to adopt > how git and mercurial work: immutable data that some hash ID > refers to, which, as you said is, "never" deleted. > > This is an issue which has occupied many minds for decades, and I >> think it can be distilled into the widely accepted notion that cached >> objects should never be overwritten, but only joined by updated >> versions. At a stroke this lets highly concurrent asset services >> avoid the thorny issue of writing in the presence of concurrent >> readers, and at the same time it lets caches have very simple update >> semantics since nothing is mutable from their perspective. The only >> cost is some loss of disk space to hold old versions, which is rarely >> significant given disk sizes and costs today. >> > > You totally convinced me :). And for the others: note that I tried > it in other ways for YEARS. So, it means something that now I'm > convinced that wasn't right and we should avoid it. > > While that is good for asset services and caches, it does place the >> burden of achieving mutability on the parties who require it. And >> that of course is how burdens should be borne. >> > > Also very true. > > What this means for virtual worlds is that a mutator becomes >> responsible for notifying endpoints that something has mutated, so >> that they can fetch the new versions. >> > > This sound like an 'authority' however: one entity and one alone > can issue the out going message that something has changed... > That is not how it should work though. I can't wrap my finger > around the difference yet though :/... If we go for immutability > then why suddenly are we talking about having to notify others > that something changed? > > Of course, things DO change in-world. For example, someone could > detach something - and attach something else. Then the Agent of > that avatar is the authority I'd think: the viewer requests the > Agent to make a change, and if approved then the Agent tells the > viewer and everyone else that the change was made. > > I guess that the big difference is that in those outgoing messages > is no large 'data'.. no ASSET data. The Asset servers themselves > would never do this. Only work-tied (location tied) things will do > this: avatars and rezzed objects, with respectively the Agent > and the Region as authority/source of the mutating messages. > > Routing probably goes all through the Region server: if someone > changes an attachment while they are 4000 meter away (in the same > sim) then that STILL has to be routed to everyone else in the sim, > and not later. Basically at least, the Agent *tells* the Region > server that the avatars appears has changed and the Region sends > outward messages of that fact to everyone who is connected. > > As long as all mutating messages go in one direction: away from > the authority (the Agent in this case) and there are no RE-routing > issues (which is not the case here) then there are no problems > with this model. > > This needn't be an onerous >> requirement, and it may not even need to be wrapped up in security >> tape, since having had access once probably qualifies you for an >> unconditional update. In any case, the original item is still in its >> asset service (as well as in users' terabyte caches), so one very >> useful property of this approach is that a simulation can't be broken >> for long by a poor update since reverting is always possible. That's >> a an engineering plus point. >> > > If all things are well, then the outgoing 'mutation' message from > the Agent/Region only contains new asset ID's, not the data itself. > And people will get the new data using the new ID. > > This sound perfectly ok for textures (which aren't even mutatable > in-world), but what about a little change to the shape of a prim > of an object? An object (existing of many prims) is an asset: > you can get store it in an asset server and later retrieve it > again. Hence, we have to realize that such objects are NOT > mutable. Only once they are rezzed they are mutable. This is a > requirement for things to work. A rezzed object is therefore > not an asset: it's world-data that can change (with the Region > as authority? or the owner/viewer maybe, when they are online). > Only once an object is taken back into inventory is the data > send to an asset server and a new ID is created. Until that point > all the data for such objects is exclusively stored in the region > and people obtain the data for the shape of objects (not the textures, > but for which texture ID is used on what face) from the region, > not from an asset server. > > This follows from the mutablity argument (not from the fact that > this how it works in SL too). > > In respect of addressing, you mentioned using hashes as item >> addresses, and this is of course my preferred strategy, which I have >> described and advocated several times this week, and back in >> September. Hash-based addressing has numerous excellent engineering >> properties that put it head and shoulders above other schemes. I say >> go with that approach. In any event, when we pit alternative schemes >> against each other on merit, I bet nothing will come close to >> hash-based. >> > > I can't think of any disadvantages. The hash has to have a large size > of course, comparable to UUID's. Still,I'm willing to assume that > with a lot of effort it would be possible to create an asset with > a given hash that in fact is different... Would that be a problem? > > Once you know the data, you can reconstruct the item anyway. You > also know the ID (hash or not). You can only know the hash if you > already know the data anyway, or when you have access to it (of course). > Being able to then create an asset that has the same hash, but in > fact is white noise (I definitely can't think of any other way > to construct a known hash) should simply result in the white noise > being discarded: someone "uploads" data that has an already existing > hash, then discard the uploaded data and use the old data. The result > is the uploader/hacker didn't gain anything at all. > > On the issue of caps, I think that keeping their semantics simple has >> great merit, because heavyweight schemes are less likely to be >> accepted, and complex ones are unlikely to be implemented uniformly. >> But in any case, as I described to Vaughn, caps should be *optional* >> anyway (ie. asset dependent). Having to acquire a cap in order to >> fetch a Creative Commons licensed asset is unnecessary, and indeed it >> is rather comic. A cap only needs to be requested when the asset >> requires it, and only those assets that need it should bear the >> burden. >> > > Hear hear! I like this idea very much :). > But it is unrelated to the ID / unmutable data of course. > This is just about how easy it is to get a cap for something. > I guess that what you mean is that a free asset should have a > cap that exists of it's hash. So that if you know the ID/hash > (ie 'Z') you know immediately where to get it. > > The issue of flag bits (or more generally, property fields) for >> assets is one that interests me a lot, as it relates to the above. >> As I described to Vaughn, it is the assets that impose requirements >> on the protocol, not vice versa, so it is the assets that should >> carry the properties that control the protocol. >> > > I've often desired mutable bit in no-modify objects in SL. > There are numerous applications for it! The idea is that > you have a no modify object but as owner still can change > certain bits that define how it is used AND that are > stored when you take it back into your inventory (are preserved > when next time you rez it again). However, 'no modify' and > the immutability that we talked about are different things > of course! If we assume that such bits are simple changes > to the object that are allowed by the owner at all times, > then the only disadvantage is that (apparently) all data > of the object needs to be stored multiple times: if their > are 4 bits and the users "plays" with them until they had > all 16 possibilities once in their inventory then we'd have > 16 times the same data in the asset server. > > This however is just a way to look at it (compare with > the way how we look at how a git server works: that view > is highly inefficient too, though easy to grasp). > > The real implementation can of course make it so that it > doesn't store that data 16 times... > > -- > Carlo Wood > _______________________________________________ > 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 > --0016368340c02eb75204a07e8419 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Patnad, if you mean synchronized updates of objects, then yes, this is what= Carlo and I were discussing in the emails of this thread.=A0 That's th= e "mutability" of an object to which we were referring.

    Ho= wever, it shouldn't happen through actual mutation of an asset in the a= sset services (in our view), because as we discussed earlier, this would ha= ve bad consequences for the cacheability of assets, it would complicate ass= et services and make them less concurrently scalable, and there would be no= means of fault isolation when an update delivers bad data and propagates t= o everyone automatically.

    Instead, we were envisaging all assets in asset services being complete= ly immutable, always.=A0 Then an "update" would consist of adding= another newer asset to the asset service, and signaling that an update exi= sts only to the desired endpoints.=A0 This would allow control over the bre= adth of update effect, since endpoints that are not notified would not auto= matically sync up, so you can select your own target set for your update tr= ial.

    Although we haven't discussed the following mechanism yet, the way = I envisage updates being propagated is through an optional subscription pat= h in the protocol, which has the merit that the burden of updateability res= ts only on those assets that require it, and not on all assets.=A0 I mentio= ned "property fields" (ie. bits or flags) in a response to Carlo = yestereday, and this is one place where the notion of "asset propertie= s" can be put to good use.

    If an asset is marked as being "Updateable" through a = property bit, it is still entirely immutable in asset services and remains = valid in all caches.=A0 However, at the point where a client (or a region s= erver in the case of a bounding-box / collision mesh asset) receives the as= set, when it notices the "Updateable" property bit on the = asset then it has the option of availing itself of the update when it becom= es available.

    The way this would work in my subscription-based approach is very simpl= e.=A0 On noticing the Updateable" bit being set in an attribute= for asset A, the receiving endpoint E would send off a protocol message wh= ich says "This endpoint E wishes to subscribe to notifications for = updates on asset A", which would be a protocol message type define= d in our protocol.=A0 Notice that this makes the update process "op= t-in", which is a very desirable trait especially in regards to pr= ivacy and security.

    But where would the recipient endpoint send this message?=A0 I propose = that specifying the target should be kept flexible and extensible by placin= g that information in yet another asset, which the asset service can give t= he recipient upon request.=A0 This can work as follows, although there are = many possible variations on this theme:

    The party that offers updateability of asset A also stores an "= UpdateInfo" asset in the same asset service, a tuple structured li= ke this:

    UpdateInfo:{A, UpdateS= ubscriptionURI, Description}

    When the asset service receives this UpdateInfo asset, it = creates a local binding between asset A and the URI of this UpdateIn= fo asset, such that if an endpoint subsequently requests fetchUpdateInfo= (A) then the URI of the UpdateInfo asset is returned.=A0 The requester = can then use that URI to fetch the UpdateInfo asset using the standard asse= t fetch mechanism, and can then use the URI held in the received UpdateS= ubscriptionURI field to send a subscription request to the party offeri= ng updates.

    There are many possible variations on this idea, but the key to flexibi= lity is holding the update information in a new asset.=A0 This introduces m= any benefits:

    • Ordinary assets do not carry the burden of any= update machinery.
    • Updateable assets that the user does not wish to update do not carry th= e burden of any update machinery either (the "Updateable" = property is just ignored at the time the asset is received).
    • If a r= ecipient that did not initially subscribe to updates changes its mind later= , nothing is lost, because the update contact information is securely store= d in the asset service and can be requested at any time.
    • It also allows endpoints to choose not to subscribe to updates at the t= ime of asset receipt but as a scheduled background activity instead.
    • Asset services can continue to do what they do best, namely just stre= am immutable assets at blue light speeds.=A0 The separate binding service (= a simple hashed lookup keyed on the same asset address as normal asset fetc= hes) is a side facility, and doesn't impact on the asset service at all= .
    • The update mechanism is opt-in, which is a benefit for privacy and= security.
    • The party offering the update can easily store a new = UpdateInfo asset if the UpdateSubscriptionURI changes, which the= asset service can either use to replace its previous binding, or else just= add it to a list of UpdateInfo offers.
    • The UpdateInfo assets themselves are immutably stored in the ass= et service, so the bindings are recoverable even if lost.
    • Caching w= orks normally for all assets, even the updateable ones.
    • The updater= retains full control over to whom to offer updates out of the opt-ins, and= can reduce the set of endpoints updated to suit its policy or resources.
    • The UpdateInfo assets don't even need to be stored in the sa= me asset service as the assets to which they are bound.=A0 It's perfect= ly possible to have asset sites dedicated to update notifications alone.=A0= This would require clients to have knowledge of such sites so that they re= quest update notifications to them instead of to the original asset service= s, but it's not particularly hard.

    How updates are actually offered later, once they become avai= lable, is a separate issue.=A0 The above just handles subscribing to notifi= cations about updates.=A0 It's pretty easy to see how the circle could = be made complete though --- the updater notifies opt-ins that an update is = available, upon which they can fetch the new asset from an asset service an= d save it as an asset replacement in their cache.

    How the notification is sent by the updater should be flexible.=A0 I ha= ve implied that the user's agent service is online and so direct notifi= cation is possible, as this will probably become much more common tomorrow = under IPv6 which does not hide clients behind NAT.=A0 Other means by which = updaters can send update notifications should be provided too though.=A0 Al= ternatively, regions could subscribe to be notified of updates to client as= sets, and when the region is sending the asset URIs to its attached clients= , it could pass any notifications about updates along to these clients too.= =A0 Giving regions more work is not a very good idea though.

    There are lots of possible alternatives in this area.=A0 I've descr= ibed only one or two.


    Morgaine.




    =3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    On Sat, Apr 9, 2011 at 10:38 AM, Patnad Babii = <djshag@hotmail.= com> wrote:
    While reading thr= ough this email, I've got an idea, that i don't think we spoke abou= t before but I really think it could become handy.

    We have to allow some kind of synchronisation to take place on some assets.=

    Let me describe you the use case i see where it fits.

    I make a vendor's server lets say, that i'm going to use on GRID A = and GRID B.

    I don't visit GRID B very often, but on the other hand i'm connecti= ng on GRID A alot.

    I do some modification on my server's code in GRID A and I'd like t= he GRID B to have the exact same modifications without having to log there = and start to code again.

    So, what would be really useful is if in a way I could say to GRID B to ref= resh my server without having to log in there.

    That's it, that was my idea, not sure it fits right here right now, but= might be to take in consideration =A0while designing the protocol.

    Thanks

    -----Message d'origine----- From: Carlo Wood
    Sent: Friday, April 08, 2011 9:58 PM
    To: vwrap@ietf.org<= br> Subject: Re: [vwrap] Is 'Data Z' immutable (like a git snapshot)?


    On Sat, 9 Apr 2011 02:11:00 +0100
    Morgaine <morgaine.dinova@googlemail.com> wrote:

    First of all, mutability breaks caching entirely, so it needs to be
    approached with great caution. =A0Caching can make the difference
    between a great service and a totally unusable one (or at least one
    that doesn't work very well), so if mutability is allowed then things need to be designed in such a way that caching still works *most of
    the time*, namely in between mutations.

    Yup, I totally agree. As you might know I've been working a lot
    on improving the IRC protocol at the time. IRC works with handles
    (nicks and channel names) and everything else is mutable (ie,
    the channel topic, the channel modes, etc). This turned out to
    be an unsolvable horror (and trust me on that please, I worked
    7 years on this topic). What I did was change nick names into
    numerics that are *unmutable*, so at least the bloody handle
    wasn't changing all the time, heheh (channel names are already
    unmutable) and then assigned authortities for the nick names
    (namely those servers where the users are connected to). Authorities
    have the nice property to have exclusively an outwards message
    stream: from the authority away, and therefore for streamable:
    if every mutating operation is kept in order than everything
    remains synched in the end. This requires that one always ASKS
    the authority to change something and not tell it that you
    changed something. For example, I changed it that when you KICK
    someone from a channel, then a request is sent to the server
    where that person is connected to and that server actually
    sends out the message that this user is removed from the channel.
    Making an authority for channels was never done, there I have
    tried to solve this problem with timestamps.

    I don't think we should go this route (using time stamps).
    Also, the authority "solution" has a the major disadvantage
    that it only works in a non-cyclic routing tree; and and
    as soon as any rerouting takes place you get into MAJOR problems
    for messages that were still under way.

    The ONLY way to really avoid all those nightmares is to adopt
    how git and mercurial work: immutable data that some hash ID
    refers to, which, as you said is, "never" deleted.

    This is an issue which has occupied many minds for decades, and I
    think it can be distilled into the widely accepted notion that cached
    objects should never be overwritten, but only joined by updated
    versions. =A0At a stroke this lets highly concurrent asset services
    avoid the thorny issue of writing in the presence of concurrent
    readers, and at the same time it lets caches have very simple update
    semantics since nothing is mutable from their perspective. =A0The only
    cost is some loss of disk space to hold old versions, which is rarely
    significant given disk sizes and costs today.

    You totally convinced me :). And for the others: note that I tried
    it in other ways for YEARS. So, it means something that now I'm
    convinced that wasn't right and we should avoid it.

    While that is good for asset services and caches, it does place the
    burden of achieving mutability on the parties who require it. =A0And
    that of course is how burdens should be borne.

    Also very true.

    What this means for virtual worlds is that a mutator becomes
    responsible for notifying endpoints that something has mutated, so
    that they can fetch the new versions.

    This sound like an 'authority' however: one entity and one alone can issue the out going message that something has changed...
    That is not how it should work though. I can't wrap my finger
    around the difference yet though :/... If we go for immutability
    then why suddenly are we talking about having to notify others
    that something changed?

    Of course, things DO change in-world. For example, someone could
    detach something - and attach something else. Then the Agent of
    that avatar is the authority I'd think: the viewer requests the
    Agent to make a change, and if approved then the Agent tells the
    viewer and everyone else that the change was made.

    I guess that the big difference is that in those outgoing messages
    is no large 'data'.. no ASSET data. =A0The Asset servers themselves=
    would never do this. Only work-tied (location tied) things will do
    this: avatars and rezzed objects, with respectively the Agent
    and the Region as authority/source of the mutating messages.

    Routing probably goes all through the Region server: if someone
    changes an attachment while they are 4000 meter away (in the same
    sim) then that STILL has to be routed to everyone else in the sim,
    and not later. Basically at least, the Agent *tells* the Region
    server that the avatars appears has changed and the Region sends
    outward messages of that fact to everyone who is connected.

    As long as all mutating messages go in one direction: away from
    the authority (the Agent in this case) and there are no RE-routing
    issues (which is not the case here) then there are no problems
    with this model.

    =A0This needn't be an onerous
    requirement, and it may not even need to be wrapped up in security
    tape, since having had access once probably qualifies you for an
    unconditional update. =A0In any case, the original item is still in its
    asset service (as well as in users' terabyte caches), so one very
    useful property of this approach is that a simulation can't be broken for long by a poor update since reverting is always possible. =A0That's=
    a an engineering plus point.

    If all things are well, then the outgoing 'mutation' message from the Agent/Region only contains new asset ID's, not the data itself.
    And people will get the new data using the new ID.

    This sound perfectly ok for textures (which aren't even mutatable
    in-world), but what about a little change to the shape of a prim
    of an object? =A0An object (existing of many prims) is an asset:
    you can get store it in an asset server and later retrieve it
    again. =A0Hence, we have to realize that such objects are NOT
    mutable. Only once they are rezzed they are mutable. This is a
    requirement for things to work. A rezzed object is therefore
    not an asset: it's world-data that can change (with the Region
    as authority? or the owner/viewer maybe, when they are online).
    Only once an object is taken back into inventory is the data
    send to an asset server and a new ID is created. Until that point
    all the data for such objects is exclusively stored in the region
    and people obtain the data for the shape of objects (not the textures,
    but for which texture ID is used on what face) from the region,
    not from an asset server.

    This follows from the mutablity argument (not from the fact that
    this how it works in SL too).

    In respect of addressing, you mentioned using hashes as item
    addresses, and this is of course my preferred strategy, which I have
    described and advocated several times this week, and back in
    September. =A0Hash-based addressing has numerous excellent engineering
    properties that put it head and shoulders above other schemes. =A0I say
    go with that approach. =A0In any event, when we pit alternative schemes
    against each other on merit, I bet nothing will come close to
    hash-based.

    I can't think of any disadvantages. The hash has to have a large size of course, comparable to UUID's. Still,I'm willing to assume that with a lot of effort it would be possible to create an asset with
    a given hash that in fact is different... Would that be a problem?

    Once you know the data, you can reconstruct the item anyway. You
    also know the ID (hash or not). You can only know the hash if you
    already know the data anyway, or when you have access to it (of course). Being able to then create an asset that has the same hash, but in
    fact is white noise (I definitely can't think of any other way
    to construct a known hash) should simply result in the white noise
    being discarded: someone "uploads" data that has an already exist= ing
    hash, then discard the uploaded data and use the old data. The result
    is the uploader/hacker didn't gain anything at all.

    On the issue of caps, I think that keeping their semantics simple has
    great merit, because heavyweight schemes are less likely to be
    accepted, and complex ones are unlikely to be implemented uniformly.
    But in any case, as I described to Vaughn, caps should be *optional*
    anyway (ie. asset dependent). =A0Having to acquire a cap in order to
    fetch a Creative Commons licensed asset is unnecessary, and indeed it
    is rather comic. =A0A cap only needs to be requested when the asset
    requires it, and only those assets that need it should bear the
    burden.

    Hear hear! I like this idea very much :).
    But it is unrelated to the ID / unmutable data of course.
    This is just about how easy it is to get a cap for something.
    I guess that what you mean is that a free asset should have a
    cap that exists of it's hash. So that if you know the ID/hash
    (ie 'Z') you know immediately where to get it.

    The issue of flag bits (or more generally, property fields) for
    assets is one that interests me a lot, as it relates to the above.
    As I described to Vaughn, it is the assets that impose requirements
    on the protocol, not vice versa, so it is the assets that should
    carry the properties that control the protocol.

    I've often desired mutable bit in no-modify objects in SL.
    There are numerous applications for it! The idea is that
    you have a no modify object but as owner still can change
    certain bits that define how it is used AND that are
    stored when you take it back into your inventory (are preserved
    when next time you rez it again). However, 'no modify' and
    the immutability that we talked about are different things
    of course! If we assume that such bits are simple changes
    to the object that are allowed by the owner at all times,
    then the only disadvantage is that (apparently) all data
    of the object needs to be stored multiple times: if their
    are 4 bits and the users "plays" with them until they had
    all 16 possibilities once in their inventory then we'd have
    16 times the same data in the asset server.

    This however is just a way to look at it (compare with
    the way how we look at how a git server works: that view
    is highly inefficient too, though easy to grasp).

    The real implementation can of course make it so that it
    doesn't store that data 16 times...

    --
    Carlo Wood <carlo@= alinoe.com>
    _______________________________________________
    vwrap mailing list
    vwrap@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/vwrap
    _______________________________________________
    vwrap mailing list
    vwrap@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/vwrap

    --0016368340c02eb75204a07e8419-- From dzonatas@gmail.com Sat Apr 9 09:16:56 2011 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 996F63A69E1 for ; Sat, 9 Apr 2011 09:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.293 X-Spam-Level: X-Spam-Status: No, score=-3.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 JXFF9HNAYznA for ; Sat, 9 Apr 2011 09:16:56 -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 039C33A6876 for ; Sat, 9 Apr 2011 09:16:55 -0700 (PDT) Received: by pzk30 with SMTP id 30so1945952pzk.31 for ; Sat, 09 Apr 2011 09:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=Y9C39/79KyDKsGh2M410GT776nFz/fs4RGooERwJrHg=; b=t7HTSkQkgnHAGj9EoX4SnK1kii7LP4KDrEsEoUJX9s4h/x2wZ7MCyAXvqgqz8Yv+UE TKB2JVd33hP6GZlvTkCyMJ3qqc95sNQzbd3gRXaH2dCvlSB6Y3F9f5Q9mW7P31+Jy9f/ clOb5PeFi6QbFJrUINWkqEvpLvmWp6yyfRLvM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=figyqeCbHOuqkk3h9FHuGEyV3FKlgV8K5FfcnpdiVqF3frcxip3HqssdrzXaVopMLm TmJucOOi5R3kxCFoBkz0zkN93P48eTLamp1liVrycvLlNp9NXojo27GqgzantAMxVkvI fo2na3c/hYU1QRwuuIZl59GWQnRi68yWKVQTM= Received: by 10.142.121.41 with SMTP id t41mr3311029wfc.358.1302365922155; Sat, 09 Apr 2011 09:18:42 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id s39sm5324626wfc.16.2011.04.09.09.18.40 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Apr 2011 09:18:41 -0700 (PDT) Message-ID: <4DA08716.1040208@gmail.com> Date: Sat, 09 Apr 2011 09:19:34 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: "vwrap@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [vwrap] Assets & Avatar space 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: Sat, 09 Apr 2011 16:16:56 -0000 One thing to keep in mind is that ultimately it is the avatar and not the region that has the rights to wear whatever the user chooses the avatar to wear. Of course, it is not implemented that way right now since the grid overrides it all by default. It may be simpler in the future to think of only physical and phantom data being sent to the grid and the local-region/local-simulator knows all other details the grid doesn't need to know. I think where this has comprehensively failed earlier by avoidance of middle-ware, as it appears that way. Assets are not quite split between physical data and everything else. Let me know if I need to give more detail for above. In particular, futurewise, avatar space (or space around the avatar) should be completely owned by the avatar in order to make sure consistent simulation occurs and there is no "can I wear these clothes before and after teleport" type questions. The answer should always be yes with only appropriate exceptions (adult/pg, battle sims/script limits, rpg, etc). This is, by the way, the dumb childish banning deal from... you know... and any further physics prediction makes it obvious what some want to avoid per their personal-agenda/biz-agenda rather than what's best for the avatar/user-experience. They cried the sky is falling (not in public) with loss of $$$ if it happens, and never considered the facts over the paranoid despair, and called everybody stupid for any presentation of this. Obviously, a pinning point. Seriously (& professionally), when you put on your clothes in the morning do you ever get faced with someone that says "hay you can't do that! Your stupid because our business down the road will lose $$$ if you let others see your clothes! You must wear what we allow you to wear! And we know you are going to walk down that road!" All other disagreements of ability to render the clothes falls-back to the default conditioners and refineries (i.e. collada). That being it is the local-renderer that really displays the avatar, and the abilities to render the avatar is appropriately the onus of the viewer technology, not the grid technology. The viewer can display a lower-rez OBJ, refined from the collada file, rather than a higher rez format. (Of course, not all assets are collada, yet I have to remind someone of this as futurewise and ideal-consideration/from-use-case before another endless...). From carlo@alinoe.com Sat Apr 9 12:35:54 2011 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 ED6763A699C for ; Sat, 9 Apr 2011 12:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 1FZk++OyZgfp for ; Sat, 9 Apr 2011 12:35:53 -0700 (PDT) Received: from fep15.mx.upcmail.net (fep15.mx.upcmail.net [62.179.121.35]) by core3.amsl.com (Postfix) with ESMTP id E10D13A6989 for ; Sat, 9 Apr 2011 12:35:52 -0700 (PDT) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep15-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110409193737.BSLL1633.viefep15-int.chello.at@edge01.upcmail.net> for ; Sat, 9 Apr 2011 21:37:37 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upcmail.net with edge id VXdb1g0140FlQed01XdcDC; Sat, 09 Apr 2011 21:37:37 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q8dyR-0007Ay-Ek for vwrap@ietf.org; Sat, 09 Apr 2011 21:37:35 +0200 Date: Sat, 9 Apr 2011 21:37:35 +0200 From: Carlo Wood To: vwrap@ietf.org Message-ID: <20110409213735.1ab8d6ef@hikaru.localdomain> In-Reply-To: <4DA08716.1040208@gmail.com> References: <4DA08716.1040208@gmail.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=JvXQbuMnWGQeb488dJ7w43Du7THgE+O7ieb9U20/rjk= c=1 sm=0 a=WxYJGR-fJXgA:10 a=_kSIUADMT0YA:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=BjFOTwK7AAAA:8 a=q4rX8xwiN39s7iIKTDEA:9 a=Ry-ZeTIoROrxh26pIOQA:7 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=bW3kdApBr58A:10 a=7_umSVhk6O_MWMq5:21 a=TuO0i3JAqAC1Ck3Z:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [vwrap] Assets & Avatar space 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: Sat, 09 Apr 2011 19:35:55 -0000 On Sat, 09 Apr 2011 09:19:34 -0700 Dzonatas Sol wrote: Although it should be known / is known, then I'm all for freedom ;)... I think I have to disagree. I think that the reason for our disagreement is that there is a difference between "being allowed to wear" something and "being the authority" about what you wear. Please recall that "authority" means no more and no less than that it is the sole source of mutating messages: mutating messages cannot be denied: downstream is TOLD that something changed; hence the word 'authority'. Let me add my remaining comments below in context. > One thing to keep in mind is that ultimately it is the avatar and not > the region that has the rights to wear whatever the user chooses the > avatar to wear. Of course, it is not implemented that way right now > since the grid overrides it all by default. While I agree that the viewer, or at least the Agent, should be the authority for protocol messages that propagate changes of what an avatar is wearing, it is possible and therefore has to be supported that *someone* thinks it is needed that you can't be allowed to wear whatever you like. You even give an example of that yourself! In a PG region you could be disallowed to take of your clothes. If you are in a prison you have to wear some uniform... It's not up to use to decide that such use case should not be supported at protocol level. > It may be simpler in the future to think of only physical and phantom > data being sent to the grid and the local-region/local-simulator > knows all other details the grid doesn't need to know. I think where > this has comprehensively failed earlier by avoidance of middle-ware, > as it appears that way. Assets are not quite split between physical > data and everything else. I have no idea what this paragraph means :( > Let me know if I need to give more detail for above. Yup, definitely ;) > In particular, futurewise, avatar space (or space around the avatar) > should be completely owned by the avatar in order to make sure > consistent simulation occurs and there is no "can I wear these > clothes before and after teleport" type questions. Not sure what you mean with 'space around the avatar'? The 3D space around an avatar is nothing to do with what they wear imho. But I'll assume you mean "what they wear", or more in general, "their appearance". > The answer should > always be yes with only appropriate exceptions (adult/pg, battle > sims/script limits, rpg, etc). Even a single exception means the protocol has to support it, so you are contradicting yourself here. > This is, by the way, the dumb childish > banning deal from... you know... and any further physics prediction > makes it obvious what some want to avoid per their > personal-agenda/biz-agenda rather than what's best for the > avatar/user-experience. They cried the sky is falling (not in public) > with loss of $$$ if it happens, and never considered the facts over > the paranoid despair, and called everybody stupid for any > presentation of this. Obviously, a pinning point. Not sure what you mean here... but it sounds like politics. Unfortunately, we are not to make any political decisions: we have to design a protocol that supports *every* required use case, by anyone. > Seriously (& professionally), when you put on your clothes in the > morning do you ever get faced with someone that says "hay you can't > do that! Your stupid because our business down the road will lose $$$ > if you let others see your clothes! You must wear what we allow you > to wear! And we know you are going to walk down that road!" This is your opinion, and might be mine... but I fail to see what it has to do with protocol design. We will have to support a use case where some region wants to be able to refuse certain types of appearances. I think, therefore, that what it has to look like when you want to change what you wear is something like this: Agent --> Region "Is it ok if I wear this?" Region --> Agent "Yes" Agent --> Region Avatar is now wearing this. Region --> others Avatar is now wearing this. Note that Region is not sending back the message to the Agent, because the Agent already made the change: the actual mutating message is exclusively streaming away from the Agent. If we didn't first ask the Region if it was ok, you get the following problem(s): Agent --> Region: I'm wearing X now! Agent --> Region: I'm wearing Y now! Agent --> Region: I'm wearing Z now! Region --> Agent: You are not allowed to wear Y! and the Agent has a problem synchronizing itself with what the rest of the world sees: the refusal message has become a mutating message (the Agent has to change back) and is travelling UPSTREAM towards the authority. This leads to problems. > All other disagreements of ability to render the clothes falls-back > to the default conditioners and refineries (i.e. collada). That being > it is the local-renderer that really displays the avatar, and the > abilities to render the avatar is appropriately the onus of the > viewer technology, not the grid technology. The viewer can display a > lower-rez OBJ, refined from the collada file, rather than a higher > rez format. (Of course, not all assets are collada, yet I have to > remind someone of this as futurewise and > ideal-consideration/from-use-case before another endless...). > _______________________________________________ vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap -- Carlo Wood From dzonatas@gmail.com Sat Apr 9 13:51:17 2011 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 A125A3A68CB for ; Sat, 9 Apr 2011 13:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 L3-EyF89WPXe for ; Sat, 9 Apr 2011 13:51:16 -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 049853A68C2 for ; Sat, 9 Apr 2011 13:51:15 -0700 (PDT) Received: by pwi5 with SMTP id 5so2031835pwi.31 for ; Sat, 09 Apr 2011 13:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UH3U2k5p6ktfjwrRtZpRKVOccL3VS+Beq2CDwnuGkuA=; b=dYcFkkNcX7hUeRORjiSz3CcGc44oyMqz9yWP6uFKldmnYX3Sngp3mXTKqembSUysNT ubnOq2ABNh+CGKEIdxN/uJ/zhuoBifeGHhK2Kq4mf0KZjujwCPFjrzGGPxroZzyCqGfr 1D6RtoVnf1FFS5hDYRwEBPmhDqda7kpICRqAc= 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=xNw7BeDRJ9PPFBGJnvm5tvXUGqL4aGQRNIoO2hRRyGQc6MsZMBKGAfhdwD2Xh42+lr TRknLSyM0jOQh+7sQfGC0plOqsKFQLchgeU3rhnc/ngwjPGgp6LeqjUk9dLgXABQQxN5 arv7PsCrqa/BPNepA6oi1J7E3sbD5eZF6kju4= Received: by 10.143.46.3 with SMTP id y3mr3150330wfj.331.1302382382202; Sat, 09 Apr 2011 13:53:02 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id p40sm5629965wfc.17.2011.04.09.13.52.59 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Apr 2011 13:53:01 -0700 (PDT) Message-ID: <4DA0C763.8070006@gmail.com> Date: Sat, 09 Apr 2011 13:53:55 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Carlo Wood References: <4DA08716.1040208@gmail.com> <20110409213735.1ab8d6ef@hikaru.localdomain> In-Reply-To: <20110409213735.1ab8d6ef@hikaru.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Assets & Avatar space 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: Sat, 09 Apr 2011 20:51:17 -0000 My comments inline... Carlo Wood wrote: > On Sat, 09 Apr 2011 09:19:34 -0700 > Dzonatas Sol wrote: > > Although it should be known / is known, then I'm all for > freedom ;)... I think I have to disagree. > > I think that the reason for our disagreement is that > there is a difference between "being allowed to wear" something > and "being the authority" about what you wear. > That sounds more like semanticists argue about and not issues that programmers need to worry about. There is no reason to create straw men and then claim I'm contradiction over your straw man, not myself. > Please recall that "authority" means no more and no less > than that it is the sole source of mutating messages: > mutating messages cannot be denied: downstream is TOLD that > something changed; hence the word 'authority'. > The arguments you presented, however, is that you say "region" semantically GOD. Why should we agree to your god? Again, semantics just turn the issue religious rather than something programmers really need in general. There are "trust domains" and people screamed semantics over the word "domains", yet that already proves that that domains are what programmers desires just because, as the word is used in math, they need to know the range of relationships. If some group doesn't implement the documentation then they need to use language the implementators desire and makes sense to them, not only what the writer prefers. That's like "do what I say, not as I do." I'm sure people, especially those who actually implement, don't need this kind of "authority". > Let me add my remaining comments below in context. > > >> One thing to keep in mind is that ultimately it is the avatar and not >> the region that has the rights to wear whatever the user chooses the >> avatar to wear. Of course, it is not implemented that way right now >> since the grid overrides it all by default. >> > > While I agree that the viewer, or at least the Agent, should be > the authority for protocol messages that propagate changes of > what an avatar is wearing, it is possible and therefore has to be > supported that *someone* thinks it is needed that you can't be > allowed to wear whatever you like. > > You even give an example of that yourself! In a PG region you > could be disallowed to take of your clothes. If you are in a > prison you have to wear some uniform... It's not up to use to > decide that such use case should not be supported at protocol > level. > Again, lets not make this religious debate. Whatever the avatar wears is 100% the result what the human being allows. Whatever happens to the avatar is 100% the result of what the human being allows. We are not going to allow clowned-jar-head psycho-traumatic "gods". We learned this lesson well back at the start of MUDs and MOOs where people used to think exceptions meant that the human being "lost control" of themselves due to virtual experiences. Technically, what you want, by exceptions, happens to the agent, not the avatar. > > >> It may be simpler in the future to think of only physical and phantom >> data being sent to the grid and the local-region/local-simulator >> knows all other details the grid doesn't need to know. I think where >> this has comprehensively failed earlier by avoidance of middle-ware, >> as it appears that way. Assets are not quite split between physical >> data and everything else. >> > > I have no idea what this paragraph means :( > Thats is probably why you disagree besides semantics. Assets need their physical data separate from their visual data. The viewer/visual-simulator only needs the visual data. The physics simulator only needs the physics data. There is no need for either to have the complete asset. This is something that can help protect assets, future-wise, if someone asks for the complete assets, as we can then error back and say "either your are the visual side or the physical side, not both, unless your the owner of the asset." Optimization can happen also, likewise, where only partial data needs to go to either the grid or or the viewer instead of the full asset. There is nothing political about those differences. > >> In particular, futurewise, avatar space (or space around the avatar) >> should be completely owned by the avatar in order to make sure >> consistent simulation occurs and there is no "can I wear these >> clothes before and after teleport" type questions. >> > > Not sure what you mean with 'space around the avatar'? The 3D space > around an avatar is nothing to do with what they wear imho. But I'll > assume you mean "what they wear", or more in general, "their > appearance". > The space around the avatar is the simulation. What probably confuses this is that 256x256x(some-value) has become the default region of simulation. That's mainly due to technological and political reasons and not due to natural reasons. Within more natural reason, the space around your avatar is it's own simulation. If these simulations overlap, then there would be technology ability to compute such overlapped regions. This is not the current case, yet we want this to be the case. There are experimental simulators that due exactly these cases (even spherical instead of borgish cubes). > >> The answer should >> always be yes with only appropriate exceptions (adult/pg, battle >> sims/script limits, rpg, etc). >> > > Even a single exception means the protocol has to support it, so you > are contradicting yourself here. > Don't create straw men and tell me I'm in contradiction of your straw men. Given the overlap of regions, there is no contradiction. > >> This is, by the way, the dumb childish >> banning deal from... you know... and any further physics prediction >> makes it obvious what some want to avoid per their >> personal-agenda/biz-agenda rather than what's best for the >> avatar/user-experience. They cried the sky is falling (not in public) >> with loss of $$$ if it happens, and never considered the facts over >> the paranoid despair, and called everybody stupid for any >> presentation of this. Obviously, a pinning point. >> > > Not sure what you mean here... but it sounds like politics. > Unfortunately, we are not to make any political decisions: we have to > design a protocol that supports *every* required use case, by anyone. > True, yet there are some that appear here and on other lists that keep-up their agendas. It's strange when some business considers themselves open, yet they are not open to ideas of optimization due to political nature of revenue. Due consider how you even pointed out with semantics above about "authority", some only want to play god. Any need for any region/server to play god is obvious turtles on turtles. Do you ever have to ask Earth if you can wear your jeans? > >> Seriously (& professionally), when you put on your clothes in the >> morning do you ever get faced with someone that says "hay you can't >> do that! Your stupid because our business down the road will lose $$$ >> if you let others see your clothes! You must wear what we allow you >> to wear! And we know you are going to walk down that road!" >> > > This is your opinion, and might be mine... but I fail to see what > it has to do with protocol design. We will have to support a use case > where some region wants to be able to refuse certain types of > appearances. > > I think, therefore, that what it has to look like when you want to > change what you wear is something like this: > > Agent --> Region "Is it ok if I wear this?" > Region --> Agent "Yes" > Agent --> Region Avatar is now wearing this. > Region --> others Avatar is now wearing this. > > Note that Region is not sending back the message to the Agent, > because the Agent already made the change: the actual mutating > message is exclusively streaming away from the Agent. > > If we didn't first ask the Region if it was ok, you get > the following problem(s): > > Agent --> Region: I'm wearing X now! > Agent --> Region: I'm wearing Y now! > Agent --> Region: I'm wearing Z now! > Region --> Agent: You are not allowed to wear Y! > > and the Agent has a problem synchronizing itself with what > the rest of the world sees: the refusal message has become a mutating > message (the Agent has to change back) and is travelling UPSTREAM > towards the authority. This leads to problems. > This is easily solved by what "materials" the regions supports, and by regions we mean both visual and physical sides. Materials is one of those ideals (even by LL) that has been around for years that hasn't seen any practical implementation by LL or compatibles. This is one of those use-cases, however. Avatar --> Agent : I just put on asset X! Agent --> Region : Asset X uses material A, B, or C. Region --> Agent : We only support material B. Agent --> Avatar : Use material B. This only further the case about conditioners and refineries. The refinery can take asset X and compile it with material B to produce what the region supports. The viewer & human-user both technically denote the "Avatar" above as user and automation. The agent is the region's automaton in sync with the avatar's and region's simulation(s). People get confused by conditioners and refineries because they still think in terms of parametric primitives. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From vaughn.deluca@gmail.com Sat Apr 9 14:18:29 2011 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 002C73A694F for ; Sat, 9 Apr 2011 14:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.273 X-Spam-Level: X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ORL1bVU4nTUx for ; Sat, 9 Apr 2011 14:18:26 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 452243A681B for ; Sat, 9 Apr 2011 14:18:26 -0700 (PDT) Received: by eye13 with SMTP id 13so1649701eye.31 for ; Sat, 09 Apr 2011 14:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ueQSR1xxx6HfV9blnOVtl/fDnGF0n9qysig5pmdr1/4=; b=R/trpBX5NPqUaHdyE6enyyv85kcR815tQnnWTqm3Yxyo4W+tCYFIqW9DuvZmvO9VtT O3xCb6axP82W3ipO+JJ1tXJgbTwYf2x/4wmroMsc2Q2Eu2lY51PSXXyZXaJtGw9ed3EA AiDs5wshU7BH7hoWcQTl5FIFFXHw3rtgbqlNo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RAYhrjlHONm+X6wujRp1PLOoT39BP3u2/ZhkNTdfCAWxX+LyUj7bEP8oUuoI0CczoO CZZVlgwYRX+iacxaSXoTEr65c0XOj5lErvw3A/u2MfuWfeWY2LBuyx2Lpj8AmlOj3XNt vFGkR5q1RRNNYNB89D+pRGJVKPC4Io/1QRtPk= MIME-Version: 1.0 Received: by 10.213.0.202 with SMTP id 10mr1562799ebc.79.1302384010773; Sat, 09 Apr 2011 14:20:10 -0700 (PDT) Received: by 10.213.17.17 with HTTP; Sat, 9 Apr 2011 14:20:10 -0700 (PDT) In-Reply-To: References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> <20110408223402.36ae68a9@hikaru.localdomain> Date: Sat, 9 Apr 2011 23:20:10 +0200 Message-ID: From: Vaughn Deluca To: Morgaine Content-Type: multipart/alternative; boundary=000e0cdfd9f852c3eb04a082e87a Cc: vwrap@ietf.org Subject: Re: [vwrap] Is 'Data Z' immutable (like a git snapshot)? 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: Sat, 09 Apr 2011 21:18:29 -0000 --000e0cdfd9f852c3eb04a082e87a Content-Type: text/plain; charset=ISO-8859-1 Carlo, Morgaine, Here are some anwers to your questions. I skipped some points stuff that i don't really feel qualified to answer. >'Z' (or rather, then handle used to refer to Z when asking >for it) therefore refers to a unmodifiable data >1) Is that correct? Very good question, its clear the answer should be yes, or we end up with big problems, (as has been detailed in the meantime in the exchange between you and Morgaine. When i made the example i indeed tacitly assumed the data was immutable. A agree that the way SL is doing this now will be a good start. We have trouble enough as it is. Regarding your question 2 about hash vs. special ID, I leave that to the experts to contemplate, and answer. I just would like to say that when a bandwith argument is used, the complete transaction should be considered, there is no point in optimising the first phase, if in the final exchange orders of magnitude larger blocks of data are send, swamping small bandwidth differences created at relative hight coasts (in term of design complexity). But in cases were only a small amount of metadata is exchanged it could have an impact, -however, i doubt it. >3) What would happen if someone gets a cap for Z, a >modifiable object; then the object is modified and then >the cap is used? Does the cap have a guaranteed life time? I assumed existing REST-full methodology would have provisions to communicate the lifetime and restrictions of the cap. I explicitly used that in my examples (one-time cap and fair use resctictions) If such mechanisms are not standard practise (what i would find surprising) i think we should define them. >4) If not every previous state of an object is kept >eternally and after changing some object old caps (and >their static data) disappear - then how will the asset >servers that contain copies know that? See above for the mutability and lifetime issues. Regarding storage times of objects, Its up to the asset server to decide what caps it gives out, if those are supposed to work eternally the data should be kept eternally by a quality service. Garbage collection rules can be advertised upfront, so users can decide what service type fits there needs, and be prepared to find there stuff evaporated if they opted for a minimal service... >5) [...]Are we going to build into the protocol a provision for >such mutable bits? I would say no. Not that i dislike the idea, but I wonder if that is a VWRAP issue or something that could be delegated to lower levels. Certain object types could have this mutability property in spite of a fixed ID, but at the protocol level its still an object like all others. Or not? --Vaughn On Sat, Apr 9, 2011 at 3:11 AM, Morgaine wrote: > Carlo, I too would like to hear what Vaughn had in mind in the areas you > mention, although it's perfectly possible that he was trying to keep the > issues of mutability and addressing out of the initial picture entirely, > just to keep things simple. They are important issues though, and I'm glad > that you pointed them out. > > Here I'll provide my views about this general area. > > First of all, mutability breaks caching entirely, so it needs to be > approached with great caution. Caching can make the difference between a > great service and a totally unusable one (or at least one that doesn't work > very well), so if mutability is allowed then things need to be designed in > such a way that caching still works *most of the time*, namely in between > mutations. > > This is an issue which has occupied many minds for decades, and I think it > can be distilled into the widely accepted notion that cached objects should > never be overwritten, but only joined by updated versions. At a stroke this > lets highly concurrent asset services avoid the thorny issue of writing in > the presence of concurrent readers, and at the same time it lets caches have > very simple update semantics since nothing is mutable from their > perspective. The only cost is some loss of disk space to hold old versions, > which is rarely significant given disk sizes and costs today. > > While that is good for asset services and caches, it does place the burden > of achieving mutability on the parties who require it. And that of course > is how burdens should be borne. > > What this means for virtual worlds is that a mutator becomes responsible > for notifying endpoints that something has mutated, so that they can fetch > the new versions. This needn't be an onerous requirement, and it may not > even need to be wrapped up in security tape, since having had access once > probably qualifies you for an unconditional update. In any case, the > original item is still in its asset service (as well as in users' terabyte > caches), so one very useful property of this approach is that a simulation > can't be broken for long by a poor update since reverting is always > possible. That's a an engineering plus point. > > In respect of addressing, you mentioned using hashes as item addresses, and > this is of course my preferred strategy, which I have described and > advocated several times this week, and back in September. Hash-based > addressing has numerous excellent engineering properties that put it head > and shoulders above other schemes. I say go with that approach. In any > event, when we pit alternative schemes against each other on merit, I bet > nothing will come close to hash-based. > > On the issue of caps, I think that keeping their semantics simple has great > merit, because heavyweight schemes are less likely to be accepted, and > complex ones are unlikely to be implemented uniformly. But in any case, as > I described to Vaughn, caps should be *optional* anyway (ie. asset > dependent). Having to acquire a cap in order to fetch a Creative Commons > licensed asset is unnecessary, and indeed it is rather comic. A cap only > needs to be requested when the asset requires it, and only those assets that > need it should bear the burden. > > The issue of flag bits (or more generally, property fields) for assets is > one that interests me a lot, as it relates to the above. As I described to > Vaughn, it is the assets that impose requirements on the protocol, not vice > versa, so it is the assets that should carry the properties that control the > protocol. > > > Morgaine. > > > > > > ============================== > > > > On Fri, Apr 8, 2011 at 9:34 PM, Carlo Wood wrote: > >> This is very nice work and I think it clarifies a lot. >> >> I have a few very basic questions. >> >> I see that you request Z from two different Asset servers >> (originally A, but also C when a backup has been stored there). >> >> No matter how you look at it, that is distributed storage: >> compare it with git or mercurial; if Z on A could be changed >> then the backup would be out dated, and that is not what >> we want. So, I conclude that 'Z' (or rather, then handle >> used to refer to Z when asking for it) therefore refers to >> a unmodifiable data (compare git's hex ID's that point to >> a snapshot). >> >> 1) Is that correct? >> >> If it is correct and the handle for Z used in messages >> like "give me a cap for Z" refer to immutable data, then >> the most logical thing to do would be to use a (large) >> hash value of the data (ie, md5) or an UUID that was >> generated when the data was last changed (which is less >> good because it would cause duplicated data when something >> is changed back to what it was before), or to use an >> ID that is less large, but whose uniqueness would be >> guaranteed by including a (for that authority unique) ID >> of the authority that made the last change. The advantage >> of the latter is less bandwidth (smaller ID's) and knowledge >> of the authority right into the ID of something (handy >> for routing). Disadvantages are: it suffers from the same >> as the UUID in that it will duplicate data whenever the >> same data is generated and it requires administration to >> make sure that every authority has a unique ID (compare >> giving people unique IP addresses). >> >> 2) Which of those is used? has, UUID or smaller specially >> crafted ID? >> >> 3) What would happen if someone gets a cap for Z, a >> modifiable object; then the object is modified and then >> the cap is used? Does the cap have a guaranteed life time? >> >> 4) If not every previous state of an object is kept >> eternally and after changing some object old caps (and >> their static data) disappear - then how will the asset >> servers that contain copies know that? They are not >> necessarily aware that anything changed at all for >> that object, so they can't know what the life time >> is. It seems that once you make a copy you are doomed >> to keep it forever or do garbage collection for assets >> that are never accessed anymore. >> >> 5) I can image that at SOME TIME in the future we want >> a few bit (or more) that ARE mutable-- despite that the >> asset ID (Z) refers to snapshot (immutable) data. >> Are we going to build into the protocol a provision for >> such mutable bits? >> >> This would mean, in the case that the ID is a hash (ie md5) >> that the asset Data exists of a payload that the hash is >> taken over plus a mutable part that is not considered for >> the hash. Obviously, such data then could get desynced >> between assets servers with copies. >> >> -- >> Carlo Wood >> _______________________________________________ >> 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 > > --000e0cdfd9f852c3eb04a082e87a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Carlo, Morgaine,
    Here are some anwers to your questions. I s= kipped some points stuff=A0
    that i don't really feel qualifie= d to answer.=A0

    >'Z' (or rather, then h= andle used to refer to Z when asking=A0
    >for it) therefore refers to a unmodifiable data
    >1) I= s that correct?

    Very good question, its clear the = answer should be yes, or we end=A0
    up with big problems, (as has = been detailed in the meantime in the=A0
    exchange between =A0you and Morgaine. When i made the example i indeed= =A0
    tacitly assumed the data was immutable. A agree that the way = SL is doing=A0
    this now will be a good start. We have trouble eno= ugh as it is.


    Regarding your question 2 about hash vs.= special ID, I leave=A0
    that to the experts to contemplate, and a= nswer. I just would=A0
    like to say that when a bandwith argument = is used, the complete =A0
    transaction should be considered, there is no point in optimising
    the first phase, if in the final exchange =A0orders of magnitude=A0
    larger blocks of data are send, swamping small bandwidth=A0
    <= div> differences created at relative hight coasts (in term of design complexity)= .
    But in cases were only a small amount =A0of metadata=A0
    is exchanged it could have an impact, -however, i doubt it.=A0

    >3) What would happen if someone gets a cap for Z, a
    >modifiable object; then the object is modified and then
    >= ;the cap is used? Does the cap have a guaranteed life time?

    I assumed existing REST-full methodology would=A0
    have= provisions =A0to communicate the lifetime and restrictions of the cap.
    I explicitly used that in my examples (one-time cap and=A0
    fair use resctictions) If such mechanisms are not standard practise
    (what i would find surprising) i think we should define them.


    >4) If not every previous state of an ob= ject is kept
    >eternally and after changing some object old cap= s (and
    >their static data) disappear - then how will the asset
    &= gt;servers that contain copies know that?=A0

    See a= bove for the mutability and lifetime issues. Regarding=A0
    storage= times of objects, Its up to the asset server to decide=A0
    what caps it gives out, if those are supposed to work eternally=A0
    the data should be kept eternally by a quality service. Garbage=A0
    collection rules can be advertised upfront, so users can decide wh= at
    service type fits there needs, and be prepared to find there stuff=A0<= /div>
    evaporated if they =A0opted for a minimal service...
    >5) [...]Are we going to build into the protocol a provisio= n for
    >such mutable bits?

    I would say no. Not th= at i dislike =A0the idea, but I wonder if that is a=A0
    VWRAP issu= e or something that could be delegated to lower levels. Certain=A0
    object types could have this mutability property in spite of a fixed ID, bu= t=A0
    at the protocol level its still an object like all others. O= r not?

    --Vaughn

    On Sat, Apr 9, 2011 at 3:11 AM, Morgaine <morgaine.dinova@googlemail.com>= ; wrote:
    Carlo, I too would like to hear what Vaughn had in mind in the areas you me= ntion, although it's perfectly possible that he was trying to keep the = issues of mutability and addressing out of the initial picture entirely, ju= st to keep things simple.=A0 They are important issues though, and I'm = glad that you pointed them out.

    Here I'll provide my views about this general area.

    First of= all, mutability breaks caching entirely, so it needs to be approached with= great caution.=A0 Caching can make the difference between a great service = and a totally unusable one (or at least one that doesn't work very well= ), so if mutability is allowed then things need to be designed in such a wa= y that caching still works most of the time, namely in between mutat= ions.

    This is an issue which has occupied many minds for decades, and I think= it can be distilled into the widely accepted notion that cached objects sh= ould never be overwritten, but only joined by updated versions.=A0 At a str= oke this lets highly concurrent asset services avoid the thorny issue of wr= iting in the presence of concurrent readers, and at the same time it lets c= aches have very simple update semantics since nothing is mutable from their= perspective.=A0 The only cost is some loss of disk space to hold old versi= ons, which is rarely significant given disk sizes and costs today.

    While that is good for asset services and caches, it does place the bur= den of achieving mutability on the parties who require it.=A0 And that of c= ourse is how burdens should be borne.

    What this means for virtual wo= rlds is that a mutator becomes responsible for notifying endpoints that som= ething has mutated, so that they can fetch the new versions.=A0 This needn&= #39;t be an onerous requirement, and it may not even need to be wrapped up = in security tape, since having had access once probably qualifies you for a= n unconditional update.=A0 In any case, the original item is still in its a= sset service (as well as in users' terabyte caches), so one very useful= property of this approach is that a simulation can't be broken for lon= g by a poor update since reverting is always possible.=A0 That's a an e= ngineering plus point.

    In respect of addressing, you mentioned using hashes as item addresses,= and this is of course my preferred strategy, which I have described and ad= vocated several times this week, and back in September.=A0 Hash-based addre= ssing has numerous excellent engineering properties that put it head and sh= oulders above other schemes.=A0 I say go with that approach.=A0 In any even= t, when we pit alternative schemes against each other on merit, I bet nothi= ng will come close to hash-based.

    On the issue of caps, I think that keeping their semantics simple has g= reat merit, because heavyweight schemes are less likely to be accepted, and= complex ones are unlikely to be implemented uniformly.=A0 But in any case,= as I described to Vaughn, caps should be optional anyway (ie. asset= dependent).=A0 Having to acquire a cap in order to fetch a Creative Common= s licensed asset is unnecessary, and indeed it is rather comic.=A0 A cap on= ly needs to be requested when the asset requires it, and only those assets = that need it should bear the burden.

    The issue of flag bits (or more generally, property fields) for assets = is one that interests me a lot, as it relates to the above.=A0 As I describ= ed to Vaughn, it is the assets that impose requirements on the protocol, no= t vice versa, so it is the assets that should carry the properties that con= trol the protocol.


    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
    <= /div>



    On Fri, Apr 8= , 2011 at 9:34 PM, Carlo Wood <carlo@alinoe.com> wrote:
    This is very nice work = and I think it clarifies a lot.

    I have a few very basic questions.

    I see that you request Z from two different Asset servers
    (originally A, but also C when a backup has been stored there).

    No matter how you look at it, that is distributed storage:
    compare it with git or mercurial; if Z on A could be changed
    then the backup would be out dated, and that is not what
    we want. So, I conclude that 'Z' (or rather, then handle
    used to refer to Z when asking for it) therefore refers to
    a unmodifiable data (compare git's hex ID's that point to
    a snapshot).

    1) Is that correct?

    If it is correct and the handle for Z used in messages
    like "give me a cap for Z" refer to immutable data, then
    the most logical thing to do would be to use a (large)
    hash value of the data (ie, md5) or an UUID that was
    generated when the data was last changed (which is less
    good because it would cause duplicated data when something
    is changed back to what it was before), or to use an
    ID that is less large, but whose uniqueness would be
    guaranteed by including a (for that authority unique) ID
    of the authority that made the last change. The advantage
    of the latter is less bandwidth (smaller ID's) and knowledge
    of the authority right into the ID of something (handy
    for routing). Disadvantages are: it suffers from the same
    as the UUID in that it will duplicate data whenever the
    same data is generated and it requires administration to
    make sure that every authority has a unique ID (compare
    giving people unique IP addresses).

    2) Which of those is used? has, UUID or smaller specially
    crafted ID?

    3) What would happen if someone gets a cap for Z, a
    modifiable object; then the object is modified and then
    the cap is used? Does the cap have a guaranteed life time?

    4) If not every previous state of an object is kept
    eternally and after changing some object old caps (and
    their static data) disappear - then how will the asset
    servers that contain copies know that? They are not
    necessarily aware that anything changed at all for
    that object, so they can't know what the life time
    is. It seems that once you make a copy you are doomed
    to keep it forever or do garbage collection for assets
    that are never accessed anymore.

    5) I can image that at SOME TIME in the future we want
    a few bit (or more) that ARE mutable-- despite that the
    asset ID (Z) refers to snapshot (immutable) data.
    Are we going to build into the protocol a provision for
    such mutable bits?

    This would mean, in the case that the ID is a hash (ie md5)
    that the asset Data exists of a payload that the hash is
    taken over plus a mutable part that is not considered for
    the hash. Obviously, such data then could get desynced
    between assets servers with copies.

    --
    Carlo Wood <carlo@= alinoe.com>
    _______________________________________________
    vwrap mailing list
    vwrap@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/vwrap


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


    --000e0cdfd9f852c3eb04a082e87a-- From vaughn.deluca@gmail.com Sat Apr 9 14:29:45 2011 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 345413A698F for ; Sat, 9 Apr 2011 14:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] 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 VjVokzvSDak3 for ; Sat, 9 Apr 2011 14:29:39 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 0A5BD3A681B for ; Sat, 9 Apr 2011 14:29:37 -0700 (PDT) Received: by eye13 with SMTP id 13so1651240eye.31 for ; Sat, 09 Apr 2011 14:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IKqcwuyHjedRvDh89v0RHTcjMHjz08i7iXXF5bggpSA=; b=cnUltn/M7i2YXMKTF1xrBqWzt60Q3tRWbKI3b+jz0QnR5JvpL35LiA0FRNxvwYltXN NamUiT45bgD4wPmAVpD8PyTB2XdU9QJZIjUCIqwFJyHC53m8IQ+CLI/3lUFR1dmWCOKf DGtHiT1eBMZA3tBOY+nx0gwF0RvCc8vr4oYpc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AhLGGR6rxabi1hJopPJsjk8dj+rmwB27cmEug1qeGDGhMKfxtBL4bzsSsJrrI69Day 9Mtm+pVrP21p3uxDRrv/Yd3/QQT9gNq/upJnnN2inactUC3sLz2dbQhb4DC9/kH0tvq1 AsdMo0Ll4gbklJfofpqHm14/s/vMsGSuMruM8= MIME-Version: 1.0 Received: by 10.213.0.202 with SMTP id 10mr1566035ebc.79.1302384681668; Sat, 09 Apr 2011 14:31:21 -0700 (PDT) Received: by 10.213.17.17 with HTTP; Sat, 9 Apr 2011 14:31:20 -0700 (PDT) In-Reply-To: References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> Date: Sat, 9 Apr 2011 23:31:20 +0200 Message-ID: From: Vaughn Deluca To: Morgaine Content-Type: multipart/alternative; boundary=000e0cdfd9f84fd13904a0831019 Cc: vwrap@ietf.org Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sat, 09 Apr 2011 21:29:45 -0000 --000e0cdfd9f84fd13904a0831019 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Morgaine, Thanks for the compliments and the extensive comments :) I am in a time crunch, so i will only respond to one aspect of your mail, and come back to some other points later. I am not sure i understand your emphasis on the (non)transfer of trust info to gain speed. When drafting the diagram I was thinking that depending on the "domain" of the sender of the message (with domain defined in the classical sense of a range of IP addresses) the authorisation info might simply be dropped and the data used without further checking if the receiver wishes to do so. Also since in the majority of cases only caps are passed that contain *implicit* trust. The checking of the validity of the cap is local to the service, and should be really fast. Regarding capabilities, i was viewing them not so much as credentials (although they are) but more as a convenient way to pass references to some bit of underlaying data around. You can't eliminate those messages even when not checking credentials. The roundtrips are anyhow needed to make sure that the communication is actually working. Or can we really get away with an UDP style of send and pray?? I fail to see how you would be able to realise a substantial gain over what will be needed anyhow as bare bone infrastructur= e and for error checking/reporting. But i might be wrong. One way way to find out is to implement it, and I feel that we are getting closer to be able to do just that. -- Vaughn On Sat, Apr 9, 2011 at 1:18 AM, Morgaine wr= ote: > Excellent work, Vaughn! > > You're right, I am working on something related to this, specifically a > design study for the Tourism use case. It happens to end with a protocol > sequence diagram presented as a table of text, so I was very pleased to s= ee > your highly relevant diagram. Yours captures part of my use case, and it= 's > a lot prettier than my text format. :P > > I was particularly impressed by the way you start off with completely > separable services right from the start. Since separable services can be > put together under a single administrative domain very easily, whereas > separating conjoined services is not easy at all, I think you've started > this off perfectly for the VWRAP approach to services. > > Because you have separated the services so well, your suggested protocol > flow could be said to to be targeting some kind of "*superset of all VWRA= P > deployments*" deployment. :-) Although it's logically structured, it's a > sort of worst-case scenario (or lawyer's delight) in which everyone has t= o > ask everyone else for permission to do anything, regardless of whether > permission is actually required or not. > > That's viable, but less than optimal. Specifically, you are working to t= he > principle of "The heaviest burden required by anyone must be borne by > everyone." I have been trying to stick to the opposite principle of "A > burden should be borne only by those whose use case requires it", which i= s > both fairer and more efficient. > > To illustrate this, consider the case of an asset service which serves (b= y > choice) only Creative Commons licensed assets --- an extremely important = use > case which could well become the dominant one in an open metaverse of > community worlds. Who knows, it could be operated by Debian, or Blender,= or > OSgrid, or even Google Warehouse. :P > > In such a scenario, because the license on all the assets in the asset > service permits unchecked distribution to all destinations in perpetuity, > the vast majority of all the request-grant protocol flows in your diagram > are superfluous when the assets come from this repository. By using a > protocol which understands *WHEN* it needs to ask a question, a large > amount of cumulative round-trip time latency (and its resulting lag) can = be > avoided entirely. This is also true on a per-asset basis if an asset > service serves a mixture of encumbered and freely distributable assets, > except that then the difference would be seen per-asset instead of per as= set > service. > > For such freely distributable assets, the agent service doesn't need to d= o > anything at all beyond recording the addresses of assets which are curren= tly > being worn by the agent. Since you start off your trip (sensibly) by > checking your clothing at home before you leave, you'll notice a broken > asset service locally anyway since your viewer will be trying to fetch it > for local viewing. The agent service need do nothing at all, beyond reco= rd > the addresses of top level items. (In my design study, I refer to a *Wor= n > Assets List *which is held by the user's agent service, and which is > entirely separate from any concept of inventory.) > > Likewise, region services don't need to fetch the graphic assets normally > either (unless they opt to proxy them), but only pass the addresses of th= ose > assets around to all the other agents in the corresponding region, so the > request-grant exchanges between regions and asset services can be avoided= in > this case. (Regions will be requesting other server-side data though, fo= r > example the bounding box information or collision mesh of an asset, which > typically the viewer would not be fetching.) > > That's not the end of the "*no unnecessary burden*" issue yet though, > because even if you removed all the unnecessary request-grant protocol > flows, you're still making the incorrect assumption that assets *ALL NEED > TO BE RESTRICTED* by the mere fact of asking for caps to everything. Thi= s > itself is wrong. The logic need to first determine whether a cap is need= ed > for fetching a given asset, and if it's not needed then the fetch can be > done by the viewer or region without this protocol burden at all. > > So you see, there is a fundamental assumption in your nicely laid out flo= ws > that all assets must be tied up in heavy red tape by the needs of the mos= t > burdensome use case. I don't agree with that, neither on principle nor o= n > engineering grounds. > > Many of the flows you have shown are exactly what we need for securing > access to proprietary resources, but not all resources have that burden, = and > I would want to elide a number of the flows away entirely when an asset > service allows it. > > To put it another way, the data is king, and protocol flows should reflec= t > the requirements imposed by data, not the other way around. > > I need this expressed in your flows, possibly as asset requirement > annotations. > > > PS. Great work Vaughn, I think this gives us a wonderful launching point= ! > > > Morgaine. > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > On Fri, Apr 8, 2011 at 5:40 PM, Vaughn Deluca wr= ote: > >> VWRAP services high level message flow (preliminary diagram draft) see >> >> >> http://trac.tools.ietf.org/wg/vwrap/trac/attachment/wiki/Diagrams/VWRAP_= FlowExample_VD1.pdf >> >> The main reason that i am submitting this in spite of my lack of formal >> expertise is that the group in my view badly needs a solid basis for >> discussion and preventing endless repeating loops. This example is proba= bly >> wrong in many ways, but its better than what we have publicly available = on >> interop now (although Morgaine is working on something along the lines o= f >> the recent discussions here) >> >> I hope this diagram will give us a base for discussion. I could have don= e >> my homework better by researching the old OGP stuff in more depth, and i >> probably will do so in the future , but for now I just tried to followe= d >> the general principles as far as i understand them, to see what response >> that yields from the group. In other words,I try to let the group educat= e me >> :p >> >> Note that in my view all services are equal, in principle it does not >> matter in what "domain" they run, since trust and policy are fully >> localized. It is however very possible to have internal shortcuts in the >> services to speed up processing. >> >> In the example I opted for an external Agent service, but I could as wel= l >> have incorporated that in the set of local services. As indicated above = all >> services could also be run by different organisations, true to what VWRA= P >> stands for. Its all up to the deployer, including a user at home who mig= ht >> want to run a full world for family and friends. Those friends might try= to >> use that agent service to venture out in the virtual universe. >> I envision that the final identity provider is external, using OpenID a= nd >> OAut or whatever other magic that I do not yet fully understand exists= out >> there. >> >> The example has 3 main purposes: >> - Provide a reference for discussion >> - Illustrates the use case of tourism, and *true* interop. >> - Illustrate consistency problems along the lines discussed here higher >> up in this tread, as well as the "slashdot" problem that Morgaine outlin= ed >> so clearly. >> >> The message flow assumes an avatar already present in some region, (a >> small scale local home region in this case, but that is by no means >> essential, it could be a build in region in the viewer or a big commerci= al >> region). The user is preparing for a trip to immersive world, and after = some >> outfit adjustments moves over. >> >> Finally i apologize for for the simplistic notation used here. I simply >> add the most relevant parameters passed in square brackets to a keyword >> specifying the nature of the message. Please improve on that where neede= d. >> >> So here we go, the avatar is prepare for a visit to "immersive world" >> 0) Viewer, here is an update of the state of the world your agent is in= , >> please render. >> 1) Agent service, I will go in my Zodiac dress that i keep in the >> "Amazing assets" service. >> 2) Asset service A, please send a cap for Z, here are my credentials >> 3) Your fine, here is the cap >> 4) Local region, can you please put this on my agent, i included the ca= p. >> 5) Hello asset service A, i need Z, here is the cap >> 6) Cap is good, data coming up, have fun. >> 7) Agent service, your agent is now wearing Z >> 8) Viewer, your avatar is now wearing Z >> User: Hmm, amazing inventory has not been *that* amazing lately. 'll >> make a backup, just in case >> 9) Hello asset service A, please send me a cap for Z, here are my >> credentials >> 10) Your fine, here is the cap >> 11) Local asset storage, please store Z for me, here is the cap to get i= t >> 12) Hello asset service A, i want Z, here is the cap >> 13) Cap is good, data coming up, have fun. >> 14) Viewer, Z is now stored for you >> User: I am Ready!, Lets try to get to immersive world! >> 15) Hello immersive world, can i get in? Here are my credentials, and a >> list of my stuff. >> 16) Asset service A, please send me a cap for X, here are my credentials >> (I want this cap for consistency) >> 17) Your fine, here is the cap >> 18) Asset service B, please send me a cap for Y, here are my credentials >> (I want this cap for consistency) >> 19) Very sorry, but your not one of us, you can't have Y >> 20) Asset service B, please send me a cap for Z, here are my credentials >> (I want a cap for consistency) >> [Region service: Timeout... amazing inventory must be overloaded.. oh >> well... ] >> 21) Agent service, you wanted to send somebody over, here are your >> permissions. >> 22) Viewer, you asked for a transfer try, here are your results >> User thinks: Crap! Big asset service does not allow me to take my >> yellow stockings! And Amazing assets failed to deliver my zodiac dress.= At >> least i made a backup of that dress! >> 23) 'll take the yellow stockings off... >> 24) ... done ('ll trash them here and now, forever, who needs stuff you >> can't use!) >> 25) The zodiac dress was not delivered by Big assets service, but i have= a >> local copy! >> 26) Local Asset service, please send me Z, here are my credentials >> 27) I dont know you, but I 'll trust you, here is the cap, but you bette= r >> store the data, its single use, i need to protect myself. >> 28) Local region, can you please put this on my agent, i include the cap= . >> 29) Local Asset service, i need Z, here is the cap >> 30) Cap is good, data coming up, have fun. >> 31) Cap was only good for one time, I made a copy, but my policy is to >> only grant you fair use rights, at a later time i might even tell you to >> replace the dress. >> 32) Viewer, you can wear Z for now, but the asset service granted only >> fair use, i might ask you to replace the dress at a later time. >> 33) Ready at last! Off to immersive world!, I hope its not to crowded >> there or 'll loose my dress... >> 34) Hello immersive world, here are my credentials, and a list of stuff = i >> want to bring >> 35) Hello asset service A, please send me a cap for X, here are my >> credentials >> [darn, I should have kept that cap from last time..] >> 36) Your fine, here is the cap. >> [Region service finds fair-use warning on Z and decides to make its o= wn >> copy] >> 37) Hello Local region, can i still have Z? Here is the cap >> 38) Cap is still good, data coming up, have fun. >> [Region service stores asset in private storage, providing a cap to >> replace the fair use one] >> 39) Agent service, you wanted to send somebody over, here are your >> permissions & info. >> 40) Hello immersive world, just get me there, and use what you can >> 41) Placement done, Z is currently buffered by us as wel, you need to ge= t >> details for X, have fun. >> 42) You are now in immersive world, your dress is buffered there as well= , >> but you need to get X! >> 43) Hello asset service A, i want X, here is the cap >> 44) Cap is good, data coming up, have fun. >> 45) Viewer, here is an update of the state of the world your agent is in= , >> please render. >> >> As far as I can see this conforms fully to our charter, and i hope it is >> possible to use large portions of the existing code bases. However, as s= aid >> above, i did not really try to capture the old thinking, and I also migh= t >> have misconceptions about the way to do these things in general. >> Looking forward to constructive comments. >> >> -- Vaughn >> >> On Sun, Apr 3, 2011 at 8:38 PM, Vaughn Deluca w= rote: >> >>> Thanks for the pointers. I have a busy week in RL in front of me, so = i >>> wont have to much time to respond the next few days, however, i intend = to >>> start doing the following things: >>> >>> - Produce a visual that reflects my thinking, i.e. an illustration of m= y >>> response to Morgaine's itemlist above. >>> - Read up on the older notes, as well as more reading in the list >>> archive >>> - Try to make a summary for the wiki >>> >>> Regarding the use of domain, I think services are eventually what count= s, >>> but its all terminology. The way I read the AWG diagrams is that the ag= ent >>> domain is actually a cluster of tightly integrated services. When the >>> functionality of each sub-service is described properly and with unifor= m >>> interfaces the domain will slowly dissolve. But let not get ahead of ou= t >>> selfs. We should put up some clear descriptions on the wiki for our vie= ws on >>> this, and *after* that we can decide what we need and what can go. >>> >>> Its been a very useful and illuminating weekend for me, and i am a lot >>> more optimistic about the future of vwrap than two weeks ago. >>> >>> -- Vaughn >>> >>> >>> >>> On Sun, Apr 3, 2011 at 7:20 PM, Dzonatas Sol wrote= : >>> >>>> Probably easy as suggested in other terms here on this list, as how th= e >>>> client contacts the asset services now in the regions. The newer issue= is to >>>> unitize that asset services. Since their is proprietary (legacy) code = then >>>> we can't expect that to change, and some form of proxy is of need. Wha= tever >>>> works best, I tried to narrow it down to suggestions here. >>>> >>>> Eventually, the agent domain is ideal to handle the direction of the >>>> asset services. This concept, unfortunately, ended support awhile ago = with >>>> changes in LL. >>>> Also see; http://wiki.secondlife.com/wiki/Agent_Domain >>>> And: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset (warn= : >>>> unstructured collaborative notes, dumped on me and I tried to fix) >>>> >>>> I tried to find previous visuals. >>>> >>>> I'd imagine the agent domain could grow out of unitized versions of >>>> asset services. Despite that, I think that concept helps view where we= were >>>> at in discussion and what didn't happen. >>>> >>>> Vaughn Deluca wrote: >>>> >>>>> Hi=EF=BF=BDDzonatas >>>>> >>>>> Can you expand on that, what would be needed for legacy support in VW= AP >>>>> terms=EF=BF=BD?, >>>>> If i want to read up on how the=EF=BF=BDasset server may proxy the si= mulator, >>>>> what would you recommend me to read? >>>>> >>>>> -- Vaughn >>>>> >>>>> On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol >>>> dzonatas@gmail.com>> wrote: >>>>> >>>>> Some stated the proxy-to-asset-server is built into the sim; >>>>> however, keep in mind possible legacy support where the asset >>>>> server may proxy the simulator. >>>>> >>>>> >>>>> Dzonatas Sol wrote: >>>>> >>>>> Somehow I feel the basic asset server being able to login and >>>>> download assets is now priority, yet I also wondered the best >>>>> way to patch this into the current mode of viewers. >>>>> >>>>> Maybe offer (1) by proxy (sim-side) and (2) by patch >>>>> (viewer-side) that either of these two are optional and >>>>> neither are mandatory for now. Thoughts? >>>>> >>>>> Israel Alanis wrote: >>>>> >>>>> >>>>> > when designing for scalability, the model to bear in >>>>> mind is ... >>>>> >>>>> Well, there are a lot of different models to keep in mind, >>>>> and many different use cases. One particular use case to >>>>> keep in mind is: "User acquires new outfit, and wants to >>>>> 'show it off' in a highly populated region". >>>>> >>>>> > Both worlds and asset services may include commercial, >>>>> community, and personal services >>>>> >>>>> Yes, yes and yes. I'm particularly concerned about how the >>>>> model affects the ability to host personal asset services. >>>>> >>>>> > a proxying region, which would get slammed for every >>>>> asset worn by every avatar present. >>>>> >>>>> Granted the collection of services that are provided by >>>>> the region need to be scaled to meet the demands of that >>>>> region. That's all part of capacity planning. >>>>> >>>>> > regions run many different CPU-intensive tasks, >>>>> including physics simulation and server-side scripting, >>>>> and absolutely cannot afford to serve assets too >>>>> Well... who said the same CPU's have to do proxying, >>>>> physics simulation and server-side scripting? Asset >>>>> proxying is a different service than physics simulation >>>>> and can be on separate hardware, could make use of >>>>> geographically distributed caching, and in certain >>>>> deployment patterns, the same caching services could be >>>>> shared by different regions. (Server-side scripting is a >>>>> discussion for another day). >>>>> >>>>> > This is why we have to go parallel... >>>>> >>>>> Totally agree, and a proxying model could and should also >>>>> take advantage of parallelism. >>>>> >>>>> > I think you're wrong that it has to cost much money. ?vs= ? >>>>> > It costs money to host a high performance and scalable >>>>> asset service and a high bandwidth network to handle the >>>>> traffic. =EF=BF=BDA *lot* of money. >>>>> I think what you're saying is: "It costs a lot of money to >>>>> build a scalable asset service, but if assets are spread >>>>> throughout the internet they don't have to be scalable." >>>>> But that's not quite right. You're opening up every asset >>>>> server to the VW equivalent of being slashdotted, so are >>>>> you sure you're not forcing *every* asset service to be >>>>> scalable and handle a lot of bandwith and network traffic? >>>>> It's the exact opposite of your intention, but I think >>>>> that's the result, all the same. >>>>> >>>>> This particular design decision has a big effect on the >>>>> economics of the VW infrastructure. I'd rather the >>>>> economics to work out such that a region provider who >>>>> wishes to build a region that supports a small population, >>>>> can do so economically. A region that wants to host a >>>>> *large* population has to bear that cost of providing that >>>>> scalable asset service. >>>>> I want the economics of hosting a small asset service to >>>>> be a non-issue (as to best promote creation and >>>>> creativity). Creating a high bar to provide asset services >>>>> will mean that service will cost money and people >>>>> shouldn't have to pay money just to create or own VW >>>>> objects (I'm using 'own' here to refer to maintaining >>>>> their existence, I'm not trying to make a >>>>> 'leftist'/'communist' statement about ownership ;) >>>>> >>>>> - Izzy >>>>> >>>>> >>>>> On Apr 2, 2011, at 3:58 PM, Morgaine wrote: >>>>> >>>>> Izzy, when designing for scalability, the model to >>>>> bear in mind is that of seasoned virtual world >>>>> travelers whose inventories contain assets from many >>>>> different worlds, those assets being served by many >>>>> different asset services. =EF=BF=BDBoth worlds and ass= et >>>>> services may include commercial, community, and >>>>> personal services, and as the metaverse grows, that >>>>> set is highly likely to become progressively less >>>>> clustered and more diverse. >>>>> >>>>> When those seasoned travelers click on an advertised >>>>> VW link and perform an inter-world teleport to one >>>>> particular world's region to share an experience, >>>>> their "worn" assets (the only ones of interest to the >>>>> region) will contain references to asset services >>>>> spread widely across the Internet. =EF=BF=BDThe fetche= s by the >>>>> travelers' clients occur over many parallel paths from >>>>> clients to asset services, so one can reasonably >>>>> expect reduced network contention and reduced asset >>>>> server loading because they are both spread out over >>>>> however many asset services are being referenced by >>>>> the overall set of assets in the region. >>>>> >>>>> This is very different to the case of a proxying >>>>> region, which would get slammed for every asset worn >>>>> by every avatar present. =EF=BF=BDIn our current archi= tecture, >>>>> regions run many different CPU-intensive tasks, >>>>> including physics simulation and server-side >>>>> scripting, and absolutely cannot afford to serve >>>>> assets too unless your scalability requirements are >>>>> very low indeed, ie. just a few dozen avatars of >>>>> today's kind. =EF=BF=BDWe've hit the ceiling already o= n region >>>>> scalability done that way. =EF=BF=BDThere is nowhere t= o go in >>>>> that direction at all beyond improving the code like >>>>> Intel demonstrated, and that work is subject to a law >>>>> of diminishing returns. >>>>> >>>>> This is why we have to go parallel, and I think you're >>>>> wrong that it has to cost much money. =EF=BF=BDAs we s= pread >>>>> the load across more and more asset services, we are >>>>> simply better utilizing all the hardware that's >>>>> already out there on the Internet, at least in respect >>>>> of community and private resources. =EF=BF=BDBut add t= o the >>>>> community and private resources the commercial asset >>>>> services that are likely to appear to exploit this >>>>> opportunity, and not only will the number of asset >>>>> services leap, but the power of each one will rocket >>>>> too, because, after all, these businesses will be >>>>> heavily optimized for the job. >>>>> >>>>> As to why a world would want clients to access >>>>> external asset services instead of providing its own >>>>> implementation, that's an easy question. =EF=BF=BDIt c= osts >>>>> money to host a high performance and scalable asset >>>>> service and a high bandwidth network to handle the >>>>> traffic. =EF=BF=BDA *lot* of money. =EF=BF=BDIn contra= st, it costs a >>>>> world nothing to let others serve the assets to >>>>> clients. =EF=BF=BDAnd that matters to the bottom line. >>>>> >>>>> >>>>> Morgaine. >>>>> >>>>> >>>>> >>>>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>>> >>>>> On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis >>>>> >>>>> >>>> >>>>> >> wrote: >>>>> >>>>> =EF=BF=BD =EF=BF=BD> As always though, it's a trade-of= f, since the >>>>> proxied design >>>>> =EF=BF=BD =EF=BF=BDhas very poor scalability compared = to the >>>>> distributed one. >>>>> >>>>> =EF=BF=BD =EF=BF=BDI don't agree with that... If a use= r enters a >>>>> highly populated >>>>> =EF=BF=BD =EF=BF=BDregion, >>>>> =EF=BF=BD =EF=BF=BDevery other client is going to (cou= ld and should be >>>>> trying to) >>>>> =EF=BF=BD =EF=BF=BDhit the >>>>> =EF=BF=BD =EF=BF=BDasset server(s) for the assets that= the user is >>>>> wearing (assuming >>>>> =EF=BF=BD =EF=BF=BDthey're not cached locally). =EF=BF= =BDEvery asset server >>>>> has to be scaled up >>>>> =EF=BF=BD =EF=BF=BDto the point that it can handle tha= t load from all >>>>> over... >>>>> >>>>> =EF=BF=BD =EF=BF=BDIf I'm hosting a region that suppor= ts 10s of >>>>> thousands of >>>>> =EF=BF=BD =EF=BF=BDsimultaneous >>>>> =EF=BF=BD =EF=BF=BDusers (thinking of the future), I a= lready have to >>>>> scale to meet that >>>>> =EF=BF=BD =EF=BF=BDdemand. If the region is proxying t= he assets, then, >>>>> yes the >>>>> =EF=BF=BD =EF=BF=BDregion has >>>>> =EF=BF=BD =EF=BF=BDto be scaled to meet that asset dem= and too, but it >>>>> already has to be >>>>> =EF=BF=BD =EF=BF=BDscaled to meet other demands of bei= ng a region >>>>> server... and why is >>>>> =EF=BF=BD =EF=BF=BDscaling those asset proxy services = hard? =EF=BF=BDIt's >>>>> going to cost $, >>>>> =EF=BF=BD =EF=BF=BDbut is >>>>> =EF=BF=BD =EF=BF=BDnot technically challenging. So, if= I want to host >>>>> a region like >>>>> =EF=BF=BD =EF=BF=BDthat... sure it will cost me, but t= he simulation >>>>> will be consistent >>>>> =EF=BF=BD =EF=BF=BDand users will be able to participa= te equally, >>>>> regardless of the >>>>> =EF=BF=BD =EF=BF=BDcapabilities of their individual as= set services. >>>>> >>>>> >>>>> >>>>> >>>>> =EF=BF=BD =EF=BF=BDOn Fri, Apr 1, 2011 at 11:55 PM, Mo= rgaine >>>>> =EF=BF=BD =EF=BF=BD>>>> >>>>> =EF=BF=BD =EF=BF=BD>>>> >>>>> >> wrote: >>>>> =EF=BF=BD =EF=BF=BD> Every design choice results in a = trade-off, >>>>> Vaughn, improving >>>>> =EF=BF=BD =EF=BF=BDone thing at >>>>> =EF=BF=BD =EF=BF=BD> the expense of something else. = =EF=BF=BDIf every time we >>>>> offered a >>>>> =EF=BF=BD =EF=BF=BDservice we had to >>>>> =EF=BF=BD =EF=BF=BD> inform its users about the downsi= des of all the >>>>> trade-offs we >>>>> =EF=BF=BD =EF=BF=BDhave made, >>>>> =EF=BF=BD =EF=BF=BD> they would have an awful lot to r= ead. ;-) >>>>> =EF=BF=BD =EF=BF=BD> >>>>> =EF=BF=BD =EF=BF=BD> The specific trade-off that you a= re discussing is >>>>> no >>>>> =EF=BF=BD =EF=BF=BDdifferent. =EF=BF=BDA region >>>>> =EF=BF=BD =EF=BF=BD> that proxies all content has the = "benefit" of >>>>> acquiring control >>>>> =EF=BF=BD =EF=BF=BDfrom the >>>>> =EF=BF=BD =EF=BF=BD> asset servers over the items in t= he region, so >>>>> that it can >>>>> =EF=BF=BD =EF=BF=BDensure that >>>>> =EF=BF=BD =EF=BF=BD> everyone in the region not only o= btains the items >>>>> but obtains >>>>> =EF=BF=BD =EF=BF=BDthe same items >>>>> =EF=BF=BD =EF=BF=BD> as everyone else. =EF=BF=BDThat d= oes indeed provide a >>>>> greater guarantee of >>>>> =EF=BF=BD =EF=BF=BD> consistency than a deployment in = which the region >>>>> only passes >>>>> =EF=BF=BD =EF=BF=BDasset URIs to >>>>> =EF=BF=BD =EF=BF=BD> clients who then fetch the items = from asset >>>>> services >>>>> =EF=BF=BD =EF=BF=BDseparately. =EF=BF=BDAs always >>>>> =EF=BF=BD =EF=BF=BD> though, it's a trade-off, since t= he proxied >>>>> design has very >>>>> =EF=BF=BD =EF=BF=BDpoor scalability >>>>> =EF=BF=BD =EF=BF=BD> compared to the distributed one. >>>>> =EF=BF=BD =EF=BF=BD> >>>>> =EF=BF=BD =EF=BF=BD> If we're going to warn users of t= he potential for >>>>> inconsistency >>>>> =EF=BF=BD =EF=BF=BDin the >>>>> =EF=BF=BD =EF=BF=BD> distributed deployment as you sug= gest, are we >>>>> also going to >>>>> =EF=BF=BD =EF=BF=BDwarn them of >>>>> =EF=BF=BD =EF=BF=BD> non-scalability in the proxied on= e? =EF=BF=BDI really >>>>> don't see much >>>>> =EF=BF=BD =EF=BF=BDmerit in the >>>>> =EF=BF=BD =EF=BF=BD> idea of warning about design choi= ces. =EF=BF=BDMany such >>>>> choices are >>>>> =EF=BF=BD =EF=BF=BDtechnical, and >>>>> =EF=BF=BD =EF=BF=BD> the issues are quite likely to be= of little >>>>> interest to >>>>> =EF=BF=BD =EF=BF=BDnon-technical users >>>>> =EF=BF=BD =EF=BF=BD> anyway. =EF=BF=BDIn any case, the= better services are >>>>> likely to provide >>>>> =EF=BF=BD =EF=BF=BDsuch >>>>> =EF=BF=BD =EF=BF=BD> information in their online docum= entation, I >>>>> would guess. >>>>> =EF=BF=BD =EF=BF=BD> >>>>> =EF=BF=BD =EF=BF=BD> You mentioned users "voting with = their feet" or >>>>> choosing to >>>>> =EF=BF=BD =EF=BF=BDaccept the risk >>>>> =EF=BF=BD =EF=BF=BD> of inconsistency. =EF=BF=BDWell t= hat will happen anyway, >>>>> when services >>>>> =EF=BF=BD =EF=BF=BDfail and >>>>> =EF=BF=BD =EF=BF=BD> users get annoyed. =EF=BF=BDIf so= me asset services refuse >>>>> to send the >>>>> =EF=BF=BD =EF=BF=BDrequested >>>>> =EF=BF=BD =EF=BF=BD> items to some users, those servic= es will get a >>>>> bad reputation >>>>> =EF=BF=BD =EF=BF=BDand people >>>>> =EF=BF=BD =EF=BF=BD> will choose different asset servi= ces instead. >>>>> =EF=BF=BDLikewise, if a >>>>> =EF=BF=BD =EF=BF=BDworld service >>>>> =EF=BF=BD =EF=BF=BD> proxies everything and so it can'= t handle a large >>>>> number of >>>>> =EF=BF=BD =EF=BF=BDassets or of >>>>> =EF=BF=BD =EF=BF=BD> people, users will get annoyed at= the lag and will >>>>> go >>>>> =EF=BF=BD =EF=BF=BDelsewhere. =EF=BF=BDThis user >>>>> =EF=BF=BD =EF=BF=BD> evaluation and "voting with their= feet" happens >>>>> already with >>>>> =EF=BF=BD =EF=BF=BDonline services >>>>> =EF=BF=BD =EF=BF=BD> all over the Internet, and I am s= ure that this >>>>> human process >>>>> =EF=BF=BD =EF=BF=BDwill continue >>>>> =EF=BF=BD =EF=BF=BD> to work when the services are ass= et and region >>>>> services. >>>>> =EF=BF=BD =EF=BF=BD> >>>>> =EF=BF=BD =EF=BF=BD> Back in September 2010, I wrote t= his post which >>>>> proposes that >>>>> =EF=BF=BD =EF=BF=BDwe use in >>>>> =EF=BF=BD =EF=BF=BD> VWRAP a form of asset addressing = that provides >>>>> massive >>>>> =EF=BF=BD =EF=BF=BDscalability at the >>>>> =EF=BF=BD =EF=BF=BD> same time as a very high degree o= f resilience -- >>>>> =EF=BF=BD =EF=BF=BD> >>>>> =EF=BF=BD >>>>> =EF=BF=BD >>>>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >>>>> =EF=BF=BD =EF=BF=BD. =EF=BF=BDIt is >>>>> =EF=BF=BD =EF=BF=BD> based on the concept of the URI c= ontaining a host >>>>> part and a >>>>> =EF=BF=BD =EF=BF=BDhash part, >>>>> =EF=BF=BD =EF=BF=BD> where the hash is generated (once= , at the time of >>>>> storage to >>>>> =EF=BF=BD =EF=BF=BDthe asset >>>>> =EF=BF=BD =EF=BF=BD> service) using a specified digest= algorithm over >>>>> the content of >>>>> =EF=BF=BD =EF=BF=BDthe asset >>>>> =EF=BF=BD =EF=BF=BD> being referenced. =EF=BF=BDYou ma= y wish to note that if >>>>> this design >>>>> =EF=BF=BD =EF=BF=BDwere used, the >>>>> =EF=BF=BD =EF=BF=BD> failure of an asset service to de= liver a >>>>> requested item would >>>>> =EF=BF=BD =EF=BF=BDresult in a >>>>> =EF=BF=BD =EF=BF=BD> failover request for the item to = one or more >>>>> backup services, >>>>> =EF=BF=BD =EF=BF=BDusing the same >>>>> =EF=BF=BD =EF=BF=BD> hash part but with a different ho= st address. >>>>> =EF=BF=BD =EF=BF=BD> >>>>> =EF=BF=BD =EF=BF=BD> This can go some way towards over= coming the >>>>> problem that you >>>>> =EF=BF=BD =EF=BF=BDthink might >>>>> =EF=BF=BD =EF=BF=BD> occur when assets are fetched by = clients from >>>>> asset services >>>>> =EF=BF=BD =EF=BF=BDdirectly. >>>>> =EF=BF=BD =EF=BF=BD> Although it won't help when the m= issing item is >>>>> available from >>>>> =EF=BF=BD =EF=BF=BDonly a single >>>>> =EF=BF=BD =EF=BF=BD> asset service, it will help in ma= ny other cases, >>>>> and it will >>>>> =EF=BF=BD =EF=BF=BDcompensate for >>>>> =EF=BF=BD =EF=BF=BD> service failures and network outa= ges >>>>> automatically at the same >>>>> =EF=BF=BD =EF=BF=BDtime. >>>>> =EF=BF=BD =EF=BF=BD> >>>>> =EF=BF=BD =EF=BF=BD> PS. This design for hash-based as= set addressing >>>>> is already >>>>> =EF=BF=BD =EF=BF=BDbeing tested by >>>>> =EF=BF=BD =EF=BF=BD> Mojito Sorbet in her experimental= world and >>>>> client. =EF=BF=BDIt would give >>>>> =EF=BF=BD =EF=BF=BD> VWRAP-based worlds an improved le= vel of service >>>>> availability, >>>>> =EF=BF=BD =EF=BF=BDso I think it >>>>> =EF=BF=BD =EF=BF=BD> should be a core feature of our p= rotocol. >>>>> =EF=BF=BD =EF=BF=BD> >>>>> =EF=BF=BD =EF=BF=BD> >>>>> =EF=BF=BD =EF=BF=BD> Morgaine. >>>>> =EF=BF=BD =EF=BF=BD> >>>>> =EF=BF=BD =EF=BF=BD> >>>>> =EF=BF=BD =EF=BF=BD> >>>>> =EF=BF=BD =EF=BF=BD> >>>>> =EF=BF=BD =EF=BF=BD> =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 >>>>> =EF=BF=BD =EF=BF=BD> >>>>> =EF=BF=BD =EF=BF=BD> On Fri, Apr 1, 2011 at 11:17 PM, = Vaughn Deluca >>>>> =EF=BF=BD =EF=BF=BD>>>> >>>>> >>>> >> >>>>> =EF=BF=BD =EF=BF=BD> wrote: >>>>> =EF=BF=BD =EF=BF=BD>> >>>>> =EF=BF=BD =EF=BF=BD>> This is a question i discussed w= ith Morgaine >>>>> off-list a while >>>>> =EF=BF=BD =EF=BF=BDago (I >>>>> =EF=BF=BD =EF=BF=BD>> intended to send it to the list = but pushed the >>>>> wrong button...) I >>>>> =EF=BF=BD =EF=BF=BD>> think we need to address this pr= oblem, and >>>>> decide how to deal >>>>> =EF=BF=BD =EF=BF=BDwith it. >>>>> =EF=BF=BD =EF=BF=BD>> >>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDIn Davids deployment dr= aft, section 7.3.1.1 an >>>>> overview is >>>>> =EF=BF=BD =EF=BF=BDgiven van >>>>> =EF=BF=BD =EF=BF=BD>> ways to deliver content to the r= egion. One way >>>>> is only passing a >>>>> =EF=BF=BD =EF=BF=BD>> capability that allows access to= (part of) the >>>>> resource: >>>>> =EF=BF=BD =EF=BF=BD>> >>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD 7.3.1.1. =EF=BF=BDContent delivery models >>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD A range of possible represenations can >>>>> be passed to >>>>> =EF=BF=BD =EF=BF=BDa region for >>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD simulation. [...] The other end of the >>>>> delivery spectrum >>>>> =EF=BF=BD =EF=BF=BD>> involves passing >>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD only a URI or capability used to >>>>> access the rendering >>>>> =EF=BF=BD =EF=BF=BD>> information and a >>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD collision mesh,and related data for >>>>> physical simulation. >>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD In such a model, the client is >>>>> responsible for >>>>> =EF=BF=BD =EF=BF=BDfetching the >>>>> =EF=BF=BD =EF=BF=BD>> additional >>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD information needed to render the >>>>> item's visual >>>>> =EF=BF=BD =EF=BF=BDpresence from a >>>>> =EF=BF=BD =EF=BF=BD>> separate >>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD service. =EF=BF=BDThis fetch can be done >>>>> *under the >>>>> =EF=BF=BD =EF=BF=BDcredentials of the >>>>> =EF=BF=BD =EF=BF=BD>> end user* >>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD viewing the material [my emphasis--VD] >>>>> , and >>>>> =EF=BF=BD =EF=BF=BDdivorces the >>>>> =EF=BF=BD =EF=BF=BD>> simulation from >>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD the trust chain needed to manage >>>>> content. =EF=BF=BDAny >>>>> =EF=BF=BD =EF=BF=BDautomation >>>>> =EF=BF=BD =EF=BF=BD>> is done on a >>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD separate host which the content >>>>> creator or owner trusts, >>>>> =EF=BF=BD =EF=BF=BD>> interacting with the >>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD object through remoted interfaces. >>>>> =EF=BF=BD =EF=BF=BD>> >>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDI can see the need for = such a setup, however, i >>>>> feel we are >>>>> =EF=BF=BD =EF=BF=BD>> unpleasantly close to a situatio= n were the >>>>> coherence of the >>>>> =EF=BF=BD =EF=BF=BDsimulation >>>>> =EF=BF=BD =EF=BF=BD>> falls apart. >>>>> =EF=BF=BD =EF=BF=BD>> In this deployment pattern the r= egion advertises >>>>> the presence >>>>> =EF=BF=BD =EF=BF=BDof the >>>>> =EF=BF=BD =EF=BF=BD>> asset, and *some* clients will b= e able to get it >>>>> as expected, >>>>> =EF=BF=BD =EF=BF=BDwhile >>>>> =EF=BF=BD =EF=BF=BD>> -based on the arbitrary whims of= the asset >>>>> service- others >>>>> =EF=BF=BD =EF=BF=BDmight not. >>>>> =EF=BF=BD =EF=BF=BD>> >>>>> =EF=BF=BD =EF=BF=BD>> My hope would be that after the = asset server >>>>> provides the >>>>> =EF=BF=BD =EF=BF=BDregion with >>>>> =EF=BF=BD =EF=BF=BD>> the capability to get the asset,= it gives up >>>>> control. That >>>>> =EF=BF=BD =EF=BF=BDwould mean >>>>> =EF=BF=BD =EF=BF=BD>> that if the client finds the inv= entory server is >>>>> unwilling to >>>>> =EF=BF=BD =EF=BF=BDserve >>>>> =EF=BF=BD =EF=BF=BD>> the content - in spire of the re= gion saying it >>>>> is present-, >>>>> =EF=BF=BD =EF=BF=BDthe client >>>>> =EF=BF=BD =EF=BF=BD>> should be able to turn around as= k the *region* >>>>> for the asset, >>>>> =EF=BF=BD =EF=BF=BD(and get >>>>> =EF=BF=BD =EF=BF=BD>> is after all). >>>>> =EF=BF=BD =EF=BF=BD>> >>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDIf that is not the case= , -and there are >>>>> probably good reasons >>>>> =EF=BF=BD =EF=BF=BDfor the >>>>> =EF=BF=BD =EF=BF=BD>> deployment pattern as described-= =EF=BF=BDshouldn't we >>>>> *warn* clients >>>>> =EF=BF=BD =EF=BF=BDthat the >>>>> =EF=BF=BD =EF=BF=BD>> region might be inconsistent, so= the users >>>>> behind the client >>>>> =EF=BF=BD =EF=BF=BDcan vote >>>>> =EF=BF=BD =EF=BF=BD>> with their feet, (or take the ri= sk)? >>>>> =EF=BF=BD =EF=BF=BD>> >>>>> =EF=BF=BD =EF=BF=BD>> --Vaughn >>>>> =EF=BF=BD =EF=BF=BD>> ________________________________= _______________ >>>>> =EF=BF=BD =EF=BF=BD>> vwrap mailing list >>>>> =EF=BF=BD =EF=BF=BD>> vwrap@ietf.org >>>>> > >>>>> >>>>> =EF=BF=BD =EF=BF=BD>> https://www.ietf.org/mailman/lis= tinfo/vwrap >>>>> =EF=BF=BD =EF=BF=BD> >>>>> =EF=BF=BD =EF=BF=BD> >>>>> =EF=BF=BD =EF=BF=BD> _________________________________= ______________ >>>>> =EF=BF=BD =EF=BF=BD> vwrap mailing list >>>>> =EF=BF=BD =EF=BF=BD> vwrap@ietf.org >>>>> > >>>>> >>>>> =EF=BF=BD =EF=BF=BD> https://www.ietf.org/mailman/list= info/vwrap >>>>> =EF=BF=BD =EF=BF=BD> >>>>> =EF=BF=BD =EF=BF=BD> >>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------= ---- >>>>> >>>>> _______________________________________________ >>>>> vwrap mailing list >>>>> vwrap@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/vwrap >>>>> =EF=BF=BD >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- --- https://twitter.com/Dzonatas_Sol --- >>>>> Web Development, Software Engineering, Virtual Reality, Consultant >>>>> >>>>> _______________________________________________ >>>>> vwrap mailing list >>>>> vwrap@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/vwrap >>>>> >>>>> >>>>> >>>> >>>> -- >>>> --- https://twitter.com/Dzonatas_Sol --- >>>> Web Development, Software Engineering, Virtual Reality, Consultant >>>> >>>> >>> >> >> _______________________________________________ >> >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > --000e0cdfd9f84fd13904a0831019 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Morgaine,=C2=A0

    Thanks for the compliments and the exten= sive comments =C2=A0:)
    I am in a time crunch, so i will only resp= ond to one aspect of your mail, and come back to some other points later.

    I am not sure i understand your emphasis on the (non)tr= ansfer of trust info to gain speed. When drafting the diagram I was thinkin= g that depending on the =C2=A0"domain" of the sender of the messa= ge =C2=A0(with domain defined in the classical sense of a range of IP addre= sses) the authorisation info might =C2=A0simply be dropped and the data use= d without further checking if the receiver wishes to do so. Also since in t= he majority of cases only caps are passed that contain *implicit* trust. Th= e checking of the validity of the cap is local to the service, and should b= e really fast.

    Regarding capabilities, i was viewing them not so= much as credentials (although they are) but more
    as a convenient= way to pass references to some bit of underlaying data around. You can'= ;t =C2=A0eliminate those messages even when not checking credentials. The r= oundtrips are anyhow needed to make sure that the communication is actually= working. Or can we really get away with an UDP style of send and pray?? I = fail to see how you would be able to realise a substantial gain over what w= ill be needed anyhow as bare bone infrastructure and for error checking/rep= orting. =C2=A0But i might be wrong.

    One way way to find out is to implement it, and I feel = that we are getting closer to be able to do just that.=C2=A0

    =
    -- Vaughn


    On = Sat, Apr 9, 2011 at 1:18 AM, Morgaine <morgaine.dinova@googlemail.com> wrote:
    Excellent work, Vaughn!

    You're r= ight, I am working on something related to this, specifically a design stud= y for the Tourism use case.=C2=A0 It happens to end with a protocol sequenc= e diagram presented as a table of text, so I was very pleased to see your h= ighly relevant diagram.=C2=A0 Yours captures part of my use case, and it= 9;s a lot prettier than my text format. :P

    I was particularly impressed by the way you start off with completely s= eparable services right from the start.=C2=A0 Since separable services can = be put together under a single administrative domain very easily, whereas s= eparating conjoined services is not easy at all, I think you've started= this off perfectly for the VWRAP approach to services.

    Because you have separated the services so well, your suggested protoco= l flow could be said to to be targeting some kind of "superset of a= ll VWRAP deployments" deployment. :-)=C2=A0 Although it's logi= cally structured, it's a sort of worst-case scenario (or lawyer's d= elight) in which everyone has to ask everyone else for permission to do any= thing, regardless of whether permission is actually required or not.

    That's viable, but less than optimal.=C2=A0 Specifically, you are w= orking to the principle of "The heaviest burden required by anyone mus= t be borne by everyone."=C2=A0 I have been trying to stick to the oppo= site principle of "A burden should be borne only by those whose use ca= se requires it", which is both fairer and more efficient.

    To illustrate this, consider the case of an asset service which serves = (by choice) only Creative Commons licensed assets --- an extremely importan= t use case which could well become the dominant one in an open metaverse of= community worlds.=C2=A0 Who knows, it could be operated by Debian, or Blen= der, or OSgrid, or even Google Warehouse. :P

    In such a scenario, because the license on all the assets in the asset = service permits unchecked distribution to all destinations in perpetuity, t= he vast majority of all the request-grant protocol flows in your diagram ar= e superfluous when the assets come from this repository.=C2=A0 By using a p= rotocol which understands WHEN it needs to ask a question, a large a= mount of cumulative round-trip time latency (and its resulting lag) can be = avoided entirely.=C2=A0 This is also true on a per-asset basis if an asset = service serves a mixture of encumbered and freely distributable assets, exc= ept that then the difference would be seen per-asset instead of per asset s= ervice.

    For such freely distributable assets, the agent service doesn't nee= d to do anything at all beyond recording the addresses of assets which are = currently being worn by the agent.=C2=A0 Since you start off your trip (sen= sibly) by checking your clothing at home before you leave, you'll notic= e a broken asset service locally anyway since your viewer will be trying to= fetch it for local viewing.=C2=A0 The agent service need do nothing at all= , beyond record the addresses of top level items.=C2=A0 (In my design study= , I refer to a Worn Assets List which is held by the user's agen= t service, and which is entirely separate from any concept of inventory.)
    Likewise, region services don't need to fetch the graphic assets no= rmally either (unless they opt to proxy them), but only pass the addresses = of those assets around to all the other agents in the corresponding region,= so the request-grant exchanges between regions and asset services can be a= voided in this case.=C2=A0 (Regions will be requesting other server-side da= ta though, for example the bounding box information or collision mesh of an= asset, which typically the viewer would not be fetching.)

    That's not the end of the "no unnecessary burden" = issue yet though, because even if you removed all the unnecessary request-g= rant protocol flows, you're still making the incorrect assumption that = assets ALL NEED TO BE RESTRICTED by the mere fact of asking for caps= to everything.=C2=A0 This itself is wrong.=C2=A0 The logic need to first d= etermine whether a cap is needed for fetching a given asset, and if it'= s not needed then the fetch can be done by the viewer or region without thi= s protocol burden at all.

    So you see, there is a fundamental assumption in your nicely laid out f= lows that all assets must be tied up in heavy red tape by the needs of the = most burdensome use case.=C2=A0 I don't agree with that, neither on pri= nciple nor on engineering grounds.

    Many of the flows you have shown are exactly what we need for securing = access to proprietary resources, but not all resources have that burden, an= d I would want to elide a number of the flows away entirely when an asset s= ervice allows it.

    To put it another way, the data is king, and protocol flows should refl= ect the requirements imposed by data, not the other way around.

    I ne= ed this expressed in your flows, possibly as asset requirement annotations.=


    PS.=C2=A0 Great work Vaughn, I think this gives us a wonderful laun= ching point!


    Morgaine.



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

    On Fri, Apr 8, 2011 at 5:40 PM, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
    <= /div>
    VWRAP services high level message flow (prelimi= nary diagram draft) see


    The main reason that i am submitting this in spit= e of my lack of formal expertise is that the group in my view badly needs a= solid basis for discussion and preventing endless repeating loops. This ex= ample is probably wrong in many ways, but its better than what we have publ= icly available on interop now (although Morgaine is working on something al= ong the lines of the recent discussions here)=C2=A0

    I hope this diagram will give us a base for discussion.= I could have done my homework better by researching the old OGP stuff in m= ore depth, and i probably =C2=A0will do so in the future , but for now I ju= st tried to followed the general principles as far as i understand them, to= see what response that yields from the group. In other words,I try to let = the group educate me :p

    Note that in =C2=A0my view all services are equal, in p= rinciple it does not matter in what "domain" they run, since trus= t and policy are fully localized. It is however very possible to have inter= nal shortcuts in the services to speed up processing.=C2=A0

    In the example I opted for an external Agent service, b= ut I could as well have incorporated that in the set of local services. As = indicated above all services could also be run by different organisations, = true to what VWRAP stands for. Its all up to the deployer, including a user= at home who might want to run a full world for family and friends. Those f= riends might try to use that agent service to venture out in the virtual un= iverse.=C2=A0
    I envision that the final identity =C2=A0provider is external, using O= penID and OAut =C2=A0or whatever other =C2=A0magic that I do not yet fully = understand exists out there.

    The =C2=A0example has= 3 main purposes:
    - =C2=A0Provide a reference for discussion=C2=A0
    - Illustrat= es the use case of tourism, and *true* interop.
    - Illustrate cons= istency problems along the lines discussed =C2=A0here higher up in this tre= ad, as well as the "slashdot" problem that Morgaine outlined so c= learly.

    The message flow assumes an avatar already present in s= ome region, (a small scale local home region in this case, but that is by n= o means essential, it could be a build in region in the viewer or a big com= mercial region). The user is preparing for a trip to immersive world, and a= fter some outfit adjustments moves over.=C2=A0

    Finally i apologize for for the simplistic notation use= d here. I simply add the most relevant parameters passed in square brackets= to a keyword specifying the nature of the message. Please improve on that = where needed.

    So here we go, the avatar is =C2=A0prepare for a visit = to "immersive world"
    0) =C2=A0Viewer, here is an update= of the state of the world your agent is in, please render.
    1) = =C2=A0Agent service, I will go in my Zodiac dress that i keep in the =C2=A0= "Amazing assets" service.
    2) =C2=A0Asset service A, please send a cap for Z, here are my credent= ials
    3) =C2=A0Your fine, here is the cap
    4) =C2=A0Local= region, can you please put this on my agent, i included the cap.
    5) =C2=A0Hello asset service A, i need Z, here is the cap
    6) =C2=A0Cap is good, data coming up, have fun.
    7) =C2=A0Age= nt service, your agent is now wearing Z
    8) =C2=A0Viewer, your ava= tar is now wearing Z
    =C2=A0=C2=A0 =C2=A0User: Hmm, amazing invent= ory has not been *that* amazing lately. 'll make a backup, just in case=
    9) =C2=A0Hello asset service A, please send me a cap for Z, here are m= y credentials
    10) Your fine, here is the cap
    11) Local = asset storage, please store Z for me, here is the cap to get it
    1= 2) Hello asset service A, i want Z, here is the cap
    13) Cap is good, data coming up, have fun.
    14) Viewer, Z is = now stored for you=C2=A0
    =C2=A0=C2=A0 =C2=A0User: I am Ready!, Le= ts try to get to immersive world!
    15) Hello immersive world, can = i get in? Here are my credentials, and a list of my stuff.
    16) Asset service A, please send me a cap for X, here are my credentia= ls (I want this cap for consistency)
    17) Your fine, here is the c= ap
    18) Asset service B, please send me a cap for Y, here are my c= redentials (I want this cap for consistency)
    19) Very sorry, but your not one of us, you can't have Y
    20) Asset service B, please send me a cap for Z, here are my credentials (= I want a cap for consistency)
    [Region service: Timeout... amazing= inventory must be overloaded.. oh well... ]
    21) Agent service, you wanted to send somebody over, here are your per= missions.
    22) Viewer, you asked for a transfer try, here are your= results
    =C2=A0=C2=A0 =C2=A0 User thinks: =C2=A0Crap! Big asset s= ervice does not allow =C2=A0me to take my yellow stockings! And Amazing ass= ets =C2=A0failed to deliver my zodiac dress. At least i made a backup of th= at dress!
    23) 'll take the yellow stockings off...
    24) ... done (&= #39;ll trash them here and now, forever, who needs stuff you can't use!= )
    25) The zodiac dress was not delivered by Big assets service, b= ut i have a local copy!
    26) Local Asset service, please send me Z, here are my credentials
    27) I dont know you, but I 'll trust you, here is the cap, but y= ou better store the data, its single use, i need to protect myself.
    28) Local region, can you please put this on my agent, i include the c= ap.
    29) Local Asset service, i need Z, here is the cap
    = 30) Cap is good, data coming up, have fun.
    31) Cap was only good = for one time, I made a copy, but my policy is to only grant you fair use ri= ghts, at a later time i might even tell you to replace the dress.
    32) Viewer, you can wear Z for now, but the asset service granted only= fair use, i might ask you to replace the dress at a later time.
    = 33) Ready at last! Off to immersive world!, I hope its not to crowded there= or 'll loose my dress...
    34) Hello immersive world, here are my credentials, and a list of stuf= f i want to bring
    35) Hello asset service A, please send me a cap= for X, here are my credentials=C2=A0
    =C2=A0=C2=A0 =C2=A0[darn, I= should have kept that cap from last time..]
    36) Your fine, here is the cap.
    =C2=A0=C2=A0 [Region service= finds fair-use warning on Z and decides to make its own copy]
    37= ) Hello Local region, can i still have Z? Here is the cap=C2=A0
    3= 8) Cap is still good, data coming up, have fun.
    =C2=A0=C2=A0 [Region service stores asset in private storage, providin= g a cap to replace the fair use one]
    39) Agent service, you wante= d to send somebody over, here are your permissions & info.
    40= ) Hello immersive world, just =C2=A0get me there, and use what you can
    41) Placement done, Z is currently buffered by us as wel, you need to = get details for X, have fun.
    42) You are now in immersive world, = your dress is buffered there as well, but you need to get X!
    43) Hello asset service A, i want X, here is the cap
    44) Cap is g= ood, data coming up, have fun.
    45) Viewer, here is an update of t= he state of the world your agent is in, please render.

    As far as I can see this conforms fully to our charter, and i hope it = is possible to use large portions of the existing code bases. However, as s= aid above, i did not really try to capture the old thinking, and I also mig= ht have misconceptions about the way to do these things in general.
    Looking forward to constructive comments.

    -- Vaughn

    On Sun, Apr 3, 2011 at 8:38 PM, Vaughn Deluc= a <vaughn.deluca@gmail.com> wrote:
    Thanks for the pointers= . =C2=A0I have a =C2=A0busy week in RL in front of me, so i wont have to mu= ch time to respond the next few days, however, i intend to start doing the = following things:

    - Produce a visual that reflects my thinking, i.e. an illust= ration of my response to Morgaine's itemlist =C2=A0above.
    - Read up on the older notes, as well as =C2=A0more reading= in the list archive
    - Try to make a summary for the wiki

    Regarding the use of domain, I think services are e= ventually what counts, but its all terminology. The way I read the AWG diag= rams is that the agent domain is actually a cluster of tightly integrated s= ervices. When the functionality of each sub-service is described properly a= nd with uniform interfaces the domain will slowly dissolve. But let not get= ahead of out selfs. We should put up some clear descriptions on the wiki f= or our views on this, and *after* that we can decide what we need and what = can go.

    Its been a very useful and illuminating weekend for me,= and i am a lot more optimistic about the future of vwrap than two weeks ag= o.

    -- Vaughn
    <= div>



    On Sun, Apr 3, 2011 at 7:20 = PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
    Probably easy as suggested in other terms here on this list, as how the cli= ent contacts the asset services now in the regions. The newer issue is to u= nitize that asset services. Since their is proprietary (legacy) code then w= e can't expect that to change, and some form of proxy is of need. Whate= ver works best, I tried to narrow it down to suggestions here.

    Eventually, the agent domain is ideal to handle the direction of the asset = services. This concept, unfortunately, ended support awhile ago with change= s in LL.
    Also see; http://wiki.secondlife.com/wiki/Agent_Domain
    And: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_A= sset (warn: unstructured collaborative notes, dumped on me and I tried = to fix)

    I tried to find previous visuals.

    I'd imagine the agent domain could grow out of unitized versions of ass= et services. Despite that, I think that concept helps view where we were at= in discussion and what didn't happen.

    Vaughn Deluca wrote:
    Hi=EF=BF=BDDzonatas

    Can you expand on that, what would be needed for legacy support in VWAP ter= ms=EF=BF=BD?,
    If i want to read up on how the=EF=BF=BDasset server may proxy the simulato= r, what would you recommend me to read?

    -- Vaughn

    On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol <dzonatas@gmail.com <mailto:dzonatas@gmail.com>>= wrote:

    =C2=A0 =C2=A0Some stated the proxy-to-asset-server is built into the sim;<= br> =C2=A0 =C2=A0however, keep in mind possible legacy support where the asset=
    =C2=A0 =C2=A0server may proxy the simulator.


    =C2=A0 =C2=A0Dzonatas Sol wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0Somehow I feel the basic asset server being abl= e to login and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0download assets is now priority, yet I also won= dered the best
    =C2=A0 =C2=A0 =C2=A0 =C2=A0way to patch this into the current mode of view= ers.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0Maybe offer (1) by proxy (sim-side) and (2) by = patch
    =C2=A0 =C2=A0 =C2=A0 =C2=A0(viewer-side) that either of these two are opti= onal and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0neither are mandatory for now. Thoughts?

    =C2=A0 =C2=A0 =C2=A0 =C2=A0Israel Alanis wrote:


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> when designing for scalabili= ty, the model to bear in
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mind is ...

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Well, there are a lot of differen= t models to keep in mind,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and many different use cases. One= particular use case to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0keep in mind is: "User acqui= res new outfit, and wants to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'show it off' in a highly= populated region".

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Both worlds and asset servic= es may include commercial,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0community, and personal services<= br>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, yes and yes. I'm particu= larly concerned about how the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0model affects the ability to host= personal asset services.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> a proxying region, which wou= ld get slammed for every
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0asset worn by every avatar presen= t.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Granted the collection of service= s that are provided by
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the region need to be scaled to m= eet the demands of that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0region. That's all part of ca= pacity planning.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> regions run many different C= PU-intensive tasks,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0including physics simulation and = server-side scripting,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and absolutely cannot afford to s= erve assets too
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Well... who said the same CPU'= ;s have to do proxying,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0physics simulation and server-sid= e scripting? Asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proxying is a different service t= han physics simulation
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and can be on separate hardware, = could make use of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0geographically distributed cachin= g, and in certain
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0deployment patterns, the same cac= hing services could be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0shared by different regions. (Ser= ver-side scripting is a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discussion for another day).

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> This is why we have to go pa= rallel...

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Totally agree, and a proxying mod= el could and should also
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0take advantage of parallelism.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I think you're wrong tha= t it has to cost much money. ?vs?
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> It costs money to host a hig= h performance and scalable
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0asset service and a high bandwidt= h network to handle the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0traffic. =EF=BF=BDA *lot* of mone= y.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I think what you're saying is= : "It costs a lot of money to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0build a scalable asset service, b= ut if assets are spread
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0throughout the internet they don&= #39;t have to be scalable."
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0But that's not quite right. Y= ou're opening up every asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server to the VW equivalent of be= ing slashdotted, so are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0you sure you're not forcing *= every* asset service to be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scalable and handle a lot of band= with and network traffic?
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It's the exact opposite of yo= ur intention, but I think
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that's the result, all the sa= me.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This particular design decision h= as a big effect on the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0economics of the VW infrastructur= e. I'd rather the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0economics to work out such that a= region provider who
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wishes to build a region that sup= ports a small population,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0can do so economically. A region = that wants to host a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*large* population has to bear th= at cost of providing that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scalable asset service.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I want the economics of hosting a= small asset service to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be a non-issue (as to best promot= e creation and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0creativity). Creating a high bar = to provide asset services
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0will mean that service will cost = money and people
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0shouldn't have to pay money j= ust to create or own VW
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0objects (I'm using 'own&#= 39; here to refer to maintaining
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0their existence, I'm not tryi= ng to make a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'leftist'/'communist&= #39; statement about ownership ;)

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Izzy


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Apr 2, 2011, at 3:58 PM, Morga= ine wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Izzy, when designin= g for scalability, the model to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bear in mind is tha= t of seasoned virtual world
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0travelers whose inv= entories contain assets from many
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0different worlds, t= hose assets being served by many
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0different asset ser= vices. =EF=BF=BDBoth worlds and asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0services may includ= e commercial, community, and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0personal services, = and as the metaverse grows, that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0set is highly likel= y to become progressively less
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clustered and more = diverse.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0When those seasoned= travelers click on an advertised
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0VW link and perform= an inter-world teleport to one
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0particular world= 9;s region to share an experience,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0their "worn&qu= ot; assets (the only ones of interest to the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0region) will contai= n references to asset services
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spread widely acros= s the Internet. =EF=BF=BDThe fetches by the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0travelers' clie= nts occur over many parallel paths from
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clients to asset se= rvices, so one can reasonably
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0expect reduced netw= ork contention and reduced asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server loading beca= use they are both spread out over
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0however many asset = services are being referenced by
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the overall set of = assets in the region.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This is very differ= ent to the case of a proxying
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0region, which would= get slammed for every asset worn
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by every avatar pre= sent. =EF=BF=BDIn our current architecture,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0regions run many di= fferent CPU-intensive tasks,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0including physics s= imulation and server-side
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scripting, and abso= lutely cannot afford to serve
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0assets too unless y= our scalability requirements are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0very low indeed, ie= . just a few dozen avatars of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0today's kind. = =EF=BF=BDWe've hit the ceiling already on region
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scalability done th= at way. =EF=BF=BDThere is nowhere to go in
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that direction at a= ll beyond improving the code like
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Intel demonstrated,= and that work is subject to a law
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of diminishing retu= rns.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This is why we have= to go parallel, and I think you're
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrong that it has t= o cost much money. =EF=BF=BDAs we spread
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the load across mor= e and more asset services, we are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0simply better utili= zing all the hardware that's
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0already out there o= n the Internet, at least in respect
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of community and pr= ivate resources. =EF=BF=BDBut add to the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0community and priva= te resources the commercial asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0services that are l= ikely to appear to exploit this
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opportunity, and no= t only will the number of asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0services leap, but = the power of each one will rocket
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0too, because, after= all, these businesses will be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0heavily optimized f= or the job.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As to why a world w= ould want clients to access
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0external asset serv= ices instead of providing its own
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implementation, tha= t's an easy question. =EF=BF=BDIt costs
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0money to host a hig= h performance and scalable asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0service and a high = bandwidth network to handle the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0traffic. =EF=BF=BDA= *lot* of money. =EF=BF=BDIn contrast, it costs a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0world nothing to le= t others serve the assets to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clients. =EF=BF=BDA= nd that matters to the bottom line.


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Morgaine.




    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, Apr 2, 2011= at 7:05 PM, Izzy Alanis
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<izzyalanis@gmail.com <mai= lto:izzyalanis@gm= ail.com>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:izzyalanis@gmail.com=

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:izzyalanis@gmail.com= >>> wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > As always though, it's a trade-off, since the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proxied design
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= has very poor scalability compared to the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0distributed one.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= I don't agree with that... If a user enters a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0highly populated =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= region,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= every other client is going to (could and should be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0trying to)
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= hit the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= asset server(s) for the assets that the user is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wearing (assuming =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= they're not cached locally). =EF=BF=BDEvery asset server
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has to be scaled up=
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= to the point that it can handle that load from all
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0over...

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= If I'm hosting a region that supports 10s of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0thousands of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= simultaneous
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= users (thinking of the future), I already have to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scale to meet that<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= demand. If the region is proxying the assets, then,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yes the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= region has
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= to be scaled to meet that asset demand too, but it
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0already has to be =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= scaled to meet other demands of being a region
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server... and why i= s
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= scaling those asset proxy services hard? =EF=BF=BDIt's
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0going to cost $, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= but is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= not technically challenging. So, if I want to host
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a region like
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= that... sure it will cost me, but the simulation
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0will be consistent<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= and users will be able to participate equally,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0regardless of the =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= capabilities of their individual asset services.




    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= On Fri, Apr 1, 2011 at 11:55 PM, Morgaine
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= <mor= gaine.dinova@googlemail.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:morgaine.dinov= a@googlemail.com>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= <mailto:morgaine.dinova@googlemail.com

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:morgaine.dinov= a@googlemail.com>>> wrote:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > Every design choice results in a trade-off,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vaughn, improving =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= one thing at
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > the expense of something else. =EF=BF=BDIf every time we
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0offered a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= service we had to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > inform its users about the downsides of all the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0trade-offs we
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= have made,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > they would have an awful lot to read. ;-)
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > The specific trade-off that you are discussing is no
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= different. =EF=BF=BDA region
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > that proxies all content has the "benefit" of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0acquiring control =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= from the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > asset servers over the items in the region, so
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that it can
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= ensure that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > everyone in the region not only obtains the items
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0but obtains
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= the same items
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > as everyone else. =EF=BF=BDThat does indeed provide a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0greater guarantee o= f
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > consistency than a deployment in which the region
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0only passes
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= asset URIs to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > clients who then fetch the items from asset services
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= separately. =EF=BF=BDAs always
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > though, it's a trade-off, since the proxied
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0design has very
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= poor scalability
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > compared to the distributed one.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > If we're going to warn users of the potential for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inconsistency
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= in the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > distributed deployment as you suggest, are we
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0also going to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= warn them of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > non-scalability in the proxied one? =EF=BF=BDI really
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0don't see much<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= merit in the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > idea of warning about design choices. =EF=BF=BDMany such
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0choices are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= technical, and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > the issues are quite likely to be of little
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interest to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= non-technical users
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > anyway. =EF=BF=BDIn any case, the better services are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0likely to provide =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= such
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > information in their online documentation, I
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0would guess.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > You mentioned users "voting with their feet" or
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0choosing to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= accept the risk
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > of inconsistency. =EF=BF=BDWell that will happen anyway,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0when services
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= fail and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > users get annoyed. =EF=BF=BDIf some asset services refuse
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to send the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= requested
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > items to some users, those services will get a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bad reputation
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= and people
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > will choose different asset services instead.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BDLikewise, = if a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= world service
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > proxies everything and so it can't handle a large
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0number of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= assets or of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > people, users will get annoyed at the lag and will go
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= elsewhere. =EF=BF=BDThis user
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > evaluation and "voting with their feet" happens
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0already with
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= online services
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > all over the Internet, and I am sure that this
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0human process
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= will continue
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > to work when the services are asset and region
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0services.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > Back in September 2010, I wrote this post which
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proposes that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= we use in
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > VWRAP a form of asset addressing that provides
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0massive
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= scalability at the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > same time as a very high degree of resilience --
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BDhttp://www.ietf.org/mail-archive/web/vwrap/current/msg00463.htm= l
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= . =EF=BF=BDIt is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > based on the concept of the URI containing a host
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0part and a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= hash part,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > where the hash is generated (once, at the time of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0storage to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= the asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > service) using a specified digest algorithm over
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the content of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= the asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > being referenced. =EF=BF=BDYou may wish to note that if
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this design
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= were used, the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > failure of an asset service to deliver a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0requested item woul= d
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= result in a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > failover request for the item to one or more
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0backup services, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= using the same
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > hash part but with a different host address.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > This can go some way towards overcoming the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0problem that you =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= think might
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > occur when assets are fetched by clients from
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0asset services
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= directly.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > Although it won't help when the missing item is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0available from
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= only a single
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > asset service, it will help in many other cases,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and it will
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= compensate for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > service failures and network outages
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0automatically at th= e same
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= time.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > PS. This design for hash-based asset addressing
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is already
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= being tested by
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > Mojito Sorbet in her experimental world and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0client. =EF=BF=BDIt= would give
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > VWRAP-based worlds an improved level of service
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0availability,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= so I think it
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > should be a core feature of our protocol.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > Morgaine.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > =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
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= <vaughn.del= uca@gmail.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vaughn.deluca@gmail.c= om>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vaughn.deluca@gmail.c= om
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vaughn.deluca@gmail.c= om>>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > wrote:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> This is a question i discussed with Morgaine
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0off-list a while =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= ago (I
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> intended to send it to the list but pushed the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrong button...) I<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> think we need to address this problem, and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0decide how to deal<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= with it.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BDIn Davids deployment draft, section 7.3.1.1 an
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0overview is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= given van
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> ways to deliver content to the region. One way
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is only passing a =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> capability that allows access to (part of) the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0resource:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD 7.3.1.1. =EF=BF= =BDContent delivery models
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD A range of possi= ble represenations can
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be passed to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= a region for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD simulation. [...= ] The other end of the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0delivery spectrum =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> involves passing
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD only a URI or ca= pability used to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0access the renderin= g
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> information and a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD collision mesh,a= nd related data for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0physical simulation= .
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD In such a model,= the client is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0responsible for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= fetching the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> additional
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD information need= ed to render the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0item's visual =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= presence from a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> separate
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD service. =EF=BF= =BDThis fetch can be done
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*under the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= credentials of the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> end user*
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD viewing the mate= rial [my emphasis--VD]
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0, and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= divorces the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> simulation from
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD the trust chain = needed to manage
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0content. =EF=BF=BDA= ny
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= automation
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> is done on a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD separate host wh= ich the content
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0creator or owner tr= usts,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> interacting with the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD object through r= emoted interfaces.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BDI can see the need for such a setup, however, i
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0feel we are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> unpleasantly close to a situation were the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0coherence of the =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= simulation
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> falls apart.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> In this deployment pattern the region advertises
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the presence
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= of the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> asset, and *some* clients will be able to get it
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as expected,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= while
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> -based on the arbitrary whims of the asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0service- others
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= might not.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> My hope would be that after the asset server
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0provides the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= region with
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> the capability to get the asset, it gives up
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0control. That
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= would mean
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> that if the client finds the inventory server is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unwilling to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= serve
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> the content - in spire of the region saying it
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is present-,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= the client
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> should be able to turn around ask the *region*
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for the asset,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= (and get
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> is after all).
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BDIf that is not the case, -and there are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0probably good reaso= ns
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= for the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> deployment pattern as described- =EF=BF=BDshouldn't we
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*warn* clients
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= that the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> region might be inconsistent, so the users
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0behind the client =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= can vote
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> with their feet, (or take the risk)?
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> --Vaughn
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> _______________________________________________
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> vwrap mailing list
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> vwrap@ietf.org= <mailto:vwrap@i= etf.org>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:= vwrap@ietf.org>&= gt;

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> https://www.ietf.org/mailman/listinfo/vwrap
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > _______________________________________________
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > vwrap mailing list
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > vwrap@ietf.org= <mailto:vwrap@ietf.= org>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:= vwrap@ietf.org>&= gt;

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > https://www.ietf.org/mailman/listinfo/vwrap
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >



    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------------------------------= ---------------------------------------

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_________________________________= ______________
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vwrap mailing list
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vwrap@ietf.org <mailto:vwrap@ietf.org>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listi= nfo/vwrap
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD





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

    =C2=A0 =C2=A0_______________________________________________
    =C2=A0 =C2=A0vwrap mailing list


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



    --000e0cdfd9f84fd13904a0831019-- From dzonatas@gmail.com Sat Apr 9 18:24:51 2011 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 E72073A6988 for ; Sat, 9 Apr 2011 18:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.78 X-Spam-Level: X-Spam-Status: No, score=-2.78 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] 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 J7ePU6L3i2yI for ; Sat, 9 Apr 2011 18:24:48 -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 9155A3A6905 for ; Sat, 9 Apr 2011 18:24:48 -0700 (PDT) Received: by pwi5 with SMTP id 5so2078959pwi.31 for ; Sat, 09 Apr 2011 18:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XxVN3VhX8m8k87iivjIKLQZvL7Sgbvq3S8CW9AWxdf0=; b=cznbOMaDI0wtKGnMHnpam5KAucDf9ULwbmW/X8k37cjuFKz6mMuTgD2nnEkcQpaoSy 5zxD3IdPEgsvzU4hGUMyJJdrTuy5eqE3NyI2eb6x+277fLorY7TUy7ZsEwyyb4eeNSPu raCIlnSdAn7mMiKsRzPoCXtl22WN48Rbyk208= 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=kCTyWMoQqLEkOGHBb4VJ/jw8UNVsisnK3fl9i384P9IGphPCsiQTjshElyL5qKOOa3 TMyhLVIufFcEHEFKoob7DOr73SO3Ol2jZ/yTyfPnCBe5w1PxcWtjdA3SFd9I15+EGrpW RPoG6HHyLmhwZrMe9/z/6WESxkeJMHNNJe/XI= Received: by 10.142.222.1 with SMTP id u1mr3495709wfg.181.1302398794705; Sat, 09 Apr 2011 18:26:34 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id z10sm5953556wfj.0.2011.04.09.18.26.31 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Apr 2011 18:26:33 -0700 (PDT) Message-ID: <4DA10780.7020100@gmail.com> Date: Sat, 09 Apr 2011 18:27:28 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: "vwrap@ietf.org" References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> <4D9F5B5F.2060401@gmail.com> <4DA07A5D.9050402@gmail.com> <4DA08D99.6020402@gmail.com> In-Reply-To: <4DA08D99.6020402@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 10 Apr 2011 01:24:52 -0000 Forwarded to vwrap-list: Dzonatas Sol wrote: > Just thought about this a little more... > > I think with your first VD1 that only thing that really needs to be > added is to add space between the local and external area to fit in > the resource name per arrow. That way the public resource name is > specified. Then instead of those request for cap transitions, these > would be implied by those resource names. Above each line of each > arrow, just add the appropriate public resource name there. We can > deal with private resources later, as those are already implied, too. > > This group never did create any dictionary of resource names. They > only exist in viewer source and in SNOW-375. > > I don't know if I can modify the PDF to make an example of above. > > Dzonatas Sol wrote: >> Perhaps, that would be best to reflect upon the past. >> >> There have been talks to split out the renderer from the viewer, yet >> the render depends on some of the network. To call that the local >> region is appropriate as you have. The renderer/network-loop does the >> bulk of the work now that others think the simulator does. That's >> where we get hung up on local sim or external sim, and components. >> >> Maybe easier not to worry about requests for caps for now and keep >> the way your going. We can come back later and describe how the >> connections/ReSTful patterns work later. Please just indicate it's >> the above ReSTful view of the flow (higher-level) and us >> implementators will comprehend. >> >> =) >> >> Vaughn Deluca wrote: >>> Dzonatas Sol >>> >Then again, split the viewer out for local agent services and maybe >>> it will appear trivial. >>> >>> Right, Maybe we should consider *only* the viewer as local, and >>> assume all other services are external, just to make the example clear. >>> Thanks for the other feedback, I will look at the snow-375 example. >>> --Vaughn >>> >>> On Fri, Apr 8, 2011 at 9:00 PM, Dzonatas Sol >> > wrote: >>> >>> I've read it, and off hand I would say the "flow" needs further >>> definition. Not that you did anything wrong, it just something >>> that happens more at the transfer layer from ReST and lower. All >>> the arrows you have that go from the Local to External let's >>> consider those "forward flow" and those that from from external to >>> local as "reverse flow." This becomes more obvious for reasons why >>> when firewalls and proxies are in the way and connections may need >>> to exist in opposite of the flow. Between unidirectional and >>> bidirectional flows is were this discussion digresses to vanilla >>> HTTP/caps and not fully ReSTful as desired. >>> >>> See also this doc on "forward/reverse" how Icesphere handles the >>> implementation of bidirectional resources: >>> >>> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Interface >>> >>> >>> I think you already see the higher-level request to begin >>> capability, end capability, and determine if it needs to request >>> capabilities. With bidirectional resources, there are less >>> requests for capabilities and mainly need for digests of >>> capabilities that begin and end. With unidirectional resources, >>> there are needs to request capabilities, that (currently on >>> servers) begin as private capabilities. Also with unidirectional >>> resources, there are keep-alives and long-poll requirements on the >>> resources, which isn't mandatory on bidirectional resources. >>> Bidirectional resources can use more ReSTful credentials, so there >>> would be no need to request capabilities (only need to know they >>> are capable by the digests). >>> >>> I imagine two big polygons around the Local and External areas on >>> the diagrams, yet to further image the arrows on actual flow might >>> not be so trivial as the desired flow noted. Then again, split the >>> viewer out for local agent services and maybe it will appear >>> trivial. >>> >>> Vaughn Deluca wrote: >>> >>> VWRAP services high level message flow (preliminary diagram >>> draft) see >>> >>> >>> http://trac.tools.ietf.org/wg/vwrap/trac/attachment/wiki/Diagrams/VWRAP_FlowExample_VD1.pdf >>> >>> >>> The main reason that i am submitting this in spite of my lack >>> of formal expertise is that the group in my view badly needs a >>> solid basis for discussion and preventing endless repeating >>> loops. This example is probably wrong in many ways, but its >>> better than what we have publicly available on interop now >>> (although Morgaine is working on something along the lines of >>> the recent discussions here) >>> I hope this diagram will give us a base for discussion. I >>> could have done my homework better by researching the old OGP >>> stuff in more depth, and i probably will do so in the future >>> , but for now I just tried to followed the general principles >>> as far as i understand them, to see what response that yields >>> from the group. In other words,I try to let the group educate >>> me :p >>> >>> Note that in my view all services are equal, in principle it >>> does not matter in what "domain" they run, since trust and >>> policy are fully localized. It is however very possible to >>> have internal shortcuts in the services to speed up processing. >>> In the example I opted for an external Agent service, but I >>> could as well have incorporated that in the set of local >>> services. As indicated above all services could also be run by >>> different organisations, true to what VWRAP stands for. Its >>> all up to the deployer, including a user at home who might >>> want to run a full world for family and friends. Those friends >>> might try to use that agent service to venture out in the >>> virtual universe. I envision that the final identity provider >>> is external, using OpenID and OAut or whatever other magic >>> that I do not yet fully understand exists out there. >>> >>> The example has 3 main purposes: >>> - Provide a reference for discussion - Illustrates the use >>> case of tourism, and *true* interop. >>> - Illustrate consistency problems along the lines discussed >>> here higher up in this tread, as well as the "slashdot" >>> problem that Morgaine outlined so clearly. >>> >>> The message flow assumes an avatar already present in some >>> region, (a small scale local home region in this case, but >>> that is by no means essential, it could be a build in region >>> in the viewer or a big commercial region). The user is >>> preparing for a trip to immersive world, and after some outfit >>> adjustments moves over. >>> Finally i apologize for for the simplistic notation used here. >>> I simply add the most relevant parameters passed in square >>> brackets to a keyword specifying the nature of the message. >>> Please improve on that where needed. >>> >>> So here we go, the avatar is prepare for a visit to >>> "immersive world" >>> 0) Viewer, here is an update of the state of the world your >>> agent is in, please render. >>> 1) Agent service, I will go in my Zodiac dress that i keep in >>> the "Amazing assets" service. >>> 2) Asset service A, please send a cap for Z, here are my >>> credentials >>> 3) Your fine, here is the cap >>> 4) Local region, can you please put this on my agent, i >>> included the cap. >>> 5) Hello asset service A, i need Z, here is the cap >>> 6) Cap is good, data coming up, have fun. >>> 7) Agent service, your agent is now wearing Z >>> 8) Viewer, your avatar is now wearing Z >>> User: Hmm, amazing inventory has not been *that* amazing >>> lately. 'll make a backup, just in case >>> 9) Hello asset service A, please send me a cap for Z, here >>> are my credentials >>> 10) Your fine, here is the cap >>> 11) Local asset storage, please store Z for me, here is the >>> cap to get it >>> 12) Hello asset service A, i want Z, here is the cap >>> 13) Cap is good, data coming up, have fun. >>> 14) Viewer, Z is now stored for you User: I am Ready!, >>> Lets try to get to immersive world! >>> 15) Hello immersive world, can i get in? Here are my >>> credentials, and a list of my stuff. >>> 16) Asset service A, please send me a cap for X, here are my >>> credentials (I want this cap for consistency) >>> 17) Your fine, here is the cap >>> 18) Asset service B, please send me a cap for Y, here are my >>> credentials (I want this cap for consistency) >>> 19) Very sorry, but your not one of us, you can't have Y >>> 20) Asset service B, please send me a cap for Z, here are my >>> credentials (I want a cap for consistency) >>> [Region service: Timeout... amazing inventory must be >>> overloaded.. oh well... ] >>> 21) Agent service, you wanted to send somebody over, here are >>> your permissions. >>> 22) Viewer, you asked for a transfer try, here are your results >>> User thinks: Crap! Big asset service does not allow me >>> to take my yellow stockings! And Amazing assets failed to >>> deliver my zodiac dress. At least i made a backup of that >>> dress! >>> 23) 'll take the yellow stockings off... >>> 24) ... done ('ll trash them here and now, forever, who needs >>> stuff you can't use!) >>> 25) The zodiac dress was not delivered by Big assets service, >>> but i have a local copy! >>> 26) Local Asset service, please send me Z, here are my >>> credentials >>> 27) I dont know you, but I 'll trust you, here is the cap, but >>> you better store the data, its single use, i need to protect >>> myself. >>> 28) Local region, can you please put this on my agent, i >>> include the cap. >>> 29) Local Asset service, i need Z, here is the cap >>> 30) Cap is good, data coming up, have fun. >>> 31) Cap was only good for one time, I made a copy, but my >>> policy is to only grant you fair use rights, at a later time i >>> might even tell you to replace the dress. >>> 32) Viewer, you can wear Z for now, but the asset service >>> granted only fair use, i might ask you to replace the dress at >>> a later time. >>> 33) Ready at last! Off to immersive world!, I hope its not to >>> crowded there or 'll loose my dress... >>> 34) Hello immersive world, here are my credentials, and a list >>> of stuff i want to bring >>> 35) Hello asset service A, please send me a cap for X, here >>> are my credentials [darn, I should have kept that cap from >>> last time..] >>> 36) Your fine, here is the cap. >>> [Region service finds fair-use warning on Z and decides to >>> make its own copy] >>> 37) Hello Local region, can i still have Z? Here is the cap >>> 38) Cap is still good, data coming up, have fun. >>> [Region service stores asset in private storage, providing a >>> cap to replace the fair use one] >>> 39) Agent service, you wanted to send somebody over, here are >>> your permissions & info. >>> 40) Hello immersive world, just get me there, and use what >>> you can >>> 41) Placement done, Z is currently buffered by us as wel, you >>> need to get details for X, have fun. >>> 42) You are now in immersive world, your dress is buffered >>> there as well, but you need to get X! >>> 43) Hello asset service A, i want X, here is the cap >>> 44) Cap is good, data coming up, have fun. >>> 45) Viewer, here is an update of the state of the world your >>> agent is in, please render. >>> >>> As far as I can see this conforms fully to our charter, and i >>> hope it is possible to use large portions of the existing code >>> bases. However, as said above, i did not really try to capture >>> the old thinking, and I also might have misconceptions about >>> the way to do these things in general. >>> Looking forward to constructive comments. >>> >>> -- Vaughn >>> >>> On Sun, Apr 3, 2011 at 8:38 PM, Vaughn Deluca >>> >>> >> >> wrote: >>> >>> Thanks for the pointers. I have a busy week in RL in >>> front of >>> me, so i wont have to much time to respond the next few >>> days, >>> however, i intend to start doing the following things: >>> >>> - Produce a visual that reflects my thinking, i.e. an >>> illustration >>> of my response to Morgaine's itemlist above. >>> - Read up on the older notes, as well as more reading in >>> the list >>> archive >>> - Try to make a summary for the wiki >>> >>> Regarding the use of domain, I think services are >>> eventually what >>> counts, but its all terminology. The way I read the AWG >>> diagrams >>> is that the agent domain is actually a cluster of tightly >>> integrated services. When the functionality of each >>> sub-service is >>> described properly and with uniform interfaces the domain >>> will >>> slowly dissolve. But let not get ahead of out selfs. We >>> should put >>> up some clear descriptions on the wiki for our views on >>> this, and >>> *after* that we can decide what we need and what can go. >>> >>> Its been a very useful and illuminating weekend for me, and >>> i am a >>> lot more optimistic about the future of vwrap than two >>> weeks ago. >>> >>> -- Vaughn >>> >>> >>> >>> On Sun, Apr 3, 2011 at 7:20 PM, Dzonatas Sol >>> >>> >> >>> wrote: >>> >>> Probably easy as suggested in other terms here on this >>> list, >>> as how the client contacts the asset services now in the >>> regions. The newer issue is to unitize that asset >>> services. >>> Since their is proprietary (legacy) code then we can't >>> expect >>> that to change, and some form of proxy is of need. >>> Whatever >>> works best, I tried to narrow it down to suggestions >>> here. >>> >>> Eventually, the agent domain is ideal to handle the >>> direction >>> of the asset services. This concept, unfortunately, >>> ended >>> support awhile ago with changes in LL. >>> Also see; http://wiki.secondlife.com/wiki/Agent_Domain >>> And: >>> >>> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset >>> (warn: unstructured collaborative notes, dumped on me >>> and I >>> tried to fix) >>> >>> I tried to find previous visuals. >>> >>> I'd imagine the agent domain could grow out of unitized >>> versions of asset services. Despite that, I think that >>> concept >>> helps view where we were at in discussion and what >>> didn't happen. >>> >>> Vaughn Deluca wrote: >>> >>> Hi�Dzonatas >>> >>> Can you expand on that, what would be needed for >>> legacy >>> support in VWAP terms�?, >>> If i want to read up on how the�asset server may >>> proxy the >>> simulator, what would you recommend me to read? >>> >>> -- Vaughn >>> >>> On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol >>> >>> > >>> >> >> >>> >>> >>> wrote: >>> >>> Some stated the proxy-to-asset-server is built >>> into the >>> sim; >>> however, keep in mind possible legacy support >>> where the >>> asset >>> server may proxy the simulator. >>> >>> >>> Dzonatas Sol wrote: >>> >>> Somehow I feel the basic asset server being >>> able to >>> login and >>> download assets is now priority, yet I also >>> wondered the best >>> way to patch this into the current mode of >>> viewers. >>> >>> Maybe offer (1) by proxy (sim-side) and (2) >>> by patch >>> (viewer-side) that either of these two are >>> optional and >>> neither are mandatory for now. Thoughts? >>> >>> Israel Alanis wrote: >>> >>> >>> > when designing for scalability, the >>> model to >>> bear in >>> mind is ... >>> >>> Well, there are a lot of different >>> models to >>> keep in mind, >>> and many different use cases. One >>> particular >>> use case to >>> keep in mind is: "User acquires new >>> outfit, and >>> wants to >>> 'show it off' in a highly populated >>> region". >>> >>> > Both worlds and asset services may >>> include >>> commercial, >>> community, and personal services >>> >>> Yes, yes and yes. I'm particularly >>> concerned >>> about how the >>> model affects the ability to host >>> personal >>> asset services. >>> >>> > a proxying region, which would get >>> slammed >>> for every >>> asset worn by every avatar present. >>> >>> Granted the collection of services >>> that are >>> provided by >>> the region need to be scaled to meet the >>> demands of that >>> region. That's all part of capacity >>> planning. >>> >>> > regions run many different >>> CPU-intensive tasks, >>> including physics simulation and >>> server-side >>> scripting, >>> and absolutely cannot afford to serve >>> assets too >>> Well... who said the same CPU's have >>> to do >>> proxying, >>> physics simulation and server-side >>> scripting? Asset >>> proxying is a different service than >>> physics >>> simulation >>> and can be on separate hardware, could >>> make use of >>> geographically distributed caching, and >>> in certain >>> deployment patterns, the same caching >>> services >>> could be >>> shared by different regions. (Server-side >>> scripting is a >>> discussion for another day). >>> >>> > This is why we have to go parallel... >>> >>> Totally agree, and a proxying model >>> could and >>> should also >>> take advantage of parallelism. >>> >>> > I think you're wrong that it has to >>> cost much >>> money. ?vs? >>> > It costs money to host a high >>> performance and >>> scalable >>> asset service and a high bandwidth >>> network to >>> handle the >>> traffic. �A *lot* of money. >>> I think what you're saying is: "It costs >>> a lot >>> of money to >>> build a scalable asset service, but if >>> assets >>> are spread >>> throughout the internet they don't have >>> to be >>> scalable." >>> But that's not quite right. You're >>> opening up >>> every asset >>> server to the VW equivalent of being >>> slashdotted, so are >>> you sure you're not forcing *every* asset >>> service to be >>> scalable and handle a lot of bandwith and >>> network traffic? >>> It's the exact opposite of your >>> intention, but >>> I think >>> that's the result, all the same. >>> >>> This particular design decision has a big >>> effect on the >>> economics of the VW infrastructure. I'd >>> rather the >>> economics to work out such that a region >>> provider who >>> wishes to build a region that supports a >>> small >>> population, >>> can do so economically. A region that >>> wants to >>> host a >>> *large* population has to bear that >>> cost of >>> providing that >>> scalable asset service. >>> I want the economics of hosting a small >>> asset >>> service to >>> be a non-issue (as to best promote >>> creation and >>> creativity). Creating a high bar to >>> provide >>> asset services >>> will mean that service will cost money >>> and people >>> shouldn't have to pay money just to >>> create or >>> own VW >>> objects (I'm using 'own' here to refer to >>> maintaining >>> their existence, I'm not trying to make a >>> 'leftist'/'communist' statement about >>> ownership ;) >>> >>> - Izzy >>> >>> >>> On Apr 2, 2011, at 3:58 PM, Morgaine >>> wrote: >>> >>> Izzy, when designing for >>> scalability, the >>> model to >>> bear in mind is that of seasoned >>> virtual world >>> travelers whose inventories contain >>> assets >>> from many >>> different worlds, those assets being >>> served >>> by many >>> different asset services. �Both >>> worlds and >>> asset >>> services may include commercial, >>> community, and >>> personal services, and as the >>> metaverse >>> grows, that >>> set is highly likely to become >>> progressively less >>> clustered and more diverse. >>> >>> When those seasoned travelers click >>> on an >>> advertised >>> VW link and perform an inter-world >>> teleport >>> to one >>> particular world's region to share an >>> experience, >>> their "worn" assets (the only ones of >>> interest to the >>> region) will contain references to >>> asset >>> services >>> spread widely across the Internet. >>> �The >>> fetches by the >>> travelers' clients occur over many >>> parallel >>> paths from >>> clients to asset services, so one can >>> reasonably >>> expect reduced network contention and >>> reduced asset >>> server loading because they are both >>> spread >>> out over >>> however many asset services are being >>> referenced by >>> the overall set of assets in the >>> region. >>> >>> This is very different to the case >>> of a >>> proxying >>> region, which would get slammed for >>> every >>> asset worn >>> by every avatar present. �In our >>> current >>> architecture, >>> regions run many different >>> CPU-intensive tasks, >>> including physics simulation and >>> server-side >>> scripting, and absolutely cannot >>> afford to >>> serve >>> assets too unless your scalability >>> requirements are >>> very low indeed, ie. just a few dozen >>> avatars of >>> today's kind. �We've hit the ceiling >>> already on region >>> scalability done that way. �There is >>> nowhere to go in >>> that direction at all beyond >>> improving the >>> code like >>> Intel demonstrated, and that work is >>> subject to a law >>> of diminishing returns. >>> >>> This is why we have to go parallel, >>> and I >>> think you're >>> wrong that it has to cost much >>> money. �As >>> we spread >>> the load across more and more asset >>> services, we are >>> simply better utilizing all the >>> hardware that's >>> already out there on the Internet, >>> at least >>> in respect >>> of community and private >>> resources. �But >>> add to the >>> community and private resources the >>> commercial asset >>> services that are likely to appear to >>> exploit this >>> opportunity, and not only will the >>> number >>> of asset >>> services leap, but the power of >>> each one >>> will rocket >>> too, because, after all, these >>> businesses >>> will be >>> heavily optimized for the job. >>> >>> As to why a world would want clients >>> to access >>> external asset services instead of >>> providing its own >>> implementation, that's an easy >>> question. >>> �It costs >>> money to host a high performance and >>> scalable asset >>> service and a high bandwidth >>> network to >>> handle the >>> traffic. �A *lot* of money. �In >>> contrast, >>> it costs a >>> world nothing to let others serve >>> the assets to >>> clients. �And that matters to the >>> bottom line. >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> ====================== >>> >>> On Sat, Apr 2, 2011 at 7:05 PM, Izzy >>> Alanis >>> >> >>> >> > >> >>> >> >> >>> >> >>> >> > >>> >>> >> >>> >> >>>> wrote: >>> >>> � �> As always though, it's a >>> trade-off, >>> since the >>> proxied design >>> � �has very poor scalability >>> compared to the >>> distributed one. >>> >>> � �I don't agree with that... If a >>> user >>> enters a >>> highly populated >>> � �region, >>> � �every other client is going to >>> (could >>> and should be >>> trying to) >>> � �hit the >>> � �asset server(s) for the assets >>> that the >>> user is >>> wearing (assuming >>> � �they're not cached locally). >>> �Every >>> asset server >>> has to be scaled up >>> � �to the point that it can handle >>> that >>> load from all >>> over... >>> >>> � �If I'm hosting a region that >>> supports 10s of >>> thousands of >>> � �simultaneous >>> � �users (thinking of the future), I >>> already have to >>> scale to meet that >>> � �demand. If the region is >>> proxying the >>> assets, then, >>> yes the >>> � �region has >>> � �to be scaled to meet that asset >>> demand >>> too, but it >>> already has to be >>> � �scaled to meet other demands of >>> being a >>> region >>> server... and why is >>> � �scaling those asset proxy >>> services hard? >>> �It's >>> going to cost $, >>> � �but is >>> � �not technically challenging. >>> So, if I >>> want to host >>> a region like >>> � �that... sure it will cost me, >>> but the >>> simulation >>> will be consistent >>> � �and users will be able to >>> participate >>> equally, >>> regardless of the >>> � �capabilities of their individual >>> asset >>> services. >>> >>> >>> >>> >>> � �On Fri, Apr 1, 2011 at 11:55 PM, >>> Morgaine >>> � �>> >>> >> > >>> >>> >> >>> >> >> >>> � >>> �>> >>> >>> >> > >>> >>> >>> >> >>> >> >>>> wrote: >>> � �> Every design choice results in a >>> trade-off, >>> Vaughn, improving >>> � �one thing at >>> � �> the expense of something >>> else. �If >>> every time we >>> offered a >>> � �service we had to >>> � �> inform its users about the >>> downsides >>> of all the >>> trade-offs we >>> � �have made, >>> � �> they would have an awful lot to >>> read. ;-) >>> � �> >>> � �> The specific trade-off that >>> you are >>> discussing is no >>> � �different. �A region >>> � �> that proxies all content has the >>> "benefit" of >>> acquiring control >>> � �from the >>> � �> asset servers over the items >>> in the >>> region, so >>> that it can >>> � �ensure that >>> � �> everyone in the region not only >>> obtains the items >>> but obtains >>> � �the same items >>> � �> as everyone else. �That does >>> indeed >>> provide a >>> greater guarantee of >>> � �> consistency than a deployment >>> in which >>> the region >>> only passes >>> � �asset URIs to >>> � �> clients who then fetch the >>> items from >>> asset services >>> � �separately. �As always >>> � �> though, it's a trade-off, >>> since the >>> proxied >>> design has very >>> � �poor scalability >>> � �> compared to the distributed one. >>> � �> >>> � �> If we're going to warn users >>> of the >>> potential for >>> inconsistency >>> � �in the >>> � �> distributed deployment as you >>> suggest, >>> are we >>> also going to >>> � �warn them of >>> � �> non-scalability in the proxied >>> one? �I >>> really >>> don't see much >>> � �merit in the >>> � �> idea of warning about design >>> choices. >>> �Many such >>> choices are >>> � �technical, and >>> � �> the issues are quite likely to >>> be of >>> little >>> interest to >>> � �non-technical users >>> � �> anyway. �In any case, the better >>> services are >>> likely to provide >>> � �such >>> � �> information in their online >>> documentation, I >>> would guess. >>> � �> >>> � �> You mentioned users "voting >>> with their >>> feet" or >>> choosing to >>> � �accept the risk >>> � �> of inconsistency. �Well that >>> will >>> happen anyway, >>> when services >>> � �fail and >>> � �> users get annoyed. �If some >>> asset >>> services refuse >>> to send the >>> � �requested >>> � �> items to some users, those >>> services >>> will get a >>> bad reputation >>> � �and people >>> � �> will choose different asset >>> services >>> instead. >>> �Likewise, if a >>> � �world service >>> � �> proxies everything and so it >>> can't >>> handle a large >>> number of >>> � �assets or of >>> � �> people, users will get annoyed >>> at the >>> lag and will go >>> � �elsewhere. �This user >>> � �> evaluation and "voting with >>> their >>> feet" happens >>> already with >>> � �online services >>> � �> all over the Internet, and I am >>> sure >>> that this >>> human process >>> � �will continue >>> � �> to work when the services are >>> asset >>> and region >>> services. >>> � �> >>> � �> Back in September 2010, I wrote >>> this >>> post which >>> proposes that >>> � �we use in >>> � �> VWRAP a form of asset >>> addressing that >>> provides >>> massive >>> � �scalability at the >>> � �> same time as a very high >>> degree of >>> resilience -- >>> � �> >>> � >>> >>> �http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >>> � �. �It is >>> � �> based on the concept of the URI >>> containing a host >>> part and a >>> � �hash part, >>> � �> where the hash is generated >>> (once, at >>> the time of >>> storage to >>> � �the asset >>> � �> service) using a specified >>> digest >>> algorithm over >>> the content of >>> � �the asset >>> � �> being referenced. �You may >>> wish to >>> note that if >>> this design >>> � �were used, the >>> � �> failure of an asset service to >>> deliver a >>> requested item would >>> � �result in a >>> � �> failover request for the item >>> to one >>> or more >>> backup services, >>> � �using the same >>> � �> hash part but with a >>> different host >>> address. >>> � �> >>> � �> This can go some way towards >>> overcoming the >>> problem that you >>> � �think might >>> � �> occur when assets are fetched by >>> clients from >>> asset services >>> � �directly. >>> � �> Although it won't help when the >>> missing item is >>> available from >>> � �only a single >>> � �> asset service, it will help >>> in many >>> other cases, >>> and it will >>> � �compensate for >>> � �> service failures and network >>> outages >>> automatically at the same >>> � �time. >>> � �> >>> � �> PS. This design for hash-based >>> asset >>> addressing >>> is already >>> � �being tested by >>> � �> Mojito Sorbet in her >>> experimental >>> world and >>> client. �It would give >>> � �> VWRAP-based worlds an improved >>> level >>> of service >>> availability, >>> � �so I think it >>> � �> should be a core feature of our >>> protocol. >>> � �> >>> � �> >>> � �> Morgaine. >>> � �> >>> � �> >>> � �> >>> � �> >>> � �> =========================== >>> � �> >>> � �> On Fri, Apr 1, 2011 at 11:17 PM, >>> Vaughn Deluca >>> � �>> >>> >> > >>> >> >>> >> >> >>> >> >>> >> > >>> >> >>> >> >>>> >>> � �> wrote: >>> � �>> >>> � �>> This is a question i discussed >>> with >>> Morgaine >>> off-list a while >>> � �ago (I >>> � �>> intended to send it to the >>> list but >>> pushed the >>> wrong button...) I >>> � �>> think we need to address this >>> problem, and >>> decide how to deal >>> � �with it. >>> � �>> >>> � �>> �In Davids deployment draft, >>> section >>> 7.3.1.1 an >>> overview is >>> � �given van >>> � �>> ways to deliver content to the >>> region. One way >>> is only passing a >>> � �>> capability that allows >>> access to >>> (part of) the >>> resource: >>> � �>> >>> � �>> � � � � � 7.3.1.1. �Content >>> delivery >>> models >>> � �>> � � � � � A range of possible >>> represenations can >>> be passed to >>> � �a region for >>> � �>> � � � � � simulation. [...] >>> The other >>> end of the >>> delivery spectrum >>> � �>> involves passing >>> � �>> � � � � � only a URI or >>> capability >>> used to >>> access the rendering >>> � �>> information and a >>> � �>> � � � � � collision mesh,and >>> related >>> data for >>> physical simulation. >>> � �>> � � � � � In such a model, the >>> client is >>> responsible for >>> � �fetching the >>> � �>> additional >>> � �>> � � � � � information needed to >>> render the >>> item's visual >>> � �presence from a >>> � �>> separate >>> � �>> � � � � � service. �This fetch >>> can be >>> done >>> *under the >>> � �credentials of the >>> � �>> end user* >>> � �>> � � � � � viewing the >>> material [my >>> emphasis--VD] >>> , and >>> � �divorces the >>> � �>> simulation from >>> � �>> � � � � � the trust chain >>> needed to >>> manage >>> content. �Any >>> � �automation >>> � �>> is done on a >>> � �>> � � � � � separate host which >>> the content >>> creator or owner trusts, >>> � �>> interacting with the >>> � �>> � � � � � object through >>> remoted >>> interfaces. >>> � �>> >>> � �>> �I can see the need for such a >>> setup, >>> however, i >>> feel we are >>> � �>> unpleasantly close to a >>> situation >>> were the >>> coherence of the >>> � �simulation >>> � �>> falls apart. >>> � �>> In this deployment pattern the >>> region >>> advertises >>> the presence >>> � �of the >>> � �>> asset, and *some* clients >>> will be >>> able to get it >>> as expected, >>> � �while >>> � �>> -based on the arbitrary whims >>> of the >>> asset >>> service- others >>> � �might not. >>> � �>> >>> � �>> My hope would be that after >>> the asset >>> server >>> provides the >>> � �region with >>> � �>> the capability to get the >>> asset, it >>> gives up >>> control. That >>> � �would mean >>> � �>> that if the client finds the >>> inventory server is >>> unwilling to >>> � �serve >>> � �>> the content - in spire of the >>> region >>> saying it >>> is present-, >>> � �the client >>> � �>> should be able to turn around >>> ask the >>> *region* >>> for the asset, >>> � �(and get >>> � �>> is after all). >>> � �>> >>> � �>> �If that is not the case, -and >>> there are >>> probably good reasons >>> � �for the >>> � �>> deployment pattern as >>> described- >>> �shouldn't we >>> *warn* clients >>> � �that the >>> � �>> region might be inconsistent, >>> so the >>> users >>> behind the client >>> � �can vote >>> � �>> with their feet, (or take the >>> risk)? >>> � �>> >>> � �>> --Vaughn >>> � �>> >>> _______________________________________________ >>> � �>> vwrap mailing list >>> � �>> vwrap@ietf.org >>> >>> > >>> >>> >> >>> >> >>> > >>> >>> >>> >>> >>> � �>> >>> https://www.ietf.org/mailman/listinfo/vwrap >>> � �> >>> � �> >>> � �> >>> _______________________________________________ >>> � �> vwrap mailing list >>> � �> vwrap@ietf.org >>> >> > >>> >>> >> >>> >> >>> > >>> >>> >>> >>> >>> � �> >>> https://www.ietf.org/mailman/listinfo/vwrap >>> � �> >>> � �> >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> _______________________________________________ >>> vwrap mailing list >>> vwrap@ietf.org >>> > >>> >>> >> >>> >>> https://www.ietf.org/mailman/listinfo/vwrap >>> � >>> >>> >>> >>> >>> >>> -- --- https://twitter.com/Dzonatas_Sol --- >>> Web Development, Software Engineering, Virtual >>> Reality, >>> Consultant >>> >>> _______________________________________________ >>> vwrap mailing list >>> vwrap@ietf.org >>> > >>> >>> >> >>> https://www.ietf.org/mailman/listinfo/vwrap >>> >>> >>> >>> >>> -- --- https://twitter.com/Dzonatas_Sol --- >>> Web Development, Software Engineering, Virtual Reality, >>> Consultant >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> vwrap mailing list >>> vwrap@ietf.org >>> https://www.ietf.org/mailman/listinfo/vwrap >>> >>> >>> -- --- https://twitter.com/Dzonatas_Sol --- >>> Web Development, Software Engineering, Virtual Reality, Consultant >>> >>> >> >> > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From vaughn.deluca@gmail.com Sun Apr 10 00:05:27 2011 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 1F2B13A69DB for ; Sun, 10 Apr 2011 00:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] 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 Km2pQURkXYtT for ; Sun, 10 Apr 2011 00:05:20 -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 B693E3A69D3 for ; Sun, 10 Apr 2011 00:05:18 -0700 (PDT) Received: by ewy19 with SMTP id 19so1713006ewy.31 for ; Sun, 10 Apr 2011 00:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DkD6h36R/9CGLhDnG6bkmztt8J5HHCS9Cbbmch82qKU=; b=mQPoxkn7msz1V20qRbhuq6A2atXOJ8KCrRNAwJ2DEq71fOTsYZrRi+NIKGRrwa0UUw aauqJW7Zl51xdZqusxOxre+iSnB7d3usZATYWaBYq/G7lFadHXgfHi1aQPbS1Zs4+eyL 7+IR1fwhUORHB3OAK3jW1u4j3WNDMAXQ2K2lk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=az4WUDVLtoR0U28gYMTojVLo1iaxTDjEpkCdw+UUcXP0ZmyjfvZUrCJUznsUCdAwik 6KQr8eUK5bYISm5sUegLiTnK13S3aVzhrcx6i/Zq3q1ocdM6bpVYGgN6LwxzxHL1XORd 5Y7PTN44Nv4yrPAkGSMA0vQx/VOFB5+gxEjTQ= MIME-Version: 1.0 Received: by 10.213.0.202 with SMTP id 10mr1673108ebc.79.1302419223845; Sun, 10 Apr 2011 00:07:03 -0700 (PDT) Received: by 10.213.17.17 with HTTP; Sun, 10 Apr 2011 00:07:03 -0700 (PDT) In-Reply-To: <4DA10780.7020100@gmail.com> References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> <4D9F5B5F.2060401@gmail.com> <4DA07A5D.9050402@gmail.com> <4DA08D99.6020402@gmail.com> <4DA10780.7020100@gmail.com> Date: Sun, 10 Apr 2011 09:07:03 +0200 Message-ID: From: Vaughn Deluca To: Dzonatas Sol Content-Type: multipart/alternative; boundary=000e0cdfd9f82f9c2d04a08b1b4b Cc: "vwrap@ietf.org" Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 10 Apr 2011 07:05:27 -0000 --000e0cdfd9f82f9c2d04a08b1b4b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dzonatas, >There have been talks to split out the renderer from the viewer, >yet the render depends on some of the network. To call that the >local region is appropriate as you have. >The renderer/network-loop does the bulk of the work now that others >think the simulator does. That's where we get hung up on local sim >or external sim, and components. Hmm, to be honest, i was thinking of that local region as a "real" region, something like the opensim region that i have running on my local machine. I called it local because it would run on one of my own machines. The entity that i called "viewer" was supposed to depict something like the standard SL viewer. I see your general point about taking an even higher point of view and dro= p some REST details. I will give that a try, it might simplify the figure a lot. >I think with your first VD1 that only thing that really needs to be added is to >add space between the local and external area to fit in the resource name per arrow. >That way the public resource name is specified. Then instead of those request for >cap transitions, these would be implied by those resource names. Above eac= h line of >each arrow, just add the appropriate public resource name there. We can deal with >private resources later, as those are already implied, too. OK, that sounds sensible, have been thinking about that, but decided agains= t it since at the time i was not exactly sure how to specify the resource names. In relation to that problem you wrote: >This group never did create any dictionary of resource names. They only exist in viewer source and >in SNOW-375. That dictionary would be something we should copy over from SNOW-375 or the viewer code. And it reminds me, is it still true hat if i look at that code, that might prevent me from working on opensim for some time? Would that be the case fo= r snow-375 code as well? I can make that new figure, but it will be a few days, i am overloaded with RL work :( Feel free to give it a try based on the PSD file. -- Vaughn On Sun, Apr 10, 2011 at 3:27 AM, Dzonatas Sol wrote: > Forwarded to vwrap-list: > > Dzonatas Sol wrote: > >> Just thought about this a little more... >> >> I think with your first VD1 that only thing that really needs to be adde= d >> is to add space between the local and external area to fit in the resour= ce >> name per arrow. That way the public resource name is specified. Then ins= tead >> of those request for cap transitions, these would be implied by those >> resource names. Above each line of each arrow, just add the appropriate >> public resource name there. We can deal with private resources later, as >> those are already implied, too. >> >> This group never did create any dictionary of resource names. They only >> exist in viewer source and in SNOW-375. >> >> I don't know if I can modify the PDF to make an example of above. >> >> Dzonatas Sol wrote: >> >>> Perhaps, that would be best to reflect upon the past. >>> >>> There have been talks to split out the renderer from the viewer, yet th= e >>> render depends on some of the network. To call that the local region is >>> appropriate as you have. The renderer/network-loop does the bulk of the= work >>> now that others think the simulator does. That's where we get hung up o= n >>> local sim or external sim, and components. >>> >>> Maybe easier not to worry about requests for caps for now and keep the >>> way your going. We can come back later and describe how the >>> connections/ReSTful patterns work later. Please just indicate it's the = above >>> ReSTful view of the flow (higher-level) and us implementators will >>> comprehend. >>> >>> =3D) >>> >>> Vaughn Deluca wrote: >>> >>>> Dzonatas Sol >>>> >Then again, split the viewer out for local agent services and maybe i= t >>>> will appear trivial. >>>> >>>> Right, Maybe we should consider *only* the viewer as local, and assu= me >>>> all other services are external, just to make the example clear. >>>> Thanks for the other feedback, I will look at the snow-375 example. >>>> --Vaughn >>>> >>>> On Fri, Apr 8, 2011 at 9:00 PM, Dzonatas Sol >>> dzonatas@gmail.com>> wrote: >>>> >>>> I've read it, and off hand I would say the "flow" needs further >>>> definition. Not that you did anything wrong, it just something >>>> that happens more at the transfer layer from ReST and lower. All >>>> the arrows you have that go from the Local to External let's >>>> consider those "forward flow" and those that from from external to >>>> local as "reverse flow." This becomes more obvious for reasons why >>>> when firewalls and proxies are in the way and connections may need >>>> to exist in opposite of the flow. Between unidirectional and >>>> bidirectional flows is were this discussion digresses to vanilla >>>> HTTP/caps and not fully ReSTful as desired. >>>> >>>> See also this doc on "forward/reverse" how Icesphere handles the >>>> implementation of bidirectional resources: >>>> >>>> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/I= nterface >>>> >>>> I think you already see the higher-level request to begin >>>> capability, end capability, and determine if it needs to request >>>> capabilities. With bidirectional resources, there are less >>>> requests for capabilities and mainly need for digests of >>>> capabilities that begin and end. With unidirectional resources, >>>> there are needs to request capabilities, that (currently on >>>> servers) begin as private capabilities. Also with unidirectional >>>> resources, there are keep-alives and long-poll requirements on the >>>> resources, which isn't mandatory on bidirectional resources. >>>> Bidirectional resources can use more ReSTful credentials, so there >>>> would be no need to request capabilities (only need to know they >>>> are capable by the digests). >>>> >>>> I imagine two big polygons around the Local and External areas on >>>> the diagrams, yet to further image the arrows on actual flow might >>>> not be so trivial as the desired flow noted. Then again, split the >>>> viewer out for local agent services and maybe it will appear trivia= l. >>>> >>>> Vaughn Deluca wrote: >>>> >>>> VWRAP services high level message flow (preliminary diagram >>>> draft) see >>>> >>>> >>>> http://trac.tools.ietf.org/wg/vwrap/trac/attachment/wiki/Diagrams/VWRA= P_FlowExample_VD1.pdf >>>> >>>> The main reason that i am submitting this in spite of my lack >>>> of formal expertise is that the group in my view badly needs a >>>> solid basis for discussion and preventing endless repeating >>>> loops. This example is probably wrong in many ways, but its >>>> better than what we have publicly available on interop now >>>> (although Morgaine is working on something along the lines of >>>> the recent discussions here) >>>> I hope this diagram will give us a base for discussion. I >>>> could have done my homework better by researching the old OGP >>>> stuff in more depth, and i probably will do so in the future >>>> , but for now I just tried to followed the general principles >>>> as far as i understand them, to see what response that yields >>>> from the group. In other words,I try to let the group educate >>>> me :p >>>> >>>> Note that in my view all services are equal, in principle it >>>> does not matter in what "domain" they run, since trust and >>>> policy are fully localized. It is however very possible to >>>> have internal shortcuts in the services to speed up processing. >>>> In the example I opted for an external Agent service, but I >>>> could as well have incorporated that in the set of local >>>> services. As indicated above all services could also be run by >>>> different organisations, true to what VWRAP stands for. Its >>>> all up to the deployer, including a user at home who might >>>> want to run a full world for family and friends. Those friends >>>> might try to use that agent service to venture out in the >>>> virtual universe. I envision that the final identity provider >>>> is external, using OpenID and OAut or whatever other magic >>>> that I do not yet fully understand exists out there. >>>> >>>> The example has 3 main purposes: >>>> - Provide a reference for discussion - Illustrates the use >>>> case of tourism, and *true* interop. >>>> - Illustrate consistency problems along the lines discussed >>>> here higher up in this tread, as well as the "slashdot" >>>> problem that Morgaine outlined so clearly. >>>> >>>> The message flow assumes an avatar already present in some >>>> region, (a small scale local home region in this case, but >>>> that is by no means essential, it could be a build in region >>>> in the viewer or a big commercial region). The user is >>>> preparing for a trip to immersive world, and after some outfit >>>> adjustments moves over. >>>> Finally i apologize for for the simplistic notation used here. >>>> I simply add the most relevant parameters passed in square >>>> brackets to a keyword specifying the nature of the message. >>>> Please improve on that where needed. >>>> >>>> So here we go, the avatar is prepare for a visit to >>>> "immersive world" >>>> 0) Viewer, here is an update of the state of the world your >>>> agent is in, please render. >>>> 1) Agent service, I will go in my Zodiac dress that i keep in >>>> the "Amazing assets" service. >>>> 2) Asset service A, please send a cap for Z, here are my >>>> credentials >>>> 3) Your fine, here is the cap >>>> 4) Local region, can you please put this on my agent, i >>>> included the cap. >>>> 5) Hello asset service A, i need Z, here is the cap >>>> 6) Cap is good, data coming up, have fun. >>>> 7) Agent service, your agent is now wearing Z >>>> 8) Viewer, your avatar is now wearing Z >>>> User: Hmm, amazing inventory has not been *that* amazing >>>> lately. 'll make a backup, just in case >>>> 9) Hello asset service A, please send me a cap for Z, here >>>> are my credentials >>>> 10) Your fine, here is the cap >>>> 11) Local asset storage, please store Z for me, here is the >>>> cap to get it >>>> 12) Hello asset service A, i want Z, here is the cap >>>> 13) Cap is good, data coming up, have fun. >>>> 14) Viewer, Z is now stored for you User: I am Ready!, >>>> Lets try to get to immersive world! >>>> 15) Hello immersive world, can i get in? Here are my >>>> credentials, and a list of my stuff. >>>> 16) Asset service A, please send me a cap for X, here are my >>>> credentials (I want this cap for consistency) >>>> 17) Your fine, here is the cap >>>> 18) Asset service B, please send me a cap for Y, here are my >>>> credentials (I want this cap for consistency) >>>> 19) Very sorry, but your not one of us, you can't have Y >>>> 20) Asset service B, please send me a cap for Z, here are my >>>> credentials (I want a cap for consistency) >>>> [Region service: Timeout... amazing inventory must be >>>> overloaded.. oh well... ] >>>> 21) Agent service, you wanted to send somebody over, here are >>>> your permissions. >>>> 22) Viewer, you asked for a transfer try, here are your results >>>> User thinks: Crap! Big asset service does not allow me >>>> to take my yellow stockings! And Amazing assets failed to >>>> deliver my zodiac dress. At least i made a backup of that dress= ! >>>> 23) 'll take the yellow stockings off... >>>> 24) ... done ('ll trash them here and now, forever, who needs >>>> stuff you can't use!) >>>> 25) The zodiac dress was not delivered by Big assets service, >>>> but i have a local copy! >>>> 26) Local Asset service, please send me Z, here are my >>>> credentials >>>> 27) I dont know you, but I 'll trust you, here is the cap, but >>>> you better store the data, its single use, i need to protect >>>> myself. >>>> 28) Local region, can you please put this on my agent, i >>>> include the cap. >>>> 29) Local Asset service, i need Z, here is the cap >>>> 30) Cap is good, data coming up, have fun. >>>> 31) Cap was only good for one time, I made a copy, but my >>>> policy is to only grant you fair use rights, at a later time i >>>> might even tell you to replace the dress. >>>> 32) Viewer, you can wear Z for now, but the asset service >>>> granted only fair use, i might ask you to replace the dress at >>>> a later time. >>>> 33) Ready at last! Off to immersive world!, I hope its not to >>>> crowded there or 'll loose my dress... >>>> 34) Hello immersive world, here are my credentials, and a list >>>> of stuff i want to bring >>>> 35) Hello asset service A, please send me a cap for X, here >>>> are my credentials [darn, I should have kept that cap from >>>> last time..] >>>> 36) Your fine, here is the cap. >>>> [Region service finds fair-use warning on Z and decides to >>>> make its own copy] >>>> 37) Hello Local region, can i still have Z? Here is the cap >>>> 38) Cap is still good, data coming up, have fun. >>>> [Region service stores asset in private storage, providing a >>>> cap to replace the fair use one] >>>> 39) Agent service, you wanted to send somebody over, here are >>>> your permissions & info. >>>> 40) Hello immersive world, just get me there, and use what >>>> you can >>>> 41) Placement done, Z is currently buffered by us as wel, you >>>> need to get details for X, have fun. >>>> 42) You are now in immersive world, your dress is buffered >>>> there as well, but you need to get X! >>>> 43) Hello asset service A, i want X, here is the cap >>>> 44) Cap is good, data coming up, have fun. >>>> 45) Viewer, here is an update of the state of the world your >>>> agent is in, please render. >>>> >>>> As far as I can see this conforms fully to our charter, and i >>>> hope it is possible to use large portions of the existing code >>>> bases. However, as said above, i did not really try to capture >>>> the old thinking, and I also might have misconceptions about >>>> the way to do these things in general. >>>> Looking forward to constructive comments. >>>> >>>> -- Vaughn >>>> >>>> On Sun, Apr 3, 2011 at 8:38 PM, Vaughn Deluca >>>> >>>> >>> >> wrote: >>>> >>>> Thanks for the pointers. I have a busy week in RL in front >>>> of >>>> me, so i wont have to much time to respond the next few days= , >>>> however, i intend to start doing the following things: >>>> >>>> - Produce a visual that reflects my thinking, i.e. an >>>> illustration >>>> of my response to Morgaine's itemlist above. >>>> - Read up on the older notes, as well as more reading in >>>> the list >>>> archive >>>> - Try to make a summary for the wiki >>>> >>>> Regarding the use of domain, I think services are >>>> eventually what >>>> counts, but its all terminology. The way I read the AWG >>>> diagrams >>>> is that the agent domain is actually a cluster of tightly >>>> integrated services. When the functionality of each >>>> sub-service is >>>> described properly and with uniform interfaces the domain wi= ll >>>> slowly dissolve. But let not get ahead of out selfs. We >>>> should put >>>> up some clear descriptions on the wiki for our views on >>>> this, and >>>> *after* that we can decide what we need and what can go. >>>> >>>> Its been a very useful and illuminating weekend for me, and >>>> i am a >>>> lot more optimistic about the future of vwrap than two >>>> weeks ago. >>>> >>>> -- Vaughn >>>> >>>> >>>> >>>> On Sun, Apr 3, 2011 at 7:20 PM, Dzonatas Sol >>>> >>>> >> >>>> wrote: >>>> >>>> Probably easy as suggested in other terms here on this >>>> list, >>>> as how the client contacts the asset services now in the >>>> regions. The newer issue is to unitize that asset >>>> services. >>>> Since their is proprietary (legacy) code then we can't >>>> expect >>>> that to change, and some form of proxy is of need. >>>> Whatever >>>> works best, I tried to narrow it down to suggestions her= e. >>>> >>>> Eventually, the agent domain is ideal to handle the >>>> direction >>>> of the asset services. This concept, unfortunately, ende= d >>>> support awhile ago with changes in LL. >>>> Also see; http://wiki.secondlife.com/wiki/Agent_Domain >>>> And: >>>> >>>> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset >>>> (warn: unstructured collaborative notes, dumped on me an= d >>>> I >>>> tried to fix) >>>> >>>> I tried to find previous visuals. >>>> >>>> I'd imagine the agent domain could grow out of unitized >>>> versions of asset services. Despite that, I think that >>>> concept >>>> helps view where we were at in discussion and what >>>> didn't happen. >>>> >>>> Vaughn Deluca wrote: >>>> >>>> Hi=EF=BF=BDDzonatas >>>> >>>> Can you expand on that, what would be needed for >>>> legacy >>>> support in VWAP terms=EF=BF=BD?, >>>> If i want to read up on how the=EF=BF=BDasset server= may >>>> proxy the >>>> simulator, what would you recommend me to read? >>>> >>>> -- Vaughn >>>> >>>> On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol >>>> >>>> > >>>> >>> >>> >>> >>>> >>>> wrote: >>>> >>>> Some stated the proxy-to-asset-server is built >>>> into the >>>> sim; >>>> however, keep in mind possible legacy support >>>> where the >>>> asset >>>> server may proxy the simulator. >>>> >>>> >>>> Dzonatas Sol wrote: >>>> >>>> Somehow I feel the basic asset server being >>>> able to >>>> login and >>>> download assets is now priority, yet I also >>>> wondered the best >>>> way to patch this into the current mode of >>>> viewers. >>>> >>>> Maybe offer (1) by proxy (sim-side) and (2) >>>> by patch >>>> (viewer-side) that either of these two are >>>> optional and >>>> neither are mandatory for now. Thoughts? >>>> >>>> Israel Alanis wrote: >>>> >>>> >>>> > when designing for scalability, the >>>> model to >>>> bear in >>>> mind is ... >>>> >>>> Well, there are a lot of different models >>>> to >>>> keep in mind, >>>> and many different use cases. One >>>> particular >>>> use case to >>>> keep in mind is: "User acquires new >>>> outfit, and >>>> wants to >>>> 'show it off' in a highly populated >>>> region". >>>> >>>> > Both worlds and asset services may >>>> include >>>> commercial, >>>> community, and personal services >>>> >>>> Yes, yes and yes. I'm particularly >>>> concerned >>>> about how the >>>> model affects the ability to host persona= l >>>> asset services. >>>> >>>> > a proxying region, which would get >>>> slammed >>>> for every >>>> asset worn by every avatar present. >>>> >>>> Granted the collection of services that a= re >>>> provided by >>>> the region need to be scaled to meet the >>>> demands of that >>>> region. That's all part of capacity >>>> planning. >>>> >>>> > regions run many different >>>> CPU-intensive tasks, >>>> including physics simulation and >>>> server-side >>>> scripting, >>>> and absolutely cannot afford to serve >>>> assets too >>>> Well... who said the same CPU's have to d= o >>>> proxying, >>>> physics simulation and server-side >>>> scripting? Asset >>>> proxying is a different service than >>>> physics >>>> simulation >>>> and can be on separate hardware, could >>>> make use of >>>> geographically distributed caching, and >>>> in certain >>>> deployment patterns, the same caching >>>> services >>>> could be >>>> shared by different regions. (Server-side >>>> scripting is a >>>> discussion for another day). >>>> >>>> > This is why we have to go parallel... >>>> >>>> Totally agree, and a proxying model >>>> could and >>>> should also >>>> take advantage of parallelism. >>>> >>>> > I think you're wrong that it has to >>>> cost much >>>> money. ?vs? >>>> > It costs money to host a high >>>> performance and >>>> scalable >>>> asset service and a high bandwidth >>>> network to >>>> handle the >>>> traffic. =EF=BF=BDA *lot* of money. >>>> I think what you're saying is: "It costs >>>> a lot >>>> of money to >>>> build a scalable asset service, but if >>>> assets >>>> are spread >>>> throughout the internet they don't have >>>> to be >>>> scalable." >>>> But that's not quite right. You're >>>> opening up >>>> every asset >>>> server to the VW equivalent of being >>>> slashdotted, so are >>>> you sure you're not forcing *every* asset >>>> service to be >>>> scalable and handle a lot of bandwith and >>>> network traffic? >>>> It's the exact opposite of your >>>> intention, but >>>> I think >>>> that's the result, all the same. >>>> >>>> This particular design decision has a big >>>> effect on the >>>> economics of the VW infrastructure. I'd >>>> rather the >>>> economics to work out such that a region >>>> provider who >>>> wishes to build a region that supports a >>>> small >>>> population, >>>> can do so economically. A region that >>>> wants to >>>> host a >>>> *large* population has to bear that cost = of >>>> providing that >>>> scalable asset service. >>>> I want the economics of hosting a small >>>> asset >>>> service to >>>> be a non-issue (as to best promote >>>> creation and >>>> creativity). Creating a high bar to provi= de >>>> asset services >>>> will mean that service will cost money >>>> and people >>>> shouldn't have to pay money just to >>>> create or >>>> own VW >>>> objects (I'm using 'own' here to refer to >>>> maintaining >>>> their existence, I'm not trying to make a >>>> 'leftist'/'communist' statement about >>>> ownership ;) >>>> >>>> - Izzy >>>> >>>> >>>> On Apr 2, 2011, at 3:58 PM, Morgaine wrot= e: >>>> >>>> Izzy, when designing for >>>> scalability, the >>>> model to >>>> bear in mind is that of seasoned >>>> virtual world >>>> travelers whose inventories contain >>>> assets >>>> from many >>>> different worlds, those assets being >>>> served >>>> by many >>>> different asset services. =EF=BF=BDBo= th >>>> worlds and >>>> asset >>>> services may include commercial, >>>> community, and >>>> personal services, and as the metaver= se >>>> grows, that >>>> set is highly likely to become >>>> progressively less >>>> clustered and more diverse. >>>> >>>> When those seasoned travelers click >>>> on an >>>> advertised >>>> VW link and perform an inter-world >>>> teleport >>>> to one >>>> particular world's region to share an >>>> experience, >>>> their "worn" assets (the only ones of >>>> interest to the >>>> region) will contain references to >>>> asset >>>> services >>>> spread widely across the Internet. = =EF=BF=BDThe >>>> fetches by the >>>> travelers' clients occur over many >>>> parallel >>>> paths from >>>> clients to asset services, so one can >>>> reasonably >>>> expect reduced network contention and >>>> reduced asset >>>> server loading because they are both >>>> spread >>>> out over >>>> however many asset services are being >>>> referenced by >>>> the overall set of assets in the >>>> region. >>>> >>>> This is very different to the case of= a >>>> proxying >>>> region, which would get slammed for >>>> every >>>> asset worn >>>> by every avatar present. =EF=BF=BDIn = our >>>> current >>>> architecture, >>>> regions run many different >>>> CPU-intensive tasks, >>>> including physics simulation and >>>> server-side >>>> scripting, and absolutely cannot >>>> afford to >>>> serve >>>> assets too unless your scalability >>>> requirements are >>>> very low indeed, ie. just a few dozen >>>> avatars of >>>> today's kind. =EF=BF=BDWe've hit the = ceiling >>>> already on region >>>> scalability done that way. =EF=BF=BDT= here is >>>> nowhere to go in >>>> that direction at all beyond >>>> improving the >>>> code like >>>> Intel demonstrated, and that work is >>>> subject to a law >>>> of diminishing returns. >>>> >>>> This is why we have to go parallel, >>>> and I >>>> think you're >>>> wrong that it has to cost much >>>> money. =EF=BF=BDAs >>>> we spread >>>> the load across more and more asset >>>> services, we are >>>> simply better utilizing all the >>>> hardware that's >>>> already out there on the Internet, >>>> at least >>>> in respect >>>> of community and private resources. >>>> =EF=BF=BDBut >>>> add to the >>>> community and private resources the >>>> commercial asset >>>> services that are likely to appear to >>>> exploit this >>>> opportunity, and not only will the >>>> number >>>> of asset >>>> services leap, but the power of each >>>> one >>>> will rocket >>>> too, because, after all, these >>>> businesses >>>> will be >>>> heavily optimized for the job. >>>> >>>> As to why a world would want clients >>>> to access >>>> external asset services instead of >>>> providing its own >>>> implementation, that's an easy >>>> question. >>>> =EF=BF=BDIt costs >>>> money to host a high performance and >>>> scalable asset >>>> service and a high bandwidth network = to >>>> handle the >>>> traffic. =EF=BF=BDA *lot* of money. = =EF=BF=BDIn >>>> contrast, >>>> it costs a >>>> world nothing to let others serve >>>> the assets to >>>> clients. =EF=BF=BDAnd that matters to= the >>>> bottom line. >>>> >>>> >>>> Morgaine. >>>> >>>> >>>> >>>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> On Sat, Apr 2, 2011 at 7:05 PM, Izzy >>>> Alanis >>>> >>> >>>> >>> > >>> >>>> >>> >> >>>> >>> >>>> >>> > >>>> >>>> >>> >>>> >>> >>>> wrote: >>>> >>>> =EF=BF=BD =EF=BF=BD> As always though= , it's a >>>> trade-off, >>>> since the >>>> proxied design >>>> =EF=BF=BD =EF=BF=BDhas very poor scal= ability >>>> compared to the >>>> distributed one. >>>> >>>> =EF=BF=BD =EF=BF=BDI don't agree with= that... If a user >>>> enters a >>>> highly populated >>>> =EF=BF=BD =EF=BF=BDregion, >>>> =EF=BF=BD =EF=BF=BDevery other client= is going to >>>> (could >>>> and should be >>>> trying to) >>>> =EF=BF=BD =EF=BF=BDhit the >>>> =EF=BF=BD =EF=BF=BDasset server(s) fo= r the assets >>>> that the >>>> user is >>>> wearing (assuming >>>> =EF=BF=BD =EF=BF=BDthey're not cached= locally). =EF=BF=BDEvery >>>> asset server >>>> has to be scaled up >>>> =EF=BF=BD =EF=BF=BDto the point that = it can handle that >>>> load from all >>>> over... >>>> >>>> =EF=BF=BD =EF=BF=BDIf I'm hosting a r= egion that >>>> supports 10s of >>>> thousands of >>>> =EF=BF=BD =EF=BF=BDsimultaneous >>>> =EF=BF=BD =EF=BF=BDusers (thinking of= the future), I >>>> already have to >>>> scale to meet that >>>> =EF=BF=BD =EF=BF=BDdemand. If the reg= ion is proxying >>>> the >>>> assets, then, >>>> yes the >>>> =EF=BF=BD =EF=BF=BDregion has >>>> =EF=BF=BD =EF=BF=BDto be scaled to me= et that asset >>>> demand >>>> too, but it >>>> already has to be >>>> =EF=BF=BD =EF=BF=BDscaled to meet oth= er demands of >>>> being a >>>> region >>>> server... and why is >>>> =EF=BF=BD =EF=BF=BDscaling those asse= t proxy >>>> services hard? >>>> =EF=BF=BDIt's >>>> going to cost $, >>>> =EF=BF=BD =EF=BF=BDbut is >>>> =EF=BF=BD =EF=BF=BDnot technically ch= allenging. So, if >>>> I >>>> want to host >>>> a region like >>>> =EF=BF=BD =EF=BF=BDthat... sure it wi= ll cost me, but >>>> the >>>> simulation >>>> will be consistent >>>> =EF=BF=BD =EF=BF=BDand users will be = able to >>>> participate >>>> equally, >>>> regardless of the >>>> =EF=BF=BD =EF=BF=BDcapabilities of th= eir individual >>>> asset >>>> services. >>>> >>>> >>>> >>>> >>>> =EF=BF=BD =EF=BF=BDOn Fri, Apr 1, 201= 1 at 11:55 PM, >>>> Morgaine >>>> =EF=BF=BD =EF=BF=BD>>> >>>> >>> > >>>> >>> morgaine.dinova@googlemail.com >>>> >>>> >>> >> >>>> =EF=BF=BD >>>> =EF=BF=BD>>> >>>> >>>> >>> > >>>> >>>> >>> morgaine.dinova@googlemail.com >>>> >>>> >>> >>>> wrote: >>>> =EF=BF=BD =EF=BF=BD> Every design cho= ice results in a >>>> trade-off, >>>> Vaughn, improving >>>> =EF=BF=BD =EF=BF=BDone thing at >>>> =EF=BF=BD =EF=BF=BD> the expense of s= omething else. =EF=BF=BDIf >>>> every time we >>>> offered a >>>> =EF=BF=BD =EF=BF=BDservice we had to >>>> =EF=BF=BD =EF=BF=BD> inform its users= about the >>>> downsides >>>> of all the >>>> trade-offs we >>>> =EF=BF=BD =EF=BF=BDhave made, >>>> =EF=BF=BD =EF=BF=BD> they would have = an awful lot to >>>> read. ;-) >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> The specific tra= de-off that you >>>> are >>>> discussing is no >>>> =EF=BF=BD =EF=BF=BDdifferent. =EF=BF= =BDA region >>>> =EF=BF=BD =EF=BF=BD> that proxies all= content has the >>>> "benefit" of >>>> acquiring control >>>> =EF=BF=BD =EF=BF=BDfrom the >>>> =EF=BF=BD =EF=BF=BD> asset servers ov= er the items in >>>> the >>>> region, so >>>> that it can >>>> =EF=BF=BD =EF=BF=BDensure that >>>> =EF=BF=BD =EF=BF=BD> everyone in the = region not only >>>> obtains the items >>>> but obtains >>>> =EF=BF=BD =EF=BF=BDthe same items >>>> =EF=BF=BD =EF=BF=BD> as everyone else= . =EF=BF=BDThat does >>>> indeed >>>> provide a >>>> greater guarantee of >>>> =EF=BF=BD =EF=BF=BD> consistency than= a deployment >>>> in which >>>> the region >>>> only passes >>>> =EF=BF=BD =EF=BF=BDasset URIs to >>>> =EF=BF=BD =EF=BF=BD> clients who then= fetch the >>>> items from >>>> asset services >>>> =EF=BF=BD =EF=BF=BDseparately. =EF=BF= =BDAs always >>>> =EF=BF=BD =EF=BF=BD> though, it's a t= rade-off, since >>>> the >>>> proxied >>>> design has very >>>> =EF=BF=BD =EF=BF=BDpoor scalability >>>> =EF=BF=BD =EF=BF=BD> compared to the = distributed one. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> If we're going t= o warn users of >>>> the >>>> potential for >>>> inconsistency >>>> =EF=BF=BD =EF=BF=BDin the >>>> =EF=BF=BD =EF=BF=BD> distributed depl= oyment as you >>>> suggest, >>>> are we >>>> also going to >>>> =EF=BF=BD =EF=BF=BDwarn them of >>>> =EF=BF=BD =EF=BF=BD> non-scalability = in the proxied >>>> one? =EF=BF=BDI >>>> really >>>> don't see much >>>> =EF=BF=BD =EF=BF=BDmerit in the >>>> =EF=BF=BD =EF=BF=BD> idea of warning = about design >>>> choices. >>>> =EF=BF=BDMany such >>>> choices are >>>> =EF=BF=BD =EF=BF=BDtechnical, and >>>> =EF=BF=BD =EF=BF=BD> the issues are q= uite likely to >>>> be of >>>> little >>>> interest to >>>> =EF=BF=BD =EF=BF=BDnon-technical user= s >>>> =EF=BF=BD =EF=BF=BD> anyway. =EF=BF= =BDIn any case, the better >>>> services are >>>> likely to provide >>>> =EF=BF=BD =EF=BF=BDsuch >>>> =EF=BF=BD =EF=BF=BD> information in t= heir online >>>> documentation, I >>>> would guess. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> You mentioned us= ers "voting >>>> with their >>>> feet" or >>>> choosing to >>>> =EF=BF=BD =EF=BF=BDaccept the risk >>>> =EF=BF=BD =EF=BF=BD> of inconsistency= . =EF=BF=BDWell that will >>>> happen anyway, >>>> when services >>>> =EF=BF=BD =EF=BF=BDfail and >>>> =EF=BF=BD =EF=BF=BD> users get annoye= d. =EF=BF=BDIf some asset >>>> services refuse >>>> to send the >>>> =EF=BF=BD =EF=BF=BDrequested >>>> =EF=BF=BD =EF=BF=BD> items to some us= ers, those >>>> services >>>> will get a >>>> bad reputation >>>> =EF=BF=BD =EF=BF=BDand people >>>> =EF=BF=BD =EF=BF=BD> will choose diff= erent asset >>>> services >>>> instead. >>>> =EF=BF=BDLikewise, if a >>>> =EF=BF=BD =EF=BF=BDworld service >>>> =EF=BF=BD =EF=BF=BD> proxies everythi= ng and so it can't >>>> handle a large >>>> number of >>>> =EF=BF=BD =EF=BF=BDassets or of >>>> =EF=BF=BD =EF=BF=BD> people, users wi= ll get annoyed >>>> at the >>>> lag and will go >>>> =EF=BF=BD =EF=BF=BDelsewhere. =EF=BF= =BDThis user >>>> =EF=BF=BD =EF=BF=BD> evaluation and "= voting with their >>>> feet" happens >>>> already with >>>> =EF=BF=BD =EF=BF=BDonline services >>>> =EF=BF=BD =EF=BF=BD> all over the Int= ernet, and I am >>>> sure >>>> that this >>>> human process >>>> =EF=BF=BD =EF=BF=BDwill continue >>>> =EF=BF=BD =EF=BF=BD> to work when the= services are >>>> asset >>>> and region >>>> services. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> Back in Septembe= r 2010, I wrote >>>> this >>>> post which >>>> proposes that >>>> =EF=BF=BD =EF=BF=BDwe use in >>>> =EF=BF=BD =EF=BF=BD> VWRAP a form of = asset >>>> addressing that >>>> provides >>>> massive >>>> =EF=BF=BD =EF=BF=BDscalability at the >>>> =EF=BF=BD =EF=BF=BD> same time as a v= ery high degree of >>>> resilience -- >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD >>>> =EF=BF=BD >>>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >>>> =EF=BF=BD =EF=BF=BD. =EF=BF=BDIt is >>>> =EF=BF=BD =EF=BF=BD> based on the con= cept of the URI >>>> containing a host >>>> part and a >>>> =EF=BF=BD =EF=BF=BDhash part, >>>> =EF=BF=BD =EF=BF=BD> where the hash i= s generated >>>> (once, at >>>> the time of >>>> storage to >>>> =EF=BF=BD =EF=BF=BDthe asset >>>> =EF=BF=BD =EF=BF=BD> service) using a= specified digest >>>> algorithm over >>>> the content of >>>> =EF=BF=BD =EF=BF=BDthe asset >>>> =EF=BF=BD =EF=BF=BD> being referenced= . =EF=BF=BDYou may wish to >>>> note that if >>>> this design >>>> =EF=BF=BD =EF=BF=BDwere used, the >>>> =EF=BF=BD =EF=BF=BD> failure of an as= set service to >>>> deliver a >>>> requested item would >>>> =EF=BF=BD =EF=BF=BDresult in a >>>> =EF=BF=BD =EF=BF=BD> failover request= for the item >>>> to one >>>> or more >>>> backup services, >>>> =EF=BF=BD =EF=BF=BDusing the same >>>> =EF=BF=BD =EF=BF=BD> hash part but wi= th a different >>>> host >>>> address. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> This can go some= way towards >>>> overcoming the >>>> problem that you >>>> =EF=BF=BD =EF=BF=BDthink might >>>> =EF=BF=BD =EF=BF=BD> occur when asset= s are fetched by >>>> clients from >>>> asset services >>>> =EF=BF=BD =EF=BF=BDdirectly. >>>> =EF=BF=BD =EF=BF=BD> Although it won'= t help when the >>>> missing item is >>>> available from >>>> =EF=BF=BD =EF=BF=BDonly a single >>>> =EF=BF=BD =EF=BF=BD> asset service, i= t will help in >>>> many >>>> other cases, >>>> and it will >>>> =EF=BF=BD =EF=BF=BDcompensate for >>>> =EF=BF=BD =EF=BF=BD> service failures= and network >>>> outages >>>> automatically at the same >>>> =EF=BF=BD =EF=BF=BDtime. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> PS. This design = for hash-based >>>> asset >>>> addressing >>>> is already >>>> =EF=BF=BD =EF=BF=BDbeing tested by >>>> =EF=BF=BD =EF=BF=BD> Mojito Sorbet in= her experimental >>>> world and >>>> client. =EF=BF=BDIt would give >>>> =EF=BF=BD =EF=BF=BD> VWRAP-based worl= ds an improved >>>> level >>>> of service >>>> availability, >>>> =EF=BF=BD =EF=BF=BDso I think it >>>> =EF=BF=BD =EF=BF=BD> should be a core= feature of our >>>> protocol. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> Morgaine. >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> =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 >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> On Fri, Apr 1, 2= 011 at 11:17 PM, >>>> Vaughn Deluca >>>> =EF=BF=BD =EF=BF=BD>>> >>>> >>> > >>>> >>> >>>> >>> >> >>>> >>> >>>> >>> > >>>> >>> >>>> >>> >>>> >>>> =EF=BF=BD =EF=BF=BD> wrote: >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> This is a quest= ion i discussed >>>> with >>>> Morgaine >>>> off-list a while >>>> =EF=BF=BD =EF=BF=BDago (I >>>> =EF=BF=BD =EF=BF=BD>> intended to sen= d it to the >>>> list but >>>> pushed the >>>> wrong button...) I >>>> =EF=BF=BD =EF=BF=BD>> think we need t= o address this >>>> problem, and >>>> decide how to deal >>>> =EF=BF=BD =EF=BF=BDwith it. >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDIn Dav= ids deployment draft, >>>> section >>>> 7.3.1.1 an >>>> overview is >>>> =EF=BF=BD =EF=BF=BDgiven van >>>> =EF=BF=BD =EF=BF=BD>> ways to deliver= content to the >>>> region. One way >>>> is only passing a >>>> =EF=BF=BD =EF=BF=BD>> capability that= allows access to >>>> (part of) the >>>> resource: >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF= =BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD 7.3.1.1. =EF=BF=BDContent >>>> delivery >>>> models >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF= =BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD A range of possible >>>> represenations can >>>> be passed to >>>> =EF=BF=BD =EF=BF=BDa region for >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF= =BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD simulation. [...] >>>> The other >>>> end of the >>>> delivery spectrum >>>> =EF=BF=BD =EF=BF=BD>> involves passin= g >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF= =BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD only a URI or >>>> capability >>>> used to >>>> access the rendering >>>> =EF=BF=BD =EF=BF=BD>> information and= a >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF= =BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD collision mesh,and >>>> related >>>> data for >>>> physical simulation. >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF= =BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD In such a model, the >>>> client is >>>> responsible for >>>> =EF=BF=BD =EF=BF=BDfetching the >>>> =EF=BF=BD =EF=BF=BD>> additional >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF= =BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD information needed to >>>> render the >>>> item's visual >>>> =EF=BF=BD =EF=BF=BDpresence from a >>>> =EF=BF=BD =EF=BF=BD>> separate >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF= =BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD service. =EF=BF=BDThis fetch >>>> can be >>>> done >>>> *under the >>>> =EF=BF=BD =EF=BF=BDcredentials of the >>>> =EF=BF=BD =EF=BF=BD>> end user* >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF= =BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD viewing the material >>>> [my >>>> emphasis--VD] >>>> , and >>>> =EF=BF=BD =EF=BF=BDdivorces the >>>> =EF=BF=BD =EF=BF=BD>> simulation from >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF= =BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD the trust chain >>>> needed to >>>> manage >>>> content. =EF=BF=BDAny >>>> =EF=BF=BD =EF=BF=BDautomation >>>> =EF=BF=BD =EF=BF=BD>> is done on a >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF= =BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD separate host which >>>> the content >>>> creator or owner trusts, >>>> =EF=BF=BD =EF=BF=BD>> interacting wit= h the >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF= =BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD object through remoted >>>> interfaces. >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDI can = see the need for such a >>>> setup, >>>> however, i >>>> feel we are >>>> =EF=BF=BD =EF=BF=BD>> unpleasantly cl= ose to a situation >>>> were the >>>> coherence of the >>>> =EF=BF=BD =EF=BF=BDsimulation >>>> =EF=BF=BD =EF=BF=BD>> falls apart. >>>> =EF=BF=BD =EF=BF=BD>> In this deploym= ent pattern the >>>> region >>>> advertises >>>> the presence >>>> =EF=BF=BD =EF=BF=BDof the >>>> =EF=BF=BD =EF=BF=BD>> asset, and *som= e* clients will be >>>> able to get it >>>> as expected, >>>> =EF=BF=BD =EF=BF=BDwhile >>>> =EF=BF=BD =EF=BF=BD>> -based on the a= rbitrary whims >>>> of the >>>> asset >>>> service- others >>>> =EF=BF=BD =EF=BF=BDmight not. >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> My hope would b= e that after >>>> the asset >>>> server >>>> provides the >>>> =EF=BF=BD =EF=BF=BDregion with >>>> =EF=BF=BD =EF=BF=BD>> the capability = to get the >>>> asset, it >>>> gives up >>>> control. That >>>> =EF=BF=BD =EF=BF=BDwould mean >>>> =EF=BF=BD =EF=BF=BD>> that if the cli= ent finds the >>>> inventory server is >>>> unwilling to >>>> =EF=BF=BD =EF=BF=BDserve >>>> =EF=BF=BD =EF=BF=BD>> the content - i= n spire of the >>>> region >>>> saying it >>>> is present-, >>>> =EF=BF=BD =EF=BF=BDthe client >>>> =EF=BF=BD =EF=BF=BD>> should be able = to turn around >>>> ask the >>>> *region* >>>> for the asset, >>>> =EF=BF=BD =EF=BF=BD(and get >>>> =EF=BF=BD =EF=BF=BD>> is after all). >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDIf tha= t is not the case, -and >>>> there are >>>> probably good reasons >>>> =EF=BF=BD =EF=BF=BDfor the >>>> =EF=BF=BD =EF=BF=BD>> deployment patt= ern as described- >>>> =EF=BF=BDshouldn't we >>>> *warn* clients >>>> =EF=BF=BD =EF=BF=BDthat the >>>> =EF=BF=BD =EF=BF=BD>> region might be= inconsistent, >>>> so the >>>> users >>>> behind the client >>>> =EF=BF=BD =EF=BF=BDcan vote >>>> =EF=BF=BD =EF=BF=BD>> with their feet= , (or take the >>>> risk)? >>>> =EF=BF=BD =EF=BF=BD>> >>>> =EF=BF=BD =EF=BF=BD>> --Vaughn >>>> =EF=BF=BD =EF=BF=BD>> >>>> _______________________________________________ >>>> =EF=BF=BD =EF=BF=BD>> vwrap mailing l= ist >>>> =EF=BF=BD =EF=BF=BD>> vwrap@ietf.org >>>> >>>> > >>>> >>>> >> >>>> >>> >>>> > >>>> >>>> >>> >>>> >>>> =EF=BF=BD =EF=BF=BD>> >>>> https://www.ietf.org/mailman/listinfo/vwrap >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> >>>> _______________________________________________ >>>> =EF=BF=BD =EF=BF=BD> vwrap mailing li= st >>>> =EF=BF=BD =EF=BF=BD> vwrap@ietf.org >>>> >>> > >>>> >>>> >> >>>> >>> >>>> > >>>> >>>> >>> >>>> >>>> =EF=BF=BD =EF=BF=BD> >>>> https://www.ietf.org/mailman/listinfo/vwrap >>>> =EF=BF=BD =EF=BF=BD> >>>> =EF=BF=BD =EF=BF=BD> >>>> >>>> >>>> >>>> >>>> ---------------------------------------------------------------------= --- >>>> >>>> >>>> _______________________________________________ >>>> vwrap mailing list >>>> vwrap@ietf.org >>>> > >>>> >>>> >> >>>> >>>> https://www.ietf.org/mailman/listinfo/vwrap >>>> =EF=BF=BD >>>> >>>> >>>> >>>> >>>> >>>> -- --- https://twitter.com/Dzonatas_Sol --- >>>> Web Development, Software Engineering, Virtual >>>> Reality, >>>> Consultant >>>> >>>> _______________________________________________ >>>> vwrap mailing list >>>> vwrap@ietf.org >>>> > >>>> >>>> >> >>>> https://www.ietf.org/mailman/listinfo/vwrap >>>> >>>> >>>> >>>> >>>> -- --- https://twitter.com/Dzonatas_Sol --- >>>> Web Development, Software Engineering, Virtual Reality, >>>> Consultant >>>> >>>> >>>> >>>> >>>> ---------------------------------------------------------------------= --- >>>> >>>> _______________________________________________ >>>> vwrap mailing list >>>> vwrap@ietf.org >>>> https://www.ietf.org/mailman/listinfo/vwrap >>>> >>>> -- --- https://twitter.com/Dzonatas_Sol --- >>>> Web Development, Software Engineering, Virtual Reality, Consultant >>>> >>>> >>>> >>> >>> >> >> > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > --000e0cdfd9f82f9c2d04a08b1b4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj5Eem9uYXRhcyw8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PiZndDtUaGVyZSBoYXZlIGJl ZW4gdGFsa3MgdG8gc3BsaXQgb3V0IHRoZSByZW5kZXJlciBmcm9tIHRoZSB2aWV3ZXIswqA8L2Rp dj48ZGl2PiZndDt5ZXQgdGhlIHJlbmRlciBkZXBlbmRzIG9uIHNvbWUgb2YgdGhlIG5ldHdvcmsu IFRvIGNhbGwgdGhhdCB0aGXCoDwvZGl2PjxkaXY+Jmd0O2xvY2FsIHJlZ2lvbiBpcyBhcHByb3By aWF0ZSBhcyB5b3UgaGF2ZS7CoDwvZGl2Pgo8ZGl2PiZndDtUaGUgcmVuZGVyZXIvbmV0d29yay1s b29wIGRvZXMgdGhlIGJ1bGsgb2YgdGhlIHdvcmsgbm93IHRoYXQgb3RoZXJzwqA8L2Rpdj48ZGl2 PiZndDt0aGluayB0aGUgc2ltdWxhdG9yIGRvZXMuIFRoYXQmIzM5O3Mgd2hlcmUgd2UgZ2V0IGh1 bmcgdXAgb24gbG9jYWwgc2ltwqA8L2Rpdj48ZGl2PiZndDtvciBleHRlcm5hbCBzaW0sIGFuZCBj b21wb25lbnRzLjwvZGl2PjxkaXY+Cjxicj48L2Rpdj48ZGl2PkhtbSwgdG8gYmUgaG9uZXN0LCBp IHdhcyB0aGlua2luZyBvZiB0aGF0IGxvY2FsIHJlZ2lvbiBhcyBhICZxdW90O3JlYWwmcXVvdDsg wqByZWdpb24sIHNvbWV0aGluZyBsaWtlPC9kaXY+PGRpdj50aGUgb3BlbnNpbSByZWdpb24gdGhh dCBpIGhhdmUgcnVubmluZyBvbiBteSBsb2NhbCBtYWNoaW5lLiDCoEkgY2FsbGVkIGl0IGxvY2Fs IGJlY2F1c2UgaXQgd291bGQgcnVuIG9uIG9uZSBvZiBteSBvd24gbWFjaGluZXMuIFRoZSBlbnRp dHkgdGhhdCBpIGNhbGxlZCAmcXVvdDt2aWV3ZXImcXVvdDsgd2FzIHN1cHBvc2VkIHRvIGRlcGlj dCBzb21ldGhpbmcgbGlrZSB0aGUgc3RhbmRhcmQgU0wgdmlld2VyLjwvZGl2Pgo8ZGl2Pjxicj48 L2Rpdj48ZGl2PsKgSSBzZWUgeW91ciBnZW5lcmFsIHBvaW50IGFib3V0IHRha2luZyBhbiBldmVu IGhpZ2hlciBwb2ludCBvZiB2aWV3IGFuZCBkcm9wIHNvbWUgUkVTVCBkZXRhaWxzLiBJIHdpbGwg Z2l2ZSB0aGF0IGEgdHJ5LCBpdCBtaWdodCBzaW1wbGlmeSB0aGUgZmlndXJlIGEgbG90LjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+Jmd0O0kgdGhpbmsgd2l0aCB5b3VyIGZpcnN0IFZEMSB0aGF0 IG9ubHkgdGhpbmcgdGhhdCByZWFsbHkgbmVlZHMgdG8gYmUgYWRkZWQgaXMgdG/CoDwvZGl2Pgo8 ZGl2PiZndDthZGQgc3BhY2UgYmV0d2VlbiB0aGUgbG9jYWwgYW5kIGV4dGVybmFsIGFyZWEgdG8g Zml0IGluIHRoZSByZXNvdXJjZSBuYW1lIHBlciBhcnJvdy7CoDwvZGl2PjxkaXY+Jmd0O1RoYXQg d2F5IHRoZSBwdWJsaWMgcmVzb3VyY2UgbmFtZSBpcyBzcGVjaWZpZWQuIFRoZW4gaW5zdGVhZCBv ZiB0aG9zZSByZXF1ZXN0IGZvcsKgPC9kaXY+PGRpdj4mZ3Q7Y2FwIHRyYW5zaXRpb25zLCB0aGVz ZSB3b3VsZCBiZSBpbXBsaWVkIGJ5IHRob3NlIHJlc291cmNlIG5hbWVzLiBBYm92ZSBlYWNoIGxp bmUgb2bCoDwvZGl2Pgo8ZGl2PiZndDtlYWNoIGFycm93LCBqdXN0IGFkZCB0aGUgYXBwcm9wcmlh dGUgcHVibGljIHJlc291cmNlIG5hbWUgdGhlcmUuIFdlIGNhbiBkZWFsIHdpdGjCoDwvZGl2Pjxk aXY+Jmd0O3ByaXZhdGUgcmVzb3VyY2VzIGxhdGVyLCBhcyB0aG9zZSBhcmUgYWxyZWFkeSBpbXBs aWVkLCB0b28uPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5PSywgdGhhdCBzb3VuZHMgc2Vuc2li bGUsIGhhdmUgYmVlbiB0aGlua2luZyBhYm91dCB0aGF0LCBidXQgZGVjaWRlZCBhZ2FpbnN0IGl0 IHNpbmNlIGF0IHRoZSB0aW1lIMKgaSB3YXMgbm90IGV4YWN0bHkgc3VyZSBob3cgdG8gc3BlY2lm eSB0aGUgcmVzb3VyY2UgbmFtZXMuIEluIHJlbGF0aW9uIHRvIHRoYXQgcHJvYmxlbSB5b3Ugd3Jv dGU6PC9kaXY+CjxkaXY+PGJyPjwvZGl2PjxkaXY+Jmd0O1RoaXMgZ3JvdXAgbmV2ZXIgZGlkIGNy ZWF0ZSBhbnkgZGljdGlvbmFyeSBvZiByZXNvdXJjZSBuYW1lcy4gVGhleSBvbmx5IGV4aXN0IGlu IHZpZXdlciBzb3VyY2UgYW5kICZndDtpbiBTTk9XLTM3NS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2PlRoYXQgZGljdGlvbmFyeSB3b3VsZCBiZSBzb21ldGhpbmcgd2Ugc2hvdWxkIGNvcHkgb3Zl ciBmcm9tIFNOT1ctMzc1IG9yIHRoZSB2aWV3ZXIgY29kZS48L2Rpdj4KPGRpdj5BbmQgaXQgcmVt aW5kcyBtZSwgaXMgaXQgc3RpbGwgdHJ1ZSBoYXQgaWYgaSBsb29rIGF0IHRoYXQgY29kZSwgdGhh dCBtaWdodCBwcmV2ZW50IG1lIGZyb20gd29ya2luZyBvbiBvcGVuc2ltIGZvciBzb21lIHRpbWU/ IFdvdWxkIHRoYXQgYmUgdGhlIGNhc2UgZm9yIHNub3ctMzc1IGNvZGUgYXMgd2VsbD88L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2PkkgY2FuIG1ha2UgdGhhdCBuZXcgZmlndXJlLCBidXQgaXQgd2ls bCBiZSBhIGZldyBkYXlzLCBpIGFtIG92ZXJsb2FkZWQgd2l0aCBSTCB3b3JrIMKgOig8L2Rpdj4K PGRpdj5GZWVsIGZyZWUgdG8gZ2l2ZSBpdCBhIHRyeSBiYXNlZCBvbiB0aGUgUFNEIGZpbGUuPC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj4tLSBWYXVnaG48L2Rpdj48YnI+PGRpdiBjbGFzcz0iZ21h aWxfcXVvdGUiPk9uIFN1biwgQXByIDEwLCAyMDExIGF0IDM6MjcgQU0sIER6b25hdGFzIFNvbCA8 c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpkem9uYXRhc0BnbWFpbC5jb20iPmR6 b25hdGFzQGdtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+CjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXg7Ij5Gb3J3YXJkZWQgdG8gdndyYXAtbGlzdDo8 YnI+Cjxicj4KRHpvbmF0YXMgU29sIHdyb3RlOjxicj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29s aWQ7cGFkZGluZy1sZWZ0OjFleCI+Ckp1c3QgdGhvdWdodCBhYm91dCB0aGlzIGEgbGl0dGxlIG1v cmUuLi48YnI+Cjxicj4KSSB0aGluayB3aXRoIHlvdXIgZmlyc3QgVkQxIHRoYXQgb25seSB0aGlu ZyB0aGF0IHJlYWxseSBuZWVkcyB0byBiZSBhZGRlZCBpcyB0byBhZGQgc3BhY2UgYmV0d2VlbiB0 aGUgbG9jYWwgYW5kIGV4dGVybmFsIGFyZWEgdG8gZml0IGluIHRoZSByZXNvdXJjZSBuYW1lIHBl ciBhcnJvdy4gVGhhdCB3YXkgdGhlIHB1YmxpYyByZXNvdXJjZSBuYW1lIGlzIHNwZWNpZmllZC4g VGhlbiBpbnN0ZWFkIG9mIHRob3NlIHJlcXVlc3QgZm9yIGNhcCB0cmFuc2l0aW9ucywgdGhlc2Ug d291bGQgYmUgaW1wbGllZCBieSB0aG9zZSByZXNvdXJjZSBuYW1lcy4gQWJvdmUgZWFjaCBsaW5l IG9mIGVhY2ggYXJyb3csIGp1c3QgYWRkIHRoZSBhcHByb3ByaWF0ZSBwdWJsaWMgcmVzb3VyY2Ug bmFtZSB0aGVyZS4gV2UgY2FuIGRlYWwgd2l0aCBwcml2YXRlIHJlc291cmNlcyBsYXRlciwgYXMg dGhvc2UgYXJlIGFscmVhZHkgaW1wbGllZCwgdG9vLjxicj4KCjxicj4KVGhpcyBncm91cCBuZXZl ciBkaWQgY3JlYXRlIGFueSBkaWN0aW9uYXJ5IG9mIHJlc291cmNlIG5hbWVzLiBUaGV5IG9ubHkg ZXhpc3QgaW4gdmlld2VyIHNvdXJjZSBhbmQgaW4gU05PVy0zNzUuPGJyPgo8YnI+CkkgZG9uJiMz OTt0IGtub3cgaWYgSSBjYW4gbW9kaWZ5IHRoZSBQREYgdG8gbWFrZSBhbiBleGFtcGxlIG9mIGFi b3ZlLjxicj4KPGJyPgpEem9uYXRhcyBTb2wgd3JvdGU6PGJyPgo8YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2Nj YyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4KUGVyaGFwcywgdGhhdCB3b3VsZCBiZSBiZXN0IHRv IHJlZmxlY3QgdXBvbiB0aGUgcGFzdC48YnI+Cjxicj4KVGhlcmUgaGF2ZSBiZWVuIHRhbGtzIHRv IHNwbGl0IG91dCB0aGUgcmVuZGVyZXIgZnJvbSB0aGUgdmlld2VyLCB5ZXQgdGhlIHJlbmRlciBk ZXBlbmRzIG9uIHNvbWUgb2YgdGhlIG5ldHdvcmsuIFRvIGNhbGwgdGhhdCB0aGUgbG9jYWwgcmVn aW9uIGlzIGFwcHJvcHJpYXRlIGFzIHlvdSBoYXZlLiBUaGUgcmVuZGVyZXIvbmV0d29yay1sb29w IGRvZXMgdGhlIGJ1bGsgb2YgdGhlIHdvcmsgbm93IHRoYXQgb3RoZXJzIHRoaW5rIHRoZSBzaW11 bGF0b3IgZG9lcy4gVGhhdCYjMzk7cyB3aGVyZSB3ZSBnZXQgaHVuZyB1cCBvbiBsb2NhbCBzaW0g b3IgZXh0ZXJuYWwgc2ltLCBhbmQgY29tcG9uZW50cy48YnI+Cgo8YnI+Ck1heWJlIGVhc2llciBu b3QgdG8gd29ycnkgYWJvdXQgcmVxdWVzdHMgZm9yIGNhcHMgZm9yIG5vdyBhbmQga2VlcCB0aGUg d2F5IHlvdXIgZ29pbmcuIFdlIGNhbiBjb21lIGJhY2sgbGF0ZXIgYW5kIGRlc2NyaWJlIGhvdyB0 aGUgY29ubmVjdGlvbnMvUmVTVGZ1bCBwYXR0ZXJucyB3b3JrIGxhdGVyLiBQbGVhc2UganVzdCBp bmRpY2F0ZSBpdCYjMzk7cyB0aGUgYWJvdmUgUmVTVGZ1bCB2aWV3IG9mIHRoZSBmbG93IChoaWdo ZXItbGV2ZWwpIGFuZCB1cyBpbXBsZW1lbnRhdG9ycyB3aWxsIGNvbXByZWhlbmQuPGJyPgoKPGJy Pgo9KTxicj4KPGJyPgpWYXVnaG4gRGVsdWNhIHdyb3RlOjxicj4KPGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNj Y2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+CkR6b25hdGFzIFNvbDxicj4KJmd0O1RoZW4gYWdh aW4sIHNwbGl0IHRoZSB2aWV3ZXIgb3V0IGZvciBsb2NhbCBhZ2VudCBzZXJ2aWNlcyBhbmQgbWF5 YmUgaXQgd2lsbCBhcHBlYXIgdHJpdmlhbC48YnI+Cjxicj4KUmlnaHQsIMKgTWF5YmUgd2Ugc2hv dWxkIGNvbnNpZGVyIMKgKm9ubHkqIHRoZSB2aWV3ZXIgYXMgbG9jYWwsIGFuZCBhc3N1bWUgYWxs IG90aGVyIHNlcnZpY2VzIGFyZSBleHRlcm5hbCwganVzdCB0byBtYWtlIHRoZSBleGFtcGxlIGNs ZWFyLjxicj4KVGhhbmtzIGZvciB0aGUgb3RoZXIgZmVlZGJhY2ssIEkgd2lsbCBsb29rIGF0IHRo ZSBzbm93LTM3NSBleGFtcGxlLjxicj4KLS1WYXVnaG48YnI+Cjxicj4KT24gRnJpLCBBcHIgOCwg MjAxMSBhdCA5OjAwIFBNLCBEem9uYXRhcyBTb2wgJmx0OzxhIGhyZWY9Im1haWx0bzpkem9uYXRh c0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kem9uYXRhc0BnbWFpbC5jb208L2E+ICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmR6b25hdGFzQGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+Cgo8YnI+CiDCoCDCoEkm IzM5O3ZlIHJlYWQgaXQsIGFuZCBvZmYgaGFuZCBJIHdvdWxkIHNheSB0aGUgJnF1b3Q7ZmxvdyZx dW90OyBuZWVkcyBmdXJ0aGVyPGJyPgogwqAgwqBkZWZpbml0aW9uLiBOb3QgdGhhdCB5b3UgZGlk IGFueXRoaW5nIHdyb25nLCBpdCBqdXN0IHNvbWV0aGluZzxicj4KIMKgIMKgdGhhdCBoYXBwZW5z IG1vcmUgYXQgdGhlIHRyYW5zZmVyIGxheWVyIGZyb20gUmVTVCBhbmQgbG93ZXIuIEFsbDxicj4K IMKgIMKgdGhlIGFycm93cyB5b3UgaGF2ZSB0aGF0IGdvIGZyb20gdGhlIExvY2FsIHRvIEV4dGVy bmFsIGxldCYjMzk7czxicj4KIMKgIMKgY29uc2lkZXIgdGhvc2UgJnF1b3Q7Zm9yd2FyZCBmbG93 JnF1b3Q7IGFuZCB0aG9zZSB0aGF0IGZyb20gZnJvbSBleHRlcm5hbCB0bzxicj4KIMKgIMKgbG9j YWwgYXMgJnF1b3Q7cmV2ZXJzZSBmbG93LiZxdW90OyBUaGlzIGJlY29tZXMgbW9yZSBvYnZpb3Vz IGZvciByZWFzb25zIHdoeTxicj4KIMKgIMKgd2hlbiBmaXJld2FsbHMgYW5kIHByb3hpZXMgYXJl IGluIHRoZSB3YXkgYW5kIGNvbm5lY3Rpb25zIG1heSBuZWVkPGJyPgogwqAgwqB0byBleGlzdCBp biBvcHBvc2l0ZSBvZiB0aGUgZmxvdy4gQmV0d2VlbiB1bmlkaXJlY3Rpb25hbCBhbmQ8YnI+CiDC oCDCoGJpZGlyZWN0aW9uYWwgZmxvd3MgaXMgd2VyZSB0aGlzIGRpc2N1c3Npb24gZGlncmVzc2Vz IHRvIHZhbmlsbGE8YnI+CiDCoCDCoEhUVFAvY2FwcyBhbmQgbm90IGZ1bGx5IFJlU1RmdWwgYXMg ZGVzaXJlZC48YnI+Cjxicj4KIMKgIMKgU2VlIGFsc28gdGhpcyBkb2Mgb24gJnF1b3Q7Zm9yd2Fy ZC9yZXZlcnNlJnF1b3Q7IGhvdyBJY2VzcGhlcmUgaGFuZGxlcyB0aGU8YnI+CiDCoCDCoGltcGxl bWVudGF0aW9uIG9mIGJpZGlyZWN0aW9uYWwgcmVzb3VyY2VzOjxicj4KIMKgIMKgPGEgaHJlZj0i aHR0cDovL3dpa2kuc2Vjb25kbGlmZS5jb20vd2lraS9Vc2VyOkR6b25hdGFzX1NvbC9TTk9XLTM3 NV9SZXNvdXJjZXMvSW50ZXJmYWNlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3dpa2kuc2Vjb25k bGlmZS5jb20vd2lraS9Vc2VyOkR6b25hdGFzX1NvbC9TTk9XLTM3NV9SZXNvdXJjZXMvSW50ZXJm YWNlPC9hPiA8YnI+Cjxicj4KIMKgIMKgSSB0aGluayB5b3UgYWxyZWFkeSBzZWUgdGhlIGhpZ2hl ci1sZXZlbCByZXF1ZXN0IHRvIGJlZ2luPGJyPgogwqAgwqBjYXBhYmlsaXR5LCBlbmQgY2FwYWJp bGl0eSwgYW5kIGRldGVybWluZSBpZiBpdCBuZWVkcyB0byByZXF1ZXN0PGJyPgogwqAgwqBjYXBh YmlsaXRpZXMuIFdpdGggYmlkaXJlY3Rpb25hbCByZXNvdXJjZXMsIHRoZXJlIGFyZSBsZXNzPGJy PgogwqAgwqByZXF1ZXN0cyBmb3IgY2FwYWJpbGl0aWVzIGFuZCBtYWlubHkgbmVlZCBmb3IgZGln ZXN0cyBvZjxicj4KIMKgIMKgY2FwYWJpbGl0aWVzIHRoYXQgYmVnaW4gYW5kIGVuZC4gV2l0aCB1 bmlkaXJlY3Rpb25hbCByZXNvdXJjZXMsPGJyPgogwqAgwqB0aGVyZSBhcmUgbmVlZHMgdG8gcmVx dWVzdCBjYXBhYmlsaXRpZXMsIHRoYXQgKGN1cnJlbnRseSBvbjxicj4KIMKgIMKgc2VydmVycykg YmVnaW4gYXMgcHJpdmF0ZSBjYXBhYmlsaXRpZXMuIEFsc28gd2l0aCB1bmlkaXJlY3Rpb25hbDxi cj4KIMKgIMKgcmVzb3VyY2VzLCB0aGVyZSBhcmUga2VlcC1hbGl2ZXMgYW5kIGxvbmctcG9sbCBy ZXF1aXJlbWVudHMgb24gdGhlPGJyPgogwqAgwqByZXNvdXJjZXMsIHdoaWNoIGlzbiYjMzk7dCBt YW5kYXRvcnkgb24gYmlkaXJlY3Rpb25hbCByZXNvdXJjZXMuPGJyPgogwqAgwqBCaWRpcmVjdGlv bmFsIHJlc291cmNlcyBjYW4gdXNlIG1vcmUgUmVTVGZ1bCBjcmVkZW50aWFscywgc28gdGhlcmU8 YnI+CiDCoCDCoHdvdWxkIGJlIG5vIG5lZWQgdG8gcmVxdWVzdCBjYXBhYmlsaXRpZXMgKG9ubHkg bmVlZCB0byBrbm93IHRoZXk8YnI+CiDCoCDCoGFyZSBjYXBhYmxlIGJ5IHRoZSBkaWdlc3RzKS48 YnI+Cjxicj4KIMKgIMKgSSBpbWFnaW5lIHR3byBiaWcgcG9seWdvbnMgYXJvdW5kIHRoZSBMb2Nh bCBhbmQgRXh0ZXJuYWwgYXJlYXMgb248YnI+CiDCoCDCoHRoZSBkaWFncmFtcywgeWV0IHRvIGZ1 cnRoZXIgaW1hZ2UgdGhlIGFycm93cyBvbiBhY3R1YWwgZmxvdyBtaWdodDxicj4KIMKgIMKgbm90 IGJlIHNvIHRyaXZpYWwgYXMgdGhlIGRlc2lyZWQgZmxvdyBub3RlZC4gVGhlbiBhZ2Fpbiwgc3Bs aXQgdGhlPGJyPgogwqAgwqB2aWV3ZXIgb3V0IGZvciBsb2NhbCBhZ2VudCBzZXJ2aWNlcyBhbmQg bWF5YmUgaXQgd2lsbCBhcHBlYXIgdHJpdmlhbC48YnI+Cjxicj4KIMKgIMKgVmF1Z2huIERlbHVj YSB3cm90ZTo8YnI+Cjxicj4KIMKgIMKgIMKgIMKgVldSQVAgc2VydmljZXMgaGlnaCBsZXZlbCBt ZXNzYWdlIGZsb3cgKHByZWxpbWluYXJ5IGRpYWdyYW08YnI+CiDCoCDCoCDCoCDCoGRyYWZ0KSBz ZWU8YnI+Cjxicj4KIMKgIMKgIMKgIMKgPGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5v cmcvd2cvdndyYXAvdHJhYy9hdHRhY2htZW50L3dpa2kvRGlhZ3JhbXMvVldSQVBfRmxvd0V4YW1w bGVfVkQxLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dn L3Z3cmFwL3RyYWMvYXR0YWNobWVudC93aWtpL0RpYWdyYW1zL1ZXUkFQX0Zsb3dFeGFtcGxlX1ZE MS5wZGY8L2E+IDxicj4KCjxicj4KIMKgIMKgIMKgIMKgVGhlIG1haW4gcmVhc29uIHRoYXQgaSBh bSBzdWJtaXR0aW5nIHRoaXMgaW4gc3BpdGUgb2YgbXkgbGFjazxicj4KIMKgIMKgIMKgIMKgb2Yg Zm9ybWFsIGV4cGVydGlzZSBpcyB0aGF0IHRoZSBncm91cCBpbiBteSB2aWV3IGJhZGx5IG5lZWRz IGE8YnI+CiDCoCDCoCDCoCDCoHNvbGlkIGJhc2lzIGZvciBkaXNjdXNzaW9uIGFuZCBwcmV2ZW50 aW5nIGVuZGxlc3MgcmVwZWF0aW5nPGJyPgogwqAgwqAgwqAgwqBsb29wcy4gVGhpcyBleGFtcGxl IGlzIHByb2JhYmx5IHdyb25nIGluIG1hbnkgd2F5cywgYnV0IGl0czxicj4KIMKgIMKgIMKgIMKg YmV0dGVyIHRoYW4gd2hhdCB3ZSBoYXZlIHB1YmxpY2x5IGF2YWlsYWJsZSBvbiBpbnRlcm9wIG5v dzxicj4KIMKgIMKgIMKgIMKgKGFsdGhvdWdoIE1vcmdhaW5lIGlzIHdvcmtpbmcgb24gc29tZXRo aW5nIGFsb25nIHRoZSBsaW5lcyBvZjxicj4KIMKgIMKgIMKgIMKgdGhlIHJlY2VudCBkaXNjdXNz aW9ucyBoZXJlKTxicj4KIMKgIMKgIMKgIMKgSSBob3BlIHRoaXMgZGlhZ3JhbSB3aWxsIGdpdmUg dXMgYSBiYXNlIGZvciBkaXNjdXNzaW9uLiBJPGJyPgogwqAgwqAgwqAgwqBjb3VsZCBoYXZlIGRv bmUgbXkgaG9tZXdvcmsgYmV0dGVyIGJ5IHJlc2VhcmNoaW5nIHRoZSBvbGQgT0dQPGJyPgogwqAg wqAgwqAgwqBzdHVmZiBpbiBtb3JlIGRlcHRoLCBhbmQgaSBwcm9iYWJseSDCoHdpbGwgZG8gc28g aW4gdGhlIGZ1dHVyZTxicj4KIMKgIMKgIMKgIMKgLCBidXQgZm9yIG5vdyBJIGp1c3QgdHJpZWQg dG8gZm9sbG93ZWQgdGhlIGdlbmVyYWwgcHJpbmNpcGxlczxicj4KIMKgIMKgIMKgIMKgYXMgZmFy IGFzIGkgdW5kZXJzdGFuZCB0aGVtLCB0byBzZWUgd2hhdCByZXNwb25zZSB0aGF0IHlpZWxkczxi cj4KIMKgIMKgIMKgIMKgZnJvbSB0aGUgZ3JvdXAuIEluIG90aGVyIHdvcmRzLEkgdHJ5IHRvIGxl dCB0aGUgZ3JvdXAgZWR1Y2F0ZTxicj4KIMKgIMKgIMKgIMKgbWUgOnA8YnI+Cjxicj4KIMKgIMKg IMKgIMKgTm90ZSB0aGF0IGluIMKgbXkgdmlldyBhbGwgc2VydmljZXMgYXJlIGVxdWFsLCBpbiBw cmluY2lwbGUgaXQ8YnI+CiDCoCDCoCDCoCDCoGRvZXMgbm90IG1hdHRlciBpbiB3aGF0ICZxdW90 O2RvbWFpbiZxdW90OyB0aGV5IHJ1biwgc2luY2UgdHJ1c3QgYW5kPGJyPgogwqAgwqAgwqAgwqBw b2xpY3kgYXJlIGZ1bGx5IGxvY2FsaXplZC4gSXQgaXMgaG93ZXZlciB2ZXJ5IHBvc3NpYmxlIHRv PGJyPgogwqAgwqAgwqAgwqBoYXZlIGludGVybmFsIHNob3J0Y3V0cyBpbiB0aGUgc2VydmljZXMg dG8gc3BlZWQgdXAgcHJvY2Vzc2luZy48YnI+CiDCoCDCoCDCoCDCoEluIHRoZSBleGFtcGxlIEkg b3B0ZWQgZm9yIGFuIGV4dGVybmFsIEFnZW50IHNlcnZpY2UsIGJ1dCBJPGJyPgogwqAgwqAgwqAg wqBjb3VsZCBhcyB3ZWxsIGhhdmUgaW5jb3Jwb3JhdGVkIHRoYXQgaW4gdGhlIHNldCBvZiBsb2Nh bDxicj4KIMKgIMKgIMKgIMKgc2VydmljZXMuIEFzIGluZGljYXRlZCBhYm92ZSBhbGwgc2Vydmlj ZXMgY291bGQgYWxzbyBiZSBydW4gYnk8YnI+CiDCoCDCoCDCoCDCoGRpZmZlcmVudCBvcmdhbmlz YXRpb25zLCB0cnVlIHRvIHdoYXQgVldSQVAgc3RhbmRzIGZvci4gSXRzPGJyPgogwqAgwqAgwqAg wqBhbGwgdXAgdG8gdGhlIGRlcGxveWVyLCBpbmNsdWRpbmcgYSB1c2VyIGF0IGhvbWUgd2hvIG1p Z2h0PGJyPgogwqAgwqAgwqAgwqB3YW50IHRvIHJ1biBhIGZ1bGwgd29ybGQgZm9yIGZhbWlseSBh bmQgZnJpZW5kcy4gVGhvc2UgZnJpZW5kczxicj4KIMKgIMKgIMKgIMKgbWlnaHQgdHJ5IHRvIHVz ZSB0aGF0IGFnZW50IHNlcnZpY2UgdG8gdmVudHVyZSBvdXQgaW4gdGhlPGJyPgogwqAgwqAgwqAg wqB2aXJ0dWFsIHVuaXZlcnNlLiBJIGVudmlzaW9uIHRoYXQgdGhlIGZpbmFsIGlkZW50aXR5IMKg cHJvdmlkZXI8YnI+CiDCoCDCoCDCoCDCoGlzIGV4dGVybmFsLCB1c2luZyBPcGVuSUQgYW5kIE9B dXQgwqBvciB3aGF0ZXZlciBvdGhlciDCoG1hZ2ljPGJyPgogwqAgwqAgwqAgwqB0aGF0IEkgZG8g bm90IHlldCBmdWxseSB1bmRlcnN0YW5kIGV4aXN0cyBvdXQgdGhlcmUuPGJyPgo8YnI+CiDCoCDC oCDCoCDCoFRoZSDCoGV4YW1wbGUgaGFzIDMgbWFpbiBwdXJwb3Nlczo8YnI+CiDCoCDCoCDCoCDC oC0gwqBQcm92aWRlIGEgcmVmZXJlbmNlIGZvciBkaXNjdXNzaW9uIC0gSWxsdXN0cmF0ZXMgdGhl IHVzZTxicj4KIMKgIMKgIMKgIMKgY2FzZSBvZiB0b3VyaXNtLCBhbmQgKnRydWUqIGludGVyb3Au PGJyPgogwqAgwqAgwqAgwqAtIElsbHVzdHJhdGUgY29uc2lzdGVuY3kgcHJvYmxlbXMgYWxvbmcg dGhlIGxpbmVzIGRpc2N1c3NlZDxicj4KIMKgIMKgIMKgIMKgIGhlcmUgaGlnaGVyIHVwIGluIHRo aXMgdHJlYWQsIGFzIHdlbGwgYXMgdGhlICZxdW90O3NsYXNoZG90JnF1b3Q7PGJyPgogwqAgwqAg wqAgwqBwcm9ibGVtIHRoYXQgTW9yZ2FpbmUgb3V0bGluZWQgc28gY2xlYXJseS48YnI+Cjxicj4K IMKgIMKgIMKgIMKgVGhlIG1lc3NhZ2UgZmxvdyBhc3N1bWVzIGFuIGF2YXRhciBhbHJlYWR5IHBy ZXNlbnQgaW4gc29tZTxicj4KIMKgIMKgIMKgIMKgcmVnaW9uLCAoYSBzbWFsbCBzY2FsZSBsb2Nh bCBob21lIHJlZ2lvbiBpbiB0aGlzIGNhc2UsIGJ1dDxicj4KIMKgIMKgIMKgIMKgdGhhdCBpcyBi eSBubyBtZWFucyBlc3NlbnRpYWwsIGl0IGNvdWxkIGJlIGEgYnVpbGQgaW4gcmVnaW9uPGJyPgog wqAgwqAgwqAgwqBpbiB0aGUgdmlld2VyIG9yIGEgYmlnIGNvbW1lcmNpYWwgcmVnaW9uKS4gVGhl IHVzZXIgaXM8YnI+CiDCoCDCoCDCoCDCoHByZXBhcmluZyBmb3IgYSB0cmlwIHRvIGltbWVyc2l2 ZSB3b3JsZCwgYW5kIGFmdGVyIHNvbWUgb3V0Zml0PGJyPgogwqAgwqAgwqAgwqBhZGp1c3RtZW50 cyBtb3ZlcyBvdmVyLjxicj4KIMKgIMKgIMKgIMKgRmluYWxseSBpIGFwb2xvZ2l6ZSBmb3IgZm9y IHRoZSBzaW1wbGlzdGljIG5vdGF0aW9uIHVzZWQgaGVyZS48YnI+CiDCoCDCoCDCoCDCoEkgc2lt cGx5IGFkZCB0aGUgbW9zdCByZWxldmFudCBwYXJhbWV0ZXJzIHBhc3NlZCBpbiBzcXVhcmU8YnI+ CiDCoCDCoCDCoCDCoGJyYWNrZXRzIHRvIGEga2V5d29yZCBzcGVjaWZ5aW5nIHRoZSBuYXR1cmUg b2YgdGhlIG1lc3NhZ2UuPGJyPgogwqAgwqAgwqAgwqBQbGVhc2UgaW1wcm92ZSBvbiB0aGF0IHdo ZXJlIG5lZWRlZC48YnI+Cjxicj4KIMKgIMKgIMKgIMKgU28gaGVyZSB3ZSBnbywgdGhlIGF2YXRh ciBpcyDCoHByZXBhcmUgZm9yIGEgdmlzaXQgdG88YnI+CiDCoCDCoCDCoCDCoCZxdW90O2ltbWVy c2l2ZSB3b3JsZCZxdW90Ozxicj4KIMKgIMKgIMKgIMKgMCkgwqBWaWV3ZXIsIGhlcmUgaXMgYW4g dXBkYXRlIG9mIHRoZSBzdGF0ZSBvZiB0aGUgd29ybGQgeW91cjxicj4KIMKgIMKgIMKgIMKgYWdl bnQgaXMgaW4sIHBsZWFzZSByZW5kZXIuPGJyPgogwqAgwqAgwqAgwqAxKSDCoEFnZW50IHNlcnZp Y2UsIEkgd2lsbCBnbyBpbiBteSBab2RpYWMgZHJlc3MgdGhhdCBpIGtlZXAgaW48YnI+CiDCoCDC oCDCoCDCoHRoZSDCoCZxdW90O0FtYXppbmcgYXNzZXRzJnF1b3Q7IHNlcnZpY2UuPGJyPgogwqAg wqAgwqAgwqAyKSDCoEFzc2V0IHNlcnZpY2UgQSwgcGxlYXNlIHNlbmQgYSBjYXAgZm9yIFosIGhl cmUgYXJlIG15PGJyPgogwqAgwqAgwqAgwqBjcmVkZW50aWFsczxicj4KIMKgIMKgIMKgIMKgMykg wqBZb3VyIGZpbmUsIGhlcmUgaXMgdGhlIGNhcDxicj4KIMKgIMKgIMKgIMKgNCkgwqBMb2NhbCBy ZWdpb24sIGNhbiB5b3UgcGxlYXNlIHB1dCB0aGlzIG9uIG15IGFnZW50LCBpPGJyPgogwqAgwqAg wqAgwqBpbmNsdWRlZCB0aGUgY2FwLjxicj4KIMKgIMKgIMKgIMKgNSkgwqBIZWxsbyBhc3NldCBz ZXJ2aWNlIEEsIGkgbmVlZCBaLCBoZXJlIGlzIHRoZSBjYXA8YnI+CiDCoCDCoCDCoCDCoDYpIMKg Q2FwIGlzIGdvb2QsIGRhdGEgY29taW5nIHVwLCBoYXZlIGZ1bi48YnI+CiDCoCDCoCDCoCDCoDcp IMKgQWdlbnQgc2VydmljZSwgeW91ciBhZ2VudCBpcyBub3cgd2VhcmluZyBaPGJyPgogwqAgwqAg wqAgwqA4KSDCoFZpZXdlciwgeW91ciBhdmF0YXIgaXMgbm93IHdlYXJpbmcgWjxicj4KIMKgIMKg IMKgIMKgIMKgIFVzZXI6IEhtbSwgYW1hemluZyBpbnZlbnRvcnkgaGFzIG5vdCBiZWVuICp0aGF0 KiBhbWF6aW5nPGJyPgogwqAgwqAgwqAgwqBsYXRlbHkuICYjMzk7bGwgbWFrZSBhIGJhY2t1cCwg anVzdCBpbiBjYXNlPGJyPgogwqAgwqAgwqAgwqA5KSDCoEhlbGxvIGFzc2V0IHNlcnZpY2UgQSwg cGxlYXNlIHNlbmQgbWUgYSBjYXAgZm9yIFosIGhlcmU8YnI+CiDCoCDCoCDCoCDCoGFyZSBteSBj cmVkZW50aWFsczxicj4KIMKgIMKgIMKgIMKgMTApIFlvdXIgZmluZSwgaGVyZSBpcyB0aGUgY2Fw PGJyPgogwqAgwqAgwqAgwqAxMSkgTG9jYWwgYXNzZXQgc3RvcmFnZSwgcGxlYXNlIHN0b3JlIFog Zm9yIG1lLCBoZXJlIGlzIHRoZTxicj4KIMKgIMKgIMKgIMKgY2FwIHRvIGdldCBpdDxicj4KIMKg IMKgIMKgIMKgMTIpIEhlbGxvIGFzc2V0IHNlcnZpY2UgQSwgaSB3YW50IFosIGhlcmUgaXMgdGhl IGNhcDxicj4KIMKgIMKgIMKgIMKgMTMpIENhcCBpcyBnb29kLCBkYXRhIGNvbWluZyB1cCwgaGF2 ZSBmdW4uPGJyPgogwqAgwqAgwqAgwqAxNCkgVmlld2VyLCBaIGlzIG5vdyBzdG9yZWQgZm9yIHlv dSDCoCDCoCBVc2VyOiBJIGFtIFJlYWR5ISw8YnI+CiDCoCDCoCDCoCDCoExldHMgdHJ5IHRvIGdl dCB0byBpbW1lcnNpdmUgd29ybGQhPGJyPgogwqAgwqAgwqAgwqAxNSkgSGVsbG8gaW1tZXJzaXZl IHdvcmxkLCBjYW4gaSBnZXQgaW4/IEhlcmUgYXJlIG15PGJyPgogwqAgwqAgwqAgwqBjcmVkZW50 aWFscywgYW5kIGEgbGlzdCBvZiBteSBzdHVmZi48YnI+CiDCoCDCoCDCoCDCoDE2KSBBc3NldCBz ZXJ2aWNlIEEsIHBsZWFzZSBzZW5kIG1lIGEgY2FwIGZvciBYLCBoZXJlIGFyZSBteTxicj4KIMKg IMKgIMKgIMKgY3JlZGVudGlhbHMgKEkgd2FudCB0aGlzIGNhcCBmb3IgY29uc2lzdGVuY3kpPGJy PgogwqAgwqAgwqAgwqAxNykgWW91ciBmaW5lLCBoZXJlIGlzIHRoZSBjYXA8YnI+CiDCoCDCoCDC oCDCoDE4KSBBc3NldCBzZXJ2aWNlIEIsIHBsZWFzZSBzZW5kIG1lIGEgY2FwIGZvciBZLCBoZXJl IGFyZSBteTxicj4KIMKgIMKgIMKgIMKgY3JlZGVudGlhbHMgKEkgd2FudCB0aGlzIGNhcCBmb3Ig Y29uc2lzdGVuY3kpPGJyPgogwqAgwqAgwqAgwqAxOSkgVmVyeSBzb3JyeSwgYnV0IHlvdXIgbm90 IG9uZSBvZiB1cywgeW91IGNhbiYjMzk7dCBoYXZlIFk8YnI+CiDCoCDCoCDCoCDCoDIwKSBBc3Nl dCBzZXJ2aWNlIEIsIHBsZWFzZSBzZW5kIG1lIGEgY2FwIGZvciBaLCBoZXJlIGFyZSBteTxicj4K IMKgIMKgIMKgIMKgY3JlZGVudGlhbHMgKEkgd2FudCBhIGNhcCBmb3IgY29uc2lzdGVuY3kpPGJy PgogwqAgwqAgwqAgwqBbUmVnaW9uIHNlcnZpY2U6IFRpbWVvdXQuLi4gYW1hemluZyBpbnZlbnRv cnkgbXVzdCBiZTxicj4KIMKgIMKgIMKgIMKgb3ZlcmxvYWRlZC4uIG9oIHdlbGwuLi4gXTxicj4K IMKgIMKgIMKgIMKgMjEpIEFnZW50IHNlcnZpY2UsIHlvdSB3YW50ZWQgdG8gc2VuZCBzb21lYm9k eSBvdmVyLCBoZXJlIGFyZTxicj4KIMKgIMKgIMKgIMKgeW91ciBwZXJtaXNzaW9ucy48YnI+CiDC oCDCoCDCoCDCoDIyKSBWaWV3ZXIsIHlvdSBhc2tlZCBmb3IgYSB0cmFuc2ZlciB0cnksIGhlcmUg YXJlIHlvdXIgcmVzdWx0czxicj4KIMKgIMKgIMKgIMKgIMKgIMKgVXNlciB0aGlua3M6IMKgQ3Jh cCEgQmlnIGFzc2V0IHNlcnZpY2UgZG9lcyBub3QgYWxsb3cgwqBtZTxicj4KIMKgIMKgIMKgIMKg dG8gdGFrZSBteSB5ZWxsb3cgc3RvY2tpbmdzISBBbmQgQW1hemluZyBhc3NldHMgwqBmYWlsZWQg dG88YnI+CiDCoCDCoCDCoCDCoGRlbGl2ZXIgbXkgem9kaWFjIGRyZXNzLiBBdCBsZWFzdCBpIG1h ZGUgYSBiYWNrdXAgb2YgdGhhdCBkcmVzcyE8YnI+CiDCoCDCoCDCoCDCoDIzKSAmIzM5O2xsIHRh a2UgdGhlIHllbGxvdyBzdG9ja2luZ3Mgb2ZmLi4uPGJyPgogwqAgwqAgwqAgwqAyNCkgLi4uIGRv bmUgKCYjMzk7bGwgdHJhc2ggdGhlbSBoZXJlIGFuZCBub3csIGZvcmV2ZXIsIHdobyBuZWVkczxi cj4KIMKgIMKgIMKgIMKgc3R1ZmYgeW91IGNhbiYjMzk7dCB1c2UhKTxicj4KIMKgIMKgIMKgIMKg MjUpIFRoZSB6b2RpYWMgZHJlc3Mgd2FzIG5vdCBkZWxpdmVyZWQgYnkgQmlnIGFzc2V0cyBzZXJ2 aWNlLDxicj4KIMKgIMKgIMKgIMKgYnV0IGkgaGF2ZSBhIGxvY2FsIGNvcHkhPGJyPgogwqAgwqAg wqAgwqAyNikgTG9jYWwgQXNzZXQgc2VydmljZSwgcGxlYXNlIHNlbmQgbWUgWiwgaGVyZSBhcmUg bXkgY3JlZGVudGlhbHM8YnI+CiDCoCDCoCDCoCDCoDI3KSBJIGRvbnQga25vdyB5b3UsIGJ1dCBJ ICYjMzk7bGwgdHJ1c3QgeW91LCBoZXJlIGlzIHRoZSBjYXAsIGJ1dDxicj4KIMKgIMKgIMKgIMKg eW91IGJldHRlciBzdG9yZSB0aGUgZGF0YSwgaXRzIHNpbmdsZSB1c2UsIGkgbmVlZCB0byBwcm90 ZWN0PGJyPgogwqAgwqAgwqAgwqBteXNlbGYuPGJyPgogwqAgwqAgwqAgwqAyOCkgTG9jYWwgcmVn aW9uLCBjYW4geW91IHBsZWFzZSBwdXQgdGhpcyBvbiBteSBhZ2VudCwgaTxicj4KIMKgIMKgIMKg IMKgaW5jbHVkZSB0aGUgY2FwLjxicj4KIMKgIMKgIMKgIMKgMjkpIExvY2FsIEFzc2V0IHNlcnZp Y2UsIGkgbmVlZCBaLCBoZXJlIGlzIHRoZSBjYXA8YnI+CiDCoCDCoCDCoCDCoDMwKSBDYXAgaXMg Z29vZCwgZGF0YSBjb21pbmcgdXAsIGhhdmUgZnVuLjxicj4KIMKgIMKgIMKgIMKgMzEpIENhcCB3 YXMgb25seSBnb29kIGZvciBvbmUgdGltZSwgSSBtYWRlIGEgY29weSwgYnV0IG15PGJyPgogwqAg wqAgwqAgwqBwb2xpY3kgaXMgdG8gb25seSBncmFudCB5b3UgZmFpciB1c2UgcmlnaHRzLCBhdCBh IGxhdGVyIHRpbWUgaTxicj4KIMKgIMKgIMKgIMKgbWlnaHQgZXZlbiB0ZWxsIHlvdSB0byByZXBs YWNlIHRoZSBkcmVzcy48YnI+CiDCoCDCoCDCoCDCoDMyKSBWaWV3ZXIsIHlvdSBjYW4gd2VhciBa IGZvciBub3csIGJ1dCB0aGUgYXNzZXQgc2VydmljZTxicj4KIMKgIMKgIMKgIMKgZ3JhbnRlZCBv bmx5IGZhaXIgdXNlLCBpIG1pZ2h0IGFzayB5b3UgdG8gcmVwbGFjZSB0aGUgZHJlc3MgYXQ8YnI+ CiDCoCDCoCDCoCDCoGEgbGF0ZXIgdGltZS48YnI+CiDCoCDCoCDCoCDCoDMzKSBSZWFkeSBhdCBs YXN0ISBPZmYgdG8gaW1tZXJzaXZlIHdvcmxkISwgSSBob3BlIGl0cyBub3QgdG88YnI+CiDCoCDC oCDCoCDCoGNyb3dkZWQgdGhlcmUgb3IgJiMzOTtsbCBsb29zZSBteSBkcmVzcy4uLjxicj4KIMKg IMKgIMKgIMKgMzQpIEhlbGxvIGltbWVyc2l2ZSB3b3JsZCwgaGVyZSBhcmUgbXkgY3JlZGVudGlh bHMsIGFuZCBhIGxpc3Q8YnI+CiDCoCDCoCDCoCDCoG9mIHN0dWZmIGkgd2FudCB0byBicmluZzxi cj4KIMKgIMKgIMKgIMKgMzUpIEhlbGxvIGFzc2V0IHNlcnZpY2UgQSwgcGxlYXNlIHNlbmQgbWUg YSBjYXAgZm9yIFgsIGhlcmU8YnI+CiDCoCDCoCDCoCDCoGFyZSBteSBjcmVkZW50aWFscyDCoCDC oCBbZGFybiwgSSBzaG91bGQgaGF2ZSBrZXB0IHRoYXQgY2FwIGZyb208YnI+CiDCoCDCoCDCoCDC oGxhc3QgdGltZS4uXTxicj4KIMKgIMKgIMKgIMKgMzYpIFlvdXIgZmluZSwgaGVyZSBpcyB0aGUg Y2FwLjxicj4KIMKgIMKgIMKgIMKgIMKgW1JlZ2lvbiBzZXJ2aWNlIGZpbmRzIGZhaXItdXNlIHdh cm5pbmcgb24gWiBhbmQgZGVjaWRlcyB0bzxicj4KIMKgIMKgIMKgIMKgbWFrZSBpdHMgb3duIGNv cHldPGJyPgogwqAgwqAgwqAgwqAzNykgSGVsbG8gTG9jYWwgcmVnaW9uLCBjYW4gaSBzdGlsbCBo YXZlIFo/IEhlcmUgaXMgdGhlIGNhcDxicj4KIMKgIMKgIMKgIMKgMzgpIENhcCBpcyBzdGlsbCBn b29kLCBkYXRhIGNvbWluZyB1cCwgaGF2ZSBmdW4uPGJyPgogwqAgwqAgwqAgwqAgwqBbUmVnaW9u IHNlcnZpY2Ugc3RvcmVzIGFzc2V0IGluIHByaXZhdGUgc3RvcmFnZSwgcHJvdmlkaW5nIGE8YnI+ CiDCoCDCoCDCoCDCoGNhcCB0byByZXBsYWNlIHRoZSBmYWlyIHVzZSBvbmVdPGJyPgogwqAgwqAg wqAgwqAzOSkgQWdlbnQgc2VydmljZSwgeW91IHdhbnRlZCB0byBzZW5kIHNvbWVib2R5IG92ZXIs IGhlcmUgYXJlPGJyPgogwqAgwqAgwqAgwqB5b3VyIHBlcm1pc3Npb25zICZhbXA7IGluZm8uPGJy PgogwqAgwqAgwqAgwqA0MCkgSGVsbG8gaW1tZXJzaXZlIHdvcmxkLCBqdXN0IMKgZ2V0IG1lIHRo ZXJlLCBhbmQgdXNlIHdoYXQ8YnI+CiDCoCDCoCDCoCDCoHlvdSBjYW48YnI+CiDCoCDCoCDCoCDC oDQxKSBQbGFjZW1lbnQgZG9uZSwgWiBpcyBjdXJyZW50bHkgYnVmZmVyZWQgYnkgdXMgYXMgd2Vs LCB5b3U8YnI+CiDCoCDCoCDCoCDCoG5lZWQgdG8gZ2V0IGRldGFpbHMgZm9yIFgsIGhhdmUgZnVu Ljxicj4KIMKgIMKgIMKgIMKgNDIpIFlvdSBhcmUgbm93IGluIGltbWVyc2l2ZSB3b3JsZCwgeW91 ciBkcmVzcyBpcyBidWZmZXJlZDxicj4KIMKgIMKgIMKgIMKgdGhlcmUgYXMgd2VsbCwgYnV0IHlv dSBuZWVkIHRvIGdldCBYITxicj4KIMKgIMKgIMKgIMKgNDMpIEhlbGxvIGFzc2V0IHNlcnZpY2Ug QSwgaSB3YW50IFgsIGhlcmUgaXMgdGhlIGNhcDxicj4KIMKgIMKgIMKgIMKgNDQpIENhcCBpcyBn b29kLCBkYXRhIGNvbWluZyB1cCwgaGF2ZSBmdW4uPGJyPgogwqAgwqAgwqAgwqA0NSkgVmlld2Vy LCBoZXJlIGlzIGFuIHVwZGF0ZSBvZiB0aGUgc3RhdGUgb2YgdGhlIHdvcmxkIHlvdXI8YnI+CiDC oCDCoCDCoCDCoGFnZW50IGlzIGluLCBwbGVhc2UgcmVuZGVyLjxicj4KPGJyPgogwqAgwqAgwqAg wqBBcyBmYXIgYXMgSSBjYW4gc2VlIHRoaXMgY29uZm9ybXMgZnVsbHkgdG8gb3VyIGNoYXJ0ZXIs IGFuZCBpPGJyPgogwqAgwqAgwqAgwqBob3BlIGl0IGlzIHBvc3NpYmxlIHRvIHVzZSBsYXJnZSBw b3J0aW9ucyBvZiB0aGUgZXhpc3RpbmcgY29kZTxicj4KIMKgIMKgIMKgIMKgYmFzZXMuIEhvd2V2 ZXIsIGFzIHNhaWQgYWJvdmUsIGkgZGlkIG5vdCByZWFsbHkgdHJ5IHRvIGNhcHR1cmU8YnI+CiDC oCDCoCDCoCDCoHRoZSBvbGQgdGhpbmtpbmcsIGFuZCBJIGFsc28gbWlnaHQgaGF2ZSBtaXNjb25j ZXB0aW9ucyBhYm91dDxicj4KIMKgIMKgIMKgIMKgdGhlIHdheSB0byBkbyB0aGVzZSB0aGluZ3Mg aW4gZ2VuZXJhbC48YnI+CiDCoCDCoCDCoCDCoExvb2tpbmcgZm9yd2FyZCB0byBjb25zdHJ1Y3Rp dmUgY29tbWVudHMuPGJyPgo8YnI+CiDCoCDCoCDCoCDCoC0tIFZhdWdobjxicj4KPGJyPgogwqAg wqAgwqAgwqBPbiBTdW4sIEFwciAzLCAyMDExIGF0IDg6MzggUE0sIFZhdWdobiBEZWx1Y2E8YnI+ CiDCoCDCoCDCoCDCoCZsdDs8YSBocmVmPSJtYWlsdG86dmF1Z2huLmRlbHVjYUBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj52YXVnaG4uZGVsdWNhQGdtYWlsLmNvbTwvYT4gJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86dmF1Z2huLmRlbHVjYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj52 YXVnaG4uZGVsdWNhQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPgogwqAgwqAgwqAgwqAmbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzp2YXVnaG4uZGVsdWNhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnZhdWdobi5kZWx1Y2FAZ21haWwuY29tPC9hPjxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86dmF1Z2huLmRlbHVjYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj52 YXVnaG4uZGVsdWNhQGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0OyZndDsgd3JvdGU6PGJyPgo8YnI+CiDC oCDCoCDCoCDCoCDCoCBUaGFua3MgZm9yIHRoZSBwb2ludGVycy4gwqBJIGhhdmUgYSDCoGJ1c3kg d2VlayBpbiBSTCBpbiBmcm9udCBvZjxicj4KIMKgIMKgIMKgIMKgIMKgIG1lLCBzbyBpIHdvbnQg aGF2ZSB0byBtdWNoIHRpbWUgdG8gcmVzcG9uZCB0aGUgbmV4dCBmZXcgZGF5cyw8YnI+CiDCoCDC oCDCoCDCoCDCoCBob3dldmVyLCBpIGludGVuZCB0byBzdGFydCBkb2luZyB0aGUgZm9sbG93aW5n IHRoaW5nczo8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIC0gUHJvZHVjZSBhIHZpc3VhbCB0aGF0 IHJlZmxlY3RzIG15IHRoaW5raW5nLCBpLmUuIGFuPGJyPgogwqAgwqAgwqAgwqBpbGx1c3RyYXRp b248YnI+CiDCoCDCoCDCoCDCoCDCoCBvZiBteSByZXNwb25zZSB0byBNb3JnYWluZSYjMzk7cyBp dGVtbGlzdCDCoGFib3ZlLjxicj4KIMKgIMKgIMKgIMKgIMKgIC0gUmVhZCB1cCBvbiB0aGUgb2xk ZXIgbm90ZXMsIGFzIHdlbGwgYXMgwqBtb3JlIHJlYWRpbmcgaW48YnI+CiDCoCDCoCDCoCDCoHRo ZSBsaXN0PGJyPgogwqAgwqAgwqAgwqAgwqAgYXJjaGl2ZTxicj4KIMKgIMKgIMKgIMKgIMKgIC0g VHJ5IHRvIG1ha2UgYSBzdW1tYXJ5IGZvciB0aGUgd2lraTxicj4KPGJyPgogwqAgwqAgwqAgwqAg wqAgUmVnYXJkaW5nIHRoZSB1c2Ugb2YgZG9tYWluLCBJIHRoaW5rIHNlcnZpY2VzIGFyZTxicj4K IMKgIMKgIMKgIMKgZXZlbnR1YWxseSB3aGF0PGJyPgogwqAgwqAgwqAgwqAgwqAgY291bnRzLCBi dXQgaXRzIGFsbCB0ZXJtaW5vbG9neS4gVGhlIHdheSBJIHJlYWQgdGhlIEFXRzxicj4KIMKgIMKg IMKgIMKgZGlhZ3JhbXM8YnI+CiDCoCDCoCDCoCDCoCDCoCBpcyB0aGF0IHRoZSBhZ2VudCBkb21h aW4gaXMgYWN0dWFsbHkgYSBjbHVzdGVyIG9mIHRpZ2h0bHk8YnI+CiDCoCDCoCDCoCDCoCDCoCBp bnRlZ3JhdGVkIHNlcnZpY2VzLiBXaGVuIHRoZSBmdW5jdGlvbmFsaXR5IG9mIGVhY2g8YnI+CiDC oCDCoCDCoCDCoHN1Yi1zZXJ2aWNlIGlzPGJyPgogwqAgwqAgwqAgwqAgwqAgZGVzY3JpYmVkIHBy b3Blcmx5IGFuZCB3aXRoIHVuaWZvcm0gaW50ZXJmYWNlcyB0aGUgZG9tYWluIHdpbGw8YnI+CiDC oCDCoCDCoCDCoCDCoCBzbG93bHkgZGlzc29sdmUuIEJ1dCBsZXQgbm90IGdldCBhaGVhZCBvZiBv dXQgc2VsZnMuIFdlPGJyPgogwqAgwqAgwqAgwqBzaG91bGQgcHV0PGJyPgogwqAgwqAgwqAgwqAg wqAgdXAgc29tZSBjbGVhciBkZXNjcmlwdGlvbnMgb24gdGhlIHdpa2kgZm9yIG91ciB2aWV3cyBv bjxicj4KIMKgIMKgIMKgIMKgdGhpcywgYW5kPGJyPgogwqAgwqAgwqAgwqAgwqAgKmFmdGVyKiB0 aGF0IHdlIGNhbiBkZWNpZGUgd2hhdCB3ZSBuZWVkIGFuZCB3aGF0IGNhbiBnby48YnI+Cjxicj4K IMKgIMKgIMKgIMKgIMKgIEl0cyBiZWVuIGEgdmVyeSB1c2VmdWwgYW5kIGlsbHVtaW5hdGluZyB3 ZWVrZW5kIGZvciBtZSwgYW5kPGJyPgogwqAgwqAgwqAgwqBpIGFtIGE8YnI+CiDCoCDCoCDCoCDC oCDCoCBsb3QgbW9yZSBvcHRpbWlzdGljIGFib3V0IHRoZSBmdXR1cmUgb2YgdndyYXAgdGhhbiB0 d288YnI+CiDCoCDCoCDCoCDCoHdlZWtzIGFnby48YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIC0t IFZhdWdobjxicj4KPGJyPgo8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIE9uIFN1biwgQXByIDMs IDIwMTEgYXQgNzoyMCBQTSwgRHpvbmF0YXMgU29sPGJyPgogwqAgwqAgwqAgwqAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmR6b25hdGFzQGdt YWlsLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZHpvbmF0YXNAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+ZHpvbmF0YXNAZ21haWwuY29tPC9hPiZndDs8YnI+CiDCoCDCoCDC oCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkem9uYXRhc0BnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5kem9uYXRhc0BnbWFpbC5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmR6b25hdGFzQGdtYWls LmNvbTwvYT4mZ3Q7Jmd0OyZndDsgd3JvdGU6PGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCBQcm9iYWJseSBlYXN5IGFzIHN1Z2dlc3RlZCBpbiBvdGhlciB0ZXJtcyBoZXJlIG9uIHRoaXM8 YnI+CiDCoCDCoCDCoCDCoGxpc3QsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgYXMgaG93IHRo ZSBjbGllbnQgY29udGFjdHMgdGhlIGFzc2V0IHNlcnZpY2VzIG5vdyBpbiB0aGU8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCByZWdpb25zLiBUaGUgbmV3ZXIgaXNzdWUgaXMgdG8gdW5pdGl6ZSB0 aGF0IGFzc2V0IHNlcnZpY2VzLjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNpbmNlIHRoZWly IGlzIHByb3ByaWV0YXJ5IChsZWdhY3kpIGNvZGUgdGhlbiB3ZSBjYW4mIzM5O3Q8YnI+CiDCoCDC oCDCoCDCoGV4cGVjdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoYXQgdG8gY2hhbmdlLCBh bmQgc29tZSBmb3JtIG9mIHByb3h5IGlzIG9mIG5lZWQuIFdoYXRldmVyPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgd29ya3MgYmVzdCwgSSB0cmllZCB0byBuYXJyb3cgaXQgZG93biB0byBzdWdn ZXN0aW9ucyBoZXJlLjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgRXZlbnR1YWxseSwg dGhlIGFnZW50IGRvbWFpbiBpcyBpZGVhbCB0byBoYW5kbGUgdGhlPGJyPgogwqAgwqAgwqAgwqBk aXJlY3Rpb248YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvZiB0aGUgYXNzZXQgc2VydmljZXMu IFRoaXMgY29uY2VwdCwgdW5mb3J0dW5hdGVseSwgZW5kZWQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCBzdXBwb3J0IGF3aGlsZSBhZ28gd2l0aCBjaGFuZ2VzIGluIExMLjxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIEFsc28gc2VlOyA8YSBocmVmPSJodHRwOi8vd2lraS5zZWNvbmRsaWZlLmNv bS93aWtpL0FnZW50X0RvbWFpbiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93aWtpLnNlY29uZGxp ZmUuY29tL3dpa2kvQWdlbnRfRG9tYWluPC9hPjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEFu ZDo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8YSBocmVmPSJodHRwOi8vd2lraS5zZWNvbmRs aWZlLmNvbS93aWtpL1VzZXI6RHpvbmF0YXNfU29sL0FXR19Bc3NldCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHA6Ly93aWtpLnNlY29uZGxpZmUuY29tL3dpa2kvVXNlcjpEem9uYXRhc19Tb2wvQVdHX0Fz c2V0PC9hPjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgICh3YXJuOiB1bnN0cnVjdHVyZWQgY29s bGFib3JhdGl2ZSBub3RlcywgZHVtcGVkIG9uIG1lIGFuZCBJPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgdHJpZWQgdG8gZml4KTxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgSSB0cmll ZCB0byBmaW5kIHByZXZpb3VzIHZpc3VhbHMuPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCBJJiMzOTtkIGltYWdpbmUgdGhlIGFnZW50IGRvbWFpbiBjb3VsZCBncm93IG91dCBvZiB1bml0 aXplZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHZlcnNpb25zIG9mIGFzc2V0IHNlcnZpY2Vz LiBEZXNwaXRlIHRoYXQsIEkgdGhpbmsgdGhhdDxicj4KIMKgIMKgIMKgIMKgY29uY2VwdDxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGhlbHBzIHZpZXcgd2hlcmUgd2Ugd2VyZSBhdCBpbiBkaXNj dXNzaW9uIGFuZCB3aGF0PGJyPgogwqAgwqAgwqAgwqBkaWRuJiMzOTt0IGhhcHBlbi48YnI+Cjxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFZhdWdobiBEZWx1Y2Egd3JvdGU6PGJyPgo8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBIae+/vUR6b25hdGFzPGJyPgo8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBDYW4geW91IGV4cGFuZCBvbiB0aGF0LCB3aGF0IHdvdWxkIGJl IG5lZWRlZCBmb3IgbGVnYWN5PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc3VwcG9y dCBpbiBWV0FQIHRlcm1z77+9Pyw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJZiBp IHdhbnQgdG8gcmVhZCB1cCBvbiBob3cgdGhl77+9YXNzZXQgc2VydmVyIG1heTxicj4KIMKgIMKg IMKgIMKgcHJveHkgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc2ltdWxhdG9y LCB3aGF0IHdvdWxkIHlvdSByZWNvbW1lbmQgbWUgdG8gcmVhZD88YnI+Cjxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIC0tIFZhdWdobjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgT24gU3VuLCBBcHIgMywgMjAxMSBhdCA1OjUxIEFNLCBEem9uYXRhcyBTb2w8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmR6b25hdGFz QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmR6b25hdGFzQGdtYWlsLmNvbTwvYT4gJmx0O21h aWx0bzo8YSBocmVmPSJtYWlsdG86ZHpvbmF0YXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ ZHpvbmF0YXNAZ21haWwuY29tPC9hPiZndDs8YnI+CiDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEg aHJlZj0ibWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmR6b25hdGFz QGdtYWlsLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZHpvbmF0YXNAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+ZHpvbmF0YXNAZ21haWwuY29tPC9hPiZndDsmZ3Q7PGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZHpv bmF0YXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHpvbmF0YXNAZ21haWwuY29tPC9hPjxi cj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZHpvbmF0YXNAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+ZHpvbmF0YXNAZ21haWwuY29tPC9hPiZndDsgJmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86ZHpvbmF0YXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHpv bmF0YXNAZ21haWwuY29tPC9hPjxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86ZHpvbmF0YXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHpvbmF0YXNAZ21haWwu Y29tPC9hPiZndDsmZ3Q7Jmd0OyZndDs8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHdyb3RlOjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBTb21l IHN0YXRlZCB0aGUgcHJveHktdG8tYXNzZXQtc2VydmVyIGlzIGJ1aWx0PGJyPgogwqAgwqAgwqAg wqBpbnRvIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNpbTs8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGhvd2V2ZXIsIGtlZXAgaW4gbWluZCBwb3NzaWJs ZSBsZWdhY3kgc3VwcG9ydDxicj4KIMKgIMKgIMKgIMKgd2hlcmUgdGhlPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHNlcnZlciBtYXkgcHJveHkgdGhlIHNpbXVsYXRvci48YnI+Cjxicj4KPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBEem9uYXRhcyBTb2wgd3JvdGU6PGJyPgo8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFNvbWVob3cgSSBmZWVsIHRoZSBi YXNpYyBhc3NldCBzZXJ2ZXIgYmVpbmc8YnI+CiDCoCDCoCDCoCDCoGFibGUgdG88YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBsb2dpbiBhbmQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoGRvd25sb2FkIGFzc2V0cyBpcyBub3cgcHJpb3JpdHksIHlldCBJ IGFsc288YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3b25kZXJlZCB0aGUgYmVzdDxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgd2F5IHRvIHBhdGNoIHRo aXMgaW50byB0aGUgY3VycmVudCBtb2RlIG9mPGJyPgogwqAgwqAgwqAgwqB2aWV3ZXJzLjxicj4K PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBNYXliZSBvZmZlciAo MSkgYnkgcHJveHkgKHNpbS1zaWRlKSBhbmQgKDIpPGJyPgogwqAgwqAgwqAgwqBieSBwYXRjaDxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKHZpZXdlci1zaWRlKSB0 aGF0IGVpdGhlciBvZiB0aGVzZSB0d28gYXJlPGJyPgogwqAgwqAgwqAgwqBvcHRpb25hbCBhbmQ8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG5laXRoZXIgYXJlIG1h bmRhdG9yeSBmb3Igbm93LiBUaG91Z2h0cz88YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgSXNyYWVsIEFsYW5pcyB3cm90ZTo8YnI+Cjxicj4KPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7IHdoZW4gZGVzaWdu aW5nIGZvciBzY2FsYWJpbGl0eSwgdGhlPGJyPgogwqAgwqAgwqAgwqBtb2RlbCB0bzxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGJlYXIgaW48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG1pbmQgaXMgLi4uPGJyPgo8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFdlbGwsIHRoZXJlIGFyZSBhIGxvdCBv ZiBkaWZmZXJlbnQgbW9kZWxzIHRvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAga2Vl cCBpbiBtaW5kLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgYW5kIG1hbnkgZGlmZmVyZW50IHVzZSBjYXNlcy4gT25lIHBhcnRpY3VsYXI8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB1c2UgY2FzZSB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKga2VlcCBpbiBtaW5kIGlzOiAmcXVvdDtVc2VyIGFj cXVpcmVzIG5ldzxicj4KIMKgIMKgIMKgIMKgb3V0Zml0LCBhbmQ8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCB3YW50cyB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgJiMzOTtzaG93IGl0IG9mZiYjMzk7IGluIGEgaGlnaGx5IHBvcHVsYXRl ZCByZWdpb24mcXVvdDsuPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCZndDsgQm90aCB3b3JsZHMgYW5kIGFzc2V0IHNlcnZpY2VzIG1heSBpbmNs dWRlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY29tbWVyY2lhbCw8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNvbW11bml0eSwgYW5kIHBl cnNvbmFsIHNlcnZpY2VzPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoFllcywgeWVzIGFuZCB5ZXMuIEkmIzM5O20gcGFydGljdWxhcmx5IGNvbmNl cm5lZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFib3V0IGhvdyB0aGU8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG1vZGVsIGFmZmVjdHMg dGhlIGFiaWxpdHkgdG8gaG9zdCBwZXJzb25hbDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGFzc2V0IHNlcnZpY2VzLjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAmZ3Q7IGEgcHJveHlpbmcgcmVnaW9uLCB3aGljaCB3b3VsZCBnZXQg c2xhbW1lZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZvciBldmVyeTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYXNzZXQgd29ybiBieSBl dmVyeSBhdmF0YXIgcHJlc2VudC48YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgR3JhbnRlZCB0aGUgY29sbGVjdGlvbiBvZiBzZXJ2aWNlcyB0aGF0 IGFyZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHByb3ZpZGVkIGJ5PGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGUgcmVnaW9uIG5lZWQg dG8gYmUgc2NhbGVkIHRvIG1lZXQgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg ZGVtYW5kcyBvZiB0aGF0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqByZWdpb24uIFRoYXQmIzM5O3MgYWxsIHBhcnQgb2YgY2FwYWNpdHk8YnI+CiDCoCDC oCDCoCDCoHBsYW5uaW5nLjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAmZ3Q7IHJlZ2lvbnMgcnVuIG1hbnkgZGlmZmVyZW50PGJyPgogwqAgwqAg wqAgwqBDUFUtaW50ZW5zaXZlIHRhc2tzLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgaW5jbHVkaW5nIHBoeXNpY3Mgc2ltdWxhdGlvbiBhbmQgc2VydmVy LXNpZGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzY3JpcHRpbmcsPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhbmQgYWJzb2x1dGVseSBj YW5ub3QgYWZmb3JkIHRvIHNlcnZlPGJyPgogwqAgwqAgwqAgwqBhc3NldHMgdG9vPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBXZWxsLi4uIHdobyBzYWlk IHRoZSBzYW1lIENQVSYjMzk7cyBoYXZlIHRvIGRvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgcHJveHlpbmcsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBwaHlzaWNzIHNpbXVsYXRpb24gYW5kIHNlcnZlci1zaWRlPGJyPgogwqAgwqAgwqAg wqBzY3JpcHRpbmc/IEFzc2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBwcm94eWluZyBpcyBhIGRpZmZlcmVudCBzZXJ2aWNlIHRoYW4gcGh5c2ljczxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNpbXVsYXRpb248YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGFuZCBjYW4gYmUgb24gc2VwYXJhdGUg aGFyZHdhcmUsIGNvdWxkPGJyPgogwqAgwqAgwqAgwqBtYWtlIHVzZSBvZjxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZ2VvZ3JhcGhpY2FsbHkgZGlzdHJp YnV0ZWQgY2FjaGluZywgYW5kPGJyPgogwqAgwqAgwqAgwqBpbiBjZXJ0YWluPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkZXBsb3ltZW50IHBhdHRlcm5z LCB0aGUgc2FtZSBjYWNoaW5nPGJyPgogwqAgwqAgwqAgwqBzZXJ2aWNlczxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGNvdWxkIGJlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBzaGFyZWQgYnkgZGlmZmVyZW50IHJlZ2lvbnMuIChTZXJ2ZXIt c2lkZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNjcmlwdGluZyBpcyBhPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkaXNjdXNzaW9uIGZv ciBhbm90aGVyIGRheSkuPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCZndDsgVGhpcyBpcyB3aHkgd2UgaGF2ZSB0byBnbyBwYXJhbGxlbC4uLjxi cj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBUb3Rh bGx5IGFncmVlLCBhbmQgYSBwcm94eWluZyBtb2RlbDxicj4KIMKgIMKgIMKgIMKgY291bGQgYW5k PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc2hvdWxkIGFsc288YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRha2UgYWR2YW50YWdlIG9mIHBh cmFsbGVsaXNtLjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAmZ3Q7IEkgdGhpbmsgeW91JiMzOTtyZSB3cm9uZyB0aGF0IGl0IGhhcyB0bzxicj4K IMKgIMKgIMKgIMKgY29zdCBtdWNoPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbW9u ZXkuID92cz88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCZndDsgSXQgY29zdHMgbW9uZXkgdG8gaG9zdCBhIGhpZ2g8YnI+CiDCoCDCoCDCoCDCoHBlcmZv cm1hbmNlIGFuZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNjYWxhYmxlPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhc3NldCBzZXJ2aWNl IGFuZCBhIGhpZ2ggYmFuZHdpZHRoPGJyPgogwqAgwqAgwqAgwqBuZXR3b3JrIHRvPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaGFuZGxlIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdHJhZmZpYy4g77+9QSAqbG90KiBvZiBtb25leS48 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEkgdGhpbmsg d2hhdCB5b3UmIzM5O3JlIHNheWluZyBpczogJnF1b3Q7SXQgY29zdHM8YnI+CiDCoCDCoCDCoCDC oGEgbG90PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb2YgbW9uZXkgdG88YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJ1aWxkIGEgc2NhbGFi bGUgYXNzZXQgc2VydmljZSwgYnV0IGlmPGJyPgogwqAgwqAgwqAgwqBhc3NldHM8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhcmUgc3ByZWFkPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aHJvdWdob3V0IHRoZSBpbnRlcm5ldCB0aGV5IGRv biYjMzk7dCBoYXZlPGJyPgogwqAgwqAgwqAgwqB0byBiZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHNjYWxhYmxlLiZxdW90Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgQnV0IHRoYXQmIzM5O3Mgbm90IHF1aXRlIHJpZ2h0LiBZb3UmIzM5 O3JlPGJyPgogwqAgwqAgwqAgwqBvcGVuaW5nIHVwPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgZXZlcnkgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHNlcnZlciB0byB0aGUgVlcgZXF1aXZhbGVudCBvZiBiZWluZzxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNsYXNoZG90dGVkLCBzbyBhcmU8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHlvdSBzdXJlIHlvdSYjMzk7cmUgbm90 IGZvcmNpbmcgKmV2ZXJ5KiBhc3NldDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNl cnZpY2UgdG8gYmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHNjYWxhYmxlIGFuZCBoYW5kbGUgYSBsb3Qgb2YgYmFuZHdpdGggYW5kPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgbmV0d29yayB0cmFmZmljPzxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgSXQmIzM5O3MgdGhlIGV4YWN0IG9wcG9zaXRl IG9mIHlvdXI8YnI+CiDCoCDCoCDCoCDCoGludGVudGlvbiwgYnV0PGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgSSB0aGluazxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgdGhhdCYjMzk7cyB0aGUgcmVzdWx0LCBhbGwgdGhlIHNhbWUuPGJyPgo8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFRoaXMgcGFy dGljdWxhciBkZXNpZ24gZGVjaXNpb24gaGFzIGEgYmlnPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgZWZmZWN0IG9uIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgZWNvbm9taWNzIG9mIHRoZSBWVyBpbmZyYXN0cnVjdHVyZS4gSSYjMzk7 ZDxicj4KIMKgIMKgIMKgIMKgcmF0aGVyIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgZWNvbm9taWNzIHRvIHdvcmsgb3V0IHN1Y2ggdGhhdCBhIHJl Z2lvbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHByb3ZpZGVyIHdobzxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgd2lzaGVzIHRvIGJ1aWxk IGEgcmVnaW9uIHRoYXQgc3VwcG9ydHMgYTxicj4KIMKgIMKgIMKgIMKgc21hbGw8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwb3B1bGF0aW9uLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgY2FuIGRvIHNvIGVjb25vbWljYWxseS4gQSByZWdp b24gdGhhdDxicj4KIMKgIMKgIMKgIMKgd2FudHMgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBob3N0IGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCpsYXJnZSogcG9wdWxhdGlvbiBoYXMgdG8gYmVhciB0aGF0IGNvc3Qgb2Y8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwcm92aWRpbmcgdGhhdDxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2NhbGFibGUgYXNzZXQgc2VydmljZS48 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEkgd2FudCB0 aGUgZWNvbm9taWNzIG9mIGhvc3RpbmcgYSBzbWFsbDxicj4KIMKgIMKgIMKgIMKgYXNzZXQ8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzZXJ2aWNlIHRvPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBiZSBhIG5vbi1pc3N1ZSAoYXMgdG8gYmVz dCBwcm9tb3RlPGJyPgogwqAgwqAgwqAgwqBjcmVhdGlvbiBhbmQ8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNyZWF0aXZpdHkpLiBDcmVhdGluZyBhIGhp Z2ggYmFyIHRvIHByb3ZpZGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhc3NldCBz ZXJ2aWNlczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg d2lsbCBtZWFuIHRoYXQgc2VydmljZSB3aWxsIGNvc3QgbW9uZXk8YnI+CiDCoCDCoCDCoCDCoGFu ZCBwZW9wbGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oHNob3VsZG4mIzM5O3QgaGF2ZSB0byBwYXkgbW9uZXkganVzdCB0bzxicj4KIMKgIMKgIMKgIMKg Y3JlYXRlIG9yPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb3duIFZXPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBvYmplY3RzIChJJiMzOTtt IHVzaW5nICYjMzk7b3duJiMzOTsgaGVyZSB0byByZWZlciB0bzxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIG1haW50YWluaW5nPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqB0aGVpciBleGlzdGVuY2UsIEkmIzM5O20gbm90IHRyeWluZyB0byBt YWtlIGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCYj Mzk7bGVmdGlzdCYjMzk7LyYjMzk7Y29tbXVuaXN0JiMzOTsgc3RhdGVtZW50IGFib3V0PGJyPgog wqAgwqAgwqAgwqBvd25lcnNoaXAgOyk8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgLSBJenp5PGJyPgo8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgT24gQXByIDIsIDIwMTEsIGF0IDM6NTggUE0s IE1vcmdhaW5lIHdyb3RlOjxicj4KPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBJenp5LCB3aGVuIGRlc2lnbmluZyBmb3I8YnI+CiDCoCDCoCDC oCDCoHNjYWxhYmlsaXR5LCB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBtb2Rl bCB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgYmVhciBpbiBtaW5kIGlzIHRoYXQgb2Ygc2Vhc29uZWQ8YnI+CiDCoCDCoCDCoCDCoHZpcnR1 YWwgd29ybGQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoHRyYXZlbGVycyB3aG9zZSBpbnZlbnRvcmllcyBjb250YWluPGJyPgogwqAgwqAgwqAg wqBhc3NldHM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmcm9tIG1hbnk8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGRpZmZlcmVu dCB3b3JsZHMsIHRob3NlIGFzc2V0cyBiZWluZzxicj4KIMKgIMKgIMKgIMKgc2VydmVkPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYnkgbWFueTxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZGlmZmVyZW50IGFzc2V0IHNlcnZpY2Vz LiDvv71Cb3RoPGJyPgogwqAgwqAgwqAgwqB3b3JsZHMgYW5kPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoHNlcnZpY2VzIG1heSBpbmNsdWRlIGNvbW1lcmNpYWwsPGJyPgogwqAg wqAgwqAgwqBjb21tdW5pdHksIGFuZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgcGVyc29uYWwgc2VydmljZXMsIGFuZCBhcyB0aGUgbWV0YXZl cnNlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZ3Jvd3MsIHRoYXQ8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNldCBpcyBoaWdo bHkgbGlrZWx5IHRvIGJlY29tZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHByb2dy ZXNzaXZlbHkgbGVzczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgY2x1c3RlcmVkIGFuZCBtb3JlIGRpdmVyc2UuPGJyPgo8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFdoZW4gdGhvc2Ugc2Vh c29uZWQgdHJhdmVsZXJzIGNsaWNrPGJyPgogwqAgwqAgwqAgwqBvbiBhbjxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGFkdmVydGlzZWQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFZXIGxpbmsgYW5kIHBlcmZvcm0gYW4gaW50ZXIt d29ybGQ8YnI+CiDCoCDCoCDCoCDCoHRlbGVwb3J0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgdG8gb25lPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBwYXJ0aWN1bGFyIHdvcmxkJiMzOTtzIHJlZ2lvbiB0byBzaGFyZSBhbjxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGV4cGVyaWVuY2UsPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGVpciAmcXVvdDt3b3JuJnF1 b3Q7IGFzc2V0cyAodGhlIG9ubHkgb25lcyBvZjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGludGVyZXN0IHRvIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgcmVnaW9uKSB3aWxsIGNvbnRhaW4gcmVmZXJlbmNlcyB0byBhc3Nl dDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNlcnZpY2VzPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzcHJlYWQgd2lkZWx5IGFj cm9zcyB0aGUgSW50ZXJuZXQuIO+/vVRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGZldGNoZXMgYnkgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqB0cmF2ZWxlcnMmIzM5OyBjbGllbnRzIG9jY3VyIG92ZXIgbWFueTxicj4K IMKgIMKgIMKgIMKgcGFyYWxsZWw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwYXRo cyBmcm9tPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqBjbGllbnRzIHRvIGFzc2V0IHNlcnZpY2VzLCBzbyBvbmUgY2FuPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgcmVhc29uYWJseTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZXhwZWN0IHJlZHVjZWQgbmV0d29yayBjb250ZW50 aW9uIGFuZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlZHVjZWQgYXNzZXQ8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNlcnZl ciBsb2FkaW5nIGJlY2F1c2UgdGhleSBhcmUgYm90aDxicj4KIMKgIMKgIMKgIMKgc3ByZWFkPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb3V0IG92ZXI8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGhvd2V2ZXIgbWFueSBhc3NldCBz ZXJ2aWNlcyBhcmUgYmVpbmc8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZWZlcmVu Y2VkIGJ5PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqB0aGUgb3ZlcmFsbCBzZXQgb2YgYXNzZXRzIGluIHRoZSByZWdpb24uPGJyPgo8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFRoaXMgaXMg dmVyeSBkaWZmZXJlbnQgdG8gdGhlIGNhc2Ugb2YgYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHByb3h5aW5nPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqByZWdpb24sIHdoaWNoIHdvdWxkIGdldCBzbGFtbWVkIGZvcjxicj4KIMKg IMKgIMKgIMKgZXZlcnk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhc3NldCB3b3Ju PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBi eSBldmVyeSBhdmF0YXIgcHJlc2VudC4g77+9SW4gb3VyIGN1cnJlbnQ8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBhcmNoaXRlY3R1cmUsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqByZWdpb25zIHJ1biBtYW55IGRpZmZlcmVudDxi cj4KIMKgIMKgIMKgIMKgQ1BVLWludGVuc2l2ZSB0YXNrcyw8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGluY2x1ZGluZyBwaHlzaWNzIHNpbXVs YXRpb24gYW5kPGJyPgogwqAgwqAgwqAgwqBzZXJ2ZXItc2lkZTxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2NyaXB0aW5nLCBhbmQgYWJzb2x1 dGVseSBjYW5ub3Q8YnI+CiDCoCDCoCDCoCDCoGFmZm9yZCB0bzxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHNlcnZlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqBhc3NldHMgdG9vIHVubGVzcyB5b3VyIHNjYWxhYmlsaXR5PGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVxdWlyZW1lbnRzIGFyZTxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdmVyeSBsb3cgaW5kZWVk LCBpZS4ganVzdCBhIGZldyBkb3plbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGF2 YXRhcnMgb2Y8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoHRvZGF5JiMzOTtzIGtpbmQuIO+/vVdlJiMzOTt2ZSBoaXQgdGhlIGNlaWxpbmc8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhbHJlYWR5IG9uIHJlZ2lvbjxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2NhbGFiaWxpdHkg ZG9uZSB0aGF0IHdheS4g77+9VGhlcmUgaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBub3doZXJlIHRvIGdvIGluPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqB0aGF0IGRpcmVjdGlvbiBhdCBhbGwgYmV5b25kPGJyPgogwqAgwqAg wqAgwqBpbXByb3ZpbmcgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY29kZSBs aWtlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqBJbnRlbCBkZW1vbnN0cmF0ZWQsIGFuZCB0aGF0IHdvcmsgaXM8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBzdWJqZWN0IHRvIGEgbGF3PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBvZiBkaW1pbmlzaGluZyByZXR1cm5zLjxicj4K PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBU aGlzIGlzIHdoeSB3ZSBoYXZlIHRvIGdvIHBhcmFsbGVsLDxicj4KIMKgIMKgIMKgIMKgYW5kIEk8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGluayB5b3UmIzM5O3JlPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB3cm9uZyB0aGF0 IGl0IGhhcyB0byBjb3N0IG11Y2g8YnI+CiDCoCDCoCDCoCDCoG1vbmV5LiDvv71Bczxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdlIHNwcmVhZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdGhlIGxvYWQgYWNyb3NzIG1vcmUgYW5k IG1vcmUgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzZXJ2aWNlcywgd2Ug YXJlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqBzaW1wbHkgYmV0dGVyIHV0aWxpemluZyBhbGwgdGhlPGJyPgogwqAgwqAgwqAgwqBoYXJkd2Fy ZSB0aGF0JiMzOTtzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBhbHJlYWR5IG91dCB0aGVyZSBvbiB0aGUgSW50ZXJuZXQsPGJyPgogwqAgwqAg wqAgwqBhdCBsZWFzdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGluIHJlc3BlY3Q8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG9m IGNvbW11bml0eSBhbmQgcHJpdmF0ZSByZXNvdXJjZXMuIO+/vUJ1dDxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIGFkZCB0byB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNvbW11bml0eSBhbmQgcHJpdmF0ZSByZXNvdXJjZXMg dGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY29tbWVyY2lhbCBhc3NldDxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc2Vydmlj ZXMgdGhhdCBhcmUgbGlrZWx5IHRvIGFwcGVhciB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGV4cGxvaXQgdGhpczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgb3Bwb3J0dW5pdHksIGFuZCBub3Qgb25seSB3aWxsIHRoZTxicj4K IMKgIMKgIMKgIMKgbnVtYmVyPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb2YgYXNz ZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oHNlcnZpY2VzIGxlYXAsIGJ1dCB0aGUgcG93ZXIgb2YgZWFjaCBvbmU8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB3aWxsIHJvY2tldDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdG9vLCBiZWNhdXNlLCBhZnRlciBhbGwsIHRoZXNl PGJyPgogwqAgwqAgwqAgwqBidXNpbmVzc2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgd2lsbCBiZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgaGVhdmlseSBvcHRpbWl6ZWQgZm9yIHRoZSBqb2IuPGJyPgo8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEFzIHRvIHdoeSBhIHdv cmxkIHdvdWxkIHdhbnQgY2xpZW50czxicj4KIMKgIMKgIMKgIMKgdG8gYWNjZXNzPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBleHRlcm5hbCBh c3NldCBzZXJ2aWNlcyBpbnN0ZWFkIG9mPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg cHJvdmlkaW5nIGl0cyBvd248YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoGltcGxlbWVudGF0aW9uLCB0aGF0JiMzOTtzIGFuIGVhc3kgcXVlc3Rp b24uPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9SXQgY29zdHM8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG1vbmV5IHRvIGhv c3QgYSBoaWdoIHBlcmZvcm1hbmNlIGFuZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHNjYWxhYmxlIGFzc2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqBzZXJ2aWNlIGFuZCBhIGhpZ2ggYmFuZHdpZHRoIG5ldHdvcmsgdG88YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBoYW5kbGUgdGhlPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0cmFmZmljLiDvv71BICpsb3Qq IG9mIG1vbmV5LiDvv71Jbjxicj4KIMKgIMKgIMKgIMKgY29udHJhc3QsPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgaXQgY29zdHMgYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgd29ybGQgbm90aGluZyB0byBsZXQgb3RoZXJzIHNl cnZlPGJyPgogwqAgwqAgwqAgwqB0aGUgYXNzZXRzIHRvPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBjbGllbnRzLiDvv71BbmQgdGhhdCBtYXR0 ZXJzIHRvIHRoZTxicj4KIMKgIMKgIMKgIMKgYm90dG9tIGxpbmUuPGJyPgo8YnI+Cjxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgTW9yZ2FpbmUu PGJyPgo8YnI+Cjxicj4KPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoD09PT09PT09PT09PT09PT09PT09PT08YnI+Cjxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgT24gU2F0LCBBcHIg MiwgMjAxMSBhdCA3OjA1IFBNLCBJenp5PGJyPgogwqAgwqAgwqAgwqBBbGFuaXM8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZsdDs8YSBocmVm PSJtYWlsdG86aXp6eWFsYW5pc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5penp5YWxhbmlz QGdtYWlsLmNvbTwvYT48YnI+CiDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRv Oml6enlhbGFuaXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+aXp6eWFsYW5pc0BnbWFpbC5j b208L2E+Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEg aHJlZj0ibWFpbHRvOml6enlhbGFuaXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+aXp6eWFs YW5pc0BnbWFpbC5jb208L2E+PGJyPgogwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzppenp5YWxhbmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPml6enlhbGFuaXNAZ21h aWwuY29tPC9hPiZndDsmZ3Q7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOml6enlhbGFuaXNA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+aXp6eWFsYW5pc0BnbWFpbC5jb208L2E+PGJyPgog wqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzppenp5YWxhbmlzQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPml6enlhbGFuaXNAZ21haWwuY29tPC9hPiZndDs8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzppenp5YWxh bmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPml6enlhbGFuaXNAZ21haWwuY29tPC9hPjxi cj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86aXp6eWFsYW5pc0BnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5penp5YWxhbmlzQGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0OyZn dDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOml6enlhbGFuaXNAZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+aXp6eWFsYW5pc0BnbWFpbC5jb208L2E+PGJyPgogwqAgwqAgwqAgwqAmbHQ7bWFp bHRvOjxhIGhyZWY9Im1haWx0bzppenp5YWxhbmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pml6enlhbGFuaXNAZ21haWwuY29tPC9hPiZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzppenp5YWxhbmlzQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPml6enlhbGFuaXNAZ21haWwuY29tPC9hPjxicj4KIMKgIMKgIMKgIMKgJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86aXp6eWFsYW5pc0BnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5penp5YWxhbmlzQGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0Ozxicj4KPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhy ZWY9Im1haWx0bzppenp5YWxhbmlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPml6enlhbGFu aXNAZ21haWwuY29tPC9hPjxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86aXp6eWFsYW5pc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5penp5YWxhbmlzQGdtYWls LmNvbTwvYT4mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86aXp6eWFsYW5pc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5penp5 YWxhbmlzQGdtYWlsLmNvbTwvYT48YnI+CiDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOml6enlhbGFuaXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+aXp6eWFsYW5pc0Bn bWFpbC5jb208L2E+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd3JvdGU6PGJyPgo8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IEFz IGFsd2F5cyB0aG91Z2gsIGl0JiMzOTtzIGEgdHJhZGUtb2ZmLDxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHNpbmNlIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgcHJveGllZCBkZXNpZ248YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71oYXMgdmVyeSBwb29yIHNj YWxhYmlsaXR5PGJyPgogwqAgwqAgwqAgwqBjb21wYXJlZCB0byB0aGU8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGRpc3RyaWJ1dGVkIG9uZS48 YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKg77+9IO+/vUkgZG9uJiMzOTt0IGFncmVlIHdpdGggdGhhdC4uLiBJZiBhIHVzZXI8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBlbnRlcnMgYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaGlnaGx5IHBvcHVsYXRlZDxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXJl Z2lvbiw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv71ldmVyeSBvdGhlciBjbGllbnQgaXMgZ29pbmcgdG8gKGNvdWxkPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYW5kIHNob3VsZCBiZTxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdHJ5aW5nIHRvKTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWhpdCB0 aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv71hc3NldCBzZXJ2ZXIocykgZm9yIHRoZSBhc3NldHM8YnI+CiDCoCDCoCDCoCDCoHRo YXQgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdXNlciBpczxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgd2VhcmluZyAoYXNz dW1pbmc8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv710aGV5JiMzOTtyZSBub3QgY2FjaGVkIGxvY2FsbHkpLiDvv71FdmVyeTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFzc2V0IHNlcnZlcjxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaGFzIHRvIGJlIHNjYWxlZCB1 cDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vXRvIHRoZSBwb2ludCB0aGF0IGl0IGNhbiBoYW5kbGUgdGhhdDxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGxvYWQgZnJvbSBhbGw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG92ZXIuLi48YnI+Cjxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vUlmIEkmIzM5 O20gaG9zdGluZyBhIHJlZ2lvbiB0aGF0PGJyPgogwqAgwqAgwqAgwqBzdXBwb3J0cyAxMHMgb2Y8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRo b3VzYW5kcyBvZjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vXNpbXVsdGFuZW91czxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXVzZXJzICh0aGlua2luZyBvZiB0aGUg ZnV0dXJlKSwgSTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFscmVhZHkgaGF2ZSB0 bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg c2NhbGUgdG8gbWVldCB0aGF0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9ZGVtYW5kLiBJZiB0aGUgcmVnaW9uIGlzIHByb3h5aW5n IHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFzc2V0cywgdGhlbiw8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHllcyB0aGU8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv71yZWdpb24gaGFzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqDvv70g77+9dG8gYmUgc2NhbGVkIHRvIG1lZXQgdGhhdCBhc3NldDxicj4K IMKgIMKgIMKgIMKgZGVtYW5kPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdG9vLCBi dXQgaXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoGFscmVhZHkgaGFzIHRvIGJlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c2NhbGVkIHRvIG1lZXQgb3RoZXIgZGVtYW5kcyBv Zjxicj4KIMKgIMKgIMKgIMKgYmVpbmcgYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHJlZ2lvbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgc2VydmVyLi4uIGFuZCB3aHkgaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71zY2FsaW5nIHRob3NlIGFzc2V0IHByb3h5 PGJyPgogwqAgwqAgwqAgwqBzZXJ2aWNlcyBoYXJkPzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIO+/vUl0JiMzOTtzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqBnb2luZyB0byBjb3N0ICQsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9YnV0IGlzPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9bm90IHRl Y2huaWNhbGx5IGNoYWxsZW5naW5nLiBTbywgaWYgSTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHdhbnQgdG8gaG9zdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgYSByZWdpb24gbGlrZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXRoYXQuLi4gc3VyZSBpdCB3aWxs IGNvc3QgbWUsIGJ1dCB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzaW11bGF0 aW9uPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqB3aWxsIGJlIGNvbnNpc3RlbnQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71hbmQgdXNlcnMgd2lsbCBiZSBhYmxlIHRvIHBhcnRp Y2lwYXRlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZXF1YWxseSw8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHJlZ2FyZGxlc3Mg b2YgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Y2FwYWJpbGl0aWVzIG9mIHRoZWlyIGluZGl2aWR1YWw8YnI+CiDCoCDCoCDC oCDCoGFzc2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc2VydmljZXMuPGJyPgo8 YnI+Cjxicj4KPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv71PbiBGcmksIEFwciAxLCAyMDExIGF0IDExOjU1IFBNLDxicj4K IMKgIMKgIMKgIMKgTW9yZ2FpbmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mbHQ7PGEgaHJlZj0ibWFpbHRvOm1vcmdhaW5lLmRp bm92YUBnb29nbGVtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vcmdhaW5lLmRpbm92YUBnb29n bGVtYWlsLmNvbTwvYT48YnI+CiDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRv Om1vcmdhaW5lLmRpbm92YUBnb29nbGVtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vcmdhaW5l LmRpbm92YUBnb29nbGVtYWlsLmNvbTwvYT4mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tPC9h Pjxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9yZ2FpbmUuZGlu b3ZhQGdvb2dsZW1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9yZ2FpbmUuZGlub3ZhQGdvb2ds ZW1haWwuY29tPC9hPiZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9yZ2FpbmUu ZGlub3ZhQGdvb2dsZW1haWwuY29tPC9hPjxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tPC9hPiZndDs8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb3JnYWluZS5kaW5v dmFAZ29vZ2xlbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tb3JnYWluZS5kaW5vdmFAZ29vZ2xl bWFpbC5jb208L2E+PGJyPgogwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpt b3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tb3JnYWluZS5k aW5vdmFAZ29vZ2xlbWFpbC5jb208L2E+Jmd0OyZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv708YnI+CiDCoCDCoCDCoCDCoO+/ vSZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vcmdhaW5lLmRpbm92YUBnb29nbGVtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1vcmdhaW5lLmRpbm92YUBnb29nbGVtYWlsLmNvbTwvYT48YnI+ CiDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vcmdhaW5lLmRpbm92YUBn b29nbGVtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vcmdhaW5lLmRpbm92YUBnb29nbGVtYWls LmNvbTwvYT4mZ3Q7PGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFp bHRvOjxhIGhyZWY9Im1haWx0bzptb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5tb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb208L2E+PGJyPgogwqAgwqAg wqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5tb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb208L2E+ Jmd0OyZndDs8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vcmdhaW5l LmRpbm92YUBnb29nbGVtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vcmdhaW5lLmRpbm92YUBn b29nbGVtYWlsLmNvbTwvYT48YnI+CiDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFp bHRvOm1vcmdhaW5lLmRpbm92YUBnb29nbGVtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vcmdh aW5lLmRpbm92YUBnb29nbGVtYWlsLmNvbTwvYT4mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9yZ2FpbmUuZGlub3ZhQGdvb2ds ZW1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29t PC9hPjxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9yZ2FpbmUu ZGlub3ZhQGdvb2dsZW1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9yZ2FpbmUuZGlub3ZhQGdv b2dsZW1haWwuY29tPC9hPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdyb3RlOjxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgRXZl cnkgZGVzaWduIGNob2ljZSByZXN1bHRzIGluIGE8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB0cmFkZS1vZmYsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqBWYXVnaG4sIGltcHJvdmluZzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vW9uZSB0aGluZyBhdDxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZn dDsgdGhlIGV4cGVuc2Ugb2Ygc29tZXRoaW5nIGVsc2UuIO+/vUlmPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgZXZlcnkgdGltZSB3ZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgb2ZmZXJlZCBhPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c2VydmljZSB3ZSBoYWQg dG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv70mZ3Q7IGluZm9ybSBpdHMgdXNlcnMgYWJvdXQgdGhlPGJyPgogwqAgwqAgwqAgwqBk b3duc2lkZXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvZiBhbGwgdGhlPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0cmFkZS1v ZmZzIHdlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9aGF2ZSBtYWRlLDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgdGhleSB3b3VsZCBoYXZlIGFuIGF3ZnVs IGxvdCB0bzxicj4KIMKgIMKgIMKgIMKgcmVhZC4gOy0pPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgVGhl IHNwZWNpZmljIHRyYWRlLW9mZiB0aGF0IHlvdSBhcmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBkaXNjdXNzaW5nIGlzIG5vPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9ZGlmZmVyZW50LiDvv71BIHJlZ2lvbjxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vSZndDsgdGhhdCBwcm94aWVzIGFsbCBjb250ZW50IGhhcyB0aGU8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCAmcXVvdDtiZW5lZml0JnF1b3Q7IG9mPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhY3F1aXJpbmcgY29udHJvbDxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vWZyb20gdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqDvv70g77+9Jmd0OyBhc3NldCBzZXJ2ZXJzIG92ZXIgdGhlIGl0ZW1zIGluIHRoZTxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlZ2lvbiwgc288YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRoYXQgaXQgY2FuPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 ZW5zdXJlIHRoYXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGV2ZXJ5b25lIGluIHRoZSByZWdpb24gbm90IG9ubHk8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvYnRhaW5zIHRoZSBpdGVtczxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYnV0IG9idGFpbnM8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv710aGUgc2FtZSBpdGVtczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgYXMgZXZlcnlvbmUgZWxzZS4g77+9VGhhdCBk b2VzIGluZGVlZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHByb3ZpZGUgYTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZ3JlYXRl ciBndWFyYW50ZWUgb2Y8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGNvbnNpc3RlbmN5IHRoYW4gYSBkZXBsb3ltZW50PGJy PgogwqAgwqAgwqAgwqBpbiB3aGljaDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRo ZSByZWdpb248YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoG9ubHkgcGFzc2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9YXNzZXQgVVJJcyB0bzxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgY2xpZW50cyB3 aG8gdGhlbiBmZXRjaCB0aGU8YnI+CiDCoCDCoCDCoCDCoGl0ZW1zIGZyb208YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBhc3NldCBzZXJ2aWNlczxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXNlcGFyYXRlbHkuIO+/vUFz IGFsd2F5czxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vSZndDsgdGhvdWdoLCBpdCYjMzk7cyBhIHRyYWRlLW9mZiwgc2luY2UgdGhl PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcHJveGllZDxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZGVzaWduIGhhcyB2ZXJ5PGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9cG9vciBzY2FsYWJpbGl0eTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgY29tcGFyZWQgdG8gdGhlIGRpc3RyaWJ1dGVk IG9uZS48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBJZiB3ZSYjMzk7cmUgZ29pbmcgdG8gd2FybiB1c2Vy cyBvZiB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwb3RlbnRpYWwgZm9yPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpbmNv bnNpc3RlbmN5PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqDvv70g77+9aW4gdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBkaXN0cmlidXRlZCBkZXBsb3ltZW50IGFz IHlvdTxicj4KIMKgIMKgIMKgIMKgc3VnZ2VzdCw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBhcmUgd2U8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoGFsc28gZ29pbmcgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv713YXJuIHRoZW0gb2Y8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IG5vbi1z Y2FsYWJpbGl0eSBpbiB0aGUgcHJveGllZDxicj4KIMKgIMKgIMKgIMKgb25lPyDvv71JPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVhbGx5PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkb24mIzM5O3Qgc2VlIG11Y2g8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71t ZXJpdCBpbiB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGlkZWEgb2Ygd2FybmluZyBhYm91dCBkZXNpZ248YnI+CiDC oCDCoCDCoCDCoGNob2ljZXMuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9TWFu eSBzdWNoPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqBjaG9pY2VzIGFyZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKg77+9IO+/vXRlY2huaWNhbCwgYW5kPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyB0aGUgaXNzdWVz IGFyZSBxdWl0ZSBsaWtlbHkgdG88YnI+CiDCoCDCoCDCoCDCoGJlIG9mPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgbGl0dGxlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpbnRlcmVzdCB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vW5vbi10ZWNobmljYWwgdXNl cnM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv70mZ3Q7IGFueXdheS4g77+9SW4gYW55IGNhc2UsIHRoZSBiZXR0ZXI8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzZXJ2aWNlcyBhcmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGxpa2VseSB0byBwcm92aWRlPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 c3VjaDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKg77+9IO+/vSZndDsgaW5mb3JtYXRpb24gaW4gdGhlaXIgb25saW5lPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgZG9jdW1lbnRhdGlvbiwgSTxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgd291bGQgZ3Vlc3MuPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0Ozxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vSZndDsgWW91IG1lbnRpb25lZCB1c2VycyAmcXVvdDt2b3Rpbmc8YnI+CiDCoCDCoCDCoCDC oHdpdGggdGhlaXI8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmZWV0JnF1b3Q7IG9y PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBj aG9vc2luZyB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vWFjY2VwdCB0aGUgcmlzazxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgb2YgaW5jb25zaXN0ZW5j eS4g77+9V2VsbCB0aGF0IHdpbGw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBoYXBw ZW4gYW55d2F5LDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgd2hlbiBzZXJ2aWNlczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWZhaWwgYW5kPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyB1c2VycyBnZXQg YW5ub3llZC4g77+9SWYgc29tZSBhc3NldDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHNlcnZpY2VzIHJlZnVzZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgdG8gc2VuZCB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71yZXF1ZXN0ZWQ8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGl0ZW1z IHRvIHNvbWUgdXNlcnMsIHRob3NlIHNlcnZpY2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgd2lsbCBnZXQgYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgYmFkIHJlcHV0YXRpb248YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71hbmQgcGVvcGxlPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyB3 aWxsIGNob29zZSBkaWZmZXJlbnQgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoHNlcnZpY2VzPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW5zdGVhZC48YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vUxpa2V3aXNlLCBpZiBhPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 d29ybGQgc2VydmljZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vSZndDsgcHJveGllcyBldmVyeXRoaW5nIGFuZCBzbyBpdCBjYW4m IzM5O3Q8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBoYW5kbGUgYSBsYXJnZTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbnVtYmVy IG9mPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqDvv70g77+9YXNzZXRzIG9yIG9mPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBwZW9wbGUsIHVzZXJzIHdpbGwgZ2V0IGFu bm95ZWQ8YnI+CiDCoCDCoCDCoCDCoGF0IHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGxhZyBhbmQgd2lsbCBnbzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWVsc2V3aGVyZS4g77+9VGhpcyB1c2VyPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0 OyBldmFsdWF0aW9uIGFuZCAmcXVvdDt2b3Rpbmcgd2l0aCB0aGVpcjxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIGZlZXQmcXVvdDsgaGFwcGVuczxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYWxyZWFkeSB3aXRoPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9b25saW5l IHNlcnZpY2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqDvv70g77+9Jmd0OyBhbGwgb3ZlciB0aGUgSW50ZXJuZXQsIGFuZCBJIGFtPGJyPgog wqAgwqAgwqAgwqBzdXJlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhhdCB0aGlz PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBo dW1hbiBwcm9jZXNzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqDvv70g77+9d2lsbCBjb250aW51ZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgdG8gd29yayB3aGVuIHRo ZSBzZXJ2aWNlcyBhcmUgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhbmQg cmVnaW9uPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqBzZXJ2aWNlcy48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBCYWNrIGluIFNlcHRlbWJlciAyMDEw LCBJIHdyb3RlPGJyPgogwqAgwqAgwqAgwqB0aGlzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgcG9zdCB3aGljaDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgcHJvcG9zZXMgdGhhdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXdlIHVzZSBpbjxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgVldS QVAgYSBmb3JtIG9mIGFzc2V0PGJyPgogwqAgwqAgwqAgwqBhZGRyZXNzaW5nIHRoYXQ8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwcm92aWRlczxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbWFzc2l2ZTxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXNjYWxhYmlsaXR5 IGF0IHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vSZndDsgc2FtZSB0aW1lIGFzIGEgdmVyeSBoaWdoIGRlZ3JlZSBvZjxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlc2lsaWVuY2UgLS08YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv708YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vTxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi92d3JhcC9jdXJyZW50L21zZzAwNDYzLmh0bWwiIHRhcmdldD0iX2JsYW5r Ij5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdndyYXAvY3VycmVudC9tc2cw MDQ2My5odG1sPC9hPjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vS4g77+9SXQgaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGJhc2VkIG9uIHRoZSBjb25j ZXB0IG9mIHRoZSBVUkk8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjb250YWluaW5n IGEgaG9zdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgcGFydCBhbmQgYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKg77+9IO+/vWhhc2ggcGFydCw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IHdoZXJlIHRoZSBoYXNo IGlzIGdlbmVyYXRlZDxicj4KIMKgIMKgIMKgIMKgKG9uY2UsIGF0PGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgdGhlIHRpbWUgb2Y8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHN0b3JhZ2UgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv710aGUgYXNzZXQ8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70m Z3Q7IHNlcnZpY2UpIHVzaW5nIGEgc3BlY2lmaWVkIGRpZ2VzdDxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGFsZ29yaXRobSBvdmVyPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGUgY29udGVudCBvZjxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXRoZSBhc3NldDxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vSZndDsgYmVpbmcgcmVmZXJlbmNlZC4g77+9WW91IG1heSB3aXNoIHRvPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgbm90ZSB0aGF0IGlmPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGlzIGRlc2lnbjxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXdlcmUgdXNl ZCwgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Jmd0OyBmYWlsdXJlIG9mIGFuIGFzc2V0IHNlcnZpY2UgdG88YnI+CiDCoCDC oCDCoCDCoGRlbGl2ZXIgYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgcmVxdWVzdGVkIGl0ZW0gd291bGQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71yZXN1bHQgaW4gYTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/ vSZndDsgZmFpbG92ZXIgcmVxdWVzdCBmb3IgdGhlIGl0ZW08YnI+CiDCoCDCoCDCoCDCoHRvIG9u ZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG9yIG1vcmU8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJhY2t1cCBzZXJ2aWNlcyw8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv711c2luZyB0aGUgc2FtZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgaGFzaCBwYXJ0IGJ1dCB3aXRoIGEgZGlmZmVy ZW50IGhvc3Q8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhZGRyZXNzLjxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZn dDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv70mZ3Q7IFRoaXMgY2FuIGdvIHNvbWUgd2F5IHRvd2FyZHM8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBvdmVyY29taW5nIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcHJvYmxlbSB0aGF0IHlvdTxicj4KIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXRoaW5r IG1pZ2h0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Jmd0OyBvY2N1ciB3aGVuIGFzc2V0cyBhcmUgZmV0Y2hlZCBieTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNsaWVudHMgZnJvbTxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYXNzZXQgc2VydmljZXM8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71k aXJlY3RseS48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoO+/vSDvv70mZ3Q7IEFsdGhvdWdoIGl0IHdvbiYjMzk7dCBoZWxwIHdoZW4gdGhlPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbWlzc2luZyBpdGVtIGlzPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhdmFpbGFibGUgZnJv bTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vW9ubHkgYSBzaW5nbGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IGFzc2V0IHNlcnZpY2UsIGl0IHdpbGwgaGVs cCBpbiBtYW55PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb3RoZXIgY2FzZXMsPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhbmQg aXQgd2lsbDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vWNvbXBlbnNhdGUgZm9yPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBzZXJ2aWNlIGZhaWx1cmVzIGFu ZCBuZXR3b3JrPGJyPgogwqAgwqAgwqAgwqBvdXRhZ2VzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhdXRvbWF0aWNhbGx5IGF0IHRoZSBzYW1l PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDv v70g77+9dGltZS48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyBQUy4gVGhpcyBkZXNpZ24gZm9yIGhhc2gt YmFzZWQ8YnI+CiDCoCDCoCDCoCDCoGFzc2V0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgYWRkcmVzc2luZzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgaXMgYWxyZWFkeTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWJlaW5nIHRlc3RlZCBieTxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgTW9q aXRvIFNvcmJldCBpbiBoZXIgZXhwZXJpbWVudGFsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgd29ybGQgYW5kPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqBjbGllbnQuIO+/vUl0IHdvdWxkIGdpdmU8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IFZXUkFQLWJh c2VkIHdvcmxkcyBhbiBpbXByb3ZlZDxicj4KIMKgIMKgIMKgIMKgbGV2ZWw8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBvZiBzZXJ2aWNlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhdmFpbGFiaWxpdHksPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9c28gSSB0aGlu ayBpdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKg77+9IO+/vSZndDsgc2hvdWxkIGJlIGEgY29yZSBmZWF0dXJlIG9mIG91cjxicj4KIMKgIMKg IMKgIMKgcHJvdG9jb2wuPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IE1vcmdhaW5lLjxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7ID09PT09PT09 PT09PT09PT09PT09PT09PT09PTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7IE9uIEZyaSwgQXByIDEsIDIw MTEgYXQgMTE6MTcgUE0sPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVmF1Z2huIERl bHVjYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKg77+9IO+/vSZsdDs8YSBocmVmPSJtYWlsdG86dmF1Z2huLmRlbHVjYUBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj52YXVnaG4uZGVsdWNhQGdtYWlsLmNvbTwvYT48YnI+CiDCoCDCoCDCoCDC oCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZhdWdobi5kZWx1Y2FAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+dmF1Z2huLmRlbHVjYUBnbWFpbC5jb208L2E+Jmd0Ozxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZhdWdobi5kZWx1 Y2FAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmF1Z2huLmRlbHVjYUBnbWFpbC5jb208L2E+ PGJyPgogwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2YXVnaG4uZGVsdWNh QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZhdWdobi5kZWx1Y2FAZ21haWwuY29tPC9hPiZn dDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2YXVnaG4uZGVsdWNhQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnZhdWdobi5kZWx1Y2FAZ21haWwuY29tPC9hPjxicj4KIMKgIMKgIMKg IMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dmF1Z2huLmRlbHVjYUBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj52YXVnaG4uZGVsdWNhQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dmF1Z2huLmRl bHVjYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj52YXVnaG4uZGVsdWNhQGdtYWlsLmNvbTwv YT48YnI+CiDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZhdWdobi5kZWx1 Y2FAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmF1Z2huLmRlbHVjYUBnbWFpbC5jb208L2E+ Jmd0OyZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2YXVnaG4uZGVsdWNhQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZhdWdobi5kZWx1Y2FAZ21haWwuY29tPC9hPjxicj4KIMKg IMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dmF1Z2huLmRlbHVjYUBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj52YXVnaG4uZGVsdWNhQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dmF1 Z2huLmRlbHVjYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj52YXVnaG4uZGVsdWNhQGdtYWls LmNvbTwvYT48YnI+CiDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZhdWdo bi5kZWx1Y2FAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmF1Z2huLmRlbHVjYUBnbWFpbC5j b208L2E+Jmd0OyZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZhdWdobi5kZWx1Y2FAZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmF1Z2huLmRlbHVjYUBnbWFpbC5jb208L2E+PGJyPgog wqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2YXVnaG4uZGVsdWNhQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZhdWdobi5kZWx1Y2FAZ21haWwuY29tPC9hPiZndDs8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2 YXVnaG4uZGVsdWNhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZhdWdobi5kZWx1Y2FAZ21h aWwuY29tPC9hPjxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dmF1 Z2huLmRlbHVjYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj52YXVnaG4uZGVsdWNhQGdtYWls LmNvbTwvYT4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgd3JvdGU6PGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZn dDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv70mZ3Q7Jmd0OyBUaGlzIGlzIGEgcXVlc3Rpb24gaSBkaXNjdXNzZWQ8YnI+CiDCoCDC oCDCoCDCoHdpdGg8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBNb3JnYWluZTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgb2ZmLWxp c3QgYSB3aGlsZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vWFnbyAoSTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IGludGVuZGVkIHRvIHNlbmQgaXQg dG8gdGhlPGJyPgogwqAgwqAgwqAgwqBsaXN0IGJ1dDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHB1c2hlZCB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoHdyb25nIGJ1dHRvbi4uLikgSTxicj4KIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHRoaW5rIHdl IG5lZWQgdG8gYWRkcmVzcyB0aGlzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcHJv YmxlbSwgYW5kPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBkZWNpZGUgaG93IHRvIGRlYWw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv713aXRoIGl0Ljxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7PGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9Jmd0OyZndDsg77+9SW4gRGF2aWRzIGRlcGxveW1lbnQgZHJhZnQsPGJyPgogwqAgwqAgwqAg wqBzZWN0aW9uPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgNy4zLjEuMSBhbjxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgb3ZlcnZp ZXcgaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv71naXZlbiB2YW48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyB3YXlzIHRvIGRlbGl2ZXIgY29udGVu dCB0byB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZWdpb24uIE9uZSB3YXk8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGlz IG9ubHkgcGFzc2luZyBhPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgY2FwYWJpbGl0eSB0aGF0IGFsbG93cyBhY2Nl c3MgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAocGFydCBvZikgdGhlPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqByZXNvdXJj ZTo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oO+/vSDvv70mZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/vSDvv70g77+9IO+/vSDvv70gNy4zLjEu MS4g77+9Q29udGVudDxicj4KIMKgIMKgIMKgIMKgZGVsaXZlcnk8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBtb2RlbHM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv70g77+9IO+/vSDvv70g77+9IEEg cmFuZ2Ugb2YgcG9zc2libGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZXByZXNl bmF0aW9ucyBjYW48YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoGJlIHBhc3NlZCB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWEgcmVnaW9uIGZvcjxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/ vSDvv70g77+9IO+/vSDvv70gc2ltdWxhdGlvbi4gWy4uLl08YnI+CiDCoCDCoCDCoCDCoFRoZSBv dGhlcjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGVuZCBvZiB0aGU8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGRlbGl2ZXJ5IHNw ZWN0cnVtPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Jmd0OyZndDsgaW52b2x2ZXMgcGFzc2luZzxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/vSDv v70g77+9IO+/vSDvv70gb25seSBhIFVSSSBvciBjYXBhYmlsaXR5PGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgdXNlZCB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgYWNjZXNzIHRoZSByZW5kZXJpbmc8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBp bmZvcm1hdGlvbiBhbmQgYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/vSDvv70g77+9IO+/vSDvv70gY29sbGlz aW9uIG1lc2gsYW5kPGJyPgogwqAgwqAgwqAgwqByZWxhdGVkPGJyPgogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgZGF0YSBmb3I8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHBoeXNpY2FsIHNpbXVsYXRpb24uPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsg77+9 IO+/vSDvv70g77+9IO+/vSBJbiBzdWNoIGEgbW9kZWwsIHRoZTxicj4KIMKgIMKgIMKgIMKgY2xp ZW50IGlzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqByZXNwb25zaWJsZSBmb3I8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71mZXRjaGluZyB0aGU8YnI+CiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBhZGRp dGlvbmFsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Jmd0OyZndDsg77+9IO+/vSDvv70g77+9IO+/vSBpbmZvcm1hdGlvbiBuZWVk ZWQgdG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZW5kZXIgdGhlPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpdGVtJiMzOTtz IHZpc3VhbDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vXByZXNlbmNlIGZyb20gYTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHNlcGFyYXRlPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 Jmd0OyZndDsg77+9IO+/vSDvv70g77+9IO+/vSBzZXJ2aWNlLiDvv71UaGlzIGZldGNoPGJyPgog wqAgwqAgwqAgwqBjYW4gYmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkb25lPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAqdW5k ZXIgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqDvv70g77+9Y3JlZGVudGlhbHMgb2YgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgZW5kIHVzZXIqPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9Jmd0OyZndDsg77+9IO+/vSDvv70g77+9IO+/vSB2aWV3aW5nIHRoZSBtYXRlcmlhbCBbbXk8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBlbXBoYXNpcy0tVkRdPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAsIGFuZDxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vWRp dm9yY2VzIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHNpbXVsYXRpb24gZnJvbTxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/ vSDvv70g77+9IO+/vSDvv70gdGhlIHRydXN0IGNoYWluPGJyPgogwqAgwqAgwqAgwqBuZWVkZWQg dG88YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBtYW5hZ2U8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNvbnRlbnQuIO+/vUFueTxi cj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9 IO+/vWF1dG9tYXRpb248YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBpcyBkb25lIG9uIGE8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDv v70g77+9IO+/vSDvv70g77+9IHNlcGFyYXRlIGhvc3Qgd2hpY2g8YnI+CiDCoCDCoCDCoCDCoHRo ZSBjb250ZW50PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBjcmVhdG9yIG9yIG93bmVyIHRydXN0cyw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBpbnRlcmFjdGlu ZyB3aXRoIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IO+/vSDvv70g77+9IO+/vSDvv70gb2JqZWN0IHRocm91 Z2ggcmVtb3RlZDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGludGVyZmFjZXMuPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9Jmd0OyZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyDvv71JIGNhbiBzZWUgdGhlIG5lZWQgZm9yIHN1Y2gg YTxicj4KIMKgIMKgIMKgIMKgc2V0dXAsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg aG93ZXZlciwgaTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgZmVlbCB3ZSBhcmU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyB1bnBsZWFzYW50bHkgY2xvc2UgdG8g YSBzaXR1YXRpb248YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3ZXJlIHRoZTxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgY29oZXJl bmNlIG9mIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vXNpbXVsYXRpb248YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBmYWxscyBhcGFydC48YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDv v70mZ3Q7Jmd0OyBJbiB0aGlzIGRlcGxveW1lbnQgcGF0dGVybiB0aGU8YnI+CiDCoCDCoCDCoCDC oHJlZ2lvbjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFkdmVydGlzZXM8YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRoZSBwcmVz ZW5jZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKg77+9IO+/vW9mIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IGFzc2V0LCBhbmQgKnNvbWUqIGNsaWVudHMg d2lsbCBiZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFibGUgdG8gZ2V0IGl0PGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhcyBl eHBlY3RlZCw8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoO+/vSDvv713aGlsZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IC1iYXNlZCBvbiB0aGUgYXJiaXRyYXJ5 IHdoaW1zPGJyPgogwqAgwqAgwqAgwqBvZiB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBhc3NldDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgc2VydmljZS0gb3RoZXJzPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9bWlnaHQgbm90Ljxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7PGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g 77+9Jmd0OyZndDsgTXkgaG9wZSB3b3VsZCBiZSB0aGF0IGFmdGVyPGJyPgogwqAgwqAgwqAgwqB0 aGUgYXNzZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzZXJ2ZXI8YnI+CiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHByb3ZpZGVzIHRo ZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vXJlZ2lvbiB3aXRoPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgdGhlIGNhcGFiaWxpdHkgdG8gZ2V0IHRo ZTxicj4KIMKgIMKgIMKgIMKgYXNzZXQsIGl0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgZ2l2ZXMgdXA8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoGNvbnRyb2wuIFRoYXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv713b3VsZCBtZWFuPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsgdGhh dCBpZiB0aGUgY2xpZW50IGZpbmRzIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGludmVudG9yeSBzZXJ2ZXIgaXM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHVud2lsbGluZyB0bzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vXNlcnZlPGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsg dGhlIGNvbnRlbnQgLSBpbiBzcGlyZSBvZiB0aGU8YnI+CiDCoCDCoCDCoCDCoHJlZ2lvbjxicj4K IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNheWluZyBpdDxicj4KIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaXMgcHJlc2VudC0sPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9dGhl IGNsaWVudDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vSZndDsmZ3Q7IHNob3VsZCBiZSBhYmxlIHRvIHR1cm4gYXJvdW5kPGJyPgog wqAgwqAgwqAgwqBhc2sgdGhlPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKnJlZ2lv bio8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oGZvciB0aGUgYXNzZXQsPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqDvv70g77+9KGFuZCBnZXQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7Jmd0OyBpcyBhZnRlciBhbGwp Ljxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg 77+9IO+/vSZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDsg77+9SWYgdGhhdCBpcyBub3QgdGhlIGNhc2Us IC1hbmQ8YnI+CiDCoCDCoCDCoCDCoHRoZXJlIGFyZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcHJvYmFibHkgZ29vZCByZWFzb25zPGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9 Zm9yIHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vSZndDsmZ3Q7IGRlcGxveW1lbnQgcGF0dGVybiBhcyBkZXNjcmliZWQtPGJy PgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg77+9c2hvdWxkbiYjMzk7dCB3ZTxicj4KIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKndhcm4qIGNs aWVudHM8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoO+/vSDvv710aGF0IHRoZTxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHJlZ2lvbiBtaWdodCBiZSBpbmNvbnNp c3RlbnQsPGJyPgogwqAgwqAgwqAgwqBzbyB0aGU8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB1c2Vyczxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgYmVoaW5kIHRoZSBjbGllbnQ8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv71jYW4gdm90ZTxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHdp dGggdGhlaXIgZmVldCwgKG9yIHRha2UgdGhlPGJyPgogwqAgwqAgwqAgwqByaXNrKT88YnI+CiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70m Z3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKg77+9IO+/vSZndDsmZ3Q7IC0tVmF1Z2huPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0OyZndDs8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7IHZ3cmFwIG1haWxpbmcgbGlzdDxicj4KIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7 IDxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGll dGYub3JnPC9hPjxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndy YXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndy YXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4gJmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBp ZXRmLm9yZzwvYT4mZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4g Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij52d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij52d3JhcEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7Jmd0OyZndDs8YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndy YXBAaWV0Zi5vcmc8L2E+PGJyPgogwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0 bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiZndDs8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0 bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiAmbHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3 cmFwQGlldGYub3JnPC9hPiZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhy ZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3Jn PC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3Jh cEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiZndDsmZ3Q7Jmd0 OyZndDs8YnI+Cjxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKg77+9IO+/vSZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92d3JhcCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdndyYXA8 L2E+PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/ vSDvv70mZ3Q7IHZ3cmFwIG1haWxpbmcgbGlzdDxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDsgPGEgaHJlZj0ibWFpbHRvOnZ3 cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+PGJyPgogwqAg wqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiZndDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT48YnI+ CiDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+Jmd0OyZndDs8YnI+CiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9 Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9h PiZndDs8YnI+CiDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEg aHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5v cmc8L2E+Jmd0OyZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPjxicj4KIMKgIMKgIMKgIMKgJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52 d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52 d3JhcEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7Jmd0Ozxicj4KIMKgIMKg IMKgIMKgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndy YXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPgog wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndy YXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4gJmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBp ZXRmLm9yZzwvYT4mZ3Q7Jmd0OyZndDsmZ3Q7PGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vSDvv70mZ3Q7PGJyPgogwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby92d3JhcCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdndyYXA8L2E+PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqDvv70g77+9Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg77+9IO+/vSZndDs8YnI+Cjxicj4KPGJyPgo8 YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8YnI+Cjxicj4KIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB2d3JhcCBtYWlsaW5nIGxpc3Q8YnI+CiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDxhIGhyZWY9Im1haWx0bzp2d3Jh cEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGll dGYub3JnPC9hPiZndDs8YnI+CiDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRv OnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+ICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndy YXBAaWV0Zi5vcmc8L2E+Jmd0OyZndDs8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAm bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnZ3cmFwQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiZndDs8YnI+CiDCoCDCoCDC oCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFwQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZ3cmFw QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dndyYXBAaWV0Zi5vcmc8L2E+Jmd0OyZndDsmZ3Q7 PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqA8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Z3cmFwIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92d3JhcDwvYT48YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoO+/vTxicj4KPGJy Pgo8YnI+Cjxicj4KPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoC0t IMKgIMKgIC0tLSA8YSBocmVmPSJodHRwczovL3R3aXR0ZXIuY29tL0R6b25hdGFzX1NvbCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vdHdpdHRlci5jb20vRHpvbmF0YXNfU29sPC9hPiAtLS08YnI+ CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFdlYiBEZXZlbG9wbWVudCwgU29mdHdh cmUgRW5naW5lZXJpbmcsIFZpcnR1YWw8YnI+CiDCoCDCoCDCoCDCoFJlYWxpdHksPGJyPgogwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQ29uc3VsdGFudDxicj4KPGJyPgogwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdndyYXAgbWFp bGluZyBsaXN0PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqA8YSBocmVmPSJt YWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4g Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij52d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPgogwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhy ZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3Jn PC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiZndDsmZ3Q7PGJyPgogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4mZ3Q7PGJy PgogwqAgwqAgwqAgwqAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2d3JhcEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzp2d3JhcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZ3cmFwQGlldGYub3JnPC9hPiZn dDsmZ3Q7Jmd0Ozxicj4KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92d3JhcCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdndyYXA8L2E+PGJyPgo8 YnI+Cjxicj4KPGJyPgo8YnI+CiDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtLSDCoCDCoCDCoCDCoCAt LS0gPGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9Eem9uYXRhc19Tb2wiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3R3aXR0ZXIuY29tL0R6b25hdGFzX1NvbDwvYT4gLS0tPGJyPgogwqAgwqAg wqAgwqAgwqAgwqAgwqAgV2ViIERldmVsb3BtZW50LCBTb2Z0d2FyZSBFbmdpbmVlcmluZywgVmly dHVhbCBSZWFsaXR5LDxicj4KIMKgIMKgIMKgIMKgQ29uc3VsdGFudDxicj4KPGJyPgo8YnI+Cjxi cj4KIMKgIMKgIMKgIMKgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIDxicj4KPGJyPgogwqAgwqAgwqAgwqBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KIMKgIMKgIMKg IMKgdndyYXAgbWFpbGluZyBsaXN0PGJyPgogwqAgwqAgwqAgwqA8YSBocmVmPSJtYWlsdG86dndy YXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBpZXRmLm9yZzwvYT4gJmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86dndyYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52d3JhcEBp ZXRmLm9yZzwvYT4mZ3Q7PGJyPgogwqAgwqAgwqAgwqA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Z3cmFwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92d3JhcDwvYT48YnI+CiDCoCDCoCDCoCA8YnI+CiDC oCDCoC0tIMKgIMKgIC0tLSA8YSBocmVmPSJodHRwczovL3R3aXR0ZXIuY29tL0R6b25hdGFzX1Nv bCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdHdpdHRlci5jb20vRHpvbmF0YXNfU29sPC9hPiAt LS08YnI+CiDCoCDCoFdlYiBEZXZlbG9wbWVudCwgU29mdHdhcmUgRW5naW5lZXJpbmcsIFZpcnR1 YWwgUmVhbGl0eSwgQ29uc3VsdGFudDxicj4KPGJyPgo8YnI+CjwvYmxvY2txdW90ZT4KPGJyPgo8 YnI+CjwvYmxvY2txdW90ZT4KPGJyPgo8YnI+CjwvYmxvY2txdW90ZT4KPGJyPgo8YnI+Ci0tIDxi cj4KLS0tIDxhIGhyZWY9Imh0dHBzOi8vdHdpdHRlci5jb20vRHpvbmF0YXNfU29sIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly90d2l0dGVyLmNvbS9Eem9uYXRhc19Tb2w8L2E+IC0tLTxicj4KV2Vi IERldmVsb3BtZW50LCBTb2Z0d2FyZSBFbmdpbmVlcmluZywgVmlydHVhbCBSZWFsaXR5LCBDb25z dWx0YW50PGJyPgo8YnI+CjwvYmxvY2txdW90ZT48L2Rpdj48YnI+Cg== --000e0cdfd9f82f9c2d04a08b1b4b-- From morgaine.dinova@googlemail.com Sun Apr 10 06:10:10 2011 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 20FC528B23E for ; Sun, 10 Apr 2011 06:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=-0.549, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1, 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 qmOtwAP-ZfLB for ; Sun, 10 Apr 2011 06:10:03 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id A1B7828B56A for ; Sun, 10 Apr 2011 06:10:02 -0700 (PDT) Received: by qwc23 with SMTP id 23so3455949qwc.31 for ; Sun, 10 Apr 2011 06:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qVpEUinIZGd3XUhlW0AlXq+6Xzvb8eU/AOFyCyio86Q=; b=OfELGm82UZoWULLVE87TxjmTWKqD61S5uljw5xbvhhaJA0UlCN+QSRJFxhd2zTmMWJ ZnwNRgZC/7C82fYAGzB2rmAnTDOL7/oxIK4kbQJIGYX84StIWI6DcIHl+6ihJehjNKWW dX8qFzfe7C9gAhP914PPDhgWUvh8F6qkTpyXI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kM0d0aBNzwy9w1bHIYFmeQQiHmVQvF3WRKjtFJ+iR6+/vrZkkhy+HCkpGATdLLq5ql xH6qC5jxyB51KdI1W9Uh7JiYCgMoFmsTm4g/+CMt4KhDMm7GGz0uqrWJMeCmDK7HI10e SjvcMNp8TPR8+pKE8QXtKUs5E89lzEDI8gdos= MIME-Version: 1.0 Received: by 10.224.75.21 with SMTP id w21mr3244552qaj.272.1302441107277; Sun, 10 Apr 2011 06:11:47 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sun, 10 Apr 2011 06:11:46 -0700 (PDT) In-Reply-To: References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> Date: Sun, 10 Apr 2011 14:11:46 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016367d4f048a47b804a0903310 Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 10 Apr 2011 13:10:10 -0000 --0016367d4f048a47b804a0903310 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think there's a bit of a misunderstanding about the nature of a "message"= , Vaughn. I'll see if I can describe it a little better further down. On Sat, Apr 9, 2011 at 10:31 PM, Vaughn Deluca wro= te: > > You can't eliminate those messages even when not checking credentials. T= he > roundtrips are anyhow needed to make sure that the communication is actua= lly > working. Or can we really get away with an UDP style of send and pray?? I > fail to see how you would be able to realise a substantial gain over what > will be needed anyhow as bare bone infrastructure and for error > checking/reporting. But i might be wrong. > > > In the open content use cases that I described in my previous reply, we c= an eliminate entirely the request-grant handshake messages which handle caps, because the caps are only there as a roadblock against obtaining the item. When an item is unrestricted, a roadblock against obtaining it is obviously inappropriate. What's more, once you have actually obtained the item, a roadblock against obtaining it again is inappropriate as well, since you will continue to have the item unless you choose to delete it, in our data model. What this *intrinsically* means is that caps are only meaningful as a mechanism for obtaining the direct address of an item. In the case of open content, we already have that direct address. :-) With regard to message transports, you mention "UDP style", but our messaging is not related in any way to UDP (not sure what "style" means), a= s we are talking about reliable messaging running over TCP in all of this. A message will always be received reliably if it is sent successfully. There is no return message confirming receipt needed at our level because the TCP stream does all that under the hood. A TCP session will be maintained between any two endpoints which exchange one or more protocol messages. In an efficient implementation, the same TC= P stream will carry the response message back too, since messages can be sent over a TCP stream in both directions regardless of who initiated the connection. When we speak of a message sent from A to B, we're referring to the message payload sent by A and received by B across such a TCP stream, and we're specifically *not* referring to the IP datagrams which are sent in both directions between A and B to implement the single-direction A->B message transfer. Our protocol messaging is at one level of abstraction higher tha= n that of the packets which implement the TCP stream. (It may actually be two levels higher if our message payload is carried by HTTP over TCP.) In numerous places in your protocol flows, whenever the agent wishes to introduce an asset into the region, a capability for the asset is first requested from the asset service, and such a capability must be granted before the asset can be fetched by any party. This entails a minimum of tw= o message trip times before the asset itself is even requested. Even if both request and grant messages are efficiently carried on the same TCP stream, there is still the full request-grant round trip time involved here wheneve= r this operation is performed. This is quite unnecessary when there are no distribution restrictions on th= e item and you already have its *direct address*. I'll explain this step in detail because we have not really discussed the nature of inventories and metadata much on this list before, and they are relevant to asset access. First of all, just to be sure that we're on the same page, an inventory is just a tree structure containing asset metadata at its leaves. It is not, for the purposes of this discussion, the graphical thing that appears in viewers as "Inventory", even though the two are strongly related. Assets that an agent wears are always assets that are held in an agent's inventory. When an asset is in inventory, this implicitly means that its metadata has been fetched and received, and under normal operation this asset metadata will be in the viewer's inventory cache. After all, you can't expect to wear an item when you don't know whether it is a shoe or a shirt, so the metadata *must* have been received previously for you to be able to even begin a request to wear it. Because the asset's metadata is already known, both the agent service and the client also already know whether the item has access restrictions on it or not, because that information is an asset property present in the asset'= s metadata. Knowing that it is not burdened with access restrictions, a viewer can perform a direct fetch of the asset from the asset service without any need for credentials, because credentials are irrelevant for this. Caps are not needed at all in this case, and it is highly likely tha= t this will be the most common situation in open worlds, which makes it a ver= y important use case. It is worth noting that while inventories are mostly a client-side implementation detail which can be changed unilaterally, the *metadata* hel= d by inventories is a very important and separable information type in an architecture that uses 3rd party asset services, so it needs detailed examination. The metadata has to be available to remote parties in the same way as the data itself is, and the best way of handling this is to make metadata a separate item normally stored in the same asset service as the data. The metadata item will naturally reference the corresponding data item (which i= s an N:1 relationship when hash-based addressing is used), and in some cases can reference more than one data item --- for example, the metadata of a mesh will commonly reference not only the graphical data required for rendering in the client but also the collision mesh or bounding box data required by the region. These two types of data are separate because it would be inefficient to require clients or regions to download data that they do not use. Our "asset" singleton now turns into a metadata + data pair. As a final point about metadata versus data, it should be mentioned that generally only the data ever has access restrictions placed on it, because placing restrictions on metadata leads to unsearchable inventories for whic= h the technical term is "annoying as hell", or more seriously, poorly functionality and yet another source of lag. I am going to assume that nobody wants that and hence, that metadata is never accessed through capabilities. If anyone wants to suffer the burden of capabilities for metadata then they are welcome to do so of course, just as long as the rest of us do not have to: "*the burden of a facility should be borne only by those who need it*". In the model that I am describing, metadata is directly addressed and has the same protection as a cryptographic key: the address of metadata is an unguessable address, but once you know it, you know it. Now that we understand metadata, let's look at how this affects regions. Regions don't have access to your inventory, but they do have access to the metadata of each item that is part of the region's simulation, for numerous reasons. The primary reason is of course that the metadata contains one or more references to needed data, but there are other reasons too. For example, the region may wish to ensure that every item in its region space has specific properties which are described in item metadata, such as lack of access restrictions, or the opposite, requiring certain access restrictions. (Note that your requirement for simulation consistency can b= e implemented very cleanly that way too --- just add something like Boolean:RegionConsistency to the set of asset properties). As another example, the region may wish to ensure that every item in its space is properly tagged to support accessibility, so the item type and item descriptions typically held in metadata would then be important. Now that we've progressed to this level of detail, we can at last state precisely what happens when agents inform the region of the items that they are wearing as avatars: they are supplying to the region the addresses of the relevant metadata items. The region then fetches those metadata items from the asset service (unless it already has them in cache), and then on the basis of that metadata, the region begins its decision making about whether to allow the asset to appear in its region or not. If the metadata indicates that no access restrictions are required, then the region can sen= d the metadata URIs directly to clients. In contrast, if the metadata says that the asset data has restricted access, then the region has to engage it= s more onerous access control mechanisms, ie. it first obtains an * AssetAllowedInRegion* capability for the asset from the asset service, whic= h it then passes to all clients. Note that this is only one particular design for our protocol flows, and no doubt other designs can achieve the same functionality and efficiency. I expect you were trying to keep things simple for an initial diagram, but as we get into the detail we have to start considering the role that metadata plays in asset access because this is actually central to the effective operation of external asset services. Your diagram doesn't get down to the level of metadata access, but we cannot avoid it when we have external asse= t services. A final point about metadata, before this email gets too long. There may b= e many thousands or even millions of instances of a common asset held in people's inventories, such as those used by default avatars, or trees and plants and other objects or textures common in the environment, and many others. Both our asset services and our caches need store those data items only once when we use hash-based addressing, instead of millions of times. The reason we can make this remarkable saving of space is because the * metadata* is stored as separate items and holds details such as "ownership" separately, while in terms of storage all those different metadata items ca= n point at the same asset data. That N:1 relationship between metadata and data is important as we design our protocols, because it allows us to avoid those unhelpful and inefficien= t designs that require us to download something just to determine whether we wanted to download it. By separating the two types of information, we gain a lot, but it does mean that "asset" cannot be treated as a monolithic entity as in your diagram. As we hone our design further, metadata fetches enter the picture. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Sat, Apr 9, 2011 at 10:31 PM, Vaughn Deluca wro= te: > Morgaine, > > Thanks for the compliments and the extensive comments :) > I am in a time crunch, so i will only respond to one aspect of your mail, > and come back to some other points later. > > I am not sure i understand your emphasis on the (non)transfer of trust in= fo > to gain speed. When drafting the diagram I was thinking that depending on > the "domain" of the sender of the message (with domain defined in the > classical sense of a range of IP addresses) the authorisation info might > simply be dropped and the data used without further checking if the > receiver wishes to do so. Also since in the majority of cases only caps a= re > passed that contain *implicit* trust. The checking of the validity of the > cap is local to the service, and should be really fast. > > Regarding capabilities, i was viewing them not so much as credentials > (although they are) but more > as a convenient way to pass references to some bit of underlaying data > around. You can't eliminate those messages even when not checking > credentials. The roundtrips are anyhow needed to make sure that the > communication is actually working. Or can we really get away with an UDP > style of send and pray?? I fail to see how you would be able to realise a > substantial gain over what will be needed anyhow as bare bone infrastruct= ure > and for error checking/reporting. But i might be wrong. > > One way way to find out is to implement it, and I feel that we are gettin= g > closer to be able to do just that. > > -- Vaughn > > > On Sat, Apr 9, 2011 at 1:18 AM, Morgaine = wrote: > >> Excellent work, Vaughn! >> >> You're right, I am working on something related to this, specifically a >> design study for the Tourism use case. It happens to end with a protoco= l >> sequence diagram presented as a table of text, so I was very pleased to = see >> your highly relevant diagram. Yours captures part of my use case, and i= t's >> a lot prettier than my text format. :P >> >> I was particularly impressed by the way you start off with completely >> separable services right from the start. Since separable services can b= e >> put together under a single administrative domain very easily, whereas >> separating conjoined services is not easy at all, I think you've started >> this off perfectly for the VWRAP approach to services. >> >> Because you have separated the services so well, your suggested protocol >> flow could be said to to be targeting some kind of "*superset of all >> VWRAP deployments*" deployment. :-) Although it's logically structured, >> it's a sort of worst-case scenario (or lawyer's delight) in which everyo= ne >> has to ask everyone else for permission to do anything, regardless of >> whether permission is actually required or not. >> >> That's viable, but less than optimal. Specifically, you are working to >> the principle of "The heaviest burden required by anyone must be borne b= y >> everyone." I have been trying to stick to the opposite principle of "A >> burden should be borne only by those whose use case requires it", which = is >> both fairer and more efficient. >> >> To illustrate this, consider the case of an asset service which serves (= by >> choice) only Creative Commons licensed assets --- an extremely important= use >> case which could well become the dominant one in an open metaverse of >> community worlds. Who knows, it could be operated by Debian, or Blender= , or >> OSgrid, or even Google Warehouse. :P >> >> In such a scenario, because the license on all the assets in the asset >> service permits unchecked distribution to all destinations in perpetuity= , >> the vast majority of all the request-grant protocol flows in your diagra= m >> are superfluous when the assets come from this repository. By using a >> protocol which understands *WHEN* it needs to ask a question, a large >> amount of cumulative round-trip time latency (and its resulting lag) can= be >> avoided entirely. This is also true on a per-asset basis if an asset >> service serves a mixture of encumbered and freely distributable assets, >> except that then the difference would be seen per-asset instead of per a= sset >> service. >> >> For such freely distributable assets, the agent service doesn't need to = do >> anything at all beyond recording the addresses of assets which are curre= ntly >> being worn by the agent. Since you start off your trip (sensibly) by >> checking your clothing at home before you leave, you'll notice a broken >> asset service locally anyway since your viewer will be trying to fetch i= t >> for local viewing. The agent service need do nothing at all, beyond rec= ord >> the addresses of top level items. (In my design study, I refer to a *Wo= rn >> Assets List *which is held by the user's agent service, and which is >> entirely separate from any concept of inventory.) >> >> Likewise, region services don't need to fetch the graphic assets normall= y >> either (unless they opt to proxy them), but only pass the addresses of t= hose >> assets around to all the other agents in the corresponding region, so th= e >> request-grant exchanges between regions and asset services can be avoide= d in >> this case. (Regions will be requesting other server-side data though, f= or >> example the bounding box information or collision mesh of an asset, whic= h >> typically the viewer would not be fetching.) >> >> That's not the end of the "*no unnecessary burden*" issue yet though, >> because even if you removed all the unnecessary request-grant protocol >> flows, you're still making the incorrect assumption that assets *ALL NEE= D >> TO BE RESTRICTED* by the mere fact of asking for caps to everything. >> This itself is wrong. The logic need to first determine whether a cap i= s >> needed for fetching a given asset, and if it's not needed then the fetch= can >> be done by the viewer or region without this protocol burden at all. >> >> So you see, there is a fundamental assumption in your nicely laid out >> flows that all assets must be tied up in heavy red tape by the needs of = the >> most burdensome use case. I don't agree with that, neither on principle= nor >> on engineering grounds. >> >> Many of the flows you have shown are exactly what we need for securing >> access to proprietary resources, but not all resources have that burden,= and >> I would want to elide a number of the flows away entirely when an asset >> service allows it. >> >> To put it another way, the data is king, and protocol flows should refle= ct >> the requirements imposed by data, not the other way around. >> >> I need this expressed in your flows, possibly as asset requirement >> annotations. >> >> >> PS. Great work Vaughn, I think this gives us a wonderful launching poin= t! >> >> >> Morgaine. >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> On Fri, Apr 8, 2011 at 5:40 PM, Vaughn Deluca w= rote: >> >>> VWRAP services high level message flow (preliminary diagram draft) see >>> >>> >>> http://trac.tools.ietf.org/wg/vwrap/trac/attachment/wiki/Diagrams/VWRAP= _FlowExample_VD1.pdf >>> >>> The main reason that i am submitting this in spite of my lack of formal >>> expertise is that the group in my view badly needs a solid basis for >>> discussion and preventing endless repeating loops. This example is prob= ably >>> wrong in many ways, but its better than what we have publicly available= on >>> interop now (although Morgaine is working on something along the lines = of >>> the recent discussions here) >>> >>> I hope this diagram will give us a base for discussion. I could have do= ne >>> my homework better by researching the old OGP stuff in more depth, and = i >>> probably will do so in the future , but for now I just tried to follow= ed >>> the general principles as far as i understand them, to see what respons= e >>> that yields from the group. In other words,I try to let the group educa= te me >>> :p >>> >>> Note that in my view all services are equal, in principle it does not >>> matter in what "domain" they run, since trust and policy are fully >>> localized. It is however very possible to have internal shortcuts in th= e >>> services to speed up processing. >>> >>> In the example I opted for an external Agent service, but I could as we= ll >>> have incorporated that in the set of local services. As indicated above= all >>> services could also be run by different organisations, true to what VWR= AP >>> stands for. Its all up to the deployer, including a user at home who mi= ght >>> want to run a full world for family and friends. Those friends might tr= y to >>> use that agent service to venture out in the virtual universe. >>> I envision that the final identity provider is external, using OpenID >>> and OAut or whatever other magic that I do not yet fully understand e= xists >>> out there. >>> >>> The example has 3 main purposes: >>> - Provide a reference for discussion >>> - Illustrates the use case of tourism, and *true* interop. >>> - Illustrate consistency problems along the lines discussed here highe= r >>> up in this tread, as well as the "slashdot" problem that Morgaine outli= ned >>> so clearly. >>> >>> The message flow assumes an avatar already present in some region, (a >>> small scale local home region in this case, but that is by no means >>> essential, it could be a build in region in the viewer or a big commerc= ial >>> region). The user is preparing for a trip to immersive world, and after= some >>> outfit adjustments moves over. >>> >>> Finally i apologize for for the simplistic notation used here. I simply >>> add the most relevant parameters passed in square brackets to a keyword >>> specifying the nature of the message. Please improve on that where need= ed. >>> >>> So here we go, the avatar is prepare for a visit to "immersive world" >>> 0) Viewer, here is an update of the state of the world your agent is i= n, >>> please render. >>> 1) Agent service, I will go in my Zodiac dress that i keep in the >>> "Amazing assets" service. >>> 2) Asset service A, please send a cap for Z, here are my credentials >>> 3) Your fine, here is the cap >>> 4) Local region, can you please put this on my agent, i included the >>> cap. >>> 5) Hello asset service A, i need Z, here is the cap >>> 6) Cap is good, data coming up, have fun. >>> 7) Agent service, your agent is now wearing Z >>> 8) Viewer, your avatar is now wearing Z >>> User: Hmm, amazing inventory has not been *that* amazing lately. 'l= l >>> make a backup, just in case >>> 9) Hello asset service A, please send me a cap for Z, here are my >>> credentials >>> 10) Your fine, here is the cap >>> 11) Local asset storage, please store Z for me, here is the cap to get = it >>> 12) Hello asset service A, i want Z, here is the cap >>> 13) Cap is good, data coming up, have fun. >>> 14) Viewer, Z is now stored for you >>> User: I am Ready!, Lets try to get to immersive world! >>> 15) Hello immersive world, can i get in? Here are my credentials, and a >>> list of my stuff. >>> 16) Asset service A, please send me a cap for X, here are my credential= s >>> (I want this cap for consistency) >>> 17) Your fine, here is the cap >>> 18) Asset service B, please send me a cap for Y, here are my credential= s >>> (I want this cap for consistency) >>> 19) Very sorry, but your not one of us, you can't have Y >>> 20) Asset service B, please send me a cap for Z, here are my credential= s >>> (I want a cap for consistency) >>> [Region service: Timeout... amazing inventory must be overloaded.. oh >>> well... ] >>> 21) Agent service, you wanted to send somebody over, here are your >>> permissions. >>> 22) Viewer, you asked for a transfer try, here are your results >>> User thinks: Crap! Big asset service does not allow me to take m= y >>> yellow stockings! And Amazing assets failed to deliver my zodiac dress= . At >>> least i made a backup of that dress! >>> 23) 'll take the yellow stockings off... >>> 24) ... done ('ll trash them here and now, forever, who needs stuff you >>> can't use!) >>> 25) The zodiac dress was not delivered by Big assets service, but i hav= e >>> a local copy! >>> 26) Local Asset service, please send me Z, here are my credentials >>> 27) I dont know you, but I 'll trust you, here is the cap, but you bett= er >>> store the data, its single use, i need to protect myself. >>> 28) Local region, can you please put this on my agent, i include the ca= p. >>> 29) Local Asset service, i need Z, here is the cap >>> 30) Cap is good, data coming up, have fun. >>> 31) Cap was only good for one time, I made a copy, but my policy is to >>> only grant you fair use rights, at a later time i might even tell you t= o >>> replace the dress. >>> 32) Viewer, you can wear Z for now, but the asset service granted only >>> fair use, i might ask you to replace the dress at a later time. >>> 33) Ready at last! Off to immersive world!, I hope its not to crowded >>> there or 'll loose my dress... >>> 34) Hello immersive world, here are my credentials, and a list of stuff= i >>> want to bring >>> 35) Hello asset service A, please send me a cap for X, here are my >>> credentials >>> [darn, I should have kept that cap from last time..] >>> 36) Your fine, here is the cap. >>> [Region service finds fair-use warning on Z and decides to make its >>> own copy] >>> 37) Hello Local region, can i still have Z? Here is the cap >>> 38) Cap is still good, data coming up, have fun. >>> [Region service stores asset in private storage, providing a cap to >>> replace the fair use one] >>> 39) Agent service, you wanted to send somebody over, here are your >>> permissions & info. >>> 40) Hello immersive world, just get me there, and use what you can >>> 41) Placement done, Z is currently buffered by us as wel, you need to g= et >>> details for X, have fun. >>> 42) You are now in immersive world, your dress is buffered there as wel= l, >>> but you need to get X! >>> 43) Hello asset service A, i want X, here is the cap >>> 44) Cap is good, data coming up, have fun. >>> 45) Viewer, here is an update of the state of the world your agent is i= n, >>> please render. >>> >>> As far as I can see this conforms fully to our charter, and i hope it i= s >>> possible to use large portions of the existing code bases. However, as = said >>> above, i did not really try to capture the old thinking, and I also mig= ht >>> have misconceptions about the way to do these things in general. >>> Looking forward to constructive comments. >>> >>> -- Vaughn >>> >>> On Sun, Apr 3, 2011 at 8:38 PM, Vaughn Deluca = wrote: >>> >>>> Thanks for the pointers. I have a busy week in RL in front of me, so= i >>>> wont have to much time to respond the next few days, however, i intend= to >>>> start doing the following things: >>>> >>>> - Produce a visual that reflects my thinking, i.e. an illustration of = my >>>> response to Morgaine's itemlist above. >>>> - Read up on the older notes, as well as more reading in the list >>>> archive >>>> - Try to make a summary for the wiki >>>> >>>> Regarding the use of domain, I think services are eventually what >>>> counts, but its all terminology. The way I read the AWG diagrams is th= at the >>>> agent domain is actually a cluster of tightly integrated services. Whe= n the >>>> functionality of each sub-service is described properly and with unifo= rm >>>> interfaces the domain will slowly dissolve. But let not get ahead of o= ut >>>> selfs. We should put up some clear descriptions on the wiki for our vi= ews on >>>> this, and *after* that we can decide what we need and what can go. >>>> >>>> Its been a very useful and illuminating weekend for me, and i am a lot >>>> more optimistic about the future of vwrap than two weeks ago. >>>> >>>> -- Vaughn >>>> >>>> >>>> >>>> On Sun, Apr 3, 2011 at 7:20 PM, Dzonatas Sol wrote= : >>>> >>>>> Probably easy as suggested in other terms here on this list, as how t= he >>>>> client contacts the asset services now in the regions. The newer issu= e is to >>>>> unitize that asset services. Since their is proprietary (legacy) code= then >>>>> we can't expect that to change, and some form of proxy is of need. Wh= atever >>>>> works best, I tried to narrow it down to suggestions here. >>>>> >>>>> Eventually, the agent domain is ideal to handle the direction of the >>>>> asset services. This concept, unfortunately, ended support awhile ago= with >>>>> changes in LL. >>>>> Also see; http://wiki.secondlife.com/wiki/Agent_Domain >>>>> And: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset(warn= : unstructured collaborative notes, dumped on me and I tried to fix) >>>>> >>>>> I tried to find previous visuals. >>>>> >>>>> I'd imagine the agent domain could grow out of unitized versions of >>>>> asset services. Despite that, I think that concept helps view where w= e were >>>>> at in discussion and what didn't happen. >>>>> >>>>> Vaughn Deluca wrote: >>>>> >>>>>> Hi=EF=BF=BDDzonatas >>>>>> >>>>>> Can you expand on that, what would be needed for legacy support in >>>>>> VWAP terms=EF=BF=BD?, >>>>>> If i want to read up on how the=EF=BF=BDasset server may proxy the s= imulator, >>>>>> what would you recommend me to read? >>>>>> >>>>>> -- Vaughn >>>>>> >>>>>> On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol >>>>> dzonatas@gmail.com>> wrote: >>>>>> >>>>>> Some stated the proxy-to-asset-server is built into the sim; >>>>>> however, keep in mind possible legacy support where the asset >>>>>> server may proxy the simulator. >>>>>> >>>>>> >>>>>> Dzonatas Sol wrote: >>>>>> >>>>>> Somehow I feel the basic asset server being able to login and >>>>>> download assets is now priority, yet I also wondered the best >>>>>> way to patch this into the current mode of viewers. >>>>>> >>>>>> Maybe offer (1) by proxy (sim-side) and (2) by patch >>>>>> (viewer-side) that either of these two are optional and >>>>>> neither are mandatory for now. Thoughts? >>>>>> >>>>>> Israel Alanis wrote: >>>>>> >>>>>> >>>>>> > when designing for scalability, the model to bear in >>>>>> mind is ... >>>>>> >>>>>> Well, there are a lot of different models to keep in mind= , >>>>>> and many different use cases. One particular use case to >>>>>> keep in mind is: "User acquires new outfit, and wants to >>>>>> 'show it off' in a highly populated region". >>>>>> >>>>>> > Both worlds and asset services may include commercial, >>>>>> community, and personal services >>>>>> >>>>>> Yes, yes and yes. I'm particularly concerned about how th= e >>>>>> model affects the ability to host personal asset services= . >>>>>> >>>>>> > a proxying region, which would get slammed for every >>>>>> asset worn by every avatar present. >>>>>> >>>>>> Granted the collection of services that are provided by >>>>>> the region need to be scaled to meet the demands of that >>>>>> region. That's all part of capacity planning. >>>>>> >>>>>> > regions run many different CPU-intensive tasks, >>>>>> including physics simulation and server-side scripting, >>>>>> and absolutely cannot afford to serve assets too >>>>>> Well... who said the same CPU's have to do proxying, >>>>>> physics simulation and server-side scripting? Asset >>>>>> proxying is a different service than physics simulation >>>>>> and can be on separate hardware, could make use of >>>>>> geographically distributed caching, and in certain >>>>>> deployment patterns, the same caching services could be >>>>>> shared by different regions. (Server-side scripting is a >>>>>> discussion for another day). >>>>>> >>>>>> > This is why we have to go parallel... >>>>>> >>>>>> Totally agree, and a proxying model could and should also >>>>>> take advantage of parallelism. >>>>>> >>>>>> > I think you're wrong that it has to cost much money. ?v= s? >>>>>> > It costs money to host a high performance and scalable >>>>>> asset service and a high bandwidth network to handle the >>>>>> traffic. =EF=BF=BDA *lot* of money. >>>>>> I think what you're saying is: "It costs a lot of money t= o >>>>>> build a scalable asset service, but if assets are spread >>>>>> throughout the internet they don't have to be scalable." >>>>>> But that's not quite right. You're opening up every asset >>>>>> server to the VW equivalent of being slashdotted, so are >>>>>> you sure you're not forcing *every* asset service to be >>>>>> scalable and handle a lot of bandwith and network traffic= ? >>>>>> It's the exact opposite of your intention, but I think >>>>>> that's the result, all the same. >>>>>> >>>>>> This particular design decision has a big effect on the >>>>>> economics of the VW infrastructure. I'd rather the >>>>>> economics to work out such that a region provider who >>>>>> wishes to build a region that supports a small population= , >>>>>> can do so economically. A region that wants to host a >>>>>> *large* population has to bear that cost of providing tha= t >>>>>> scalable asset service. >>>>>> I want the economics of hosting a small asset service to >>>>>> be a non-issue (as to best promote creation and >>>>>> creativity). Creating a high bar to provide asset service= s >>>>>> will mean that service will cost money and people >>>>>> shouldn't have to pay money just to create or own VW >>>>>> objects (I'm using 'own' here to refer to maintaining >>>>>> their existence, I'm not trying to make a >>>>>> 'leftist'/'communist' statement about ownership ;) >>>>>> >>>>>> - Izzy >>>>>> >>>>>> >>>>>> On Apr 2, 2011, at 3:58 PM, Morgaine wrote: >>>>>> >>>>>> Izzy, when designing for scalability, the model to >>>>>> bear in mind is that of seasoned virtual world >>>>>> travelers whose inventories contain assets from many >>>>>> different worlds, those assets being served by many >>>>>> different asset services. =EF=BF=BDBoth worlds and as= set >>>>>> services may include commercial, community, and >>>>>> personal services, and as the metaverse grows, that >>>>>> set is highly likely to become progressively less >>>>>> clustered and more diverse. >>>>>> >>>>>> When those seasoned travelers click on an advertised >>>>>> VW link and perform an inter-world teleport to one >>>>>> particular world's region to share an experience, >>>>>> their "worn" assets (the only ones of interest to the >>>>>> region) will contain references to asset services >>>>>> spread widely across the Internet. =EF=BF=BDThe fetch= es by the >>>>>> travelers' clients occur over many parallel paths fro= m >>>>>> clients to asset services, so one can reasonably >>>>>> expect reduced network contention and reduced asset >>>>>> server loading because they are both spread out over >>>>>> however many asset services are being referenced by >>>>>> the overall set of assets in the region. >>>>>> >>>>>> This is very different to the case of a proxying >>>>>> region, which would get slammed for every asset worn >>>>>> by every avatar present. =EF=BF=BDIn our current arch= itecture, >>>>>> regions run many different CPU-intensive tasks, >>>>>> including physics simulation and server-side >>>>>> scripting, and absolutely cannot afford to serve >>>>>> assets too unless your scalability requirements are >>>>>> very low indeed, ie. just a few dozen avatars of >>>>>> today's kind. =EF=BF=BDWe've hit the ceiling already = on region >>>>>> scalability done that way. =EF=BF=BDThere is nowhere = to go in >>>>>> that direction at all beyond improving the code like >>>>>> Intel demonstrated, and that work is subject to a law >>>>>> of diminishing returns. >>>>>> >>>>>> This is why we have to go parallel, and I think you'r= e >>>>>> wrong that it has to cost much money. =EF=BF=BDAs we = spread >>>>>> the load across more and more asset services, we are >>>>>> simply better utilizing all the hardware that's >>>>>> already out there on the Internet, at least in respec= t >>>>>> of community and private resources. =EF=BF=BDBut add = to the >>>>>> community and private resources the commercial asset >>>>>> services that are likely to appear to exploit this >>>>>> opportunity, and not only will the number of asset >>>>>> services leap, but the power of each one will rocket >>>>>> too, because, after all, these businesses will be >>>>>> heavily optimized for the job. >>>>>> >>>>>> As to why a world would want clients to access >>>>>> external asset services instead of providing its own >>>>>> implementation, that's an easy question. =EF=BF=BDIt = costs >>>>>> money to host a high performance and scalable asset >>>>>> service and a high bandwidth network to handle the >>>>>> traffic. =EF=BF=BDA *lot* of money. =EF=BF=BDIn contr= ast, it costs a >>>>>> world nothing to let others serve the assets to >>>>>> clients. =EF=BF=BDAnd that matters to the bottom line= . >>>>>> >>>>>> >>>>>> Morgaine. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>>> >>>>>> On Sat, Apr 2, 2011 at 7:05 PM, Izzy Alanis >>>>>> >>>>>> >>>>> >>>>>> >> wrote: >>>>>> >>>>>> =EF=BF=BD =EF=BF=BD> As always though, it's a trade-o= ff, since the >>>>>> proxied design >>>>>> =EF=BF=BD =EF=BF=BDhas very poor scalability compared= to the >>>>>> distributed one. >>>>>> >>>>>> =EF=BF=BD =EF=BF=BDI don't agree with that... If a us= er enters a >>>>>> highly populated >>>>>> =EF=BF=BD =EF=BF=BDregion, >>>>>> =EF=BF=BD =EF=BF=BDevery other client is going to (co= uld and should be >>>>>> trying to) >>>>>> =EF=BF=BD =EF=BF=BDhit the >>>>>> =EF=BF=BD =EF=BF=BDasset server(s) for the assets tha= t the user is >>>>>> wearing (assuming >>>>>> =EF=BF=BD =EF=BF=BDthey're not cached locally). =EF= =BF=BDEvery asset server >>>>>> has to be scaled up >>>>>> =EF=BF=BD =EF=BF=BDto the point that it can handle th= at load from all >>>>>> over... >>>>>> >>>>>> =EF=BF=BD =EF=BF=BDIf I'm hosting a region that suppo= rts 10s of >>>>>> thousands of >>>>>> =EF=BF=BD =EF=BF=BDsimultaneous >>>>>> =EF=BF=BD =EF=BF=BDusers (thinking of the future), I = already have to >>>>>> scale to meet that >>>>>> =EF=BF=BD =EF=BF=BDdemand. If the region is proxying = the assets, then, >>>>>> yes the >>>>>> =EF=BF=BD =EF=BF=BDregion has >>>>>> =EF=BF=BD =EF=BF=BDto be scaled to meet that asset de= mand too, but it >>>>>> already has to be >>>>>> =EF=BF=BD =EF=BF=BDscaled to meet other demands of be= ing a region >>>>>> server... and why is >>>>>> =EF=BF=BD =EF=BF=BDscaling those asset proxy services= hard? =EF=BF=BDIt's >>>>>> going to cost $, >>>>>> =EF=BF=BD =EF=BF=BDbut is >>>>>> =EF=BF=BD =EF=BF=BDnot technically challenging. So, i= f I want to host >>>>>> a region like >>>>>> =EF=BF=BD =EF=BF=BDthat... sure it will cost me, but = the simulation >>>>>> will be consistent >>>>>> =EF=BF=BD =EF=BF=BDand users will be able to particip= ate equally, >>>>>> regardless of the >>>>>> =EF=BF=BD =EF=BF=BDcapabilities of their individual a= sset services. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> =EF=BF=BD =EF=BF=BDOn Fri, Apr 1, 2011 at 11:55 PM, M= orgaine >>>>>> =EF=BF=BD =EF=BF=BD>>>>> >>>>>> =EF=BF=BD =EF=BF=BD>>>>> >>>>>> >> wrote: >>>>>> =EF=BF=BD =EF=BF=BD> Every design choice results in a= trade-off, >>>>>> Vaughn, improving >>>>>> =EF=BF=BD =EF=BF=BDone thing at >>>>>> =EF=BF=BD =EF=BF=BD> the expense of something else. = =EF=BF=BDIf every time we >>>>>> offered a >>>>>> =EF=BF=BD =EF=BF=BDservice we had to >>>>>> =EF=BF=BD =EF=BF=BD> inform its users about the downs= ides of all the >>>>>> trade-offs we >>>>>> =EF=BF=BD =EF=BF=BDhave made, >>>>>> =EF=BF=BD =EF=BF=BD> they would have an awful lot to = read. ;-) >>>>>> =EF=BF=BD =EF=BF=BD> >>>>>> =EF=BF=BD =EF=BF=BD> The specific trade-off that you = are discussing is >>>>>> no >>>>>> =EF=BF=BD =EF=BF=BDdifferent. =EF=BF=BDA region >>>>>> =EF=BF=BD =EF=BF=BD> that proxies all content has the= "benefit" of >>>>>> acquiring control >>>>>> =EF=BF=BD =EF=BF=BDfrom the >>>>>> =EF=BF=BD =EF=BF=BD> asset servers over the items in = the region, so >>>>>> that it can >>>>>> =EF=BF=BD =EF=BF=BDensure that >>>>>> =EF=BF=BD =EF=BF=BD> everyone in the region not only = obtains the items >>>>>> but obtains >>>>>> =EF=BF=BD =EF=BF=BDthe same items >>>>>> =EF=BF=BD =EF=BF=BD> as everyone else. =EF=BF=BDThat = does indeed provide a >>>>>> greater guarantee of >>>>>> =EF=BF=BD =EF=BF=BD> consistency than a deployment in= which the region >>>>>> only passes >>>>>> =EF=BF=BD =EF=BF=BDasset URIs to >>>>>> =EF=BF=BD =EF=BF=BD> clients who then fetch the items= from asset >>>>>> services >>>>>> =EF=BF=BD =EF=BF=BDseparately. =EF=BF=BDAs always >>>>>> =EF=BF=BD =EF=BF=BD> though, it's a trade-off, since = the proxied >>>>>> design has very >>>>>> =EF=BF=BD =EF=BF=BDpoor scalability >>>>>> =EF=BF=BD =EF=BF=BD> compared to the distributed one. >>>>>> =EF=BF=BD =EF=BF=BD> >>>>>> =EF=BF=BD =EF=BF=BD> If we're going to warn users of = the potential for >>>>>> inconsistency >>>>>> =EF=BF=BD =EF=BF=BDin the >>>>>> =EF=BF=BD =EF=BF=BD> distributed deployment as you su= ggest, are we >>>>>> also going to >>>>>> =EF=BF=BD =EF=BF=BDwarn them of >>>>>> =EF=BF=BD =EF=BF=BD> non-scalability in the proxied o= ne? =EF=BF=BDI really >>>>>> don't see much >>>>>> =EF=BF=BD =EF=BF=BDmerit in the >>>>>> =EF=BF=BD =EF=BF=BD> idea of warning about design cho= ices. =EF=BF=BDMany such >>>>>> choices are >>>>>> =EF=BF=BD =EF=BF=BDtechnical, and >>>>>> =EF=BF=BD =EF=BF=BD> the issues are quite likely to b= e of little >>>>>> interest to >>>>>> =EF=BF=BD =EF=BF=BDnon-technical users >>>>>> =EF=BF=BD =EF=BF=BD> anyway. =EF=BF=BDIn any case, th= e better services are >>>>>> likely to provide >>>>>> =EF=BF=BD =EF=BF=BDsuch >>>>>> =EF=BF=BD =EF=BF=BD> information in their online docu= mentation, I >>>>>> would guess. >>>>>> =EF=BF=BD =EF=BF=BD> >>>>>> =EF=BF=BD =EF=BF=BD> You mentioned users "voting with= their feet" or >>>>>> choosing to >>>>>> =EF=BF=BD =EF=BF=BDaccept the risk >>>>>> =EF=BF=BD =EF=BF=BD> of inconsistency. =EF=BF=BDWell = that will happen anyway, >>>>>> when services >>>>>> =EF=BF=BD =EF=BF=BDfail and >>>>>> =EF=BF=BD =EF=BF=BD> users get annoyed. =EF=BF=BDIf s= ome asset services refuse >>>>>> to send the >>>>>> =EF=BF=BD =EF=BF=BDrequested >>>>>> =EF=BF=BD =EF=BF=BD> items to some users, those servi= ces will get a >>>>>> bad reputation >>>>>> =EF=BF=BD =EF=BF=BDand people >>>>>> =EF=BF=BD =EF=BF=BD> will choose different asset serv= ices instead. >>>>>> =EF=BF=BDLikewise, if a >>>>>> =EF=BF=BD =EF=BF=BDworld service >>>>>> =EF=BF=BD =EF=BF=BD> proxies everything and so it can= 't handle a large >>>>>> number of >>>>>> =EF=BF=BD =EF=BF=BDassets or of >>>>>> =EF=BF=BD =EF=BF=BD> people, users will get annoyed a= t the lag and will >>>>>> go >>>>>> =EF=BF=BD =EF=BF=BDelsewhere. =EF=BF=BDThis user >>>>>> =EF=BF=BD =EF=BF=BD> evaluation and "voting with thei= r feet" happens >>>>>> already with >>>>>> =EF=BF=BD =EF=BF=BDonline services >>>>>> =EF=BF=BD =EF=BF=BD> all over the Internet, and I am = sure that this >>>>>> human process >>>>>> =EF=BF=BD =EF=BF=BDwill continue >>>>>> =EF=BF=BD =EF=BF=BD> to work when the services are as= set and region >>>>>> services. >>>>>> =EF=BF=BD =EF=BF=BD> >>>>>> =EF=BF=BD =EF=BF=BD> Back in September 2010, I wrote = this post which >>>>>> proposes that >>>>>> =EF=BF=BD =EF=BF=BDwe use in >>>>>> =EF=BF=BD =EF=BF=BD> VWRAP a form of asset addressing= that provides >>>>>> massive >>>>>> =EF=BF=BD =EF=BF=BDscalability at the >>>>>> =EF=BF=BD =EF=BF=BD> same time as a very high degree = of resilience -- >>>>>> =EF=BF=BD =EF=BF=BD> >>>>>> =EF=BF=BD >>>>>> =EF=BF=BD >>>>>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html >>>>>> =EF=BF=BD =EF=BF=BD. =EF=BF=BDIt is >>>>>> =EF=BF=BD =EF=BF=BD> based on the concept of the URI = containing a host >>>>>> part and a >>>>>> =EF=BF=BD =EF=BF=BDhash part, >>>>>> =EF=BF=BD =EF=BF=BD> where the hash is generated (onc= e, at the time of >>>>>> storage to >>>>>> =EF=BF=BD =EF=BF=BDthe asset >>>>>> =EF=BF=BD =EF=BF=BD> service) using a specified diges= t algorithm over >>>>>> the content of >>>>>> =EF=BF=BD =EF=BF=BDthe asset >>>>>> =EF=BF=BD =EF=BF=BD> being referenced. =EF=BF=BDYou m= ay wish to note that if >>>>>> this design >>>>>> =EF=BF=BD =EF=BF=BDwere used, the >>>>>> =EF=BF=BD =EF=BF=BD> failure of an asset service to d= eliver a >>>>>> requested item would >>>>>> =EF=BF=BD =EF=BF=BDresult in a >>>>>> =EF=BF=BD =EF=BF=BD> failover request for the item to= one or more >>>>>> backup services, >>>>>> =EF=BF=BD =EF=BF=BDusing the same >>>>>> =EF=BF=BD =EF=BF=BD> hash part but with a different h= ost address. >>>>>> =EF=BF=BD =EF=BF=BD> >>>>>> =EF=BF=BD =EF=BF=BD> This can go some way towards ove= rcoming the >>>>>> problem that you >>>>>> =EF=BF=BD =EF=BF=BDthink might >>>>>> =EF=BF=BD =EF=BF=BD> occur when assets are fetched by= clients from >>>>>> asset services >>>>>> =EF=BF=BD =EF=BF=BDdirectly. >>>>>> =EF=BF=BD =EF=BF=BD> Although it won't help when the = missing item is >>>>>> available from >>>>>> =EF=BF=BD =EF=BF=BDonly a single >>>>>> =EF=BF=BD =EF=BF=BD> asset service, it will help in m= any other cases, >>>>>> and it will >>>>>> =EF=BF=BD =EF=BF=BDcompensate for >>>>>> =EF=BF=BD =EF=BF=BD> service failures and network out= ages >>>>>> automatically at the same >>>>>> =EF=BF=BD =EF=BF=BDtime. >>>>>> =EF=BF=BD =EF=BF=BD> >>>>>> =EF=BF=BD =EF=BF=BD> PS. This design for hash-based a= sset addressing >>>>>> is already >>>>>> =EF=BF=BD =EF=BF=BDbeing tested by >>>>>> =EF=BF=BD =EF=BF=BD> Mojito Sorbet in her experimenta= l world and >>>>>> client. =EF=BF=BDIt would give >>>>>> =EF=BF=BD =EF=BF=BD> VWRAP-based worlds an improved l= evel of service >>>>>> availability, >>>>>> =EF=BF=BD =EF=BF=BDso I think it >>>>>> =EF=BF=BD =EF=BF=BD> should be a core feature of our = protocol. >>>>>> =EF=BF=BD =EF=BF=BD> >>>>>> =EF=BF=BD =EF=BF=BD> >>>>>> =EF=BF=BD =EF=BF=BD> Morgaine. >>>>>> =EF=BF=BD =EF=BF=BD> >>>>>> =EF=BF=BD =EF=BF=BD> >>>>>> =EF=BF=BD =EF=BF=BD> >>>>>> =EF=BF=BD =EF=BF=BD> >>>>>> =EF=BF=BD =EF=BF=BD> =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 >>>>>> =EF=BF=BD =EF=BF=BD> >>>>>> =EF=BF=BD =EF=BF=BD> On Fri, Apr 1, 2011 at 11:17 PM,= Vaughn Deluca >>>>>> =EF=BF=BD =EF=BF=BD>>>>> >>>>>> >>>>> >> >>>>>> =EF=BF=BD =EF=BF=BD> wrote: >>>>>> =EF=BF=BD =EF=BF=BD>> >>>>>> =EF=BF=BD =EF=BF=BD>> This is a question i discussed = with Morgaine >>>>>> off-list a while >>>>>> =EF=BF=BD =EF=BF=BDago (I >>>>>> =EF=BF=BD =EF=BF=BD>> intended to send it to the list= but pushed the >>>>>> wrong button...) I >>>>>> =EF=BF=BD =EF=BF=BD>> think we need to address this p= roblem, and >>>>>> decide how to deal >>>>>> =EF=BF=BD =EF=BF=BDwith it. >>>>>> =EF=BF=BD =EF=BF=BD>> >>>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDIn Davids deployment d= raft, section 7.3.1.1 an >>>>>> overview is >>>>>> =EF=BF=BD =EF=BF=BDgiven van >>>>>> =EF=BF=BD =EF=BF=BD>> ways to deliver content to the = region. One way >>>>>> is only passing a >>>>>> =EF=BF=BD =EF=BF=BD>> capability that allows access t= o (part of) the >>>>>> resource: >>>>>> =EF=BF=BD =EF=BF=BD>> >>>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD 7.3.1.1. =EF=BF=BDContent delivery models >>>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD A range of possible represenations can >>>>>> be passed to >>>>>> =EF=BF=BD =EF=BF=BDa region for >>>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD simulation. [...] The other end of the >>>>>> delivery spectrum >>>>>> =EF=BF=BD =EF=BF=BD>> involves passing >>>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD only a URI or capability used to >>>>>> access the rendering >>>>>> =EF=BF=BD =EF=BF=BD>> information and a >>>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD collision mesh,and related data for >>>>>> physical simulation. >>>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD In such a model, the client is >>>>>> responsible for >>>>>> =EF=BF=BD =EF=BF=BDfetching the >>>>>> =EF=BF=BD =EF=BF=BD>> additional >>>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD information needed to render the >>>>>> item's visual >>>>>> =EF=BF=BD =EF=BF=BDpresence from a >>>>>> =EF=BF=BD =EF=BF=BD>> separate >>>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD service. =EF=BF=BDThis fetch can be done >>>>>> *under the >>>>>> =EF=BF=BD =EF=BF=BDcredentials of the >>>>>> =EF=BF=BD =EF=BF=BD>> end user* >>>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD viewing the material [my emphasis--VD] >>>>>> , and >>>>>> =EF=BF=BD =EF=BF=BDdivorces the >>>>>> =EF=BF=BD =EF=BF=BD>> simulation from >>>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD the trust chain needed to manage >>>>>> content. =EF=BF=BDAny >>>>>> =EF=BF=BD =EF=BF=BDautomation >>>>>> =EF=BF=BD =EF=BF=BD>> is done on a >>>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD separate host which the content >>>>>> creator or owner trusts, >>>>>> =EF=BF=BD =EF=BF=BD>> interacting with the >>>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BD =EF=BF=BD =EF=BF=BD = =EF=BF=BD =EF=BF=BD object through remoted interfaces. >>>>>> =EF=BF=BD =EF=BF=BD>> >>>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDI can see the need for= such a setup, however, i >>>>>> feel we are >>>>>> =EF=BF=BD =EF=BF=BD>> unpleasantly close to a situati= on were the >>>>>> coherence of the >>>>>> =EF=BF=BD =EF=BF=BDsimulation >>>>>> =EF=BF=BD =EF=BF=BD>> falls apart. >>>>>> =EF=BF=BD =EF=BF=BD>> In this deployment pattern the = region advertises >>>>>> the presence >>>>>> =EF=BF=BD =EF=BF=BDof the >>>>>> =EF=BF=BD =EF=BF=BD>> asset, and *some* clients will = be able to get it >>>>>> as expected, >>>>>> =EF=BF=BD =EF=BF=BDwhile >>>>>> =EF=BF=BD =EF=BF=BD>> -based on the arbitrary whims o= f the asset >>>>>> service- others >>>>>> =EF=BF=BD =EF=BF=BDmight not. >>>>>> =EF=BF=BD =EF=BF=BD>> >>>>>> =EF=BF=BD =EF=BF=BD>> My hope would be that after the= asset server >>>>>> provides the >>>>>> =EF=BF=BD =EF=BF=BDregion with >>>>>> =EF=BF=BD =EF=BF=BD>> the capability to get the asset= , it gives up >>>>>> control. That >>>>>> =EF=BF=BD =EF=BF=BDwould mean >>>>>> =EF=BF=BD =EF=BF=BD>> that if the client finds the in= ventory server is >>>>>> unwilling to >>>>>> =EF=BF=BD =EF=BF=BDserve >>>>>> =EF=BF=BD =EF=BF=BD>> the content - in spire of the r= egion saying it >>>>>> is present-, >>>>>> =EF=BF=BD =EF=BF=BDthe client >>>>>> =EF=BF=BD =EF=BF=BD>> should be able to turn around a= sk the *region* >>>>>> for the asset, >>>>>> =EF=BF=BD =EF=BF=BD(and get >>>>>> =EF=BF=BD =EF=BF=BD>> is after all). >>>>>> =EF=BF=BD =EF=BF=BD>> >>>>>> =EF=BF=BD =EF=BF=BD>> =EF=BF=BDIf that is not the cas= e, -and there are >>>>>> probably good reasons >>>>>> =EF=BF=BD =EF=BF=BDfor the >>>>>> =EF=BF=BD =EF=BF=BD>> deployment pattern as described= - =EF=BF=BDshouldn't we >>>>>> *warn* clients >>>>>> =EF=BF=BD =EF=BF=BDthat the >>>>>> =EF=BF=BD =EF=BF=BD>> region might be inconsistent, s= o the users >>>>>> behind the client >>>>>> =EF=BF=BD =EF=BF=BDcan vote >>>>>> =EF=BF=BD =EF=BF=BD>> with their feet, (or take the r= isk)? >>>>>> =EF=BF=BD =EF=BF=BD>> >>>>>> =EF=BF=BD =EF=BF=BD>> --Vaughn >>>>>> =EF=BF=BD =EF=BF=BD>> _______________________________= ________________ >>>>>> =EF=BF=BD =EF=BF=BD>> vwrap mailing list >>>>>> =EF=BF=BD =EF=BF=BD>> vwrap@ietf.org >>>>>> > >>>>>> >>>>>> =EF=BF=BD =EF=BF=BD>> https://www.ietf.org/mailman/li= stinfo/vwrap >>>>>> =EF=BF=BD =EF=BF=BD> >>>>>> =EF=BF=BD =EF=BF=BD> >>>>>> =EF=BF=BD =EF=BF=BD> ________________________________= _______________ >>>>>> =EF=BF=BD =EF=BF=BD> vwrap mailing list >>>>>> =EF=BF=BD =EF=BF=BD> vwrap@ietf.org >>>>>> > >>>>>> >>>>>> =EF=BF=BD =EF=BF=BD> https://www.ietf.org/mailman/lis= tinfo/vwrap >>>>>> =EF=BF=BD =EF=BF=BD> >>>>>> =EF=BF=BD =EF=BF=BD> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -------------------------------------------------------------------= ----- >>>>>> >>>>>> _______________________________________________ >>>>>> vwrap mailing list >>>>>> vwrap@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/vwrap >>>>>> =EF=BF=BD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- --- https://twitter.com/Dzonatas_Sol --- >>>>>> Web Development, Software Engineering, Virtual Reality, Consultan= t >>>>>> >>>>>> _______________________________________________ >>>>>> vwrap mailing list >>>>>> vwrap@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/vwrap >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> --- https://twitter.com/Dzonatas_Sol --- >>>>> Web Development, Software Engineering, Virtual Reality, Consultant >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> >>> vwrap mailing list >>> vwrap@ietf.org >>> https://www.ietf.org/mailman/listinfo/vwrap >>> >>> >> > --0016367d4f048a47b804a0903310 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think there's a bit of a misunderstanding about the nature of a "= ;message", Vaughn.=C2=A0 I'll see if I can describe it a little be= tter further down.


    On Sat, Apr 9, 2011 at 10:31 PM, Vaughn Deluc= a <vaughn.d= eluca@gmail.com> wrote:

    You can't =C2=A0eliminate those messages even when not checking= =20 credentials. The roundtrips are anyhow needed to make sure that the=20 communication is actually working. Or can we really get away with an UDP style of send and pray?? I fail to see how you would be able to realise a substantial gain over what will be needed anyhow as bare bone=20 infrastructure and for error checking/reporting. =C2=A0But i might be wrong= .


    In the open content use cases th= at I described in my previous reply, we can eliminate entirely the request-= grant handshake messages which handle caps, because the caps are only there= as a roadblock against obtaining the item.=C2=A0 When an item is unrestric= ted, a roadblock against obtaining it is obviously inappropriate.=C2=A0 Wha= t's more, once you have actually obtained the item, a roadblock against= obtaining it again is inappropriate as well, since you will continue to ha= ve the item unless you choose to delete it, in our data model.=C2=A0 What t= his intrinsically means is that caps are only meaningful as a mechan= ism for obtaining the direct address of an item.=C2=A0 In the case of open = content, we already have that direct address. :-)

    With regard to message transports, you mention "UDP style", b= ut our messaging is not related in any way to UDP (not sure what "styl= e" means), as we are talking about reliable messaging running over TCP= in all of this.=C2=A0 A message will always be received reliably if it is = sent successfully.=C2=A0 There is no return message confirming receipt need= ed at our level because the TCP stream does all that under the hood.

    A TCP session will be maintained between any two endpoints which exchan= ge one or more protocol messages.=C2=A0 In an efficient implementation, the= same TCP stream will carry the response message back too, since messages c= an be sent over a TCP stream in both directions regardless of who initiated= the connection.

    When we speak of a message sent from A to B, we're referring to the= message payload sent by A and received by B across such a TCP stream, and = we're specifically not referring to the IP datagrams which are s= ent in both directions between A and B to implement the single-direction A-= >B message transfer.=C2=A0 Our protocol messaging is at one level of abs= traction higher than that of the packets which implement the TCP stream.
    (It may actually be two levels higher if our message payload is carried= by HTTP over TCP.)

    In numerous places in your protocol flows, whene= ver the agent wishes to introduce an asset into the region, a capability fo= r the asset is first requested from the asset service, and such a capabilit= y must be granted before the asset can be fetched by any party.=C2=A0 This = entails a minimum of two message trip times before the asset itself is even= requested.=C2=A0 Even if both request and grant messages are efficiently c= arried on the same TCP stream, there is still the full request-grant round = trip time involved here whenever this operation is performed.

    This is quite unnecessary when there are no distribution restrictions o= n the item and you already have its direct address.=C2=A0 I'll e= xplain this step in detail because we have not really discussed the nature = of inventories and metadata much on this list before, and they are relevant= to asset access.

    First of all, just to be sure that we're on the same page, an inven= tory is just a tree structure containing asset metadata at its leaves.=C2= =A0 It is not, for the purposes of this discussion, the graphical thing tha= t appears in viewers as "Inventory", even though the two are stro= ngly related.

    Assets that an agent wears are always assets that are held in an agent&= #39;s inventory.=C2=A0 When an asset is in inventory, this implicitly means= that its metadata has been fetched and received, and under normal operatio= n this asset metadata will be in the viewer's inventory cache.=C2=A0 Af= ter all, you can't expect to wear an item when you don't know wheth= er it is a shoe or a shirt, so the metadata must have been received = previously for you to be able to even begin a request to wear it.

    Because the asset's metadata is already known, both the agent servi= ce and the client also already know whether the item has access restriction= s on it or not, because that information is an asset property present in th= e asset's metadata.=C2=A0 Knowing that it is not burdened with access r= estrictions, a viewer can perform a direct fetch of the asset from the asse= t service without any need for credentials, because credentials are irrelev= ant for this.=C2=A0 Caps are not needed at all in this case, and it is high= ly likely that this will be the most common situation in open worlds, which= makes it a very important use case.

    It is worth noting that while inventories are mostly a client-side impl= ementation detail which can be changed unilaterally, the metadata he= ld by inventories is a very important and separable information type in an = architecture that uses 3rd party asset services, so it needs detailed exami= nation.

    The metadata has to be available to remote parties in the same way as t= he data itself is, and the best way of handling this is to make metadata a = separate item normally stored in the same asset service as the data.=C2=A0 = The metadata item will naturally reference the corresponding data item (whi= ch is an N:1 relationship when hash-based addressing is used), and in some = cases can reference more than one data item --- for example, the metadata o= f a mesh will commonly reference not only the graphical data required for r= endering in the client but also the collision mesh or bounding box data req= uired by the region.=C2=A0 These two types of data are separate because it = would be inefficient to require clients or regions to download data that th= ey do not use.=C2=A0 Our "asset" singleton now turns into a metad= ata + data pair.

    As a final point about metadata versus data, it should be mentioned tha= t generally only the data ever has access restrictions placed on it, becaus= e placing restrictions on metadata leads to unsearchable inventories for wh= ich the technical term is "annoying as hell", or more seriously, = poorly functionality and yet another source of lag.=C2=A0 I am going to ass= ume that nobody wants that and hence, that metadata is never accessed throu= gh capabilities.=C2=A0 If anyone wants to suffer the burden of capabilities= for metadata then they are welcome to do so of course, just as long as the= rest of us do not have to:=C2=A0 "the burden of a facility should = be borne only by those who need it".=C2=A0 In the model that I am = describing, metadata is directly addressed and has the same protection as a= cryptographic key:=C2=A0 the address of metadata is an unguessable address= , but once you know it, you know it.
    =C2=A0
    Now that we understand metadata, let's look at how this aff= ects regions.

    Regions don't have access to your inventory, but t= hey do have access to the metadata of each item that is part of the region&= #39;s simulation, for numerous reasons.=C2=A0 The primary reason is of cour= se that the metadata contains one or more references to needed data, but th= ere are other reasons too.=C2=A0 For example, the region may wish to ensure= that every item in its region space has specific properties which are desc= ribed in item metadata, such as lack of access restrictions, or the opposit= e, requiring certain access restrictions.=C2=A0 (Note that your requirement= for simulation consistency can be implemented very cleanly that way too --= - just add something like Boolean:RegionConsistency to the set of asset pro= perties).=C2=A0 As another example, the region may wish to ensure that ever= y item in its space is properly tagged to support accessibility, so the ite= m type and item descriptions typically held in metadata would then be impor= tant.

    Now that we've progressed to this level of detail, we can at last s= tate precisely what happens when agents inform the region of the items that= they are wearing as avatars:=C2=A0 they are supplying to the region the ad= dresses of the relevant metadata items.=C2=A0 The region then fetches those= metadata items from the asset service (unless it already has them in cache= ), and then on the basis of that metadata, the region begins its decision m= aking about whether to allow the asset to appear in its region or not.=C2= =A0 If the metadata indicates that no access restrictions are required, the= n the region can send the metadata URIs directly to clients.=C2=A0 In contr= ast, if the metadata says that the asset data has restricted access, then t= he region has to engage its more onerous access control mechanisms, ie. it = first obtains an AssetAllowedInRegion capability for the asset from = the asset service, which it then passes to all clients.

    Note that this is only one particular design for our protocol flows, an= d no doubt other designs can achieve the same functionality and efficiency.= =C2=A0 I expect you were trying to keep things simple for an initial diagra= m, but as we get into the detail we have to start considering the role that= metadata plays in asset access because this is actually central to the eff= ective operation of external asset services.=C2=A0 Your diagram doesn't= get down to the level of metadata access, but we cannot avoid it when we h= ave external asset services.

    A final point about metadata, before this email gets too long.=C2=A0 Th= ere may be many thousands or even millions of instances of a common asset h= eld in people's inventories, such as those used by default avatars, or = trees and plants and other objects or textures common in the environment, a= nd many others.=C2=A0 Both our asset services and our caches need store tho= se data items only once when we use hash-based addressing, instead of milli= ons of times.=C2=A0 The reason we can make this remarkable saving of space = is because the metadata is stored as separate items and holds detail= s such as "ownership" separately, while in terms of storage all t= hose different metadata items can point at the same asset data.

    That N:1 relationship between metadata and data is important as we desi= gn our protocols, because it allows us to avoid those unhelpful and ineffic= ient designs that require us to download something just to determine whethe= r we wanted to download it.=C2=A0 By separating the two types of informatio= n, we gain a lot, but it does mean that "asset" cannot be treated= as a monolithic entity as in your diagram.=C2=A0 As we hone our design fur= ther, metadata fetches enter the picture.


    Morgaine.




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

    On S= at, Apr 9, 2011 at 10:31 PM, Vaughn Deluca <vaughn.deluca@gmail.com> wro= te:
    Morgaine,=C2=A0
    Thanks for the compliments and the extensive comments =C2= =A0:)
    I am in a time crunch, so i will only respond to one aspect of your ma= il, and come back to some other points later.

    I am not sure i understand your emphasis on the (non)tr= ansfer of trust info to gain speed. When drafting the diagram I was thinkin= g that depending on the =C2=A0"domain" of the sender of the messa= ge =C2=A0(with domain defined in the classical sense of a range of IP addre= sses) the authorisation info might =C2=A0simply be dropped and the data use= d without further checking if the receiver wishes to do so. Also since in t= he majority of cases only caps are passed that contain *implicit* trust. Th= e checking of the validity of the cap is local to the service, and should b= e really fast.

    Regarding capabilities, i was viewing them not so= much as credentials (although they are) but more
    as a convenient= way to pass references to some bit of underlaying data around. You can'= ;t =C2=A0eliminate those messages even when not checking credentials. The r= oundtrips are anyhow needed to make sure that the communication is actually= working. Or can we really get away with an UDP style of send and pray?? I = fail to see how you would be able to realise a substantial gain over what w= ill be needed anyhow as bare bone infrastructure and for error checking/rep= orting. =C2=A0But i might be wrong.

    One way way to find out is to implement it, and I feel = that we are getting closer to be able to do just that.=C2=A0

    =
    -- Vaughn


    On Sat, Apr 9, 20= 11 at 1:18 AM, Morgaine <morgaine.dinova@googlemail.com&g= t; wrote:
    Excellent work, V= aughn!

    You're right, I am working on something related to this, = specifically a design study for the Tourism use case.=C2=A0 It happens to e= nd with a protocol sequence diagram presented as a table of text, so I was = very pleased to see your highly relevant diagram.=C2=A0 Yours captures part= of my use case, and it's a lot prettier than my text format. :P

    I was particularly impressed by the way you start off with completely s= eparable services right from the start.=C2=A0 Since separable services can = be put together under a single administrative domain very easily, whereas s= eparating conjoined services is not easy at all, I think you've started= this off perfectly for the VWRAP approach to services.

    Because you have separated the services so well, your suggested protoco= l flow could be said to to be targeting some kind of "superset of a= ll VWRAP deployments" deployment. :-)=C2=A0 Although it's logi= cally structured, it's a sort of worst-case scenario (or lawyer's d= elight) in which everyone has to ask everyone else for permission to do any= thing, regardless of whether permission is actually required or not.

    That's viable, but less than optimal.=C2=A0 Specifically, you are w= orking to the principle of "The heaviest burden required by anyone mus= t be borne by everyone."=C2=A0 I have been trying to stick to the oppo= site principle of "A burden should be borne only by those whose use ca= se requires it", which is both fairer and more efficient.

    To illustrate this, consider the case of an asset service which serves = (by choice) only Creative Commons licensed assets --- an extremely importan= t use case which could well become the dominant one in an open metaverse of= community worlds.=C2=A0 Who knows, it could be operated by Debian, or Blen= der, or OSgrid, or even Google Warehouse. :P

    In such a scenario, because the license on all the assets in the asset = service permits unchecked distribution to all destinations in perpetuity, t= he vast majority of all the request-grant protocol flows in your diagram ar= e superfluous when the assets come from this repository.=C2=A0 By using a p= rotocol which understands WHEN it needs to ask a question, a large a= mount of cumulative round-trip time latency (and its resulting lag) can be = avoided entirely.=C2=A0 This is also true on a per-asset basis if an asset = service serves a mixture of encumbered and freely distributable assets, exc= ept that then the difference would be seen per-asset instead of per asset s= ervice.

    For such freely distributable assets, the agent service doesn't nee= d to do anything at all beyond recording the addresses of assets which are = currently being worn by the agent.=C2=A0 Since you start off your trip (sen= sibly) by checking your clothing at home before you leave, you'll notic= e a broken asset service locally anyway since your viewer will be trying to= fetch it for local viewing.=C2=A0 The agent service need do nothing at all= , beyond record the addresses of top level items.=C2=A0 (In my design study= , I refer to a Worn Assets List which is held by the user's agen= t service, and which is entirely separate from any concept of inventory.)
    Likewise, region services don't need to fetch the graphic assets no= rmally either (unless they opt to proxy them), but only pass the addresses = of those assets around to all the other agents in the corresponding region,= so the request-grant exchanges between regions and asset services can be a= voided in this case.=C2=A0 (Regions will be requesting other server-side da= ta though, for example the bounding box information or collision mesh of an= asset, which typically the viewer would not be fetching.)

    That's not the end of the "no unnecessary burden" = issue yet though, because even if you removed all the unnecessary request-g= rant protocol flows, you're still making the incorrect assumption that = assets ALL NEED TO BE RESTRICTED by the mere fact of asking for caps= to everything.=C2=A0 This itself is wrong.=C2=A0 The logic need to first d= etermine whether a cap is needed for fetching a given asset, and if it'= s not needed then the fetch can be done by the viewer or region without thi= s protocol burden at all.

    So you see, there is a fundamental assumption in your nicely laid out f= lows that all assets must be tied up in heavy red tape by the needs of the = most burdensome use case.=C2=A0 I don't agree with that, neither on pri= nciple nor on engineering grounds.

    Many of the flows you have shown are exactly what we need for securing = access to proprietary resources, but not all resources have that burden, an= d I would want to elide a number of the flows away entirely when an asset s= ervice allows it.

    To put it another way, the data is king, and protocol flows should refl= ect the requirements imposed by data, not the other way around.

    I ne= ed this expressed in your flows, possibly as asset requirement annotations.=


    PS.=C2=A0 Great work Vaughn, I think this gives us a wonderful laun= ching point!


    Morgaine.



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

    On Fri, Apr 8, 2011 at 5:40 PM, Vaughn Deluca = <vaughn.del= uca@gmail.com> wrote:
    =
    VWRAP services high level message flow (preliminary di= agram draft) see


    The main reason that i am submitting this in spit= e of my lack of formal expertise is that the group in my view badly needs a= solid basis for discussion and preventing endless repeating loops. This ex= ample is probably wrong in many ways, but its better than what we have publ= icly available on interop now (although Morgaine is working on something al= ong the lines of the recent discussions here)=C2=A0

    I hope this diagram will give us a base for discussion.= I could have done my homework better by researching the old OGP stuff in m= ore depth, and i probably =C2=A0will do so in the future , but for now I ju= st tried to followed the general principles as far as i understand them, to= see what response that yields from the group. In other words,I try to let = the group educate me :p

    Note that in =C2=A0my view all services are equal, in p= rinciple it does not matter in what "domain" they run, since trus= t and policy are fully localized. It is however very possible to have inter= nal shortcuts in the services to speed up processing.=C2=A0

    In the example I opted for an external Agent service, b= ut I could as well have incorporated that in the set of local services. As = indicated above all services could also be run by different organisations, = true to what VWRAP stands for. Its all up to the deployer, including a user= at home who might want to run a full world for family and friends. Those f= riends might try to use that agent service to venture out in the virtual un= iverse.=C2=A0
    I envision that the final identity =C2=A0provider is external, using O= penID and OAut =C2=A0or whatever other =C2=A0magic that I do not yet fully = understand exists out there.

    The =C2=A0example has= 3 main purposes:
    - =C2=A0Provide a reference for discussion=C2=A0
    - Illustrat= es the use case of tourism, and *true* interop.
    - Illustrate cons= istency problems along the lines discussed =C2=A0here higher up in this tre= ad, as well as the "slashdot" problem that Morgaine outlined so c= learly.

    The message flow assumes an avatar already present in s= ome region, (a small scale local home region in this case, but that is by n= o means essential, it could be a build in region in the viewer or a big com= mercial region). The user is preparing for a trip to immersive world, and a= fter some outfit adjustments moves over.=C2=A0

    Finally i apologize for for the simplistic notation use= d here. I simply add the most relevant parameters passed in square brackets= to a keyword specifying the nature of the message. Please improve on that = where needed.

    So here we go, the avatar is =C2=A0prepare for a visit = to "immersive world"
    0) =C2=A0Viewer, here is an update= of the state of the world your agent is in, please render.
    1) = =C2=A0Agent service, I will go in my Zodiac dress that i keep in the =C2=A0= "Amazing assets" service.
    2) =C2=A0Asset service A, please send a cap for Z, here are my credent= ials
    3) =C2=A0Your fine, here is the cap
    4) =C2=A0Local= region, can you please put this on my agent, i included the cap.
    5) =C2=A0Hello asset service A, i need Z, here is the cap
    6) =C2=A0Cap is good, data coming up, have fun.
    7) =C2=A0Age= nt service, your agent is now wearing Z
    8) =C2=A0Viewer, your ava= tar is now wearing Z
    =C2=A0=C2=A0 =C2=A0User: Hmm, amazing invent= ory has not been *that* amazing lately. 'll make a backup, just in case=
    9) =C2=A0Hello asset service A, please send me a cap for Z, here are m= y credentials
    10) Your fine, here is the cap
    11) Local = asset storage, please store Z for me, here is the cap to get it
    1= 2) Hello asset service A, i want Z, here is the cap
    13) Cap is good, data coming up, have fun.
    14) Viewer, Z is = now stored for you=C2=A0
    =C2=A0=C2=A0 =C2=A0User: I am Ready!, Le= ts try to get to immersive world!
    15) Hello immersive world, can = i get in? Here are my credentials, and a list of my stuff.
    16) Asset service A, please send me a cap for X, here are my credentia= ls (I want this cap for consistency)
    17) Your fine, here is the c= ap
    18) Asset service B, please send me a cap for Y, here are my c= redentials (I want this cap for consistency)
    19) Very sorry, but your not one of us, you can't have Y
    20) Asset service B, please send me a cap for Z, here are my credentials (= I want a cap for consistency)
    [Region service: Timeout... amazing= inventory must be overloaded.. oh well... ]
    21) Agent service, you wanted to send somebody over, here are your per= missions.
    22) Viewer, you asked for a transfer try, here are your= results
    =C2=A0=C2=A0 =C2=A0 User thinks: =C2=A0Crap! Big asset s= ervice does not allow =C2=A0me to take my yellow stockings! And Amazing ass= ets =C2=A0failed to deliver my zodiac dress. At least i made a backup of th= at dress!
    23) 'll take the yellow stockings off...
    24) ... done (&= #39;ll trash them here and now, forever, who needs stuff you can't use!= )
    25) The zodiac dress was not delivered by Big assets service, b= ut i have a local copy!
    26) Local Asset service, please send me Z, here are my credentials
    27) I dont know you, but I 'll trust you, here is the cap, but y= ou better store the data, its single use, i need to protect myself.
    28) Local region, can you please put this on my agent, i include the c= ap.
    29) Local Asset service, i need Z, here is the cap
    = 30) Cap is good, data coming up, have fun.
    31) Cap was only good = for one time, I made a copy, but my policy is to only grant you fair use ri= ghts, at a later time i might even tell you to replace the dress.
    32) Viewer, you can wear Z for now, but the asset service granted only= fair use, i might ask you to replace the dress at a later time.
    = 33) Ready at last! Off to immersive world!, I hope its not to crowded there= or 'll loose my dress...
    34) Hello immersive world, here are my credentials, and a list of stuf= f i want to bring
    35) Hello asset service A, please send me a cap= for X, here are my credentials=C2=A0
    =C2=A0=C2=A0 =C2=A0[darn, I= should have kept that cap from last time..]
    36) Your fine, here is the cap.
    =C2=A0=C2=A0 [Region service= finds fair-use warning on Z and decides to make its own copy]
    37= ) Hello Local region, can i still have Z? Here is the cap=C2=A0
    3= 8) Cap is still good, data coming up, have fun.
    =C2=A0=C2=A0 [Region service stores asset in private storage, providin= g a cap to replace the fair use one]
    39) Agent service, you wante= d to send somebody over, here are your permissions & info.
    40= ) Hello immersive world, just =C2=A0get me there, and use what you can
    41) Placement done, Z is currently buffered by us as wel, you need to = get details for X, have fun.
    42) You are now in immersive world, = your dress is buffered there as well, but you need to get X!
    43) Hello asset service A, i want X, here is the cap
    44) Cap is g= ood, data coming up, have fun.
    45) Viewer, here is an update of t= he state of the world your agent is in, please render.

    As far as I can see this conforms fully to our charter, and i hope it = is possible to use large portions of the existing code bases. However, as s= aid above, i did not really try to capture the old thinking, and I also mig= ht have misconceptions about the way to do these things in general.
    Looking forward to constructive comments.

    -- Vaughn

    On Sun, Apr 3, 2011 at 8:38 PM, Vaughn Deluc= a <vaughn.deluca@gmail.com> wrote:
    Thanks for the po= inters. =C2=A0I have a =C2=A0busy week in RL in front of me, so i wont have= to much time to respond the next few days, however, i intend to start doin= g the following things:

    - Produce a visual that reflects my thinking, i.e. an illust= ration of my response to Morgaine's itemlist =C2=A0above.
    - Read up on the older notes, as well as =C2=A0more reading= in the list archive
    - Try to make a summary for the wiki

    Regarding the use of domain, I think services are e= ventually what counts, but its all terminology. The way I read the AWG diag= rams is that the agent domain is actually a cluster of tightly integrated s= ervices. When the functionality of each sub-service is described properly a= nd with uniform interfaces the domain will slowly dissolve. But let not get= ahead of out selfs. We should put up some clear descriptions on the wiki f= or our views on this, and *after* that we can decide what we need and what = can go.

    Its been a very useful and illuminating weekend for me,= and i am a lot more optimistic about the future of vwrap than two weeks ag= o.

    -- Vaughn
    <= div>



    On Sun, Apr 3, 2011 at 7:20 = PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
    Probably easy as suggested in other terms here on this list, as how the cli= ent contacts the asset services now in the regions. The newer issue is to u= nitize that asset services. Since their is proprietary (legacy) code then w= e can't expect that to change, and some form of proxy is of need. Whate= ver works best, I tried to narrow it down to suggestions here.

    Eventually, the agent domain is ideal to handle the direction of the asset = services. This concept, unfortunately, ended support awhile ago with change= s in LL.
    Also see; http://wiki.secondlife.com/wiki/Agent_Domain
    And: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_A= sset (warn: unstructured collaborative notes, dumped on me and I tried = to fix)

    I tried to find previous visuals.

    I'd imagine the agent domain could grow out of unitized versions of ass= et services. Despite that, I think that concept helps view where we were at= in discussion and what didn't happen.

    Vaughn Deluca wrote:
    Hi=EF=BF=BDDzonatas

    Can you expand on that, what would be needed for legacy support in VWAP ter= ms=EF=BF=BD?,
    If i want to read up on how the=EF=BF=BDasset server may proxy the simulato= r, what would you recommend me to read?

    -- Vaughn

    On Sun, Apr 3, 2011 at 5:51 AM, Dzonatas Sol <dzonatas@gmail.com <mailto:dzonatas@gmail.com>>= wrote:

    =C2=A0 =C2=A0Some stated the proxy-to-asset-server is built into the sim;<= br> =C2=A0 =C2=A0however, keep in mind possible legacy support where the asset=
    =C2=A0 =C2=A0server may proxy the simulator.


    =C2=A0 =C2=A0Dzonatas Sol wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0Somehow I feel the basic asset server being abl= e to login and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0download assets is now priority, yet I also won= dered the best
    =C2=A0 =C2=A0 =C2=A0 =C2=A0way to patch this into the current mode of view= ers.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0Maybe offer (1) by proxy (sim-side) and (2) by = patch
    =C2=A0 =C2=A0 =C2=A0 =C2=A0(viewer-side) that either of these two are opti= onal and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0neither are mandatory for now. Thoughts?

    =C2=A0 =C2=A0 =C2=A0 =C2=A0Israel Alanis wrote:


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> when designing for scalabili= ty, the model to bear in
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mind is ...

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Well, there are a lot of differen= t models to keep in mind,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and many different use cases. One= particular use case to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0keep in mind is: "User acqui= res new outfit, and wants to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'show it off' in a highly= populated region".

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Both worlds and asset servic= es may include commercial,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0community, and personal services<= br>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, yes and yes. I'm particu= larly concerned about how the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0model affects the ability to host= personal asset services.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> a proxying region, which wou= ld get slammed for every
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0asset worn by every avatar presen= t.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Granted the collection of service= s that are provided by
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the region need to be scaled to m= eet the demands of that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0region. That's all part of ca= pacity planning.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> regions run many different C= PU-intensive tasks,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0including physics simulation and = server-side scripting,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and absolutely cannot afford to s= erve assets too
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Well... who said the same CPU'= ;s have to do proxying,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0physics simulation and server-sid= e scripting? Asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proxying is a different service t= han physics simulation
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and can be on separate hardware, = could make use of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0geographically distributed cachin= g, and in certain
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0deployment patterns, the same cac= hing services could be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0shared by different regions. (Ser= ver-side scripting is a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discussion for another day).

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> This is why we have to go pa= rallel...

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Totally agree, and a proxying mod= el could and should also
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0take advantage of parallelism.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I think you're wrong tha= t it has to cost much money. ?vs?
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> It costs money to host a hig= h performance and scalable
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0asset service and a high bandwidt= h network to handle the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0traffic. =EF=BF=BDA *lot* of mone= y.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I think what you're saying is= : "It costs a lot of money to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0build a scalable asset service, b= ut if assets are spread
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0throughout the internet they don&= #39;t have to be scalable."
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0But that's not quite right. Y= ou're opening up every asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server to the VW equivalent of be= ing slashdotted, so are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0you sure you're not forcing *= every* asset service to be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scalable and handle a lot of band= with and network traffic?
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It's the exact opposite of yo= ur intention, but I think
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that's the result, all the sa= me.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This particular design decision h= as a big effect on the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0economics of the VW infrastructur= e. I'd rather the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0economics to work out such that a= region provider who
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wishes to build a region that sup= ports a small population,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0can do so economically. A region = that wants to host a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*large* population has to bear th= at cost of providing that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scalable asset service.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I want the economics of hosting a= small asset service to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be a non-issue (as to best promot= e creation and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0creativity). Creating a high bar = to provide asset services
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0will mean that service will cost = money and people
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0shouldn't have to pay money j= ust to create or own VW
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0objects (I'm using 'own&#= 39; here to refer to maintaining
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0their existence, I'm not tryi= ng to make a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'leftist'/'communist&= #39; statement about ownership ;)

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Izzy


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Apr 2, 2011, at 3:58 PM, Morga= ine wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Izzy, when designin= g for scalability, the model to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bear in mind is tha= t of seasoned virtual world
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0travelers whose inv= entories contain assets from many
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0different worlds, t= hose assets being served by many
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0different asset ser= vices. =EF=BF=BDBoth worlds and asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0services may includ= e commercial, community, and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0personal services, = and as the metaverse grows, that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0set is highly likel= y to become progressively less
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clustered and more = diverse.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0When those seasoned= travelers click on an advertised
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0VW link and perform= an inter-world teleport to one
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0particular world= 9;s region to share an experience,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0their "worn&qu= ot; assets (the only ones of interest to the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0region) will contai= n references to asset services
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spread widely acros= s the Internet. =EF=BF=BDThe fetches by the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0travelers' clie= nts occur over many parallel paths from
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clients to asset se= rvices, so one can reasonably
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0expect reduced netw= ork contention and reduced asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server loading beca= use they are both spread out over
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0however many asset = services are being referenced by
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the overall set of = assets in the region.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This is very differ= ent to the case of a proxying
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0region, which would= get slammed for every asset worn
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by every avatar pre= sent. =EF=BF=BDIn our current architecture,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0regions run many di= fferent CPU-intensive tasks,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0including physics s= imulation and server-side
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scripting, and abso= lutely cannot afford to serve
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0assets too unless y= our scalability requirements are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0very low indeed, ie= . just a few dozen avatars of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0today's kind. = =EF=BF=BDWe've hit the ceiling already on region
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scalability done th= at way. =EF=BF=BDThere is nowhere to go in
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that direction at a= ll beyond improving the code like
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Intel demonstrated,= and that work is subject to a law
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of diminishing retu= rns.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This is why we have= to go parallel, and I think you're
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrong that it has t= o cost much money. =EF=BF=BDAs we spread
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the load across mor= e and more asset services, we are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0simply better utili= zing all the hardware that's
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0already out there o= n the Internet, at least in respect
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of community and pr= ivate resources. =EF=BF=BDBut add to the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0community and priva= te resources the commercial asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0services that are l= ikely to appear to exploit this
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opportunity, and no= t only will the number of asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0services leap, but = the power of each one will rocket
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0too, because, after= all, these businesses will be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0heavily optimized f= or the job.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As to why a world w= ould want clients to access
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0external asset serv= ices instead of providing its own
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implementation, tha= t's an easy question. =EF=BF=BDIt costs
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0money to host a hig= h performance and scalable asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0service and a high = bandwidth network to handle the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0traffic. =EF=BF=BDA= *lot* of money. =EF=BF=BDIn contrast, it costs a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0world nothing to le= t others serve the assets to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clients. =EF=BF=BDA= nd that matters to the bottom line.


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Morgaine.




    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, Apr 2, 2011= at 7:05 PM, Izzy Alanis
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<izzyalanis@gmail.com <mai= lto:izzyalanis@gm= ail.com>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:izzyalanis@gmail.com=

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:izzyalanis@gmail.com= >>> wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > As always though, it's a trade-off, since the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proxied design
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= has very poor scalability compared to the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0distributed one.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= I don't agree with that... If a user enters a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0highly populated =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= region,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= every other client is going to (could and should be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0trying to)
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= hit the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= asset server(s) for the assets that the user is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wearing (assuming =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= they're not cached locally). =EF=BF=BDEvery asset server
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has to be scaled up=
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= to the point that it can handle that load from all
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0over...

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= If I'm hosting a region that supports 10s of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0thousands of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= simultaneous
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= users (thinking of the future), I already have to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scale to meet that<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= demand. If the region is proxying the assets, then,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yes the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= region has
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= to be scaled to meet that asset demand too, but it
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0already has to be =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= scaled to meet other demands of being a region
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server... and why i= s
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= scaling those asset proxy services hard? =EF=BF=BDIt's
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0going to cost $, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= but is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= not technically challenging. So, if I want to host
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a region like
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= that... sure it will cost me, but the simulation
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0will be consistent<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= and users will be able to participate equally,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0regardless of the =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= capabilities of their individual asset services.




    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= On Fri, Apr 1, 2011 at 11:55 PM, Morgaine
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= <mor= gaine.dinova@googlemail.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:morgaine.dinov= a@googlemail.com>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= <mailto:morgaine.dinova@googlemail.com

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:morgaine.dinov= a@googlemail.com>>> wrote:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > Every design choice results in a trade-off,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vaughn, improving =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= one thing at
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > the expense of something else. =EF=BF=BDIf every time we
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0offered a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= service we had to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > inform its users about the downsides of all the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0trade-offs we
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= have made,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > they would have an awful lot to read. ;-)
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > The specific trade-off that you are discussing is no
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= different. =EF=BF=BDA region
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > that proxies all content has the "benefit" of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0acquiring control =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= from the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > asset servers over the items in the region, so
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that it can
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= ensure that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > everyone in the region not only obtains the items
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0but obtains
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= the same items
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > as everyone else. =EF=BF=BDThat does indeed provide a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0greater guarantee o= f
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > consistency than a deployment in which the region
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0only passes
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= asset URIs to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > clients who then fetch the items from asset services
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= separately. =EF=BF=BDAs always
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > though, it's a trade-off, since the proxied
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0design has very
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= poor scalability
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > compared to the distributed one.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > If we're going to warn users of the potential for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inconsistency
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= in the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > distributed deployment as you suggest, are we
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0also going to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= warn them of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > non-scalability in the proxied one? =EF=BF=BDI really
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0don't see much<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= merit in the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > idea of warning about design choices. =EF=BF=BDMany such
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0choices are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= technical, and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > the issues are quite likely to be of little
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interest to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= non-technical users
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > anyway. =EF=BF=BDIn any case, the better services are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0likely to provide =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= such
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > information in their online documentation, I
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0would guess.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > You mentioned users "voting with their feet" or
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0choosing to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= accept the risk
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > of inconsistency. =EF=BF=BDWell that will happen anyway,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0when services
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= fail and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > users get annoyed. =EF=BF=BDIf some asset services refuse
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to send the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= requested
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > items to some users, those services will get a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bad reputation
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= and people
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > will choose different asset services instead.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BDLikewise, = if a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= world service
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > proxies everything and so it can't handle a large
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0number of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= assets or of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > people, users will get annoyed at the lag and will go
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= elsewhere. =EF=BF=BDThis user
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > evaluation and "voting with their feet" happens
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0already with
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= online services
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > all over the Internet, and I am sure that this
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0human process
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= will continue
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > to work when the services are asset and region
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0services.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > Back in September 2010, I wrote this post which
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proposes that
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= we use in
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > VWRAP a form of asset addressing that provides
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0massive
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= scalability at the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > same time as a very high degree of resilience --
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BDhttp://www.ietf.org/mail-archive/web/vwrap/current/msg00463.htm= l
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= . =EF=BF=BDIt is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > based on the concept of the URI containing a host
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0part and a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= hash part,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > where the hash is generated (once, at the time of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0storage to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= the asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > service) using a specified digest algorithm over
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the content of
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= the asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > being referenced. =EF=BF=BDYou may wish to note that if
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this design
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= were used, the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > failure of an asset service to deliver a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0requested item woul= d
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= result in a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > failover request for the item to one or more
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0backup services, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= using the same
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > hash part but with a different host address.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > This can go some way towards overcoming the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0problem that you =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= think might
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > occur when assets are fetched by clients from
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0asset services
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= directly.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > Although it won't help when the missing item is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0available from
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= only a single
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > asset service, it will help in many other cases,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and it will
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= compensate for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > service failures and network outages
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0automatically at th= e same
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= time.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > PS. This design for hash-based asset addressing
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is already
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= being tested by
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > Mojito Sorbet in her experimental world and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0client. =EF=BF=BDIt= would give
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > VWRAP-based worlds an improved level of service
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0availability,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= so I think it
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > should be a core feature of our protocol.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > Morgaine.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > =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
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > On Fri, Apr 1, 2011 at 11:17 PM, Vaughn Deluca
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= <vaughn.del= uca@gmail.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vaughn.deluca@gmail.c= om>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vaughn.deluca@gmail.c= om
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vaughn.deluca@gmail.c= om>>>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > wrote:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> This is a question i discussed with Morgaine
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0off-list a while =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= ago (I
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> intended to send it to the list but pushed the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrong button...) I<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> think we need to address this problem, and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0decide how to deal<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= with it.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BDIn Davids deployment draft, section 7.3.1.1 an
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0overview is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= given van
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> ways to deliver content to the region. One way
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is only passing a =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> capability that allows access to (part of) the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0resource:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD 7.3.1.1. =EF=BF= =BDContent delivery models
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD A range of possi= ble represenations can
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be passed to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= a region for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD simulation. [...= ] The other end of the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0delivery spectrum =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> involves passing
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD only a URI or ca= pability used to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0access the renderin= g
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> information and a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD collision mesh,a= nd related data for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0physical simulation= .
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD In such a model,= the client is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0responsible for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= fetching the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> additional
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD information need= ed to render the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0item's visual =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= presence from a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> separate
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD service. =EF=BF= =BDThis fetch can be done
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*under the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= credentials of the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> end user*
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD viewing the mate= rial [my emphasis--VD]
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0, and
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= divorces the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> simulation from
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD the trust chain = needed to manage
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0content. =EF=BF=BDA= ny
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= automation
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> is done on a
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD separate host wh= ich the content
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0creator or owner tr= usts,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> interacting with the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD object through r= emoted interfaces.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BDI can see the need for such a setup, however, i
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0feel we are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> unpleasantly close to a situation were the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0coherence of the =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= simulation
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> falls apart.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> In this deployment pattern the region advertises
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the presence
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= of the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> asset, and *some* clients will be able to get it
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as expected,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= while
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> -based on the arbitrary whims of the asset
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0service- others
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= might not.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> My hope would be that after the asset server
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0provides the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= region with
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> the capability to get the asset, it gives up
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0control. That
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= would mean
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> that if the client finds the inventory server is
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unwilling to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= serve
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> the content - in spire of the region saying it
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is present-,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= the client
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> should be able to turn around ask the *region*
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for the asset,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= (and get
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> is after all).
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> =EF=BF=BDIf that is not the case, -and there are
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0probably good reaso= ns
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= for the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> deployment pattern as described- =EF=BF=BDshouldn't we
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*warn* clients
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= that the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> region might be inconsistent, so the users
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0behind the client =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= can vote
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> with their feet, (or take the risk)?
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> --Vaughn
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> _______________________________________________
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> vwrap mailing list
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> vwrap@ietf.org= <mailto:vwrap@i= etf.org>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:= vwrap@ietf.org>&= gt;

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >> https://www.ietf.org/mailman/listinfo/vwrap
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > _______________________________________________
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > vwrap mailing list
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > vwrap@ietf.org= <mailto:vwrap@ietf.= org>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:vwrap@ietf.org <mailto:= vwrap@ietf.org>&= gt;

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= > https://www.ietf.org/mailman/listinfo/vwrap
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD =EF=BF=BD= >



    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------------------------------= ---------------------------------------

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_________________________________= ______________
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vwrap mailing list
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vwrap@ietf.org <mailto:vwrap@ietf.org>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listi= nfo/vwrap
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BF=BD





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

    =C2=A0 =C2=A0_______________________________________________
    =C2=A0 =C2=A0vwrap mailing list


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




    _______________________________________________=

    vwrap mailing list
    vwrap@ietf.org



    --0016367d4f048a47b804a0903310-- From dzonatas@gmail.com Sun Apr 10 07:43:03 2011 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 B188A28C0DE for ; Sun, 10 Apr 2011 07:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.733 X-Spam-Level: X-Spam-Status: No, score=-2.733 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] 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 EKtngMiJZgPb for ; Sun, 10 Apr 2011 07:42: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 1A85E3A6922 for ; Sun, 10 Apr 2011 07:42:43 -0700 (PDT) Received: by pwi5 with SMTP id 5so2212650pwi.31 for ; Sun, 10 Apr 2011 07:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=j6bQ+LtCf1RZnxgLHGiM+EgtFGMm6riyOmOjwGBzH/8=; b=QcdcvdFbMECwFYki82R36eDr7ZBO9w84vNhbsKW+dBOF1Bz/kDhZkEtTFqB1u76l6S OMLvKmpCL1AVn2026M9iLQJCZR8xMsQKxo9f2H43B9XN3k2jRBMKwzlG94urS6s3LoIK 1ifKY/G+1UjlTwLaeaJP2WdFxdGboFEBU942g= 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=er5bYdsxJzgEgDsazHSgENtg3xg8geFb5hVSZiQbEu/KrJa/5I4Qo8IXTkrZnIadHF kFTBJPdqwUpyYCyQI8w6jYGzXdj9+xfQYFbolB845qUmWattpAbGXx1tt1+QsA3vu2x2 MZxx67Al0zUwPhEPfC689jE542cQnl+33dnjw= Received: by 10.142.9.9 with SMTP id 9mr4024691wfi.149.1302446669583; Sun, 10 Apr 2011 07:44:29 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id z10sm6826150wfj.15.2011.04.10.07.44.24 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Apr 2011 07:44:28 -0700 (PDT) Message-ID: <4DA1C281.5010407@gmail.com> Date: Sun, 10 Apr 2011 07:45:21 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Vaughn Deluca References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> <4D9F5B5F.2060401@gmail.com> <4DA07A5D.9050402@gmail.com> <4DA08D99.6020402@gmail.com> <4DA10780.7020100@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "vwrap@ietf.org" Subject: Re: [vwrap] [wvrap] Simulation consistency 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: Sun, 10 Apr 2011 14:43:03 -0000 The viewer is quite monolithic natured piece of organic development. There were some artifacts, at least in source, that showed how everything used to be local. There has been some "this name means that now, and that name means this now" type of juggle, as the services were made apart. I wrote the documentation about resources in SNOW-375, so I don't mind if they are re-documented on the IETF wiki. I agreed with others to keep that part of the documentation as CC-by-SA, that way public resources stay public assets for reuse. I guess it's best for me to move it to PDF format, attach it to the ietf wiki, and start from there? As for your question to look at (GPL/LGPL) code, I'm not their lawyer. I think Compaq was the best example of how and how far that company needed to go for clean room, "reverse engineered" work (which is the key legal word, at issue, that doesn't play nicely with GPL). Is Compaq still the best example? Vaughn Deluca wrote: > Dzonatas, > > >There have been talks to split out the renderer from the viewer, > >yet the render depends on some of the network. To call that the > >local region is appropriate as you have. > >The renderer/network-loop does the bulk of the work now that others > >think the simulator does. That's where we get hung up on local sim > >or external sim, and components. > > Hmm, to be honest, i was thinking of that local region as a "real" > region, something like > the opensim region that i have running on my local machine. I called > it local because it would run on one of my own machines. The entity > that i called "viewer" was supposed to depict something like the > standard SL viewer. > > I see your general point about taking an even higher point of view > and drop some REST details. I will give that a try, it might simplify > the figure a lot. > > >I think with your first VD1 that only thing that really needs to be > added is to > >add space between the local and external area to fit in the resource > name per arrow. > >That way the public resource name is specified. Then instead of those > request for > >cap transitions, these would be implied by those resource names. > Above each line of > >each arrow, just add the appropriate public resource name there. We > can deal with > >private resources later, as those are already implied, too. > > OK, that sounds sensible, have been thinking about that, but decided > against it since at the time i was not exactly sure how to specify > the resource names. In relation to that problem you wrote: > > >This group never did create any dictionary of resource names. They > only exist in viewer source and >in SNOW-375. > > That dictionary would be something we should copy over from SNOW-375 > or the viewer code. > And it reminds me, is it still true hat if i look at that code, that > might prevent me from working on opensim for some time? Would that be > the case for snow-375 code as well? > > I can make that new figure, but it will be a few days, i am overloaded > with RL work :( > Feel free to give it a try based on the PSD file. > > -- Vaughn > > On Sun, Apr 10, 2011 at 3:27 AM, Dzonatas Sol > wrote: > > Forwarded to vwrap-list: > > Dzonatas Sol wrote: > > Just thought about this a little more... > > I think with your first VD1 that only thing that really needs > to be added is to add space between the local and external > area to fit in the resource name per arrow. That way the > public resource name is specified. Then instead of those > request for cap transitions, these would be implied by those > resource names. Above each line of each arrow, just add the > appropriate public resource name there. We can deal with > private resources later, as those are already implied, too. > > This group never did create any dictionary of resource names. > They only exist in viewer source and in SNOW-375. > > I don't know if I can modify the PDF to make an example of above. > > Dzonatas Sol wrote: > > Perhaps, that would be best to reflect upon the past. > > There have been talks to split out the renderer from the > viewer, yet the render depends on some of the network. To > call that the local region is appropriate as you have. The > renderer/network-loop does the bulk of the work now that > others think the simulator does. That's where we get hung > up on local sim or external sim, and components. > > Maybe easier not to worry about requests for caps for now > and keep the way your going. We can come back later and > describe how the connections/ReSTful patterns work later. > Please just indicate it's the above ReSTful view of the > flow (higher-level) and us implementators will comprehend. > > =) > > Vaughn Deluca wrote: > > Dzonatas Sol > >Then again, split the viewer out for local agent > services and maybe it will appear trivial. > > Right, Maybe we should consider *only* the viewer as > local, and assume all other services are external, > just to make the example clear. > Thanks for the other feedback, I will look at the > snow-375 example. > --Vaughn > > On Fri, Apr 8, 2011 at 9:00 PM, Dzonatas Sol > > >> wrote: > > I've read it, and off hand I would say the "flow" > needs further > definition. Not that you did anything wrong, it > just something > that happens more at the transfer layer from ReST > and lower. All > the arrows you have that go from the Local to > External let's > consider those "forward flow" and those that from > from external to > local as "reverse flow." This becomes more obvious > for reasons why > when firewalls and proxies are in the way and > connections may need > to exist in opposite of the flow. Between > unidirectional and > bidirectional flows is were this discussion > digresses to vanilla > HTTP/caps and not fully ReSTful as desired. > > See also this doc on "forward/reverse" how > Icesphere handles the > implementation of bidirectional resources: > > http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Interface > > > I think you already see the higher-level request to > begin > capability, end capability, and determine if it > needs to request > capabilities. With bidirectional resources, there > are less > requests for capabilities and mainly need for > digests of > capabilities that begin and end. With > unidirectional resources, > there are needs to request capabilities, that > (currently on > servers) begin as private capabilities. Also with > unidirectional > resources, there are keep-alives and long-poll > requirements on the > resources, which isn't mandatory on bidirectional > resources. > Bidirectional resources can use more ReSTful > credentials, so there > would be no need to request capabilities (only need > to know they > are capable by the digests). > > I imagine two big polygons around the Local and > External areas on > the diagrams, yet to further image the arrows on > actual flow might > not be so trivial as the desired flow noted. Then > again, split the > viewer out for local agent services and maybe it > will appear trivial. > > Vaughn Deluca wrote: > > VWRAP services high level message flow > (preliminary diagram > draft) see > > > http://trac.tools.ietf.org/wg/vwrap/trac/attachment/wiki/Diagrams/VWRAP_FlowExample_VD1.pdf > > > The main reason that i am submitting this in > spite of my lack > of formal expertise is that the group in my > view badly needs a > solid basis for discussion and preventing > endless repeating > loops. This example is probably wrong in many > ways, but its > better than what we have publicly available on > interop now > (although Morgaine is working on something > along the lines of > the recent discussions here) > I hope this diagram will give us a base for > discussion. I > could have done my homework better by > researching the old OGP > stuff in more depth, and i probably will do so > in the future > , but for now I just tried to followed the > general principles > as far as i understand them, to see what > response that yields > from the group. In other words,I try to let the > group educate > me :p > > Note that in my view all services are equal, > in principle it > does not matter in what "domain" they run, > since trust and > policy are fully localized. It is however very > possible to > have internal shortcuts in the services to > speed up processing. > In the example I opted for an external Agent > service, but I > could as well have incorporated that in the set > of local > services. As indicated above all services could > also be run by > different organisations, true to what VWRAP > stands for. Its > all up to the deployer, including a user at > home who might > want to run a full world for family and > friends. Those friends > might try to use that agent service to venture > out in the > virtual universe. I envision that the final > identity provider > is external, using OpenID and OAut or whatever > other magic > that I do not yet fully understand exists out > there. > > The example has 3 main purposes: > - Provide a reference for discussion - > Illustrates the use > case of tourism, and *true* interop. > - Illustrate consistency problems along the > lines discussed > here higher up in this tread, as well as the > "slashdot" > problem that Morgaine outlined so clearly. > > The message flow assumes an avatar already > present in some > region, (a small scale local home region in > this case, but > that is by no means essential, it could be a > build in region > in the viewer or a big commercial region). The > user is > preparing for a trip to immersive world, and > after some outfit > adjustments moves over. > Finally i apologize for for the simplistic > notation used here. > I simply add the most relevant parameters > passed in square > brackets to a keyword specifying the nature of > the message. > Please improve on that where needed. > > So here we go, the avatar is prepare for a > visit to > "immersive world" > 0) Viewer, here is an update of the state of > the world your > agent is in, please render. > 1) Agent service, I will go in my Zodiac dress > that i keep in > the "Amazing assets" service. > 2) Asset service A, please send a cap for Z, > here are my > credentials > 3) Your fine, here is the cap > 4) Local region, can you please put this on my > agent, i > included the cap. > 5) Hello asset service A, i need Z, here is > the cap > 6) Cap is good, data coming up, have fun. > 7) Agent service, your agent is now wearing Z > 8) Viewer, your avatar is now wearing Z > User: Hmm, amazing inventory has not been > *that* amazing > lately. 'll make a backup, just in case > 9) Hello asset service A, please send me a cap > for Z, here > are my credentials > 10) Your fine, here is the cap > 11) Local asset storage, please store Z for me, > here is the > cap to get it > 12) Hello asset service A, i want Z, here is > the cap > 13) Cap is good, data coming up, have fun. > 14) Viewer, Z is now stored for you User: I > am Ready!, > Lets try to get to immersive world! > 15) Hello immersive world, can i get in? Here > are my > credentials, and a list of my stuff. > 16) Asset service A, please send me a cap for > X, here are my > credentials (I want this cap for consistency) > 17) Your fine, here is the cap > 18) Asset service B, please send me a cap for > Y, here are my > credentials (I want this cap for consistency) > 19) Very sorry, but your not one of us, you > can't have Y > 20) Asset service B, please send me a cap for > Z, here are my > credentials (I want a cap for consistency) > [Region service: Timeout... amazing inventory > must be > overloaded.. oh well... ] > 21) Agent service, you wanted to send somebody > over, here are > your permissions. > 22) Viewer, you asked for a transfer try, here > are your results > User thinks: Crap! Big asset service does > not allow me > to take my yellow stockings! And Amazing assets > failed to > deliver my zodiac dress. At least i made a > backup of that dress! > 23) 'll take the yellow stockings off... > 24) ... done ('ll trash them here and now, > forever, who needs > stuff you can't use!) > 25) The zodiac dress was not delivered by Big > assets service, > but i have a local copy! > 26) Local Asset service, please send me Z, here > are my credentials > 27) I dont know you, but I 'll trust you, here > is the cap, but > you better store the data, its single use, i > need to protect > myself. > 28) Local region, can you please put this on my > agent, i > include the cap. > 29) Local Asset service, i need Z, here is the cap > 30) Cap is good, data coming up, have fun. > 31) Cap was only good for one time, I made a > copy, but my > policy is to only grant you fair use rights, at > a later time i > might even tell you to replace the dress. > 32) Viewer, you can wear Z for now, but the > asset service > granted only fair use, i might ask you to > replace the dress at > a later time. > 33) Ready at last! Off to immersive world!, I > hope its not to > crowded there or 'll loose my dress... > 34) Hello immersive world, here are my > credentials, and a list > of stuff i want to bring > 35) Hello asset service A, please send me a cap > for X, here > are my credentials [darn, I should have > kept that cap from > last time..] > 36) Your fine, here is the cap. > [Region service finds fair-use warning on Z > and decides to > make its own copy] > 37) Hello Local region, can i still have Z? > Here is the cap > 38) Cap is still good, data coming up, have fun. > [Region service stores asset in private > storage, providing a > cap to replace the fair use one] > 39) Agent service, you wanted to send somebody > over, here are > your permissions & info. > 40) Hello immersive world, just get me there, > and use what > you can > 41) Placement done, Z is currently buffered by > us as wel, you > need to get details for X, have fun. > 42) You are now in immersive world, your dress > is buffered > there as well, but you need to get X! > 43) Hello asset service A, i want X, here is > the cap > 44) Cap is good, data coming up, have fun. > 45) Viewer, here is an update of the state of > the world your > agent is in, please render. > > As far as I can see this conforms fully to our > charter, and i > hope it is possible to use large portions of > the existing code > bases. However, as said above, i did not really > try to capture > the old thinking, and I also might have > misconceptions about > the way to do these things in general. > Looking forward to constructive comments. > > -- Vaughn > > On Sun, Apr 3, 2011 at 8:38 PM, Vaughn Deluca > > > > > >>> wrote: > > Thanks for the pointers. I have a busy > week in RL in front of > me, so i wont have to much time to respond > the next few days, > however, i intend to start doing the > following things: > > - Produce a visual that reflects my > thinking, i.e. an > illustration > of my response to Morgaine's itemlist above. > - Read up on the older notes, as well as > more reading in > the list > archive > - Try to make a summary for the wiki > > Regarding the use of domain, I think > services are > eventually what > counts, but its all terminology. The way I > read the AWG > diagrams > is that the agent domain is actually a > cluster of tightly > integrated services. When the functionality > of each > sub-service is > described properly and with uniform > interfaces the domain will > slowly dissolve. But let not get ahead of > out selfs. We > should put > up some clear descriptions on the wiki for > our views on > this, and > *after* that we can decide what we need and > what can go. > > Its been a very useful and illuminating > weekend for me, and > i am a > lot more optimistic about the future of > vwrap than two > weeks ago. > > -- Vaughn > > > > On Sun, Apr 3, 2011 at 7:20 PM, Dzonatas Sol > > > > >>> wrote: > > Probably easy as suggested in other > terms here on this > list, > as how the client contacts the asset > services now in the > regions. The newer issue is to unitize > that asset services. > Since their is proprietary (legacy) code > then we can't > expect > that to change, and some form of proxy > is of need. Whatever > works best, I tried to narrow it down to > suggestions here. > > Eventually, the agent domain is ideal to > handle the > direction > of the asset services. This concept, > unfortunately, ended > support awhile ago with changes in LL. > Also see; > http://wiki.secondlife.com/wiki/Agent_Domain > And: > > http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/AWG_Asset > (warn: unstructured collaborative notes, > dumped on me and I > tried to fix) > > I tried to find previous visuals. > > I'd imagine the agent domain could grow > out of unitized > versions of asset services. Despite > that, I think that > concept > helps view where we were at in > discussion and what > didn't happen. > > Vaughn Deluca wrote: > > Hi�Dzonatas > > Can you expand on that, what would > be needed for legacy > support in VWAP terms�?, > If i want to read up on how > the�asset server may > proxy the > simulator, what would you recommend > me to read? > > -- Vaughn > > On Sun, Apr 3, 2011 at 5:51 AM, > Dzonatas Sol > > > >> > > > > > >>>> > > wrote: > > Some stated the > proxy-to-asset-server is built > into the > sim; > however, keep in mind possible > legacy support > where the > asset > server may proxy the simulator. > > > Dzonatas Sol wrote: > > Somehow I feel the basic > asset server being > able to > login and > download assets is now > priority, yet I also > wondered the best > way to patch this into the > current mode of > viewers. > > Maybe offer (1) by proxy > (sim-side) and (2) > by patch > (viewer-side) that either of > these two are > optional and > neither are mandatory for > now. Thoughts? > > Israel Alanis wrote: > > > > when designing for > scalability, the > model to > bear in > mind is ... > > Well, there are a lot of > different models to > keep in mind, > and many different use > cases. One particular > use case to > keep in mind is: "User > acquires new > outfit, and > wants to > 'show it off' in a highly > populated region". > > > Both worlds and asset > services may include > commercial, > community, and personal > services > > Yes, yes and yes. I'm > particularly concerned > about how the > model affects the ability > to host personal > asset services. > > > a proxying region, > which would get slammed > for every > asset worn by every > avatar present. > > Granted the collection of > services that are > provided by > the region need to be > scaled to meet the > demands of that > region. That's all part > of capacity > planning. > > > regions run many different > CPU-intensive tasks, > including physics > simulation and server-side > scripting, > and absolutely cannot > afford to serve > assets too > Well... who said the same > CPU's have to do > proxying, > physics simulation and > server-side > scripting? Asset > proxying is a different > service than physics > simulation > and can be on separate > hardware, could > make use of > geographically > distributed caching, and > in certain > deployment patterns, the > same caching > services > could be > shared by different > regions. (Server-side > scripting is a > discussion for another day). > > > This is why we have to > go parallel... > > Totally agree, and a > proxying model > could and > should also > take advantage of > parallelism. > > > I think you're wrong > that it has to > cost much > money. ?vs? > > It costs money to host > a high > performance and > scalable > asset service and a high > bandwidth > network to > handle the > traffic. �A *lot* of money. > I think what you're > saying is: "It costs > a lot > of money to > build a scalable asset > service, but if > assets > are spread > throughout the internet > they don't have > to be > scalable." > But that's not quite > right. You're > opening up > every asset > server to the VW > equivalent of being > slashdotted, so are > you sure you're not > forcing *every* asset > service to be > scalable and handle a lot > of bandwith and > network traffic? > It's the exact opposite > of your > intention, but > I think > that's the result, all > the same. > > This particular design > decision has a big > effect on the > economics of the VW > infrastructure. I'd > rather the > economics to work out > such that a region > provider who > wishes to build a region > that supports a > small > population, > can do so economically. A > region that > wants to > host a > *large* population has to > bear that cost of > providing that > scalable asset service. > I want the economics of > hosting a small > asset > service to > be a non-issue (as to > best promote > creation and > creativity). Creating a > high bar to provide > asset services > will mean that service > will cost money > and people > shouldn't have to pay > money just to > create or > own VW > objects (I'm using 'own' > here to refer to > maintaining > their existence, I'm not > trying to make a > 'leftist'/'communist' > statement about > ownership ;) > > - Izzy > > > On Apr 2, 2011, at 3:58 > PM, Morgaine wrote: > > Izzy, when designing for > scalability, the > model to > bear in mind is that > of seasoned > virtual world > travelers whose > inventories contain > assets > from many > different worlds, > those assets being > served > by many > different asset > services. �Both > worlds and > asset > services may include > commercial, > community, and > personal services, > and as the metaverse > grows, that > set is highly likely > to become > progressively less > clustered and more > diverse. > > When those seasoned > travelers click > on an > advertised > VW link and perform > an inter-world > teleport > to one > particular world's > region to share an > experience, > their "worn" assets > (the only ones of > interest to the > region) will contain > references to asset > services > spread widely across > the Internet. �The > fetches by the > travelers' clients > occur over many > parallel > paths from > clients to asset > services, so one can > reasonably > expect reduced > network contention and > reduced asset > server loading > because they are both > spread > out over > however many asset > services are being > referenced by > the overall set of > assets in the region. > > This is very > different to the case of a > proxying > region, which would > get slammed for > every > asset worn > by every avatar > present. �In our current > architecture, > regions run many > different > CPU-intensive tasks, > including physics > simulation and > server-side > scripting, and > absolutely cannot > afford to > serve > assets too unless > your scalability > requirements are > very low indeed, ie. > just a few dozen > avatars of > today's kind. �We've > hit the ceiling > already on region > scalability done that > way. �There is > nowhere to go in > that direction at all > beyond > improving the > code like > Intel demonstrated, > and that work is > subject to a law > of diminishing returns. > > This is why we have > to go parallel, > and I > think you're > wrong that it has to > cost much > money. �As > we spread > the load across more > and more asset > services, we are > simply better > utilizing all the > hardware that's > already out there on > the Internet, > at least > in respect > of community and > private resources. �But > add to the > community and private > resources the > commercial asset > services that are > likely to appear to > exploit this > opportunity, and not > only will the > number > of asset > services leap, but > the power of each one > will rocket > too, because, after > all, these > businesses > will be > heavily optimized for > the job. > > As to why a world > would want clients > to access > external asset > services instead of > providing its own > implementation, > that's an easy question. > �It costs > money to host a high > performance and > scalable asset > service and a high > bandwidth network to > handle the > traffic. �A *lot* of > money. �In > contrast, > it costs a > world nothing to let > others serve > the assets to > clients. �And that > matters to the > bottom line. > > > Morgaine. > > > > > ====================== > > On Sat, Apr 2, 2011 > at 7:05 PM, Izzy > Alanis > > > > > >> > > > > > >>> > > > > > > >> > > > > > > > >>>>> wrote: > > � �> As always > though, it's a trade-off, > since the > proxied design > � �has very poor > scalability > compared to the > distributed one. > > � �I don't agree with > that... If a user > enters a > highly populated > � �region, > � �every other client > is going to (could > and should be > trying to) > � �hit the > � �asset server(s) > for the assets > that the > user is > wearing (assuming > � �they're not cached > locally). �Every > asset server > has to be scaled up > � �to the point that > it can handle that > load from all > over... > > � �If I'm hosting a > region that > supports 10s of > thousands of > � �simultaneous > � �users (thinking of > the future), I > already have to > scale to meet that > � �demand. If the > region is proxying the > assets, then, > yes the > � �region has > � �to be scaled to > meet that asset > demand > too, but it > already has to be > � �scaled to meet > other demands of > being a > region > server... and why is > � �scaling those > asset proxy > services hard? > �It's > going to cost $, > � �but is > � �not technically > challenging. So, if I > want to host > a region like > � �that... sure it > will cost me, but the > simulation > will be consistent > � �and users will be > able to participate > equally, > regardless of the > � �capabilities of > their individual > asset > services. > > > > > � �On Fri, Apr 1, > 2011 at 11:55 PM, > Morgaine > � > � > > > > > >> > > > > > > > >>> > � > � > > > > > > >> > > > > > > > > >>>>> wrote: > � �> Every design > choice results in a > trade-off, > Vaughn, improving > � �one thing at > � �> the expense of > something else. �If > every time we > offered a > � �service we had to > � �> inform its users > about the > downsides > of all the > trade-offs we > � �have made, > � �> they would have > an awful lot to > read. ;-) > � �> > � �> The specific > trade-off that you are > discussing is no > � �different. �A region > � �> that proxies all > content has the > "benefit" of > acquiring control > � �from the > � �> asset servers > over the items in the > region, so > that it can > � �ensure that > � �> everyone in the > region not only > obtains the items > but obtains > � �the same items > � �> as everyone > else. �That does indeed > provide a > greater guarantee of > � �> consistency than > a deployment > in which > the region > only passes > � �asset URIs to > � �> clients who then > fetch the > items from > asset services > � �separately. �As always > � �> though, it's a > trade-off, since the > proxied > design has very > � �poor scalability > � �> compared to the > distributed one. > � �> > � �> If we're going > to warn users of the > potential for > inconsistency > � �in the > � �> distributed > deployment as you > suggest, > are we > also going to > � �warn them of > � �> non-scalability > in the proxied > one? �I > really > don't see much > � �merit in the > � �> idea of warning > about design > choices. > �Many such > choices are > � �technical, and > � �> the issues are > quite likely to > be of > little > interest to > � �non-technical users > � �> anyway. �In any > case, the better > services are > likely to provide > � �such > � �> information in > their online > documentation, I > would guess. > � �> > � �> You mentioned > users "voting > with their > feet" or > choosing to > � �accept the risk > � �> of > inconsistency. �Well that will > happen anyway, > when services > � �fail and > � �> users get > annoyed. �If some asset > services refuse > to send the > � �requested > � �> items to some > users, those services > will get a > bad reputation > � �and people > � �> will choose > different asset > services > instead. > �Likewise, if a > � �world service > � �> proxies > everything and so it can't > handle a large > number of > � �assets or of > � �> people, users > will get annoyed > at the > lag and will go > � �elsewhere. �This user > � �> evaluation and > "voting with their > feet" happens > already with > � �online services > � �> all over the > Internet, and I am > sure > that this > human process > � �will continue > � �> to work when the > services are asset > and region > services. > � �> > � �> Back in > September 2010, I wrote > this > post which > proposes that > � �we use in > � �> VWRAP a form of > asset > addressing that > provides > massive > � �scalability at the > � �> same time as a > very high degree of > resilience -- > � �> > � > > �http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html > � �. �It is > � �> based on the > concept of the URI > containing a host > part and a > � �hash part, > � �> where the hash > is generated > (once, at > the time of > storage to > � �the asset > � �> service) using a > specified digest > algorithm over > the content of > � �the asset > � �> being > referenced. �You may wish to > note that if > this design > � �were used, the > � �> failure of an > asset service to > deliver a > requested item would > � �result in a > � �> failover request > for the item > to one > or more > backup services, > � �using the same > � �> hash part but > with a different host > address. > � �> > � �> This can go some > way towards > overcoming the > problem that you > � �think might > � �> occur when > assets are fetched by > clients from > asset services > � �directly. > � �> Although it > won't help when the > missing item is > available from > � �only a single > � �> asset service, > it will help in many > other cases, > and it will > � �compensate for > � �> service failures > and network > outages > automatically at the same > � �time. > � �> > � �> PS. This design > for hash-based > asset > addressing > is already > � �being tested by > � �> Mojito Sorbet in > her experimental > world and > client. �It would give > � �> VWRAP-based > worlds an improved > level > of service > availability, > � �so I think it > � �> should be a core > feature of our > protocol. > � �> > � �> > � �> Morgaine. > � �> > � �> > � �> > � �> > � �> > =========================== > � �> > � �> On Fri, Apr 1, > 2011 at 11:17 PM, > Vaughn Deluca > � > � > > > > >> > > > > > > >>> > > > > > > >> > > > > > > >>>>> > � �> wrote: > � �>> > � �>> This is a > question i discussed > with > Morgaine > off-list a while > � �ago (I > � �>> intended to > send it to the > list but > pushed the > wrong button...) I > � �>> think we need > to address this > problem, and > decide how to deal > � �with it. > � �>> > � �>> �In Davids > deployment draft, > section > 7.3.1.1 an > overview is > � �given van > � �>> ways to deliver > content to the > region. One way > is only passing a > � �>> capability that > allows access to > (part of) the > resource: > � �>> > � �>> � � � � � > 7.3.1.1. �Content > delivery > models > � �>> � � � � � A > range of possible > represenations can > be passed to > � �a region for > � �>> � � � � � > simulation. [...] > The other > end of the > delivery spectrum > � �>> involves passing > � �>> � � � � � only > a URI or capability > used to > access the rendering > � �>> information and a > � �>> � � � � � > collision mesh,and > related > data for > physical simulation. > � �>> � � � � � In > such a model, the > client is > responsible for > � �fetching the > � �>> additional > � �>> � � � � � > information needed to > render the > item's visual > � �presence from a > � �>> separate > � �>> � � � � � > service. �This fetch > can be > done > *under the > � �credentials of the > � �>> end user* > � �>> � � � � � > viewing the material [my > emphasis--VD] > , and > � �divorces the > � �>> simulation from > � �>> � � � � � the > trust chain > needed to > manage > content. �Any > � �automation > � �>> is done on a > � �>> � � � � � > separate host which > the content > creator or owner trusts, > � �>> interacting > with the > � �>> � � � � � > object through remoted > interfaces. > � �>> > � �>> �I can see the > need for such a > setup, > however, i > feel we are > � �>> unpleasantly > close to a situation > were the > coherence of the > � �simulation > � �>> falls apart. > � �>> In this > deployment pattern the > region > advertises > the presence > � �of the > � �>> asset, and > *some* clients will be > able to get it > as expected, > � �while > � �>> -based on the > arbitrary whims > of the > asset > service- others > � �might not. > � �>> > � �>> My hope would > be that after > the asset > server > provides the > � �region with > � �>> the capability > to get the > asset, it > gives up > control. That > � �would mean > � �>> that if the > client finds the > inventory server is > unwilling to > � �serve > � �>> the content - > in spire of the > region > saying it > is present-, > � �the client > � �>> should be able > to turn around > ask the > *region* > for the asset, > � �(and get > � �>> is after all). > � �>> > � �>> �If that is not > the case, -and > there are > probably good reasons > � �for the > � �>> deployment > pattern as described- > �shouldn't we > *warn* clients > � �that the > � �>> region might be > inconsistent, > so the > users > behind the client > � �can vote > � �>> with their > feet, (or take the > risk)? > � �>> > � �>> --Vaughn > � �>> > > _______________________________________________ > � �>> vwrap mailing list > � �>> vwrap@ietf.org > > > > >> > > > > >>> > > > > > >> > > > > >>>> > > � �>> > > https://www.ietf.org/mailman/listinfo/vwrap > � �> > � �> > � �> > > _______________________________________________ > � �> vwrap mailing list > � �> vwrap@ietf.org > > > > > >> > > > > >>> > > > > > >> > > > > >>>> > > � �> > > https://www.ietf.org/mailman/listinfo/vwrap > � �> > � �> > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > > >> > > > > >>> > > https://www.ietf.org/mailman/listinfo/vwrap > � > > > > > > -- --- > https://twitter.com/Dzonatas_Sol --- > Web Development, Software > Engineering, Virtual > Reality, > Consultant > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > > >> > > > > >>> > > https://www.ietf.org/mailman/listinfo/vwrap > > > > > -- --- > https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, > Virtual Reality, > Consultant > > > > > ------------------------------------------------------------------------ > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > > > https://www.ietf.org/mailman/listinfo/vwrap > > -- --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual > Reality, Consultant > > > > > > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From sllists@boroon.dasgupta.ch Sun Apr 10 14:27:18 2011 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 C4E163A69B4 for ; Sun, 10 Apr 2011 14:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGCAMWDzC9bs for ; Sun, 10 Apr 2011 14:27:16 -0700 (PDT) Received: from datendelphin.net (india288.server4you.de [85.25.150.202]) by core3.amsl.com (Postfix) with ESMTP id 36A973A696D for ; Sun, 10 Apr 2011 14:27:16 -0700 (PDT) Received: from [192.168.1.107] (adsl-84-226-67-142.adslplus.ch [84.226.67.142]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by datendelphin.net (Postfix) with ESMTPSA id 8F9502E045 for ; Sun, 10 Apr 2011 23:30:14 +0200 (CEST) Message-ID: <4DA220B1.6020400@boroon.dasgupta.ch> Date: Sun, 10 Apr 2011 23:27:13 +0200 From: Boroondas Gupte User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110408 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: vwrap@ietf.org References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060609070500000301070402" Subject: [vwrap] Inventory, Asset Metadata and Privacy (was: [wvrap] Simulation consistency) 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: Sun, 10 Apr 2011 21:27:18 -0000 This is a multi-part message in MIME format. --------------060609070500000301070402 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Morgaine The distinction between metadata and 'content' and storing them in separately acquirable chunks is a good and quite important idea, I think. More generally, I can think of several reasons to split a monolithic data entity E into several separate ones, connected by referencing each other or by being referenced by a common meta-entity which replaces the previous monolithic entity: 1. Several other entities are expected to have some parts in common with E, without having other parts in common with it. 2. Some parties only need some parts of E, but not other parts. 3. Some parties are only allowed access to some parts of E, but not to other parts. (You might note the similarity between reason (1) and rules used for database normalization.) If the entities are immutable (which assets should be according to previous discussion ), (1) can not only occur between unrelated items but will also be very common for items that result from changing a previous item. Some examples how this applies specifically to the metadata-content separation (assuming a similar inventory UI as we have in SL): * You rez an object from inventory, resize it, and take it back into inventory (which creates a new item there). o Same metadata (permissions, name(?), owner) + (What about a 'last edited' date, though? SL doesn't seem to store one, but some VWRAP systems might want to keep that info.) o Different content * You rename an item in-inventory o Different metadata (maybe ... see below) o Same content * You change next-owner permissions on an item, then give it to someone o Different metadata o Same content Reason (2) off course occurs when browsing your inventory. If you just want to e.g. read the names of your items, you don't have to fetch all the associated content data. Off course, there are more potential separations that fit one or several of these three reasons than just the metadata-content one. In SL, having objects being composed of prims, having prims reference textures for their faces instead of having the texture data lumped into their own data, or gestures being composed of steps some of which can reference animation and sound assets are other examples of such separations. On 04/10/2011 03:11 PM, Morgaine wrote: > It is worth noting that while inventories are mostly a client-side > implementation detail which can be changed unilaterally, the > /metadata/ held by inventories is a very important and separable > information type in an architecture that uses 3rd party asset > services, so it needs detailed examination. > > The metadata has to be available to remote parties in the same way as > the data itself is, and the best way of handling this is to make > metadata a separate item normally stored in the same asset service as > the data. As far as I know, this differs slightly from the concepts/architecture in SL. This might be a good thing, but because it is almost, but not completely, the same, we should be aware of these differences: In SL, there are the concept of assets (which are what I called 'content' above) and the concept of inventory items, referencing these assets and holding additional information such as permissions, name, etc. These inventory items themselves however are *not* considered assets in SL. So far, that's just a difference in nomenclature, I guess. But the SL inventory items are also handled differently from SL assets: They aren't stored (and served to the region) by the asset server, like assets are, but instead by the inventory service, which also serves the inventory tree. In fact, at least in the viewer's data model, the folders making up that tree are just special inventory items that do not reference assets but reference other inventory items. One of the drawbacks of how SL draws the line between inventory (-items) and assets is that it's probably difficult to implement something like VWR-2427 . Treating the item-metadata as a type of assets as you seem to suggest might allow to better exploit the commonality that both inventory items and some data assets can refer to other assets. (Note that I'm not really an expert on SL's internal architecture, and most of the above is based on hear-say and some viewer code comments I remember. Please correct me if I'm wrong somewhere.) > The metadata item will naturally reference the corresponding data item > (which is an N:1 relationship when hash-based addressing is used), and > in some cases can reference more than one data item --- for example, > the metadata of a mesh will commonly reference not only the graphical > data required for rendering in the client but also the collision mesh > or bounding box data required by the region. Wouldn't it make more sense to keep the metadata-item-to-data-item relation strictly N:1, and have the mesh data item have a N:N relation to it's components? (Analogous to SL gestures.) While the item type should be part of the metadata, I don't think the metadata's structure should depend on the item type. After all, the structure of inodes of a file system also doesn't depend on the file formats of the referenced files. > These two types of data are separate because it would be inefficient > to require clients or regions to download data that they do not use. > Our "asset" singleton now turns into a metadata + data pair. Yep. > As a final point about metadata versus data, it should be mentioned > that generally only the data ever has access restrictions placed on it, No restrictions for whom? Just for the user whose inventory it is (but then he/she has to authenticate somehow) or no restrictions for anyone? > because placing restrictions on metadata leads to unsearchable > inventories for which the technical term is "annoying as hell", or > more seriously, poorly functionality and yet another source of lag. I agree everyone should be able to access their own inventory tree, including the item-metadata at its leaf nodes. For the tree part, you later write > Regions don't have access to your inventory [...] ("inventory" here refers to just the tree, if I understood you correctly). I guess this is also the case for other users, except where I have given them explicit permission to view parts of my inventory (if the protocol was capable of that). > I am going to assume that nobody wants that [poor functionality and > lag] and hence, that metadata is never accessed through capabilities. Now here I'm beginning to wonder, what data all is part of the tree (that others aren't able to access) and what is instead part of the item-metadata, (a fraction of) which needs to be broadcasted to other users, as it contains the references to the assets those other users have to fetch to render my avatar correctly. For example, is the item name part of that metadata or part of the tree? It obviously isn't needed by others, it's merely a reminder for myself of what that item is. If the item name for worn stuff /is/ broadcasted together with the other relevant metadata, that's OK as long as the user is aware of it, but it /does/ have some consequences: In that case, I probably wouldn't want to name a wearable "The dress that this stupid guy bought me, but that I like to wear anyway" or "Those shoes that my secret lover Example Resident gave me" but something more innocent, so that I wouldn't upset that other user and wouldn't leak that Example Resident was my secret lover. There might be other metadata that's useful to the users themselves but that they might want to withhold from region owners and other users. Imagine for example information about where and when you acquired an item, which allows you to efficiently search for that item when you forgot the item name but still remember how you got it. However, if that info is broadcasted for worn items and you wear enough different items, everyone around you has a partial trace of your virtual travels. So we can either split the metadata asset according to reason (3) above into several assets with different access policies. Or we just lump metadata we want to keep private together with the tree while only having metadata we don't mind sharing in the metadata assets. Cheers, Boroondas --------------060609070500000301070402 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Morgaine

    The distinction between metadata and 'content' and storing them in separately acquirable chunks is a good and quite important idea, I think. More generally, I can think of several reasons to split a monolithic data entity E into several separate ones, connected by referencing each other or by being referenced by a common meta-entity which replaces the previous monolithic entity:
    1. Several other entities are expected to have some parts in common with E, without having other parts in common with it.
    2. Some parties only need some parts of E, but not other parts.
    3. Some parties are only allowed access to some parts of E, but not to other parts.
    (You might note the similarity between reason (1) and rules used for database normalization.)

    If the entities are immutable (which assets should be according to previous discussion), (1) can not only occur between unrelated items but will also be very common for items that result from changing a previous item. Some examples how this applies specifically to the metadata-content separation (assuming a similar inventory UI as we have in SL):
    • You rez an object from inventory, resize it, and take it back into inventory (which creates a new item there).
      • Same metadata (permissions, name(?), owner)
        • (What about a 'last edited' date, though? SL doesn't seem to store one, but some VWRAP systems might want to keep that info.)
      • Different content
    • You rename an item in-inventory
      • Different metadata (maybe ... see below)
      • Same content
    • You change next-owner permissions on an item, then give it to someone
      • Different metadata
      • Same content
    Reason (2) off course occurs when browsing your inventory. If you just want to e.g. read the names of your items, you don't have to fetch all the associated content data.

    Off course, there are more potential separations that fit one or several of these three reasons than just the metadata-content one. In SL, having objects being composed of prims, having prims reference textures for their faces instead of having the texture data lumped into their own data, or gestures being composed of steps some of which can reference animation and sound assets are other examples of such separations.

    On 04/10/2011 03:11 PM, Morgaine wrote:
    It is worth noting that while inventories are mostly a client-side implementation detail which can be changed unilaterally, the metadata held by inventories is a very important and separable information type in an architecture that uses 3rd party asset services, so it needs detailed examination.

    The metadata has to be available to remote parties in the same way as the data itself is, and the best way of handling this is to make metadata a separate item normally stored in the same asset service as the data.
    As far as I know, this differs slightly from the concepts/architecture in SL. This might be a good thing, but because it is almost, but not completely, the same, we should be aware of these differences: In SL, there are the concept of assets (which are what I called 'content' above) and the concept of inventory items, referencing these assets and holding additional information such as permissions, name, etc. These inventory items themselves however are not considered assets in SL.

    So far, that's just a difference in nomenclature, I guess. But the SL inventory items are also handled differently from SL assets: They aren't stored (and served to the region) by the asset server, like assets are, but instead by the inventory service, which also serves the inventory tree. In fact, at least in the viewer's data model, the folders making up that tree are just special inventory items that do not reference assets but reference other inventory items.

    One of the drawbacks of how SL draws the line between inventory (-items) and assets is that it's probably difficult to implement something like VWR-2427. Treating the item-metadata as a type of assets as you seem to suggest might allow to better exploit the commonality that both inventory items and some data assets can refer to other assets.

    (Note that I'm not really an expert on SL's internal architecture, and most of the above is based on hear-say and some viewer code comments I remember. Please correct me if I'm wrong somewhere.)

    The metadata item will naturally reference the corresponding data item (which is an N:1 relationship when hash-based addressing is used), and in some cases can reference more than one data item --- for example, the metadata of a mesh will commonly reference not only the graphical data required for rendering in the client but also the collision mesh or bounding box data required by the region.
    Wouldn't it make more sense to keep the metadata-item-to-data-item relation strictly N:1, and have the mesh data item have a N:N relation to it's components? (Analogous to SL gestures.) While the item type should be part of the metadata, I don't think the metadata's structure should depend on the item type. After all, the structure of inodes of a file system also doesn't depend on the file formats of the referenced files.

    These two types of data are separate because it would be inefficient to require clients or regions to download data that they do not use.  Our "asset" singleton now turns into a metadata + data pair.
    Yep.

    As a final point about metadata versus data, it should be mentioned that generally only the data ever has access restrictions placed on it,
    No restrictions for whom? Just for the user whose inventory it is (but then he/she has to authenticate somehow) or no restrictions for anyone?

    because placing restrictions on metadata leads to unsearchable inventories for which the technical term is "annoying as hell", or more seriously, poorly functionality and yet another source of lag.
    I agree everyone should be able to access their own inventory tree, including the item-metadata at its leaf nodes. For the tree part, you later write
    Regions don't have access to your inventory [...]
    ("inventory" here refers to just the tree, if I understood you correctly). I guess this is also the case for other users, except where I have given them explicit permission to view parts of my inventory (if the protocol was capable of that).

    I am going to assume that nobody wants that [poor functionality and lag] and hence, that metadata is never accessed through capabilities.
    Now here I'm beginning to wonder, what data all is part of the tree (that others aren't able to access) and what is instead part of the item-metadata, (a fraction of) which needs to be broadcasted to other users, as it contains the references to the assets those other users have to fetch to render my avatar correctly. For example, is the item name part of that metadata or part of the tree? It obviously isn't needed by others, it's merely a reminder for myself of what that item is.

    If the item name for worn stuff is broadcasted together with the other relevant metadata, that's OK as long as the user is aware of it, but it does have some consequences: In that case, I probably wouldn't want to name a wearable "The dress that this stupid guy bought me, but that I like to wear anyway" or "Those shoes that my secret lover Example Resident gave me" but something more innocent, so that I wouldn't upset that other user and wouldn't leak that Example Resident was my secret lover.

    There might be other metadata that's useful to the users themselves but that they might want to withhold from region owners and other users. Imagine for example information about where and when you acquired an item, which allows you to efficiently search for that item when you forgot the item name but still remember how you got it. However, if that info is broadcasted for worn items and you wear enough different items, everyone around you has a partial trace of your virtual travels.

    So we can either split the metadata asset according to reason (3) above into several assets with different access policies. Or we just lump metadata we want to keep private together with the tree while only having metadata we don't mind sharing in the metadata assets.

    Cheers,
    Boroondas
    --------------060609070500000301070402-- From morgaine.dinova@googlemail.com Sun Apr 10 20:25:27 2011 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 CACA83A6A47 for ; Sun, 10 Apr 2011 20:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ASEBOMkku7ip for ; Sun, 10 Apr 2011 20:25:24 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 063763A6A43 for ; Sun, 10 Apr 2011 20:25:20 -0700 (PDT) Received: by qyk29 with SMTP id 29so869097qyk.10 for ; Sun, 10 Apr 2011 20:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GIykLlSI9iYyLzoX2iNf0KP7WbgHrh1APf2vavhWjt8=; b=U7HNuzweEN7D7Rna/3e/lqTlHCpslLj+RF7ax8q2FGR6fDnNHpcH/f3rUIWBbFFEea 4+DJmGNiSGgV3rR6n39+7FnsW3vCjCuUYlTYueuDbJiXf9gTAPl1mESuZA+UcBJqDifQ fIbOM+vgQHTQDZ1+upuaMY/I9ix7D7OtPdSdA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sdH6VXFxiGY19wo1d2LSX9472QdCB4SHP9yRs4lGcIp/Kxs5IiDgCUtNGt3mY1Axs1 ugT17ftvktrXLNB6u07LN8v9e9noSYOfqc1cggu+HDJwz0bIAfh+CmpwX1jyadraj0zG qTTm2ArZjBt8mkEcxShwhsdP6HN0afwOEXvfI= MIME-Version: 1.0 Received: by 10.229.124.145 with SMTP id u17mr3741632qcr.71.1302492320703; Sun, 10 Apr 2011 20:25:20 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sun, 10 Apr 2011 20:25:20 -0700 (PDT) In-Reply-To: <4DA220B1.6020400@boroon.dasgupta.ch> References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> <4DA220B1.6020400@boroon.dasgupta.ch> Date: Mon, 11 Apr 2011 04:25:20 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd25cae19265304a09c207a Subject: Re: [vwrap] Inventory, Asset Metadata and Privacy (was: [wvrap] Simulation consistency) 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, 11 Apr 2011 03:25:27 -0000 --000e0cd25cae19265304a09c207a Content-Type: text/plain; charset=ISO-8859-1 Excellent response, Boroondas, full of detailed analysis! :-) I won't respond to everything in-line because it would be mostly a long sequence of "Yes!" and "Good idea!", but I'll expand in a couple of areas where your reply makes me think that I should have been clearer, and also where I prefer your suggestions to mine. What's more, I'll adopt your suggested nomenclature straight away: *asset == (metadata + content)* I like that! "Metadata + data" has never felt right, because everything is "data". :-) On Sun, Apr 10, 2011 at 10:27 PM, Boroondas Gupte < sllists@boroon.dasgupta.ch> wrote: > > > > On 04/10/2011 03:11 PM, Morgaine wrote: >> The metadata has to be available to remote parties in the same way as the data itself is, and the best way of handling this is to make metadata a separate item normally stored in the same asset service as the data. As far as I know, this differs slightly from the concepts/architecture in SL. This might be a good thing, but because it is almost, but not completely, the same, we should be aware of these differences: In SL, there are the concept of assets (which are what I called 'content' above) and the concept of inventory items, referencing these assets and holding additional information such as permissions, name, etc. These inventory items themselves however are *not* considered assets in SL. So far, that's just a difference in nomenclature, I guess. But the SL inventory items are also handled differently from SL assets: They aren't stored (and served to the region) by the asset server, like assets are, but instead by the inventory service, which also serves the inventory tree. In fact, at least in the viewer's data model, the folders making up that tree are just special inventory items that do not reference assets but reference other inventory items. One of the drawbacks of how SL draws the line between inventory (-items) and assets is that it's probably difficult to implement something like VWR-2427. Treating the item-metadata as a type of assets as you seem to suggest might allow to better exploit the commonality that both inventory items and some data assets can refer to other assets. (Note that I'm not really an expert on SL's internal architecture, and most of the above is based on hear-say and some viewer code comments I remember. Please correct me if I'm wrong somewhere.) I'm not an expert on SL's architecture either, but our discussions in the AWG over 3+ years suggest that your analysis above is correct. We are actually sticking fairly closely to the *conceptual* model used in SL (not for compatibility, but because it is a reasonable model), but we are departing from SL's *physical* model in some significant ways to gain better functional properties. According to the very rough consensus in AW Groupies (:P), in SL only the * content* is stored in *asset storage*, whereas *metadata* is stored in a *relational database* (and is mutable). In the design that we are discussing here for VWRAP asset services, both *content* and *metadata *are held in asset services, and both types of data are immutable. Our "updates" are achieved simply by referring to new metadata. SL handles its metadata specially and caches it in an inventory cache separately from content, whereas we store and cache them uniformly in both asset services and caches. Our inventories merely organize our cached metadata into a hierarchical *view*. We're building on past experience to improve functionality and performance and scalability (and elegance too!), which is quite natural. The "information about assets" stored at the leaves of inventories in SL-compatible clients is conceptually very similar to the metadata stored in our proposed asset services. Even the content referencing model is similar, in the sense that capabilities are used in SL to obtain the UUIDs of textures for example, and these UUIDs are then stored in the metadata held in inventory items. In other words, UUIDs held in SL inventory leaves are equivalent to our *direct addresses* (URIs) held in metadata. In both cases, once you have the UUID or *direct address*, you no longer need a capability to obtain the item. The cap's only function is to control acquisition of the UUID, which is the actual address of the content. Our content URIs just extend the concept of an address to external asset services. >> The metadata item will naturally reference the corresponding data item (which is an N:1 relationship when hash-based addressing is used), and in some cases can reference more than one data item --- for example, the metadata of a mesh will commonly reference not only the graphical data required for rendering in the client but also the collision mesh or bounding box data required by the region. > Wouldn't it make more sense to keep the metadata-item-to-data-item relation strictly N:1, and have the mesh data item have a N:N relation to it's components? (Analogous to SL gestures.) While the item type should be part of the metadata, I don't think the metadata's structure should depend on the item type. After all, the structure of inodes of a file system also doesn't depend on the file formats of the referenced files. > > Yes! That makes more sense. I withdraw my N:M suggestion. :-) Let's stick with N:1 and then be more clever with content if needed later. This is also in keeping with my cost engineering mantra, namely "The burden of X should be borne only by those who need X". There is no sense complicating metadata to make it N:M when the vast majority of its use cases are N:1. >> As a final point about metadata versus data, it should be mentioned that generally only the data ever has access restrictions placed on it, > No restrictions for whom? Just for the user whose inventory it is (but then he/she has to authenticate somehow) or no restrictions for anyone? Sorry, I was ambiguous. What I should have said was "Only access to the content of assets may be restricted by access controls, and only when it is appropriate to do so (eg. never for open content). Access to the metadata of assets is never restricted, for anyone. When access controls restrict access to the content of a particular asset, then different policies may be applied to agents who hold assets in inventory and agents who merely render assets worn by others in the region. The asset service holds authority over the asset, and has the power to discriminate." > ("inventory" here refers to just the tree, if I understood you correctly). I guess this is also the case for other users, except where I have given them explicit permission to view parts of my inventory (if the protocol was capable of that). I do not envisage anyone ever having access to an agent's inventory, other than the agent who owns the inventory (inventories are client-side after all, despite also being saved server-side). Only the metadata that an inventory may be referencing can ever be seen by others (for example, when a region provides the references), but never the hierarchical structure. This is similar to how SL/Opensim works: you can inspect the metadata of an asset in the scene and see that it is owned by user X, but you have no access to X's inventory. >> I am going to assume that nobody wants that [poor functionality and lag] and hence, that metadata is never accessed through capabilities. > Now here I'm beginning to wonder, what data all is part of the tree (that others aren't able to access) and what is instead part of the item-metadata, (a fraction of) which needs to be broadcasted to other users, as it contains the references to the assets those other users have to fetch to render my avatar correctly. For example, is the item name part of that metadata or part of the tree? It obviously isn't needed by others, it's merely a reminder for myself of what that item is. Just in case I wasn't clear before, I'll underline that inventory trees are entirely unrelated to the process by which others gain access to assets (they use metadata which links to content, not inventories). The only reason why I mentioned inventories at all is because they too happen to point to metadata. As to the question of what is in inventories that isn't in metadata, the answer is "almost nothing" other than the hierarchical skeleton of named folders. I guess it's possible to have local symlinks, and even to modify the metadata locally if desired, for example to change the local name of an item, but those are just frills. Generally, inventory is merely metadata organized locally into a tree. > If the item name for worn stuff *is* broadcasted together with the other relevant metadata, that's OK as long as the user is aware of it, but it * does* have some consequences: In that case, I probably wouldn't want to name a wearable "The dress that this stupid guy bought me, but that I like to wear anyway" or "Those shoes that my secret lover Example Resident gave me" but something more innocent, so that I wouldn't upset that other user and wouldn't leak that Example Resident was my secret lover. Haha. :-) Well it's already the case in SL that the metadata is inspectable, so people are already used to the fact that how they name objects and what they write in object descriptions is visible publicly, nothing new there. > There might be other metadata that's useful to the users themselves but that they might want to withhold from region owners and other users. Imagine for example information about where and when you acquired an item, which allows you to efficiently search for that item when you forgot the item name but still remember how you got it. However, if that info is broadcasted for worn items and you wear enough different items, everyone around you has a partial trace of your virtual travels. Yes, good ideas for purely local enhancements to inventories. :-) I'm sure that inventories can be extended in many useful ways to build upon their primary role of organizing and referencing metadata. That could be a very interesting area. Anyone with dozens of thousands of objects in inventory can appreciate very well the need for some new thinking to help us manage the object explosion. :-) Morgaine. ====================== On Sun, Apr 10, 2011 at 10:27 PM, Boroondas Gupte < sllists@boroon.dasgupta.ch> wrote: > Hi Morgaine > > The distinction between metadata and 'content' and storing them in > separately acquirable chunks is a good and quite important idea, I think. > More generally, I can think of several reasons to split a monolithic data > entity E into several separate ones, connected by referencing each other or > by being referenced by a common meta-entity which replaces the previous > monolithic entity: > > 1. Several other entities are expected to have some parts in common > with E, without having other parts in common with it. > 2. Some parties only need some parts of E, but not other parts. > 3. Some parties are only allowed access to some parts of E, but not to > other parts. > > (You might note the similarity between reason (1) and rules used for > database normalization.) > > If the entities are immutable (which assets should be according to > previous discussion), > (1) can not only occur between unrelated items but will also be very common > for items that result from changing a previous item. Some examples how this > applies specifically to the metadata-content separation (assuming a similar > inventory UI as we have in SL): > > - You rez an object from inventory, resize it, and take it back into > inventory (which creates a new item there). > - Same metadata (permissions, name(?), owner) > - (What about a 'last edited' date, though? SL doesn't seem to > store one, but some VWRAP systems might want to keep that info.) > - Different content > - You rename an item in-inventory > - Different metadata (maybe ... see below) > - Same content > - You change next-owner permissions on an item, then give it to someone > - Different metadata > - Same content > > Reason (2) off course occurs when browsing your inventory. If you just want > to e.g. read the names of your items, you don't have to fetch all the > associated content data. > > Off course, there are more potential separations that fit one or several of > these three reasons than just the metadata-content one. In SL, having > objects being composed of prims, having prims reference textures for their > faces instead of having the texture data lumped into their own data, or > gestures being composed of steps some of which can reference animation and > sound assets are other examples of such separations. > > On 04/10/2011 03:11 PM, Morgaine wrote: > > It is worth noting that while inventories are mostly a client-side > implementation detail which can be changed unilaterally, the *metadata*held by inventories is a very important and separable information type in an > architecture that uses 3rd party asset services, so it needs detailed > examination. > > The metadata has to be available to remote parties in the same way as the > data itself is, and the best way of handling this is to make metadata a > separate item normally stored in the same asset service as the data. > > As far as I know, this differs slightly from the concepts/architecture in > SL. This might be a good thing, but because it is almost, but not > completely, the same, we should be aware of these differences: In SL, there > are the concept of assets (which are what I called 'content' above) and the > concept of inventory items, referencing these assets and holding additional > information such as permissions, name, etc. These inventory items themselves > however are *not* considered assets in SL. > > So far, that's just a difference in nomenclature, I guess. But the SL > inventory items are also handled differently from SL assets: They aren't > stored (and served to the region) by the asset server, like assets are, but > instead by the inventory service, which also serves the inventory tree. In > fact, at least in the viewer's data model, the folders making up that tree > are just special inventory items that do not reference assets but reference > other inventory items. > > One of the drawbacks of how SL draws the line between inventory (-items) > and assets is that it's probably difficult to implement something like > VWR-2427 . Treating the > item-metadata as a type of assets as you seem to suggest might allow to > better exploit the commonality that both inventory items and some data > assets can refer to other assets. > > (Note that I'm not really an expert on SL's internal architecture, and most > of the above is based on hear-say and some viewer code comments I remember. > Please correct me if I'm wrong somewhere.) > > The metadata item will naturally reference the corresponding data item > (which is an N:1 relationship when hash-based addressing is used), and in > some cases can reference more than one data item --- for example, the > metadata of a mesh will commonly reference not only the graphical data > required for rendering in the client but also the collision mesh or bounding > box data required by the region. > > Wouldn't it make more sense to keep the metadata-item-to-data-item relation > strictly N:1, and have the mesh data item have a N:N relation to it's > components? (Analogous to SL gestures.) While the item type should be part > of the metadata, I don't think the metadata's structure should depend on the > item type. After all, the structure of inodes of a file system also doesn't > depend on the file formats of the referenced files. > > These two types of data are separate because it would be inefficient to > require clients or regions to download data that they do not use. Our > "asset" singleton now turns into a metadata + data pair. > > Yep. > > As a final point about metadata versus data, it should be mentioned that > generally only the data ever has access restrictions placed on it, > > No restrictions for whom? Just for the user whose inventory it is (but then > he/she has to authenticate somehow) or no restrictions for anyone? > > because placing restrictions on metadata leads to unsearchable inventories > for which the technical term is "annoying as hell", or more seriously, > poorly functionality and yet another source of lag. > > I agree everyone should be able to access their own inventory tree, > including the item-metadata at its leaf nodes. For the tree part, you later > write > > Regions don't have access to your inventory [...] > > ("inventory" here refers to just the tree, if I understood you correctly). > I guess this is also the case for other users, except where I have given > them explicit permission to view parts of my inventory (if the protocol was > capable of that). > > I am going to assume that nobody wants that [poor functionality and lag] > and hence, that metadata is never accessed through capabilities. > > Now here I'm beginning to wonder, what data all is part of the tree (that > others aren't able to access) and what is instead part of the item-metadata, > (a fraction of) which needs to be broadcasted to other users, as it contains > the references to the assets those other users have to fetch to render my > avatar correctly. For example, is the item name part of that metadata or > part of the tree? It obviously isn't needed by others, it's merely a > reminder for myself of what that item is. > > If the item name for worn stuff *is* broadcasted together with the other > relevant metadata, that's OK as long as the user is aware of it, but it * > does* have some consequences: In that case, I probably wouldn't want to > name a wearable "The dress that this stupid guy bought me, but that I like > to wear anyway" or "Those shoes that my secret lover Example Resident gave > me" but something more innocent, so that I wouldn't upset that other user > and wouldn't leak that Example Resident was my secret lover. > > There might be other metadata that's useful to the users themselves but > that they might want to withhold from region owners and other users. Imagine > for example information about where and when you acquired an item, which > allows you to efficiently search for that item when you forgot the item name > but still remember how you got it. However, if that info is broadcasted for > worn items and you wear enough different items, everyone around you has a > partial trace of your virtual travels. > > So we can either split the metadata asset according to reason (3) above > into several assets with different access policies. Or we just lump metadata > we want to keep private together with the tree while only having metadata we > don't mind sharing in the metadata assets. > > Cheers, > Boroondas > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > --000e0cd25cae19265304a09c207a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Excellent response, Boroondas, full of detailed analysis! :-)

    I won&= #39;t respond to everything in-line because it would be mostly a long seque= nce of "Yes!" and "Good idea!", but I'll expand in = a couple of areas where your reply makes me think that I should have been c= learer, and also where I prefer your suggestions to mine.

    What's more, I'll adopt your suggested nomenclature straight aw= ay:

    asset =3D=3D (metadata + c= ontent)

    I like that!=A0 "Metadata + data" has ne= ver felt right, because everything is "data". :-)



    On Sun, Apr 10, 2011 at 10:27 PM, Boroondas Gupte <sllists@boroon.dasgu= pta.ch> wrote:
    =20 =20 =20 =20


    > On 04/10/2011 03:11 PM, Morgaine wrote:
    >= > The metadata has to be available to remote parties in the same way as the data itself is, and the best way of handling this is to make metadata a separate item normally stored in the same asset service as the data.

    As far as I know, this differs slightly from the concepts/architecture in SL. This might be a good thing, but because it is almost, but not completely, the same, we should be aware of these differences: In SL, there are the concept of assets (which are what I called 'content' above) and the concept of inventory ite= ms, referencing these assets and holding additional information such as permissions, name, etc. These inventory items themselves however are not considered assets in SL.

    So far, that's just a difference in nomenclature, I guess. But the SL inventory items are also handled differently from SL assets: They aren't stored (and served to the region) by the asset server, like assets are, but instead by the inventory service, which also serves the inventory tree. In fact, at least in the viewer's data model, the folders making up that tree are just special inventory items that do not reference assets but reference other inventory items.
    One of the drawbacks of how SL draws the line between inventory (-items) and assets is that it's probably difficult to implement something like VWR-2427. Treating the item-metadata as a type of assets as you seem to suggest might allow to better exploit the commonality that both inventory items and some data assets can refer to other assets.

    (Note that I'm not really an expert on SL's internal architectu= re, and most of the above is based on hear-say and some viewer code comments I remember. Please correct me if I'm wrong somewhere.)
    =
    =20

    I'm not an expert on SL's architecture eith= er, but our discussions in the AWG over 3+ years suggest that your analysis= above is correct.=A0 We are actually sticking fairly closely to the con= ceptual model used in SL (not for compatibility, but because it is a re= asonable model), but we are departing from SL's physical model i= n some significant ways to gain better functional properties.

    According to the very rough consensus in AW Groupies (:P), in SL only t= he content is stored in asset storage, whereas metadata is stored in a relational database (and is mutable).=A0 In the des= ign that we are discussing here for VWRAP asset services, both content and metadata are held in asset services, and both types of data a= re immutable.=A0 Our "updates" are achieved simply by referring t= o new metadata.

    SL handles its metadata specially and caches it in an inventory cache s= eparately from content, whereas we store and cache them uniformly in both a= sset services and caches.=A0 Our inventories merely organize our cached met= adata into a hierarchical view.=A0 We're building on past experi= ence to improve functionality and performance and scalability (and elegance= too!), which is quite natural.

    The "information about assets" stored at the leaves of invent= ories in SL-compatible clients is conceptually very similar to the metadata= stored in our proposed asset services.=A0 Even the content referencing mod= el is similar, in the sense that capabilities are used in SL to obtain the = UUIDs of textures for example, and these UUIDs are then stored in the metad= ata held in inventory items.

    In other words, UUIDs held in SL inventory leaves are equivalent to our= direct addresses (URIs) held in metadata.=A0 In both cases, once yo= u have the UUID or direct address, you no longer need a capability t= o obtain the item.=A0 The cap's only function is to control acquisition= of the UUID, which is the actual address of the content.=A0 Our content UR= Is just extend the concept of an address to external asset services.


    >> The metadata item will naturally reference the corresponding data item (which is an N:1 relationship when hash-based addressing is used), and in some cases can reference more than one data item --- for example, the metadata of a mesh will commonly reference not only the graphical data required for rendering in the client but also the collision mesh or bounding box data required by the region.
    =A0
    > Wouldn't it make more sense to keep the metadata-item-to-data-= item relation strictly N:1, and have the mesh data item have a N:N relation to it's components? (Analogous to SL gestures.) While the item type should be part of the metadata, I don't think the metadata's structure should depend on the item = type. After all, the structure of inodes of a file system also doesn't depend on the file formats of the referenced files.


    Yes!=A0 That makes = more sense.=A0 I withdraw my N:M suggestion. :-)=A0 Let's stick with N:= 1 and then be more clever with content if needed later.=A0 This is also in = keeping with my cost engineering mantra, namely "The burden of X shoul= d be borne only by those who need X".=A0 There is no sense complicatin= g metadata to make it N:M when the vast majority of its use cases are N:1.<= br>

    >> As a final point about metadata versus data, it should be mentioned that generally only the data ever has access restrictions placed on it,

    > No restrictions for whom? Just for the user whose inventory it is (but then he/she has to authenticate somehow) or no restrictions for anyone?


    Sorry, I was ambiguous.=A0 What I should have said was "On= ly access to the content of assets may be restricted by access controls, an= d only when it is appropriate to do so (eg. never for open content).=A0 Acc= ess to the metadata of assets is never restricted, for anyone.=A0 When acce= ss controls restrict access to the content of a particular asset, then diff= erent policies may be applied to agents who hold assets in inventory and ag= ents who merely render assets worn by others in the region.=A0 The asset se= rvice holds authority over the asset, and has the power to discriminate.&qu= ot;

    > ("inventory" here refers to just the tree, if I understo= od you correctly). I guess this is also the case for other users, except where I have given them explicit permission to view parts of my inventory (if the protocol was capable of that).
    =20

    I do not envisage anyone ever having access to an agent's i= nventory, other than the agent who owns the inventory (inventories are clie= nt-side after all, despite also being saved server-side).=A0 Only the metad= ata that an inventory may be referencing can ever be seen by others (for ex= ample, when a region provides the references), but never the hierarchical s= tructure.=A0 This is similar to how SL/Opensim works:=A0 you can inspect th= e metadata of an asset in the scene and see that it is owned by user X, but= you have no access to X's inventory.


    >= ;> I am going to assume that nobody wants that [poor functionality and lag] and hence, that metadata is never accessed through capabilities.

    > Now here I'm beginning to wonder, what data all is part of the= tree (that others aren't able to access) and what is instead part of the item-metadata, (a fraction of) which needs to be broadcasted to other users, as it contains the references to the assets those other users have to fetch to render my avatar correctly. For example, is the item name part of that metadata or part of the tree? It obviously isn't needed by others, it's merely a reminder for my= self of what that item is.


    Just in case I wasn't clear before, I'll underline that= inventory trees are entirely unrelated to the process by which others gain= access to assets (they use metadata which links to content, not inventorie= s).=A0 The only reason why I mentioned inventories at all is because they t= oo happen to point to metadata.=A0 As to the question of what is in invento= ries that isn't in metadata, the answer is "almost nothing" o= ther than the hierarchical skeleton of named folders.=A0 I guess it's p= ossible to have local symlinks, and even to modify the metadata locally if = desired, for example to change the local name of an item, but those are jus= t frills.=A0 Generally, inventory is merely metadata organized locally into= a tree.


    > If the item name for worn stuff is broadcasted together wit= h the other relevant metadata, that's OK as long as the user is aware of it, but it does have some consequences: In that case, I probably wouldn't want to name a wearable "The dress that this stupid guy bought me, but that I like to wear anyway" or "Tho= se shoes that my secret lover Example Resident gave me" but something more innocent, so that I wouldn't upset that other user and wouldn&= #39;t leak that Example Resident was my secret lover.

    Haha. :-)=A0 Well it's already the case in SL that the metadata= is inspectable, so people are already used to the fact that how they name = objects and what they write in object descriptions is visible publicly, not= hing new there.


    > There might be other metadata that's useful to the users thems= elves but that they might want to withhold from region owners and other users. Imagine for example information about where and when you acquired an item, which allows you to efficiently search for that item when you forgot the item name but still remember how you got it. However, if that info is broadcasted for worn items and you wear enough different items, everyone around you has a partial trace of your virtual travels.


    Yes, good ideas for purely local= enhancements to inventories. :-)=A0 I'm sure that inventories can be e= xtended in many useful ways to build upon their primary role of organizing = and referencing metadata.=A0 That could be a very interesting area.=A0 Anyo= ne with dozens of thousands of objects in inventory can appreciate very wel= l the need for some new thinking to help us manage the object explosion. :-= )
    =20

    Morgaine.




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

    O= n Sun, Apr 10, 2011 at 10:27 PM, Boroondas Gupte <sllists@boroon.dasgupta.ch>= ; wrote:
    =20 =20 =20 =20
    Hi Morgaine

    The distinction between metadata and 'content' and storing them= in separately acquirable chunks is a good and quite important idea, I think. More generally, I can think of several reasons to split a monolithic data entity E into several separate ones, connected by referencing each other or by being referenced by a common meta-entity which replaces the previous monolithic entity:
    1. Several other entities are expected to have some parts in common with E, without having other parts in common with it.
    2. Some parties only need some parts of E, but not other parts.
    3. Some parties are only allowed access to some parts of E, but not to other parts.
    (You might note the similarity between reason (1) and rules used for database normalization.)

    If the entities are immutable (which assets should be according to previous discussion), (1) can not only occur between unrelated items but will also be very common for items that result from changing a previous item. Some examples how this applies specifically to the metadata-content separation (assuming a similar inventory UI as we have in SL):
    • You rez an object from inventory, resize it, and take it back into inventory (which creates a new item there).
      • Same metadata (permissions, name(?), owner)
        • (What about a 'last edited' date, though? SL doesn= 9;t seem to store one, but some VWRAP systems might want to keep that info.)
      • Different content
    • You rename an item in-inventory
      • Different metadata (maybe ... see below)
      • Same content
    • You change next-owner permissions on an item, then give it to someone
      • Different metadata
      • Same content
    Reason (2) off course occurs when browsing your inventory. If you just want to e.g. read the names of your items, you don't have to fetch all the associated content data.

    Off course, there are more potential separations that fit one or several of these three reasons than just the metadata-content one. In SL, having objects being composed of prims, having prims reference textures for their faces instead of having the texture data lumped into their own data, or gestures being composed of steps some of which can reference animation and sound assets are other examples of such separations.

    On 04/10/2011 03:11 PM, Morgaine wrote:
    It is worth noting that while inventories are= mostly a client-side implementation detail which can be changed unilaterally, the metadata held by inventories is a very important and separable information type in an architecture that uses 3rd party asset services, so it needs detailed examination.

    The metadata has to be available to remote parties in the same way as the data itself is, and the best way of handling this is to make metadata a separate item normally stored in the same asset service as the data.
    As far as I know, this differs slightly from the concepts/architecture in SL. This might be a good thing, but because it is almost, but not completely, the same, we should be aware of these differences: In SL, there are the concept of assets (which are what I called 'content' above) and the concept of inventory ite= ms, referencing these assets and holding additional information such as permissions, name, etc. These inventory items themselves however are not considered assets in SL.

    So far, that's just a difference in nomenclature, I guess. But the SL inventory items are also handled differently from SL assets: They aren't stored (and served to the region) by the asset server, like assets are, but instead by the inventory service, which also serves the inventory tree. In fact, at least in the viewer's data model, the folders making up that tree are just special inventory items that do not reference assets but reference other inventory items.

    One of the drawbacks of how SL draws the line between inventory (-items) and assets is that it's probably difficult to implement something like VWR-2427. Treating the item-metadata as a type of assets as you seem to suggest might allow to better exploit the commonality that both inventory items and some data assets can refer to other assets.

    (Note that I'm not really an expert on SL's internal architectu= re, and most of the above is based on hear-say and some viewer code comments I remember. Please correct me if I'm wrong somewhere.)

    The metadata item will naturally reference th= e corresponding data item (which is an N:1 relationship when hash-based addressing is used), and in some cases can reference more than one data item --- for example, the metadata of a mesh will commonly reference not only the graphical data required for rendering in the client but also the collision mesh or bounding box data required by the region.
    Wouldn't it make more sense to keep the metadata-item-to-data-item relation strictly N:1, and have the mesh data item have a N:N relation to it's components? (Analogous to SL gestures.) While the item type should be part of the metadata, I don't think the metadata's structure should depend on the item = type. After all, the structure of inodes of a file system also doesn't depend on the file formats of the referenced files.

    These two types of data are separate because = it would be inefficient to require clients or regions to download data that they do not use.=A0 Our "asset" singleton now turns into a = metadata + data pair.
    Yep.

    As a final point about metadata versus data, it should be mentioned that generally only the data ever has access restrictions placed on it,
    No restrictions for whom? Just for the user whose inventory it is (but then he/she has to authenticate somehow) or no restrictions for anyone?

    because placing restrictions on metadata leads to unsearchable inventories for which the technical term is "annoying as hell&qu= ot;, or more seriously, poorly functionality and yet another source of lag.
    I agree everyone should be able to access their own inventory tree, including the item-metadata at its leaf nodes. For the tree part, you later write
    Regions don't have access to your invento= ry [...]
    ("inventory" here refers to just the tree, if I understood yo= u correctly). I guess this is also the case for other users, except where I have given them explicit permission to view parts of my inventory (if the protocol was capable of that).

    I am going to assume that nobody wants that [= poor functionality and lag] and hence, that metadata is never accessed through capabilities.
    Now here I'm beginning to wonder, what data all is part of the tree (that others aren't able to access) and what is instead part of the item-metadata, (a fraction of) which needs to be broadcasted to other users, as it contains the references to the assets those other users have to fetch to render my avatar correctly. For example, is the item name part of that metadata or part of the tree? It obviously isn't needed by others, it's merely a reminder for my= self of what that item is.

    If the item name for worn stuff is broadcasted together with the other relevant metadata, that's OK as long as the user is aware of it, but it does have some consequences: In that case, I probably wouldn't want to name a wearable "The dress that this stupid guy bought me, but that I like to wear anyway" or "Tho= se shoes that my secret lover Example Resident gave me" but something more innocent, so that I wouldn't upset that other user and wouldn&= #39;t leak that Example Resident was my secret lover.

    There might be other metadata that's useful to the users themselves but that they might want to withhold from region owners and other users. Imagine for example information about where and when you acquired an item, which allows you to efficiently search for that item when you forgot the item name but still remember how you got it. However, if that info is broadcasted for worn items and you wear enough different items, everyone around you has a partial trace of your virtual travels.

    So we can either split the metadata asset according to reason (3) above into several assets with different access policies. Or we just lump metadata we want to keep private together with the tree while only having metadata we don't mind sharing in the metadata assets.<= br>
    Cheers,
    Boroondas

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


    --000e0cd25cae19265304a09c207a-- From morgaine.dinova@googlemail.com Sun Apr 10 21:22:26 2011 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 BDFDC3A6A5B for ; Sun, 10 Apr 2011 21:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsyaYFeRRIm5 for ; Sun, 10 Apr 2011 21:22:22 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 7DF493A6A43 for ; Sun, 10 Apr 2011 21:22:22 -0700 (PDT) Received: by qwc23 with SMTP id 23so3712971qwc.31 for ; Sun, 10 Apr 2011 21:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jbC1mxtGI6aLAaB8YCNJs9VdOlyhBJz+CMeXydtV0kY=; b=xwZ/k123z5l/kxn/6ZOULuCBtiDvd0BMVKOqxzsg6A4HKiOUQg5WEtHLJT6PvQ0ECM KPt3sFGMuqnG112nZt0VmTyboCjCykP14GSsGn0D/89ImZje0WfYXMycxnbiFdu8oO2L PWNIciSaGeBISRXEuvzUCpkX0/fs+A0y+Yck0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sxS1Gbi1WTkl+jV+ZObImasDNuDqRJZOlSnvWquk0ky+mVfF8mrJ7g10n0bLyAXyQB JSAOJW1c2/MGefDdW+djUqJpd6J3gkHoCqwoFwrf2fu/6ANAUdrCxYeq+a5vBGyG8gWz wBLrZprxMZILaNry8s7NybsfVDW4jYasmprYs= MIME-Version: 1.0 Received: by 10.229.37.130 with SMTP id x2mr3732981qcd.147.1302495741951; Sun, 10 Apr 2011 21:22:21 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sun, 10 Apr 2011 21:22:21 -0700 (PDT) In-Reply-To: References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> <4DA220B1.6020400@boroon.dasgupta.ch> Date: Mon, 11 Apr 2011 05:22:21 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016368340c005405204a09ceccd Subject: Re: [vwrap] Inventory, Asset Metadata and Privacy (was: [wvrap] Simulation consistency) 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, 11 Apr 2011 04:22:26 -0000 --0016368340c005405204a09ceccd Content-Type: text/plain; charset=ISO-8859-1 I'd better tighten up one paragraph I wrote, because it could be interpreted as "all metadata is public", which wasn't intended. Here's an improved version: "Access to the *content* of a restricted asset may be achieved by first acquiring a capability for that asset. A capability needs to be acquired only when that asset's metadata indicates that the content is restricted. Access to the *metadata* of an asset is never restricted, for anyone, once an asset has been placed in-world. Until an asset is placed in-world, its metadata address is not known to anyone except the owner of the asset, and is unguessable. When an asset service restricts access to the content of a particular asset, then different policies may be applied to agents who hold assets in inventory and agents who merely render assets worn by others in the region. The asset service holds authority over the asset, and has the power to discriminate." And further on access controls, a point which we haven't yet discussed: "If access to the content of a restricted asset is attempted without using a capability, the access attempt will be rejected by the asset service because insufficient credentials were provided. Consequently, simply removing the * Restricted* property from a restricted asset's metadata in order to avoid requesting a capability cannot bypass required access controls." Those are actually reasonable paragraphs for a draft document describing the design model of VWRAP asset services, assuming there is agreement. :-) Morgaine. =========================== On Mon, Apr 11, 2011 at 4:25 AM, Morgaine wrote: > > > Sorry, I was ambiguous. What I should have said was "Only access to the > content of assets may be restricted by access controls, and only when it is > appropriate to do so (eg. never for open content). Access to the metadata > of assets is never restricted, for anyone. When access controls restrict > access to the content of a particular asset, then different policies may be > applied to agents who hold assets in inventory and agents who merely render > assets worn by others in the region. The asset service holds authority over > the asset, and has the power to discriminate." > > > On Mon, Apr 11, 2011 at 4:25 AM, Morgaine wrote: > Excellent response, Boroondas, full of detailed analysis! :-) > > I won't respond to everything in-line because it would be mostly a long > sequence of "Yes!" and "Good idea!", but I'll expand in a couple of areas > where your reply makes me think that I should have been clearer, and also > where I prefer your suggestions to mine. > > What's more, I'll adopt your suggested nomenclature straight away: > > *asset == (metadata + content)* > > I like that! "Metadata + data" has never felt right, because everything is > "data". :-) > > > > > On Sun, Apr 10, 2011 at 10:27 PM, Boroondas Gupte < > sllists@boroon.dasgupta.ch> wrote: > >> >> >> > On 04/10/2011 03:11 PM, Morgaine wrote: > >> The metadata has to be available to remote parties in the same way as > the data itself is, and the best way of handling this is to make metadata a > separate item normally stored in the same asset service as the data. > > As far as I know, this differs slightly from the concepts/architecture in > SL. This might be a good thing, but because it is almost, but not > completely, the same, we should be aware of these differences: In SL, there > are the concept of assets (which are what I called 'content' above) and the > concept of inventory items, referencing these assets and holding additional > information such as permissions, name, etc. These inventory items themselves > however are *not* considered assets in SL. > > So far, that's just a difference in nomenclature, I guess. But the SL > inventory items are also handled differently from SL assets: They aren't > stored (and served to the region) by the asset server, like assets are, but > instead by the inventory service, which also serves the inventory tree. In > fact, at least in the viewer's data model, the folders making up that tree > are just special inventory items that do not reference assets but reference > other inventory items. > > One of the drawbacks of how SL draws the line between inventory (-items) > and assets is that it's probably difficult to implement something like > VWR-2427 . Treating the > item-metadata as a type of assets as you seem to suggest might allow to > better exploit the commonality that both inventory items and some data > assets can refer to other assets. > > (Note that I'm not really an expert on SL's internal architecture, and most > of the above is based on hear-say and some viewer code comments I remember. > Please correct me if I'm wrong somewhere.) > > > I'm not an expert on SL's architecture either, but our discussions in the > AWG over 3+ years suggest that your analysis above is correct. We are > actually sticking fairly closely to the *conceptual* model used in SL (not > for compatibility, but because it is a reasonable model), but we are > departing from SL's *physical* model in some significant ways to gain > better functional properties. > > According to the very rough consensus in AW Groupies (:P), in SL only the > *content* is stored in *asset storage*, whereas *metadata* is stored in a > *relational database* (and is mutable). In the design that we are > discussing here for VWRAP asset services, both *content* and *metadata *are > held in asset services, and both types of data are immutable. Our "updates" > are achieved simply by referring to new metadata. > > SL handles its metadata specially and caches it in an inventory cache > separately from content, whereas we store and cache them uniformly in both > asset services and caches. Our inventories merely organize our cached > metadata into a hierarchical *view*. We're building on past experience to > improve functionality and performance and scalability (and elegance too!), > which is quite natural. > > The "information about assets" stored at the leaves of inventories in > SL-compatible clients is conceptually very similar to the metadata stored in > our proposed asset services. Even the content referencing model is similar, > in the sense that capabilities are used in SL to obtain the UUIDs of > textures for example, and these UUIDs are then stored in the metadata held > in inventory items. > > In other words, UUIDs held in SL inventory leaves are equivalent to our *direct > addresses* (URIs) held in metadata. In both cases, once you have the UUID > or *direct address*, you no longer need a capability to obtain the item. > The cap's only function is to control acquisition of the UUID, which is the > actual address of the content. Our content URIs just extend the concept of > an address to external asset services. > > > >> The metadata item will naturally reference the corresponding data item > (which is an N:1 relationship when hash-based addressing is used), and in > some cases can reference more than one data item --- for example, the > metadata of a mesh will commonly reference not only the graphical data > required for rendering in the client but also the collision mesh or bounding > box data required by the region. > > > Wouldn't it make more sense to keep the metadata-item-to-data-item > relation strictly N:1, and have the mesh data item have a N:N relation to > it's components? (Analogous to SL gestures.) While the item type should be > part of the metadata, I don't think the metadata's structure should depend > on the item type. After all, the structure of inodes of a file system also > doesn't depend on the file formats of the referenced files. > >> >> > Yes! That makes more sense. I withdraw my N:M suggestion. :-) Let's > stick with N:1 and then be more clever with content if needed later. This > is also in keeping with my cost engineering mantra, namely "The burden of X > should be borne only by those who need X". There is no sense complicating > metadata to make it N:M when the vast majority of its use cases are N:1. > > > > >> As a final point about metadata versus data, it should be mentioned > that generally only the data ever has access restrictions placed on it, > > > No restrictions for whom? Just for the user whose inventory it is (but > then he/she has to authenticate somehow) or no restrictions for anyone? > > > Sorry, I was ambiguous. What I should have said was "Only access to the > content of assets may be restricted by access controls, and only when it is > appropriate to do so (eg. never for open content). Access to the metadata > of assets is never restricted, for anyone. When access controls restrict > access to the content of a particular asset, then different policies may be > applied to agents who hold assets in inventory and agents who merely render > assets worn by others in the region. The asset service holds authority over > the asset, and has the power to discriminate." > > > > > ("inventory" here refers to just the tree, if I understood you > correctly). I guess this is also the case for other users, except where I > have given them explicit permission to view parts of my inventory (if the > protocol was capable of that). > > > I do not envisage anyone ever having access to an agent's inventory, other > than the agent who owns the inventory (inventories are client-side after > all, despite also being saved server-side). Only the metadata that an > inventory may be referencing can ever be seen by others (for example, when a > region provides the references), but never the hierarchical structure. This > is similar to how SL/Opensim works: you can inspect the metadata of an > asset in the scene and see that it is owned by user X, but you have no > access to X's inventory. > > > > >> I am going to assume that nobody wants that [poor functionality and lag] > and hence, that metadata is never accessed through capabilities. > > > Now here I'm beginning to wonder, what data all is part of the tree (that > others aren't able to access) and what is instead part of the item-metadata, > (a fraction of) which needs to be broadcasted to other users, as it contains > the references to the assets those other users have to fetch to render my > avatar correctly. For example, is the item name part of that metadata or > part of the tree? It obviously isn't needed by others, it's merely a > reminder for myself of what that item is. > > > Just in case I wasn't clear before, I'll underline that inventory trees are > entirely unrelated to the process by which others gain access to assets > (they use metadata which links to content, not inventories). The only > reason why I mentioned inventories at all is because they too happen to > point to metadata. As to the question of what is in inventories that isn't > in metadata, the answer is "almost nothing" other than the hierarchical > skeleton of named folders. I guess it's possible to have local symlinks, > and even to modify the metadata locally if desired, for example to change > the local name of an item, but those are just frills. Generally, inventory > is merely metadata organized locally into a tree. > > > > > If the item name for worn stuff *is* broadcasted together with the other > relevant metadata, that's OK as long as the user is aware of it, but it * > does* have some consequences: In that case, I probably wouldn't want to > name a wearable "The dress that this stupid guy bought me, but that I like > to wear anyway" or "Those shoes that my secret lover Example Resident gave > me" but something more innocent, so that I wouldn't upset that other user > and wouldn't leak that Example Resident was my secret lover. > > Haha. :-) Well it's already the case in SL that the metadata is > inspectable, so people are already used to the fact that how they name > objects and what they write in object descriptions is visible publicly, > nothing new there. > > > > > There might be other metadata that's useful to the users themselves but > that they might want to withhold from region owners and other users. Imagine > for example information about where and when you acquired an item, which > allows you to efficiently search for that item when you forgot the item name > but still remember how you got it. However, if that info is broadcasted for > worn items and you wear enough different items, everyone around you has a > partial trace of your virtual travels. > > > Yes, good ideas for purely local enhancements to inventories. :-) I'm sure > that inventories can be extended in many useful ways to build upon their > primary role of organizing and referencing metadata. That could be a very > interesting area. Anyone with dozens of thousands of objects in inventory > can appreciate very well the need for some new thinking to help us manage > the object explosion. :-) > > > Morgaine. > > > > > ====================== > > On Sun, Apr 10, 2011 at 10:27 PM, Boroondas Gupte < > sllists@boroon.dasgupta.ch> wrote: > >> Hi Morgaine >> >> The distinction between metadata and 'content' and storing them in >> separately acquirable chunks is a good and quite important idea, I think. >> More generally, I can think of several reasons to split a monolithic data >> entity E into several separate ones, connected by referencing each other or >> by being referenced by a common meta-entity which replaces the previous >> monolithic entity: >> >> 1. Several other entities are expected to have some parts in common >> with E, without having other parts in common with it. >> 2. Some parties only need some parts of E, but not other parts. >> 3. Some parties are only allowed access to some parts of E, but not >> to other parts. >> >> (You might note the similarity between reason (1) and rules used for >> database normalization.) >> >> If the entities are immutable (which assets should be according to >> previous discussion), >> (1) can not only occur between unrelated items but will also be very common >> for items that result from changing a previous item. Some examples how this >> applies specifically to the metadata-content separation (assuming a similar >> inventory UI as we have in SL): >> >> - You rez an object from inventory, resize it, and take it back into >> inventory (which creates a new item there). >> - Same metadata (permissions, name(?), owner) >> - (What about a 'last edited' date, though? SL doesn't seem to >> store one, but some VWRAP systems might want to keep that info.) >> - Different content >> - You rename an item in-inventory >> - Different metadata (maybe ... see below) >> - Same content >> - You change next-owner permissions on an item, then give it to >> someone >> - Different metadata >> - Same content >> >> Reason (2) off course occurs when browsing your inventory. If you just >> want to e.g. read the names of your items, you don't have to fetch all the >> associated content data. >> >> Off course, there are more potential separations that fit one or several >> of these three reasons than just the metadata-content one. In SL, having >> objects being composed of prims, having prims reference textures for their >> faces instead of having the texture data lumped into their own data, or >> gestures being composed of steps some of which can reference animation and >> sound assets are other examples of such separations. >> >> On 04/10/2011 03:11 PM, Morgaine wrote: >> >> It is worth noting that while inventories are mostly a client-side >> implementation detail which can be changed unilaterally, the *metadata*held by inventories is a very important and separable information type in an >> architecture that uses 3rd party asset services, so it needs detailed >> examination. >> >> The metadata has to be available to remote parties in the same way as the >> data itself is, and the best way of handling this is to make metadata a >> separate item normally stored in the same asset service as the data. >> >> As far as I know, this differs slightly from the concepts/architecture in >> SL. This might be a good thing, but because it is almost, but not >> completely, the same, we should be aware of these differences: In SL, there >> are the concept of assets (which are what I called 'content' above) and the >> concept of inventory items, referencing these assets and holding additional >> information such as permissions, name, etc. These inventory items themselves >> however are *not* considered assets in SL. >> >> So far, that's just a difference in nomenclature, I guess. But the SL >> inventory items are also handled differently from SL assets: They aren't >> stored (and served to the region) by the asset server, like assets are, but >> instead by the inventory service, which also serves the inventory tree. In >> fact, at least in the viewer's data model, the folders making up that tree >> are just special inventory items that do not reference assets but reference >> other inventory items. >> >> One of the drawbacks of how SL draws the line between inventory (-items) >> and assets is that it's probably difficult to implement something like >> VWR-2427 . Treating the >> item-metadata as a type of assets as you seem to suggest might allow to >> better exploit the commonality that both inventory items and some data >> assets can refer to other assets. >> >> (Note that I'm not really an expert on SL's internal architecture, and >> most of the above is based on hear-say and some viewer code comments I >> remember. Please correct me if I'm wrong somewhere.) >> >> The metadata item will naturally reference the corresponding data item >> (which is an N:1 relationship when hash-based addressing is used), and in >> some cases can reference more than one data item --- for example, the >> metadata of a mesh will commonly reference not only the graphical data >> required for rendering in the client but also the collision mesh or bounding >> box data required by the region. >> >> Wouldn't it make more sense to keep the metadata-item-to-data-item >> relation strictly N:1, and have the mesh data item have a N:N relation to >> it's components? (Analogous to SL gestures.) While the item type should be >> part of the metadata, I don't think the metadata's structure should depend >> on the item type. After all, the structure of inodes of a file system also >> doesn't depend on the file formats of the referenced files. >> >> These two types of data are separate because it would be inefficient to >> require clients or regions to download data that they do not use. Our >> "asset" singleton now turns into a metadata + data pair. >> >> Yep. >> >> As a final point about metadata versus data, it should be mentioned that >> generally only the data ever has access restrictions placed on it, >> >> No restrictions for whom? Just for the user whose inventory it is (but >> then he/she has to authenticate somehow) or no restrictions for anyone? >> >> because placing restrictions on metadata leads to unsearchable >> inventories for which the technical term is "annoying as hell", or more >> seriously, poorly functionality and yet another source of lag. >> >> I agree everyone should be able to access their own inventory tree, >> including the item-metadata at its leaf nodes. For the tree part, you later >> write >> >> Regions don't have access to your inventory [...] >> >> ("inventory" here refers to just the tree, if I understood you correctly). >> I guess this is also the case for other users, except where I have given >> them explicit permission to view parts of my inventory (if the protocol was >> capable of that). >> >> I am going to assume that nobody wants that [poor functionality and lag] >> and hence, that metadata is never accessed through capabilities. >> >> Now here I'm beginning to wonder, what data all is part of the tree (that >> others aren't able to access) and what is instead part of the item-metadata, >> (a fraction of) which needs to be broadcasted to other users, as it contains >> the references to the assets those other users have to fetch to render my >> avatar correctly. For example, is the item name part of that metadata or >> part of the tree? It obviously isn't needed by others, it's merely a >> reminder for myself of what that item is. >> >> If the item name for worn stuff *is* broadcasted together with the other >> relevant metadata, that's OK as long as the user is aware of it, but it * >> does* have some consequences: In that case, I probably wouldn't want to >> name a wearable "The dress that this stupid guy bought me, but that I like >> to wear anyway" or "Those shoes that my secret lover Example Resident gave >> me" but something more innocent, so that I wouldn't upset that other user >> and wouldn't leak that Example Resident was my secret lover. >> >> There might be other metadata that's useful to the users themselves but >> that they might want to withhold from region owners and other users. Imagine >> for example information about where and when you acquired an item, which >> allows you to efficiently search for that item when you forgot the item name >> but still remember how you got it. However, if that info is broadcasted for >> worn items and you wear enough different items, everyone around you has a >> partial trace of your virtual travels. >> >> So we can either split the metadata asset according to reason (3) above >> into several assets with different access policies. Or we just lump metadata >> we want to keep private together with the tree while only having metadata we >> don't mind sharing in the metadata assets. >> >> Cheers, >> Boroondas >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > --0016368340c005405204a09ceccd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd better tighten up one paragraph I wrote, because it could be interp= reted as "all metadata is public", which wasn't intended.=A0 = Here's an improved version:


    "If access to the content of a restricted as= set is attempted without using a capability, the access attempt will be rej= ected by the asset service because insufficient credentials were provided.= =A0 Consequently, simply removing the Restricted property from a res= tricted asset's metadata in order to avoid requesting a capability cann= ot bypass required access controls."


    Those are actually reasonable paragraphs for a draft document= describing the design model of VWRAP asset services, assuming there is agr= eement. :-)


    Morgaine.




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


    On Mon, Apr 11, 2011 at 4:25 AM, Morgaine <morgaine.dinova@googlemail.c= om> wrote:


    Sorry, I was ambig= uous.=A0 What I should have said was=20 "Only access to the content of assets may be restricted by access=20 controls, and only when it is appropriate to do so (eg. never for open=20 content).=A0 Access to the metadata of assets is never restricted, for=20 anyone.=A0 When access controls restrict access to the content of a=20 particular asset, then different policies may be applied to agents who=20 hold assets in inventory and agents who merely render assets worn by=20 others in the region.=A0 The asset service holds authority over the asset, and has the power to discriminate."


    <cut>



    On Mon, Apr 11, 2011 at 4:25 AM, Morgaine <morgaine.dinova@googlemail.c= om> wrote:
    Excellent respons= e, Boroondas, full of detailed analysis! :-)

    I won't respond to = everything in-line because it would be mostly a long sequence of "Yes!= " and "Good idea!", but I'll expand in a couple of areas= where your reply makes me think that I should have been clearer, and also = where I prefer your suggestions to mine.

    What's more, I'll adopt your suggested nomenclature straight aw= ay:

    asset =3D=3D (metadata + c= ontent)

    I like that!=A0 "Metadata + data" has ne= ver felt right, because everything is "data". :-)




    On Sun, Apr 10, 2011 at 10:27 PM, Boroondas Gupte <sl= lists@boroon.dasgupta.ch> wrote:
    =20 =20 =20 =20


    > On 04/10/2011 03:11 PM, Morgaine wrote:
    >> The metadata has to be available to remote pa= rties in the same way as the data itself is, and the best way of handling this is to make metadata a separate item normally stored in the same asset service as the data.

    As far as I know, this differs slightly from the concepts/architecture in SL. This might be a good thing, but because it is almost, but not completely, the same, we should be aware of these differences: In SL, there are the concept of assets (which are what I called 'content' above) and the concept of inventory ite= ms, referencing these assets and holding additional information such as permissions, name, etc. These inventory items themselves however are not considered assets in SL.

    So far, that's just a difference in nomenclature, I guess. But the SL inventory items are also handled differently from SL assets: They aren't stored (and served to the region) by the asset server, like assets are, but instead by the inventory service, which also serves the inventory tree. In fact, at least in the viewer's data model, the folders making up that tree are just special inventory items that do not reference assets but reference other inventory items.
    One of the drawbacks of how SL draws the line between inventory (-items) and assets is that it's probably difficult to implement something like VWR-2427. Treating the item-metadata as a type of assets as you seem to suggest might allow to better exploit the commonality that both inventory items and some data assets can refer to other assets.

    (Note that I'm not really an expert on SL's internal architectu= re, and most of the above is based on hear-say and some viewer code comments I remember. Please correct me if I'm wrong somewhere.)
    =
    =20

    I'm not an expert on SL's architecture eith= er, but our discussions in the AWG over 3+ years suggest that your analysis= above is correct.=A0 We are actually sticking fairly closely to the con= ceptual model used in SL (not for compatibility, but because it is a re= asonable model), but we are departing from SL's physical model i= n some significant ways to gain better functional properties.

    According to the very rough consensus in AW Groupies (:P), in SL only t= he content is stored in asset storage, whereas metadata is stored in a relational database (and is mutable).=A0 In the des= ign that we are discussing here for VWRAP asset services, both content and metadata are held in asset services, and both types of data a= re immutable.=A0 Our "updates" are achieved simply by referring t= o new metadata.

    SL handles its metadata specially and caches it in an inventory cache s= eparately from content, whereas we store and cache them uniformly in both a= sset services and caches.=A0 Our inventories merely organize our cached met= adata into a hierarchical view.=A0 We're building on past experi= ence to improve functionality and performance and scalability (and elegance= too!), which is quite natural.

    The "information about assets" stored at the leaves of invent= ories in SL-compatible clients is conceptually very similar to the metadata= stored in our proposed asset services.=A0 Even the content referencing mod= el is similar, in the sense that capabilities are used in SL to obtain the = UUIDs of textures for example, and these UUIDs are then stored in the metad= ata held in inventory items.

    In other words, UUIDs held in SL inventory leaves are equivalent to our= direct addresses (URIs) held in metadata.=A0 In both cases, once yo= u have the UUID or direct address, you no longer need a capability t= o obtain the item.=A0 The cap's only function is to control acquisition= of the UUID, which is the actual address of the content.=A0 Our content UR= Is just extend the concept of an address to external asset services.


    >> The metadata item will naturally reference the corresponding data item (which is an N:1 relationship when hash-based addressing is used), and in some cases can reference more than one data item --- for example, the metadata of a mesh will commonly reference not only the graphical data required for rendering in the client but also the collision mesh or bounding box data required by the region.
    =A0
    > Wouldn't it make more sense to keep the metadata-item-to-data-= item relation strictly N:1, and have the mesh data item have a N:N relation to it's components? (Analogous to SL gestures.) While the item type should be part of the metadata, I don't think the metadata's structure should depend on the item = type. After all, the structure of inodes of a file system also doesn't depend on the file formats of the referenced files.


    Yes!=A0 That = makes more sense.=A0 I withdraw my N:M suggestion. :-)=A0 Let's stick w= ith N:1 and then be more clever with content if needed later.=A0 This is al= so in keeping with my cost engineering mantra, namely "The burden of X= should be borne only by those who need X".=A0 There is no sense compl= icating metadata to make it N:M when the vast majority of its use cases are= N:1.



    >> As a final point about metadata versus data, it should be mentioned that generally only the data ever has access restrictions placed on it,

    > No restrictions for whom? Just for the user whose inventory it is (but then he/she has to authenticate somehow) or no restrictions for anyone?


    Sorry, I was ambiguous.=A0 What I should have said was &q= uot;Only access to the content of assets may be restricted by access contro= ls, and only when it is appropriate to do so (eg. never for open content).= =A0 Access to the metadata of assets is never restricted, for anyone.=A0 Wh= en access controls restrict access to the content of a particular asset, th= en different policies may be applied to agents who hold assets in inventory= and agents who merely render assets worn by others in the region.=A0 The a= sset service holds authority over the asset, and has the power to discrimin= ate."


    > ("inventory" here refers to just the tree, if I understo= od you correctly). I guess this is also the case for other users, except where I have given them explicit permission to view parts of my inventory (if the protocol was capable of that).
    =20

    I do not envisage anyone ever having access to an agent&#= 39;s inventory, other than the agent who owns the inventory (inventories ar= e client-side after all, despite also being saved server-side).=A0 Only the= metadata that an inventory may be referencing can ever be seen by others (= for example, when a region provides the references), but never the hierarch= ical structure.=A0 This is similar to how SL/Opensim works:=A0 you can insp= ect the metadata of an asset in the scene and see that it is owned by user = X, but you have no access to X's inventory.



    >= ;> I am going to assume that nobody wants that [poor functionality and lag] and hence, that metadata is never accessed through capabilities.

    > Now here I'm beginning to wonder, what data all is part of the= tree (that others aren't able to access) and what is instead part of the item-metadata, (a fraction of) which needs to be broadcasted to other users, as it contains the references to the assets those other users have to fetch to render my avatar correctly. For example, is the item name part of that metadata or part of the tree? It obviously isn't needed by others, it's merely a reminder for my= self of what that item is.


    Just in case I wasn't clear before, I'll underlin= e that inventory trees are entirely unrelated to the process by which other= s gain access to assets (they use metadata which links to content, not inve= ntories).=A0 The only reason why I mentioned inventories at all is because = they too happen to point to metadata.=A0 As to the question of what is in i= nventories that isn't in metadata, the answer is "almost nothing&q= uot; other than the hierarchical skeleton of named folders.=A0 I guess it&#= 39;s possible to have local symlinks, and even to modify the metadata local= ly if desired, for example to change the local name of an item, but those a= re just frills.=A0 Generally, inventory is merely metadata organized locall= y into a tree.



    > If the item name for worn stuff is broadcasted together wit= h the other relevant metadata, that's OK as long as the user is aware of it, but it does have some consequences: In that case, I probably wouldn't want to name a wearable "The dress that this stupid guy bought me, but that I like to wear anyway" or "Tho= se shoes that my secret lover Example Resident gave me" but something more innocent, so that I wouldn't upset that other user and wouldn&= #39;t leak that Example Resident was my secret lover.

    Haha. :-)=A0 Well it's already the case in SL that the me= tadata is inspectable, so people are already used to the fact that how they= name objects and what they write in object descriptions is visible publicl= y, nothing new there.



    > There might be other metadata that's useful to the users thems= elves but that they might want to withhold from region owners and other users. Imagine for example information about where and when you acquired an item, which allows you to efficiently search for that item when you forgot the item name but still remember how you got it. However, if that info is broadcasted for worn items and you wear enough different items, everyone around you has a partial trace of your virtual travels.


    Yes, good ideas for purely= local enhancements to inventories. :-)=A0 I'm sure that inventories ca= n be extended in many useful ways to build upon their primary role of organ= izing and referencing metadata.=A0 That could be a very interesting area.= =A0 Anyone with dozens of thousands of objects in inventory can appreciate = very well the need for some new thinking to help us manage the object explo= sion. :-)
    =20

    Morgaine.




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

    <= div>
    On Sun, Apr 10, 2011 at 10:27 PM, Boroonda= s Gupte <sllists@boroon.dasgupta.ch> wrote:
    =
    =20 =20 =20 =20
    Hi Morgaine

    The distinction between metadata and 'content' and storing them= in separately acquirable chunks is a good and quite important idea, I think. More generally, I can think of several reasons to split a monolithic data entity E into several separate ones, connected by referencing each other or by being referenced by a common meta-entity which replaces the previous monolithic entity:
    1. Several other entities are expected to have some parts in common with E, without having other parts in common with it.
    2. Some parties only need some parts of E, but not other parts.
    3. Some parties are only allowed access to some parts of E, but not to other parts.
    (You might note the similarity between reason (1) and rules used for database normalization.)

    If the entities are immutable (which assets should be according to previous discussion), (1) can not only occur between unrelated items but will also be very common for items that result from changing a previous item. Some examples how this applies specifically to the metadata-content separation (assuming a similar inventory UI as we have in SL):
    • You rez an object from inventory, resize it, and take it back into inventory (which creates a new item there).
      • Same metadata (permissions, name(?), owner)
        • (What about a 'last edited' date, though? SL doesn= 9;t seem to store one, but some VWRAP systems might want to keep that info.)
      • Different content
    • You rename an item in-inventory
      • Different metadata (maybe ... see below)
      • Same content
    • You change next-owner permissions on an item, then give it to someone
      • Different metadata
      • Same content
    Reason (2) off course occurs when browsing your inventory. If you just want to e.g. read the names of your items, you don't have to fetch all the associated content data.

    Off course, there are more potential separations that fit one or several of these three reasons than just the metadata-content one. In SL, having objects being composed of prims, having prims reference textures for their faces instead of having the texture data lumped into their own data, or gestures being composed of steps some of which can reference animation and sound assets are other examples of such separations.

    On 04/10/2011 03:11 PM, Morgaine wrote:
    It is worth noting that while inventories are= mostly a client-side implementation detail which can be changed unilaterally, the metadata held by inventories is a very important and separable information type in an architecture that uses 3rd party asset services, so it needs detailed examination.

    The metadata has to be available to remote parties in the same way as the data itself is, and the best way of handling this is to make metadata a separate item normally stored in the same asset service as the data.
    As far as I know, this differs slightly from the concepts/architecture in SL. This might be a good thing, but because it is almost, but not completely, the same, we should be aware of these differences: In SL, there are the concept of assets (which are what I called 'content' above) and the concept of inventory ite= ms, referencing these assets and holding additional information such as permissions, name, etc. These inventory items themselves however are not considered assets in SL.

    So far, that's just a difference in nomenclature, I guess. But the SL inventory items are also handled differently from SL assets: They aren't stored (and served to the region) by the asset server, like assets are, but instead by the inventory service, which also serves the inventory tree. In fact, at least in the viewer's data model, the folders making up that tree are just special inventory items that do not reference assets but reference other inventory items.

    One of the drawbacks of how SL draws the line between inventory (-items) and assets is that it's probably difficult to implement something like VWR-2427. Treating the item-metadata as a type of assets as you seem to suggest might allow to better exploit the commonality that both inventory items and some data assets can refer to other assets.

    (Note that I'm not really an expert on SL's internal architectu= re, and most of the above is based on hear-say and some viewer code comments I remember. Please correct me if I'm wrong somewhere.)

    The metadata item will naturally reference th= e corresponding data item (which is an N:1 relationship when hash-based addressing is used), and in some cases can reference more than one data item --- for example, the metadata of a mesh will commonly reference not only the graphical data required for rendering in the client but also the collision mesh or bounding box data required by the region.
    Wouldn't it make more sense to keep the metadata-item-to-data-item relation strictly N:1, and have the mesh data item have a N:N relation to it's components? (Analogous to SL gestures.) While the item type should be part of the metadata, I don't think the metadata's structure should depend on the item = type. After all, the structure of inodes of a file system also doesn't depend on the file formats of the referenced files.

    These two types of data are separate because = it would be inefficient to require clients or regions to download data that they do not use.=A0 Our "asset" singleton now turns into a = metadata + data pair.
    Yep.

    As a final point about metadata versus data, it should be mentioned that generally only the data ever has access restrictions placed on it,
    No restrictions for whom? Just for the user whose inventory it is (but then he/she has to authenticate somehow) or no restrictions for anyone?

    because placing restrictions on metadata leads to unsearchable inventories for which the technical term is "annoying as hell&qu= ot;, or more seriously, poorly functionality and yet another source of lag.
    I agree everyone should be able to access their own inventory tree, including the item-metadata at its leaf nodes. For the tree part, you later write
    Regions don't have access to your invento= ry [...]
    ("inventory" here refers to just the tree, if I understood yo= u correctly). I guess this is also the case for other users, except where I have given them explicit permission to view parts of my inventory (if the protocol was capable of that).

    I am going to assume that nobody wants that [= poor functionality and lag] and hence, that metadata is never accessed through capabilities.
    Now here I'm beginning to wonder, what data all is part of the tree (that others aren't able to access) and what is instead part of the item-metadata, (a fraction of) which needs to be broadcasted to other users, as it contains the references to the assets those other users have to fetch to render my avatar correctly. For example, is the item name part of that metadata or part of the tree? It obviously isn't needed by others, it's merely a reminder for my= self of what that item is.

    If the item name for worn stuff is broadcasted together with the other relevant metadata, that's OK as long as the user is aware of it, but it does have some consequences: In that case, I probably wouldn't want to name a wearable "The dress that this stupid guy bought me, but that I like to wear anyway" or "Tho= se shoes that my secret lover Example Resident gave me" but something more innocent, so that I wouldn't upset that other user and wouldn&= #39;t leak that Example Resident was my secret lover.

    There might be other metadata that's useful to the users themselves but that they might want to withhold from region owners and other users. Imagine for example information about where and when you acquired an item, which allows you to efficiently search for that item when you forgot the item name but still remember how you got it. However, if that info is broadcasted for worn items and you wear enough different items, everyone around you has a partial trace of your virtual travels.

    So we can either split the metadata asset according to reason (3) above into several assets with different access policies. Or we just lump metadata we want to keep private together with the tree while only having metadata we don't mind sharing in the metadata assets.<= br>
    Cheers,
    Boroondas

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



    --0016368340c005405204a09ceccd-- From morgaine.dinova@googlemail.com Sun Apr 10 23:30:45 2011 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 296723A6A81 for ; Sun, 10 Apr 2011 23:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.754 X-Spam-Level: X-Spam-Status: No, score=-2.754 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTQ+jzGKXHzz for ; Sun, 10 Apr 2011 23:30:41 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id D35623A69D1 for ; Sun, 10 Apr 2011 23:30:40 -0700 (PDT) Received: by qwc23 with SMTP id 23so3753627qwc.31 for ; Sun, 10 Apr 2011 23:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=U/nwy/26PRJzKskm4qy9yplGR+mLANxcRZUsEGeKHfE=; b=jIooVYNpEC901zAM82noZWAdxn9vSwNHR0vwQiukd2GDmoqrOMbnLmp13lsfXIbzwt QTnYh4yAG2VVcNsJ+tP8p4bk1EPAm4J1ZCSJXE3J/9v+bKYD1MGuD7iHXrSzVKjlPuy3 RYhcKD2DotaSXugWOGqn1aPhPw5EsewtFfyAU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=fViQHK/zGDS9IYCVZuL+Fhyb0BuZX10ol6wtU9q2Xcf0mhc13aU0HlDmQsiTMFlMxu 3qU/f2aGEEeZ/qQiwDUwxRMpwSxFa3AFsrzZvzGPvBKKxfL1kI7iGgbDNuzccG2+VfAi IG+bd+1ZzftIejZiNg69d3/J2dDkXHmHCAIOg= MIME-Version: 1.0 Received: by 10.229.78.22 with SMTP id i22mr3859813qck.33.1302503440569; Sun, 10 Apr 2011 23:30:40 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sun, 10 Apr 2011 23:30:40 -0700 (PDT) In-Reply-To: References: <5365485D-FFAE-46CA-B04E-D413E85FB1D1@gmail.com> <4D97E7FE.7010104@gmail.com> <4D97EEC1.7020207@gmail.com> <4D98AC5F.70501@gmail.com> <4DA220B1.6020400@boroon.dasgupta.ch> Date: Mon, 11 Apr 2011 07:30:40 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00235429d8f4e4d54604a09eb66a Subject: Re: [vwrap] Inventory, Asset Metadata and Privacy (was: [wvrap] Simulation consistency) 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, 11 Apr 2011 06:30:45 -0000 --00235429d8f4e4d54604a09eb66a Content-Type: text/plain; charset=ISO-8859-1 Notice how, by making the use of capabilities dependent on the presence of the *Restricted* bit in the asset's metadata, we have introduced the possibility of making VWRAP asset access control flexible and extensible. This single control bit is just the start. :-) Where currently we have just one access control bit in the metadata properties field and one capability mechanism to match, we could have a vector of control bits or a multi-bit field instead, each bit or the value of the field activating a different access control mechanism, perhaps to acquire different types of access credentials. This could open up many new possibilities, beyond user/region asset controls. Morgaine. ====================== On Mon, Apr 11, 2011 at 5:22 AM, Morgaine wrote: > > "If access to the content of a restricted asset is attempted without using > a capability, the access attempt will be rejected by the asset service > because insufficient credentials were provided. Consequently, simply > removing the *Restricted* property from a restricted asset's metadata in > order to avoid requesting a capability cannot bypass required access > controls." > > > Morgaine. > > > > > =========================== > > > > On Mon, Apr 11, 2011 at 4:25 AM, Morgaine wrote: > >> >> >> Sorry, I was ambiguous. What I should have said was "Only access to the >> content of assets may be restricted by access controls, and only when it is >> appropriate to do so (eg. never for open content). Access to the metadata >> of assets is never restricted, for anyone. When access controls restrict >> access to the content of a particular asset, then different policies may be >> applied to agents who hold assets in inventory and agents who merely render >> assets worn by others in the region. The asset service holds authority over >> the asset, and has the power to discriminate." >> >> >> > > > > > On Mon, Apr 11, 2011 at 4:25 AM, Morgaine wrote: > >> Excellent response, Boroondas, full of detailed analysis! :-) >> >> I won't respond to everything in-line because it would be mostly a long >> sequence of "Yes!" and "Good idea!", but I'll expand in a couple of areas >> where your reply makes me think that I should have been clearer, and also >> where I prefer your suggestions to mine. >> >> What's more, I'll adopt your suggested nomenclature straight away: >> >> *asset == (metadata + content)* >> >> I like that! "Metadata + data" has never felt right, because everything >> is "data". :-) >> >> >> >> >> On Sun, Apr 10, 2011 at 10:27 PM, Boroondas Gupte < >> sllists@boroon.dasgupta.ch> wrote: >> >>> >>> >>> > On 04/10/2011 03:11 PM, Morgaine wrote: >> >> The metadata has to be available to remote parties in the same way as >> the data itself is, and the best way of handling this is to make metadata a >> separate item normally stored in the same asset service as the data. >> >> As far as I know, this differs slightly from the concepts/architecture in >> SL. This might be a good thing, but because it is almost, but not >> completely, the same, we should be aware of these differences: In SL, there >> are the concept of assets (which are what I called 'content' above) and the >> concept of inventory items, referencing these assets and holding additional >> information such as permissions, name, etc. These inventory items themselves >> however are *not* considered assets in SL. >> >> So far, that's just a difference in nomenclature, I guess. But the SL >> inventory items are also handled differently from SL assets: They aren't >> stored (and served to the region) by the asset server, like assets are, but >> instead by the inventory service, which also serves the inventory tree. In >> fact, at least in the viewer's data model, the folders making up that tree >> are just special inventory items that do not reference assets but reference >> other inventory items. >> >> One of the drawbacks of how SL draws the line between inventory (-items) >> and assets is that it's probably difficult to implement something like >> VWR-2427 . Treating the >> item-metadata as a type of assets as you seem to suggest might allow to >> better exploit the commonality that both inventory items and some data >> assets can refer to other assets. >> >> (Note that I'm not really an expert on SL's internal architecture, and >> most of the above is based on hear-say and some viewer code comments I >> remember. Please correct me if I'm wrong somewhere.) >> >> >> I'm not an expert on SL's architecture either, but our discussions in the >> AWG over 3+ years suggest that your analysis above is correct. We are >> actually sticking fairly closely to the *conceptual* model used in SL >> (not for compatibility, but because it is a reasonable model), but we are >> departing from SL's *physical* model in some significant ways to gain >> better functional properties. >> >> According to the very rough consensus in AW Groupies (:P), in SL only the >> *content* is stored in *asset storage*, whereas *metadata* is stored in a >> *relational database* (and is mutable). In the design that we are >> discussing here for VWRAP asset services, both *content* and *metadata *are >> held in asset services, and both types of data are immutable. Our "updates" >> are achieved simply by referring to new metadata. >> >> SL handles its metadata specially and caches it in an inventory cache >> separately from content, whereas we store and cache them uniformly in both >> asset services and caches. Our inventories merely organize our cached >> metadata into a hierarchical *view*. We're building on past experience >> to improve functionality and performance and scalability (and elegance >> too!), which is quite natural. >> >> The "information about assets" stored at the leaves of inventories in >> SL-compatible clients is conceptually very similar to the metadata stored in >> our proposed asset services. Even the content referencing model is similar, >> in the sense that capabilities are used in SL to obtain the UUIDs of >> textures for example, and these UUIDs are then stored in the metadata held >> in inventory items. >> >> In other words, UUIDs held in SL inventory leaves are equivalent to our *direct >> addresses* (URIs) held in metadata. In both cases, once you have the >> UUID or *direct address*, you no longer need a capability to obtain the >> item. The cap's only function is to control acquisition of the UUID, which >> is the actual address of the content. Our content URIs just extend the >> concept of an address to external asset services. >> >> >> >> The metadata item will naturally reference the corresponding data item >> (which is an N:1 relationship when hash-based addressing is used), and in >> some cases can reference more than one data item --- for example, the >> metadata of a mesh will commonly reference not only the graphical data >> required for rendering in the client but also the collision mesh or bounding >> box data required by the region. >> >> > Wouldn't it make more sense to keep the metadata-item-to-data-item >> relation strictly N:1, and have the mesh data item have a N:N relation to >> it's components? (Analogous to SL gestures.) While the item type should be >> part of the metadata, I don't think the metadata's structure should depend >> on the item type. After all, the structure of inodes of a file system also >> doesn't depend on the file formats of the referenced files. >> >>> >>> >> Yes! That makes more sense. I withdraw my N:M suggestion. :-) Let's >> stick with N:1 and then be more clever with content if needed later. This >> is also in keeping with my cost engineering mantra, namely "The burden of X >> should be borne only by those who need X". There is no sense complicating >> metadata to make it N:M when the vast majority of its use cases are N:1. >> >> >> >> >> As a final point about metadata versus data, it should be mentioned >> that generally only the data ever has access restrictions placed on it, >> >> > No restrictions for whom? Just for the user whose inventory it is (but >> then he/she has to authenticate somehow) or no restrictions for anyone? >> >> >> Sorry, I was ambiguous. What I should have said was "Only access to the >> content of assets may be restricted by access controls, and only when it is >> appropriate to do so (eg. never for open content). Access to the metadata >> of assets is never restricted, for anyone. When access controls restrict >> access to the content of a particular asset, then different policies may be >> applied to agents who hold assets in inventory and agents who merely render >> assets worn by others in the region. The asset service holds authority over >> the asset, and has the power to discriminate." >> >> >> >> > ("inventory" here refers to just the tree, if I understood you >> correctly). I guess this is also the case for other users, except where I >> have given them explicit permission to view parts of my inventory (if the >> protocol was capable of that). >> >> >> I do not envisage anyone ever having access to an agent's inventory, other >> than the agent who owns the inventory (inventories are client-side after >> all, despite also being saved server-side). Only the metadata that an >> inventory may be referencing can ever be seen by others (for example, when a >> region provides the references), but never the hierarchical structure. This >> is similar to how SL/Opensim works: you can inspect the metadata of an >> asset in the scene and see that it is owned by user X, but you have no >> access to X's inventory. >> >> >> >> >> I am going to assume that nobody wants that [poor functionality and >> lag] and hence, that metadata is never accessed through capabilities. >> >> > Now here I'm beginning to wonder, what data all is part of the tree >> (that others aren't able to access) and what is instead part of the >> item-metadata, (a fraction of) which needs to be broadcasted to other users, >> as it contains the references to the assets those other users have to fetch >> to render my avatar correctly. For example, is the item name part of that >> metadata or part of the tree? It obviously isn't needed by others, it's >> merely a reminder for myself of what that item is. >> >> >> Just in case I wasn't clear before, I'll underline that inventory trees >> are entirely unrelated to the process by which others gain access to assets >> (they use metadata which links to content, not inventories). The only >> reason why I mentioned inventories at all is because they too happen to >> point to metadata. As to the question of what is in inventories that isn't >> in metadata, the answer is "almost nothing" other than the hierarchical >> skeleton of named folders. I guess it's possible to have local symlinks, >> and even to modify the metadata locally if desired, for example to change >> the local name of an item, but those are just frills. Generally, inventory >> is merely metadata organized locally into a tree. >> >> >> >> > If the item name for worn stuff *is* broadcasted together with the >> other relevant metadata, that's OK as long as the user is aware of it, but >> it *does* have some consequences: In that case, I probably wouldn't want >> to name a wearable "The dress that this stupid guy bought me, but that I >> like to wear anyway" or "Those shoes that my secret lover Example Resident >> gave me" but something more innocent, so that I wouldn't upset that other >> user and wouldn't leak that Example Resident was my secret lover. >> >> Haha. :-) Well it's already the case in SL that the metadata is >> inspectable, so people are already used to the fact that how they name >> objects and what they write in object descriptions is visible publicly, >> nothing new there. >> >> >> >> > There might be other metadata that's useful to the users themselves but >> that they might want to withhold from region owners and other users. Imagine >> for example information about where and when you acquired an item, which >> allows you to efficiently search for that item when you forgot the item name >> but still remember how you got it. However, if that info is broadcasted for >> worn items and you wear enough different items, everyone around you has a >> partial trace of your virtual travels. >> >> >> Yes, good ideas for purely local enhancements to inventories. :-) I'm >> sure that inventories can be extended in many useful ways to build upon >> their primary role of organizing and referencing metadata. That could be a >> very interesting area. Anyone with dozens of thousands of objects in >> inventory can appreciate very well the need for some new thinking to help us >> manage the object explosion. :-) >> >> >> Morgaine. >> >> >> >> >> ====================== >> >> On Sun, Apr 10, 2011 at 10:27 PM, Boroondas Gupte < >> sllists@boroon.dasgupta.ch> wrote: >> >>> Hi Morgaine >>> >>> The distinction between metadata and 'content' and storing them in >>> separately acquirable chunks is a good and quite important idea, I think. >>> More generally, I can think of several reasons to split a monolithic data >>> entity E into several separate ones, connected by referencing each other or >>> by being referenced by a common meta-entity which replaces the previous >>> monolithic entity: >>> >>> 1. Several other entities are expected to have some parts in common >>> with E, without having other parts in common with it. >>> 2. Some parties only need some parts of E, but not other parts. >>> 3. Some parties are only allowed access to some parts of E, but not >>> to other parts. >>> >>> (You might note the similarity between reason (1) and rules used for >>> database normalization.) >>> >>> If the entities are immutable (which assets should be according to >>> previous discussion), >>> (1) can not only occur between unrelated items but will also be very common >>> for items that result from changing a previous item. Some examples how this >>> applies specifically to the metadata-content separation (assuming a similar >>> inventory UI as we have in SL): >>> >>> - You rez an object from inventory, resize it, and take it back into >>> inventory (which creates a new item there). >>> - Same metadata (permissions, name(?), owner) >>> - (What about a 'last edited' date, though? SL doesn't seem to >>> store one, but some VWRAP systems might want to keep that info.) >>> - Different content >>> - You rename an item in-inventory >>> - Different metadata (maybe ... see below) >>> - Same content >>> - You change next-owner permissions on an item, then give it to >>> someone >>> - Different metadata >>> - Same content >>> >>> Reason (2) off course occurs when browsing your inventory. If you just >>> want to e.g. read the names of your items, you don't have to fetch all the >>> associated content data. >>> >>> Off course, there are more potential separations that fit one or several >>> of these three reasons than just the metadata-content one. In SL, having >>> objects being composed of prims, having prims reference textures for their >>> faces instead of having the texture data lumped into their own data, or >>> gestures being composed of steps some of which can reference animation and >>> sound assets are other examples of such separations. >>> >>> On 04/10/2011 03:11 PM, Morgaine wrote: >>> >>> It is worth noting that while inventories are mostly a client-side >>> implementation detail which can be changed unilaterally, the *metadata*held by inventories is a very important and separable information type in an >>> architecture that uses 3rd party asset services, so it needs detailed >>> examination. >>> >>> The metadata has to be available to remote parties in the same way as the >>> data itself is, and the best way of handling this is to make metadata a >>> separate item normally stored in the same asset service as the data. >>> >>> As far as I know, this differs slightly from the concepts/architecture in >>> SL. This might be a good thing, but because it is almost, but not >>> completely, the same, we should be aware of these differences: In SL, there >>> are the concept of assets (which are what I called 'content' above) and the >>> concept of inventory items, referencing these assets and holding additional >>> information such as permissions, name, etc. These inventory items themselves >>> however are *not* considered assets in SL. >>> >>> So far, that's just a difference in nomenclature, I guess. But the SL >>> inventory items are also handled differently from SL assets: They aren't >>> stored (and served to the region) by the asset server, like assets are, but >>> instead by the inventory service, which also serves the inventory tree. In >>> fact, at least in the viewer's data model, the folders making up that tree >>> are just special inventory items that do not reference assets but reference >>> other inventory items. >>> >>> One of the drawbacks of how SL draws the line between inventory (-items) >>> and assets is that it's probably difficult to implement something like >>> VWR-2427 . Treating the >>> item-metadata as a type of assets as you seem to suggest might allow to >>> better exploit the commonality that both inventory items and some data >>> assets can refer to other assets. >>> >>> (Note that I'm not really an expert on SL's internal architecture, and >>> most of the above is based on hear-say and some viewer code comments I >>> remember. Please correct me if I'm wrong somewhere.) >>> >>> The metadata item will naturally reference the corresponding data item >>> (which is an N:1 relationship when hash-based addressing is used), and in >>> some cases can reference more than one data item --- for example, the >>> metadata of a mesh will commonly reference not only the graphical data >>> required for rendering in the client but also the collision mesh or bounding >>> box data required by the region. >>> >>> Wouldn't it make more sense to keep the metadata-item-to-data-item >>> relation strictly N:1, and have the mesh data item have a N:N relation >>> to it's components? (Analogous to SL gestures.) While the item type should >>> be part of the metadata, I don't think the metadata's structure should >>> depend on the item type. After all, the structure of inodes of a file system >>> also doesn't depend on the file formats of the referenced files. >>> >>> These two types of data are separate because it would be inefficient to >>> require clients or regions to download data that they do not use. Our >>> "asset" singleton now turns into a metadata + data pair. >>> >>> Yep. >>> >>> As a final point about metadata versus data, it should be mentioned that >>> generally only the data ever has access restrictions placed on it, >>> >>> No restrictions for whom? Just for the user whose inventory it is (but >>> then he/she has to authenticate somehow) or no restrictions for anyone? >>> >>> because placing restrictions on metadata leads to unsearchable >>> inventories for which the technical term is "annoying as hell", or more >>> seriously, poorly functionality and yet another source of lag. >>> >>> I agree everyone should be able to access their own inventory tree, >>> including the item-metadata at its leaf nodes. For the tree part, you later >>> write >>> >>> Regions don't have access to your inventory [...] >>> >>> ("inventory" here refers to just the tree, if I understood you >>> correctly). I guess this is also the case for other users, except where I >>> have given them explicit permission to view parts of my inventory (if the >>> protocol was capable of that). >>> >>> I am going to assume that nobody wants that [poor functionality and lag] >>> and hence, that metadata is never accessed through capabilities. >>> >>> Now here I'm beginning to wonder, what data all is part of the tree (that >>> others aren't able to access) and what is instead part of the item-metadata, >>> (a fraction of) which needs to be broadcasted to other users, as it contains >>> the references to the assets those other users have to fetch to render my >>> avatar correctly. For example, is the item name part of that metadata or >>> part of the tree? It obviously isn't needed by others, it's merely a >>> reminder for myself of what that item is. >>> >>> If the item name for worn stuff *is* broadcasted together with the other >>> relevant metadata, that's OK as long as the user is aware of it, but it >>> *does* have some consequences: In that case, I probably wouldn't want to >>> name a wearable "The dress that this stupid guy bought me, but that I like >>> to wear anyway" or "Those shoes that my secret lover Example Resident gave >>> me" but something more innocent, so that I wouldn't upset that other user >>> and wouldn't leak that Example Resident was my secret lover. >>> >>> There might be other metadata that's useful to the users themselves but >>> that they might want to withhold from region owners and other users. Imagine >>> for example information about where and when you acquired an item, which >>> allows you to efficiently search for that item when you forgot the item name >>> but still remember how you got it. However, if that info is broadcasted for >>> worn items and you wear enough different items, everyone around you has a >>> partial trace of your virtual travels. >>> >>> So we can either split the metadata asset according to reason (3) above >>> into several assets with different access policies. Or we just lump metadata >>> we want to keep private together with the tree while only having metadata we >>> don't mind sharing in the metadata assets. >>> >>> Cheers, >>> Boroondas >>> >>> _______________________________________________ >>> vwrap mailing list >>> vwrap@ietf.org >>> https://www.ietf.org/mailman/listinfo/vwrap >>> >>> >> > --00235429d8f4e4d54604a09eb66a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Notice how, by making the use of capabilities dependent on the presence of = the Restricted bit in the asset's metadata, we have introduced t= he possibility of making VWRAP asset access control flexible and extensible= .=A0 This single control bit is just the start. :-)

    Where currently we have just one access control bit in the metadata pro= perties field and one capability mechanism to match, we could have a vector= of control bits or a multi-bit field instead, each bit or the value of the= field activating a different access control mechanism, perhaps to acquire = different types of access credentials.

    This could open up many new possibilities, beyond user/region asset con= trols.


    Morgaine.




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


    On Mon, Apr 11, 2011 at 5:22 AM, Morgaine <morgaine.dinova@googlemail.com> wrote:

    "If access to the content of a restricted asset i= s attempted without using a capability, the access attempt will be rejected= by the asset service because insufficient credentials were provided.=A0 Co= nsequently, simply removing the Restricted property from a restricte= d asset's metadata in order to avoid requesting a capability cannot byp= ass required access controls."


    Morgaine.




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



    On Mon, Apr 11, 2011 at 4:25 AM, Morgaine <    morgaine.d= inova@googlemail.com> wrote:


    Sorry, I was ambiguous.=A0 What= I should have said was=20 "Only access to the content of assets may be restricted by access=20 controls, and only when it is appropriate to do so (eg. never for open=20 content).=A0 Access to the metadata of assets is never restricted, for=20 anyone.=A0 When access controls restrict access to the content of a=20 particular asset, then different policies may be applied to agents who=20 hold assets in inventory and agents who merely render assets worn by=20 others in the region.=A0 The asset service holds authority over the asset, and has the power to discriminate."


    <cut>




    On Mon, Apr 11, 2011 at 4:2= 5 AM, Morgaine <morgaine.dinova@googlemail.com>= wrote:
    Excellent respons= e, Boroondas, full of detailed analysis! :-)

    I won't respond to = everything in-line because it would be mostly a long sequence of "Yes!= " and "Good idea!", but I'll expand in a couple of areas= where your reply makes me think that I should have been clearer, and also = where I prefer your suggestions to mine.

    What's more, I'll adopt your suggested nomenclature straight aw= ay:

    asset =3D=3D (metadata + c= ontent)

    I like that!=A0 "Metadata + data" has ne= ver felt right, because everything is "data". :-)




    On Sun, Apr 10, 2011 at 10:27 PM, Boroondas Gupte <sl= lists@boroon.dasgupta.ch> wrote:
    =20 =20 =20 =20


    > On 04/10/2011 03:11 PM, Morgaine wrote:
    >> The metadata has to be available to remote parties in the s= ame way as the data itself is, and the best way of handling this is to make metadata a separate item normally stored in the same asset service as the data.

    As far as I know, this differs slightly from the concepts/architecture in SL. This might be a good thing, but because it is almost, but not completely, the same, we should be aware of these differences: In SL, there are the concept of assets (which are what I called 'content' above) and the concept of inventory ite= ms, referencing these assets and holding additional information such as permissions, name, etc. These inventory items themselves however are not considered assets in SL.

    So far, that's just a difference in nomenclature, I guess. But the SL inventory items are also handled differently from SL assets: They aren't stored (and served to the region) by the asset server, like assets are, but instead by the inventory service, which also serves the inventory tree. In fact, at least in the viewer's data model, the folders making up that tree are just special inventory items that do not reference assets but reference other inventory items.
    One of the drawbacks of how SL draws the line between inventory (-items) and assets is that it's probably difficult to implement something like VWR-2427. Treating the item-metadata as a type of assets as you seem to suggest might allow to better exploit the commonality that both inventory items and some data assets can refer to other assets.

    (Note that I'm not really an expert on SL's internal architectu= re, and most of the above is based on hear-say and some viewer code comments I remember. Please correct me if I'm wrong somewhere.)
    =
    =20

    I'm not an expert on SL's architecture eith= er, but our discussions in the AWG over 3+ years suggest that your analysis= above is correct.=A0 We are actually sticking fairly closely to the con= ceptual model used in SL (not for compatibility, but because it is a re= asonable model), but we are departing from SL's physical model i= n some significant ways to gain better functional properties.

    According to the very rough consensus in AW Groupies (:P), in SL only t= he content is stored in asset storage, whereas metadata is stored in a relational database (and is mutable).=A0 In the des= ign that we are discussing here for VWRAP asset services, both content and metadata are held in asset services, and both types of data a= re immutable.=A0 Our "updates" are achieved simply by referring t= o new metadata.

    SL handles its metadata specially and caches it in an inventory cache s= eparately from content, whereas we store and cache them uniformly in both a= sset services and caches.=A0 Our inventories merely organize our cached met= adata into a hierarchical view.=A0 We're building on past experi= ence to improve functionality and performance and scalability (and elegance= too!), which is quite natural.

    The "information about assets" stored at the leaves of invent= ories in SL-compatible clients is conceptually very similar to the metadata= stored in our proposed asset services.=A0 Even the content referencing mod= el is similar, in the sense that capabilities are used in SL to obtain the = UUIDs of textures for example, and these UUIDs are then stored in the metad= ata held in inventory items.

    In other words, UUIDs held in SL inventory leaves are equivalent to our= direct addresses (URIs) held in metadata.=A0 In both cases, once yo= u have the UUID or direct address, you no longer need a capability t= o obtain the item.=A0 The cap's only function is to control acquisition= of the UUID, which is the actual address of the content.=A0 Our content UR= Is just extend the concept of an address to external asset services.


    >> The metadata item will naturally reference the corresponding data item (which is an N:1 relationship when hash-based addressing is used), and in some cases can reference more than one data item --- for example, the metadata of a mesh will commonly reference not only the graphical data required for rendering in the client but also the collision mesh or bounding box data required by the region.
    =A0
    > Wouldn't it make more sense to keep the metadata-item-to-data-= item relation strictly N:1, and have the mesh data item have a N:N relation to it's components? (Analogous to SL gestures.) While the item type should be part of the metadata, I don't think the metadata's structure should depend on the item = type. After all, the structure of inodes of a file system also doesn't depend on the file formats of the referenced files.


    Yes!=A0 That = makes more sense.=A0 I withdraw my N:M suggestion. :-)=A0 Let's stick w= ith N:1 and then be more clever with content if needed later.=A0 This is al= so in keeping with my cost engineering mantra, namely "The burden of X= should be borne only by those who need X".=A0 There is no sense compl= icating metadata to make it N:M when the vast majority of its use cases are= N:1.



    >> As a final point about metadata versus data, it should be mentioned that generally only the data ever has access restrictions placed on it,

    > No restrictions for whom? Just for the user whose inventory it is (but then he/she has to authenticate somehow) or no restrictions for anyone?


    Sorry, I was ambiguous.=A0 What I should have said was &q= uot;Only access to the content of assets may be restricted by access contro= ls, and only when it is appropriate to do so (eg. never for open content).= =A0 Access to the metadata of assets is never restricted, for anyone.=A0 Wh= en access controls restrict access to the content of a particular asset, th= en different policies may be applied to agents who hold assets in inventory= and agents who merely render assets worn by others in the region.=A0 The a= sset service holds authority over the asset, and has the power to discrimin= ate."


    > ("inventory" here refers to just the tree, if I understo= od you correctly). I guess this is also the case for other users, except where I have given them explicit permission to view parts of my inventory (if the protocol was capable of that).
    =20

    I do not envisage anyone ever having access to an agent&#= 39;s inventory, other than the agent who owns the inventory (inventories ar= e client-side after all, despite also being saved server-side).=A0 Only the= metadata that an inventory may be referencing can ever be seen by others (= for example, when a region provides the references), but never the hierarch= ical structure.=A0 This is similar to how SL/Opensim works:=A0 you can insp= ect the metadata of an asset in the scene and see that it is owned by user = X, but you have no access to X's inventory.



    >= ;> I am going to assume that nobody wants that [poor functionality and lag] and hence, that metadata is never accessed through capabilities.

    > Now here I'm beginning to wonder, what data all is part of the= tree (that others aren't able to access) and what is instead part of the item-metadata, (a fraction of) which needs to be broadcasted to other users, as it contains the references to the assets those other users have to fetch to render my avatar correctly. For example, is the item name part of that metadata or part of the tree? It obviously isn't needed by others, it's merely a reminder for my= self of what that item is.


    Just in case I wasn't clear before, I'll underlin= e that inventory trees are entirely unrelated to the process by which other= s gain access to assets (they use metadata which links to content, not inve= ntories).=A0 The only reason why I mentioned inventories at all is because = they too happen to point to metadata.=A0 As to the question of what is in i= nventories that isn't in metadata, the answer is "almost nothing&q= uot; other than the hierarchical skeleton of named folders.=A0 I guess it&#= 39;s possible to have local symlinks, and even to modify the metadata local= ly if desired, for example to change the local name of an item, but those a= re just frills.=A0 Generally, inventory is merely metadata organized locall= y into a tree.



    > If the item name for worn stuff is broadcasted together wit= h the other relevant metadata, that's OK as long as the user is aware of it, but it does have some consequences: In that case, I probably wouldn't want to name a wearable "The dress that this stupid guy bought me, but that I like to wear anyway" or "Tho= se shoes that my secret lover Example Resident gave me" but something more innocent, so that I wouldn't upset that other user and wouldn&= #39;t leak that Example Resident was my secret lover.

    Haha. :-)=A0 Well it's already the case in SL that the me= tadata is inspectable, so people are already used to the fact that how they= name objects and what they write in object descriptions is visible publicl= y, nothing new there.



    > There might be other metadata that's useful to the users thems= elves but that they might want to withhold from region owners and other users. Imagine for example information about where and when you acquired an item, which allows you to efficiently search for that item when you forgot the item name but still remember how you got it. However, if that info is broadcasted for worn items and you wear enough different items, everyone around you has a partial trace of your virtual travels.


    Yes, good ideas for purely= local enhancements to inventories. :-)=A0 I'm sure that inventories ca= n be extended in many useful ways to build upon their primary role of organ= izing and referencing metadata.=A0 That could be a very interesting area.= =A0 Anyone with dozens of thousands of objects in inventory can appreciate = very well the need for some new thinking to help us manage the object explo= sion. :-)
    =20

    Morgaine.




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

    <= div>
    On Sun, Apr 10, 2011 at 10:27 PM, Boroondas Gupte <sllists@boroon.dasgupta.ch> wrote:
    =
    =20 =20 =20 =20
    Hi Morgaine

    The distinction between metadata and 'content' and storing them= in separately acquirable chunks is a good and quite important idea, I think. More generally, I can think of several reasons to split a monolithic data entity E into several separate ones, connected by referencing each other or by being referenced by a common meta-entity which replaces the previous monolithic entity:
    1. Several other entities are expected to have some parts in common with E, without having other parts in common with it.
    2. Some parties only need some parts of E, but not other parts.
    3. Some parties are only allowed access to some parts of E, but not to other parts.
    (You might note the similarity between reason (1) and rules used for database normalization.)

    If the entities are immutable (which assets should be according to previous discussion), (1) can not only occur between unrelated items but will also be very common for items that result from changing a previous item. Some examples how this applies specifically to the metadata-content separation (assuming a similar inventory UI as we have in SL):
    • You rez an object from inventory, resize it, and take it back into inventory (which creates a new item there).
      • Same metadata (permissions, name(?), owner)
        • (What about a 'last edited' date, though? SL doesn= 9;t seem to store one, but some VWRAP systems might want to keep that info.)
      • Different content
    • You rename an item in-inventory
      • Different metadata (maybe ... see below)
      • Same content
    • You change next-owner permissions on an item, then give it to someone
      • Different metadata
      • Same content
    Reason (2) off course occurs when browsing your inventory. If you just want to e.g. read the names of your items, you don't have to fetch all the associated content data.

    Off course, there are more potential separations that fit one or several of these three reasons than just the metadata-content one. In SL, having objects being composed of prims, having prims reference textures for their faces instead of having the texture data lumped into their own data, or gestures being composed of steps some of which can reference animation and sound assets are other examples of such separations.

    On 04/10/2011 03:11 PM, Morgaine wrote:
    It is worth noting that while inventories are= mostly a client-side implementation detail which can be changed unilaterally, the metadata held by inventories is a very important and separable information type in an architecture that uses 3rd party asset services, so it needs detailed examination.

    The metadata has to be available to remote parties in the same way as the data itself is, and the best way of handling this is to make metadata a separate item normally stored in the same asset service as the data.
    As far as I know, this differs slightly from the concepts/architecture in SL. This might be a good thing, but because it is almost, but not completely, the same, we should be aware of these differences: In SL, there are the concept of assets (which are what I called 'content' above) and the concept of inventory ite= ms, referencing these assets and holding additional information such as permissions, name, etc. These inventory items themselves however are not considered assets in SL.

    So far, that's just a difference in nomenclature, I guess. But the SL inventory items are also handled differently from SL assets: They aren't stored (and served to the region) by the asset server, like assets are, but instead by the inventory service, which also serves the inventory tree. In fact, at least in the viewer's data model, the folders making up that tree are just special inventory items that do not reference assets but reference other inventory items.

    One of the drawbacks of how SL draws the line between inventory (-items) and assets is that it's probably difficult to implement something like VWR-2427. Treating the item-metadata as a type of assets as you seem to suggest might allow to better exploit the commonality that both inventory items and some data assets can refer to other assets.

    (Note that I'm not really an expert on SL's internal architectu= re, and most of the above is based on hear-say and some viewer code comments I remember. Please correct me if I'm wrong somewhere.)

    The metadata item will naturally reference th= e corresponding data item (which is an N:1 relationship when hash-based addressing is used), and in some cases can reference more than one data item --- for example, the metadata of a mesh will commonly reference not only the graphical data required for rendering in the client but also the collision mesh or bounding box data required by the region.
    Wouldn't it make more sense to keep the metadata-item-to-data-item relation strictly N:1, and have the mesh data item have a N:N relation to it's components? (Analogous to SL gestures.) While the item type should be part of the metadata, I don't think the metadata's structure should depend on the item = type. After all, the structure of inodes of a file system also doesn't depend on the file formats of the referenced files.

    These two types of data are separate because = it would be inefficient to require clients or regions to download data that they do not use.=A0 Our "asset" singleton now turns into a = metadata + data pair.
    Yep.

    As a final point about metadata versus data, it should be mentioned that generally only the data ever has access restrictions placed on it,
    No restrictions for whom? Just for the user whose inventory it is (but then he/she has to authenticate somehow) or no restrictions for anyone?

    because placing restrictions on metadata leads to unsearchable inventories for which the technical term is "annoying as hell&qu= ot;, or more seriously, poorly functionality and yet another source of lag.
    I agree everyone should be able to access their own inventory tree, including the item-metadata at its leaf nodes. For the tree part, you later write
    Regions don't have access to your invento= ry [...]
    ("inventory" here refers to just the tree, if I understood yo= u correctly). I guess this is also the case for other users, except where I have given them explicit permission to view parts of my inventory (if the protocol was capable of that).

    I am going to assume that nobody wants that [= poor functionality and lag] and hence, that metadata is never accessed through capabilities.
    Now here I'm beginning to wonder, what data all is part of the tree (that others aren't able to access) and what is instead part of the item-metadata, (a fraction of) which needs to be broadcasted to other users, as it contains the references to the assets those other users have to fetch to render my avatar correctly. For example, is the item name part of that metadata or part of the tree? It obviously isn't needed by others, it's merely a reminder for my= self of what that item is.

    If the item name for worn stuff is broadcasted together with the other relevant metadata, that's OK as long as the user is aware of it, but it does have some consequences: In that case, I probably wouldn't want to name a wearable "The dress that this stupid guy bought me, but that I like to wear anyway" or "Tho= se shoes that my secret lover Example Resident gave me" but something more innocent, so that I wouldn't upset that other user and wouldn&= #39;t leak that Example Resident was my secret lover.

    There might be other metadata that's useful to the users themselves but that they might want to withhold from region owners and other users. Imagine for example information about where and when you acquired an item, which allows you to efficiently search for that item when you forgot the item name but still remember how you got it. However, if that info is broadcasted for worn items and you wear enough different items, everyone around you has a partial trace of your virtual travels.

    So we can either split the metadata asset according to reason (3) above into several assets with different access policies. Or we just lump metadata we want to keep private together with the tree while only having metadata we don't mind sharing in the metadata assets.<= br>
    Cheers,
    Boroondas

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




    --00235429d8f4e4d54604a09eb66a-- From dzonatas@gmail.com Mon Apr 11 08:51:53 2011 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 C6FFF3A6B21 for ; Mon, 11 Apr 2011 08:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.296 X-Spam-Level: X-Spam-Status: No, score=-3.296 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 JcbHEIVRkSU5 for ; Mon, 11 Apr 2011 08:51:52 -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 742D63A697E for ; Mon, 11 Apr 2011 08:51:52 -0700 (PDT) Received: by pvh1 with SMTP id 1so2562317pvh.31 for ; Mon, 11 Apr 2011 08:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=ZHAXOaG46Phdski2zYzuGzJ2XoyXSQ/YCw8TnhGDxMk=; b=HZILlUrv86aR3tRmXdDPVRbJzrJKb4D4ZMH3puBhqMksl9z6Nx5aSuR1nCDPqOxT9f CfnG4av1sJXfOUgKFnT7VOXYh2u625sU2exAEjDqrnBLbSpqBue9Vv2Xb24CX+tlsLk1 vszyPItAW7wR8SFnhEozKJTYEawJFmNgOsnuY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=rM5Ar4XFNAm1JO0Orov9i6h8S3MFCCRpkrPzmlfkJp77pFOhcARz1h6ockUVs/iVa7 YfaBIBLzfBJYPiPeuYLlTWyqvD/zb6p2BLRoXexSPsSEXOIjWaCyI6BdkUTL+xrTVZhx 0Qaul4bYSiVOGOmeI5//lWW/UHDEW2aOVXIIA= Received: by 10.142.178.17 with SMTP id a17mr159911wff.64.1302536986279; Mon, 11 Apr 2011 08:49:46 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id m10sm8415985wfl.23.2011.04.11.08.49.44 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Apr 2011 08:49:45 -0700 (PDT) Message-ID: <4DA32353.7070306@gmail.com> Date: Mon, 11 Apr 2011 08:50:43 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: "vwrap@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [vwrap] SPDY 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, 11 Apr 2011 15:51:53 -0000 Seems like GOOGLE did something similar to what I did with "bidirectional" ReSTful combines, and they called it SPDY. (read about SPDY near the bottom) http://www.conceivablytech.com/6696/products/google-chrome-gets-spdy-and-an-onscreen-keyboard >> Google said that it saw pageload times to improve by 44 to up to 64%. According to the company, SPDY still uses HTTP methods, headers and “other semantics.” << The difference is chrome implements a modified HTTP stack (SPDY) instead of being limited to HTTP itself. So far, I only see a BSD style denotation placed on the source files. Maybe worthwhile to investigate to see how easy it is to add the ReSTful/LLSD/LLIDL combines and secure the transport within any specified trust domain. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Mon Apr 11 08:59:23 2011 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 79C4228C134 for ; Mon, 11 Apr 2011 08:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 NKNDOKP6573r for ; Mon, 11 Apr 2011 08:59:22 -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 9633E28C12E for ; Mon, 11 Apr 2011 08:59:21 -0700 (PDT) Received: by pvh1 with SMTP id 1so2565509pvh.31 for ; Mon, 11 Apr 2011 08:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=g67sGQeMra3xLD2OwrDEtmwLkHh9AwBfRiJDidmb7so=; b=kWtd9pQ65tiWDAmEGsgbRGASHvz0jn5SNin1QRIpm2dfXV1MLeFvtctbXAtR0OlA2s 24j3ugDFYe7gaL4+3YuKyOcN8YW7Mys7X2QWs8Vbt8+iwZ1zL0tB7VGibtka9bGOdK52 dxYHPDtBnsqPAZbSHEkMzUh1tUqFrCW0yHPtA= 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=DFmtvgJTQz9V4dg/4LSlgxZ7UVlHAUZY1TgOXeUgrFXItPxF4Tk/RsgCNIcIVtRlEK mzLA+bMkr8eFej957xz546JN7rFUpL9yll3P2kWnbv16EwEISaZoLo4p0zWtUIi57srZ 7ZxtmYELpe9aPuwgty14ANmwNMa6F6fFtY7BY= Received: by 10.142.250.2 with SMTP id x2mr5371218wfh.381.1302537562013; Mon, 11 Apr 2011 08:59:22 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id s39sm8428149wfc.4.2011.04.11.08.59.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Apr 2011 08:59:21 -0700 (PDT) Message-ID: <4DA32594.1040904@gmail.com> Date: Mon, 11 Apr 2011 09:00:20 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: "vwrap@ietf.org" References: <4DA32353.7070306@gmail.com> In-Reply-To: <4DA32353.7070306@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [vwrap] SPDY 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, 11 Apr 2011 15:59:23 -0000 White paper: http://www.chromium.org/spdy/spdy-whitepaper Dzonatas Sol wrote: > Seems like GOOGLE did something similar to what I did with > "bidirectional" ReSTful combines, and they called it SPDY. > > (read about SPDY near the bottom) > http://www.conceivablytech.com/6696/products/google-chrome-gets-spdy-and-an-onscreen-keyboard > > > >> Google said that it saw pageload times to improve by 44 to up to > 64%. According to the company, SPDY still uses HTTP methods, headers > and “other semantics.” << > > The difference is chrome implements a modified HTTP stack (SPDY) > instead of being limited to HTTP itself. So far, I only see a BSD > style denotation placed on the source files. > > Maybe worthwhile to investigate to see how easy it is to add the > ReSTful/LLSD/LLIDL combines and secure the transport within any > specified trust domain. > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dcolivares@gmail.com Mon Apr 11 09:48:51 2011 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 17C433A6B25 for ; Mon, 11 Apr 2011 09:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0KRAuT854Ah for ; Mon, 11 Apr 2011 09:48:49 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id BB1223A68DC for ; Mon, 11 Apr 2011 09:48:49 -0700 (PDT) Received: by iye19 with SMTP id 19so7201112iye.31 for ; Mon, 11 Apr 2011 09:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LK02YD/kK375BbToJ6lAOsXG0fmJY/3gA6JcMXK55JM=; b=RTwYJHosM33paKBExuxsyMhI2Bmjnd1r1X5XOL9UmWLpdf/k68ntAXUdGKHMT7TEZ/ hDQDlmQMaFnIRi8EFK6DbcXpFaVXV56ap6DOwSwvWM5zoR2PWaIbsg4Oj0xbbkhV/0Bs CirsDoJwqz5SnTqxZF7aCw6vANyRln9QQRbLY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=q2brYTRbuYhVDCOGBIXeTLz8dAig+EWGy3QVmghykJEwCMIcDkJL9AsgBbzagW4r6J 5ubh1mERVu1fHbjEkGs8CbdBrOW2BM+OyoHrafACdL7J7JXDYeU+4kVcYbUoPPrtRFy6 TCGZJBHHH60ZLHegyF2sKcBl6njodmUW2RwBg= MIME-Version: 1.0 Received: by 10.42.117.130 with SMTP id t2mr8217182icq.446.1302540530097; Mon, 11 Apr 2011 09:48:50 -0700 (PDT) Received: by 10.42.164.6 with HTTP; Mon, 11 Apr 2011 09:48:50 -0700 (PDT) In-Reply-To: <4DA32594.1040904@gmail.com> References: <4DA32353.7070306@gmail.com> <4DA32594.1040904@gmail.com> Date: Mon, 11 Apr 2011 12:48:50 -0400 Message-ID: From: Dan Olivares To: Dzonatas Sol Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "vwrap@ietf.org" Subject: Re: [vwrap] SPDY 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, 11 Apr 2011 16:48:51 -0000 It would be nice if they could push that through the IETF. -Dan On Mon, Apr 11, 2011 at 12:00 PM, Dzonatas Sol wrote: > White paper: http://www.chromium.org/spdy/spdy-whitepaper > > Dzonatas Sol wrote: >> >> Seems like GOOGLE did something similar to what I did with "bidirectiona= l" >> ReSTful combines, and they called it SPDY. >> >> (read about SPDY near the bottom) >> >> http://www.conceivablytech.com/6696/products/google-chrome-gets-spdy-and= -an-onscreen-keyboard >> >> >> Google said that it saw pageload times to improve by 44 to up to 64%. >> >> According to the company, SPDY still uses HTTP methods, headers and = =93other >> >> semantics.=94 << >> >> The difference is chrome implements a modified HTTP stack (SPDY) instead >> of being limited to HTTP itself. So far, I only see a BSD style denotati= on >> placed on the source files. >> >> Maybe worthwhile to investigate to see how easy it is to add the >> ReSTful/LLSD/LLIDL combines and secure the transport within any specifie= d >> trust domain. >> > > > -- > --- 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 stpeter@stpeter.im Mon Apr 11 11:11:37 2011 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 4DD763A6A34 for ; Mon, 11 Apr 2011 11:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 F05pEvqbvR-g for ; Mon, 11 Apr 2011 11:11:29 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id ECF793A6988 for ; Mon, 11 Apr 2011 11:11:27 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2DF5340022; Mon, 11 Apr 2011 12:14:14 -0600 (MDT) Message-ID: <4DA34448.50406@stpeter.im> Date: Mon, 11 Apr 2011 12:11:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dan Olivares References: <4DA32353.7070306@gmail.com> <4DA32594.1040904@gmail.com> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090109090100010609000800" Cc: "vwrap@ietf.org" Subject: Re: [vwrap] SPDY 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, 11 Apr 2011 18:11:39 -0000 This is a cryptographically signed message in MIME format. --------------ms090109090100010609000800 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/11/11 10:48 AM, Dan Olivares wrote: > It would be nice if they could push that through the IETF. At IETF 80 in Prague a few weeks ago, Mike Belshe of Google made a presentation about SPDY at the HTTPBIS WG session (and I think also the Transport Area meeting). He reported that they are interested in working to standardize SPDY at the IETF, but they don't want to pursue that until they are completely happy with the technology (they feel that it is still experimental and they want to work out more of the kinks based on deployment experience). Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090109090100010609000800 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQx MTE4MTEyMFowIwYJKoZIhvcNAQkEMRYEFM5NqjWlksBYSG73kBweyYQ0MFAsMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCXclo6ZSOntc9VFM4U7c33wLK7H8X0v1cKZhw8oRcysJLJytxW5wFIaC6c MvC0mmI4esPZkaLzKP81WbWWhjgqZDwPbgv+phVkyNqrAqEDhk3gfHcJLtJXt2EieQr72E02 20MkUYRHn8doCZVvv8iDlhs5SIdcLN7ze5oTMb3AeaS3QASG4YeI3X6KFe7U735vIoMu595W MoaSxtKL3GM2nv5J7SsAi16txO3YYACXB1/ftVBucOwN0mMrgMxG6i7w4rKST0TAPLexvLGP M0DgG/kDQxMZvmQU30gi0wuPXW0NSxFeDF8SBpzjA++Eqmr0q3wbrTHunPO/3ZIFa95dAAAA AAAA --------------ms090109090100010609000800-- From dzonatas@gmail.com Mon Apr 11 12:03:11 2011 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 52DDC3A6B16 for ; Mon, 11 Apr 2011 12:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 M2sDQkQ6--ve for ; Mon, 11 Apr 2011 12:03: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 1835D3A6A47 for ; Mon, 11 Apr 2011 12:03:10 -0700 (PDT) Received: by pwi5 with SMTP id 5so2668887pwi.31 for ; Mon, 11 Apr 2011 12:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ilaMaYB6uGL01wIN6UYRfWZSirbiEF7TldhPL8tr9BM=; b=at7vQal7p30OUa+FnTFfrwUVkxO2aZnnt5cTh/rUbSwB7CGGVKBWAvulekjj7FJOnv 04lENcD0j28wiApVgHvsrsp7sk8BUV9uAK332+0j4S0d5IJQn0ME27YuNZqiHt/UsvXW Fed3YbKGY0PPdSMcClAXeGo3cF7jpSVxTG61Y= 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=EGZOvVmO5NhW+dLq3QjqBh1F6ToV9mr6cCk4qZY7VpESN4WxG8Vn5ZH6blbjeidAsI 4vVVDWxV/EMaBAQTaAQZAmV8HXp7DBfSaM41TOa6KSeDAlcNntZjlWT5n0Mh0Bd+MZlS g3obiB/o9uueuxJRT31YNxr8OmuzP6SaNiR90= Received: by 10.143.153.18 with SMTP id f18mr177506wfo.114.1302548590524; Mon, 11 Apr 2011 12:03:10 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id o1sm8599689wfl.21.2011.04.11.12.03.09 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Apr 2011 12:03:09 -0700 (PDT) Message-ID: <4DA350A8.6090605@gmail.com> Date: Mon, 11 Apr 2011 12:04:08 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: "vwrap@ietf.org" References: <4DA32353.7070306@gmail.com> <4DA32594.1040904@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [vwrap] SPDY 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, 11 Apr 2011 19:03:11 -0000 Quoted from: http://tech.slashdot.org/comments.pl?sid=2078504&cid=35782366 by: mbelshe (462412) writes: on Monday April 11, @11:56AM (#35782366 ) Thanks for all the kind words on SPDY; I wish the magazine authors would ask before putting their own results in the titles! Regarding standards, we're still experimenting (sorry that protocol changes take so long!). You can't build a new protocol without measuring, and we're doing just that - measuring very carefully. Note that we aren't ignoring the standards bodies. We have presented this information to the IETF, and we got a lot of great feedback during the process. When the protocol is ready for a RFC, we'll submit one - but it's not ready yet. Here are the IETF presentations on SPDY: http://www.ietf.org/proceedings/80/slides/tsvarea-0.pdf [ietf.org] and https://www.tools.ietf.org/agenda/80/slides/httpbis-7.pdf [ietf.org] I've also answered a few similar questions to this here: http://hackerne.ws/item?id=2420201 [hackerne.ws] We love help- if you're passionate about protocols and want to lend implementation help, please hop onto spdy-dev@google.com Several independent implementations have already cropped up and the feedback continues to be really great. Dan Olivares wrote: > It would be nice if they could push that through the IETF. > > -Dan > > On Mon, Apr 11, 2011 at 12:00 PM, Dzonatas Sol wrote: > >> White paper: http://www.chromium.org/spdy/spdy-whitepaper >> >> Dzonatas Sol wrote: >> >>> Seems like GOOGLE did something similar to what I did with "bidirectional" >>> ReSTful combines, and they called it SPDY. >>> >>> (read about SPDY near the bottom) >>> >>> http://www.conceivablytech.com/6696/products/google-chrome-gets-spdy-and-an-onscreen-keyboard >>> >>> >>>>> Google said that it saw pageload times to improve by 44 to up to 64%. >>>>> According to the company, SPDY still uses HTTP methods, headers and �other >>>>> semantics.� << >>>>> >>> The difference is chrome implements a modified HTTP stack (SPDY) instead >>> of being limited to HTTP itself. So far, I only see a BSD style denotation >>> placed on the source files. >>> >>> Maybe worthwhile to investigate to see how easy it is to add the >>> ReSTful/LLSD/LLIDL combines and secure the transport within any specified >>> trust domain. >>> >>> >> -- >> --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Thu Apr 14 19:13:31 2011 Return-Path: X-Original-To: vwrap@ietfc.amsl.com Delivered-To: vwrap@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B0AF3E0677 for ; Thu, 14 Apr 2011 19:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7orUghjfhby for ; Thu, 14 Apr 2011 19:13:30 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfc.amsl.com (Postfix) with ESMTP id B8B2FE065C for ; Thu, 14 Apr 2011 19:13:27 -0700 (PDT) Received: by pxi20 with SMTP id 20so1421678pxi.27 for ; Thu, 14 Apr 2011 19:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=Mm8+BcQcSKaUnJsBsptcZEfU/Pul/yQQtFEARsNI1E4=; b=SRgx3iwBQxI6/c0nfSAnj5nf3FkpAJ9a1pVgzo+6tcyQzSikNCBv+49G6rc6XrKHq4 imJdQ7fR8ahKV0xYctQhXOUGo9yJHLhtMVTQv1jKtQ2uIzmaYlgTNtIVJI4UaEt7oY5s iB29UwEfVEkPTF0l+LOeuX5QHDbts5YF8jCmw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=oOtaMPpZhA3vj6fNC6ld4pmqfXcudU9Vr7PRWK63ZyDd/j6JH2G3aI01opA4/dMvps kXX1zbfDyZO4DmGi0WJFtEr6NAhufND6nU4vA1iF8qrDZ9UEnaBq4MW1LbDqhPmsqvrA Y4tUx/ZLI+MlWbCyHBzdqUkbUPncD2eaXPl88= Received: by 10.68.26.134 with SMTP id l6mr743166pbg.235.1302833602344; Thu, 14 Apr 2011 19:13:22 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id a1sm119257pbo.91.2011.04.14.19.13.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2011 19:13:21 -0700 (PDT) Message-ID: <4DA7AA00.4050707@gmail.com> Date: Thu, 14 Apr 2011 19:14:24 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: "vwrap@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [vwrap] IPv6 now mandatory, so next... X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 02:13:31 -0000 Asset servers that feature IPv6 access I can almost bet will win this next bubble. If they offer any kind of IPv6 tunnel, then I can further almost bet they will the next bubble as simulator proxies, ... ... and simulators as assets. Keep in mind more structured based transports than TCP and HTTP, yet with the same methods. The address scheme is in for the radical change. Something like the "UUID:UUID" instead of "http://some.place.xxx/strict" or "UUID://UUID.com/UUID/sec" we can see on the horizon. We've been through the best cases, yet obviously can't expect everybody to implement them in the same structure. Of course, they'll need to prove it for themselves. For now, I think we can use URN format for resources transistions: URN:UUID:AssetID,AssetID,AssetID,... Where UUID is translated to the resources we now use, yet can be used as the protocol under IPv6. If this is still vague, think of the DNS implementation in LSL ran by one of the simulators. You'll get the idea if it matters. Nice to have joined each one of us. Take care of id and it. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From barryleiba.mailing.lists@gmail.com Sat Apr 30 09:45:45 2011 Return-Path: X-Original-To: vwrap@ietfa.amsl.com Delivered-To: vwrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCD4E0688 for ; Sat, 30 Apr 2011 09:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.055 X-Spam-Level: X-Spam-Status: No, score=-103.055 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxA2HZ0psvBO for ; Sat, 30 Apr 2011 09:45:44 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id A7E63E0664 for ; Sat, 30 Apr 2011 09:45:44 -0700 (PDT) Received: by yic13 with SMTP id 13so1963801yic.31 for ; Sat, 30 Apr 2011 09:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=uUPytSHCRy3DP4ZMUxrLssD/jCcelpAioYRANN50neg=; b=IEPG5TMmtA15SDdljNHbCN3z2TEsIvmEmayiTY6UlqXEJZXDmZSclvexOUIUTRXPn5 K9fplFw8+MMHeQ/FdrSLjdOvTXIidbvS4vxjWcbrH8OB+t2y5b1e+xDkHH1Kyd/Q1lqR 7RncPbSiK2QNPun0R/OqRAPAtv7QBY94xPHKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=lWo2aF3+ibZnH8gMFUqaS2CtaSWnLpM8YjlzVqUd+gvCQ7oYodwytQnGIDwrzLNMmS D63CUNm+DQn+Zn5JvdtFAdA33fnQS2eY6lYHPt22uKMeM7DKxB+ca05BRWQe905GSnCC 7s6LwN3ogzkbxKghNfkNwMr7OuvqUrt40zAdY= MIME-Version: 1.0 Received: by 10.236.182.229 with SMTP id o65mr1696100yhm.216.1304181944208; Sat, 30 Apr 2011 09:45:44 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.137.13 with HTTP; Sat, 30 Apr 2011 09:45:44 -0700 (PDT) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Sat, 30 Apr 2011 12:45:44 -0400 X-Google-Sender-Auth: R8TyB06BGb5E8s6dHaHt7sT2Tb4 Message-ID: From: Barry Leiba To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 16:45:45 -0000 > That said, we need to be leading this discussion on consensus that can > be documented and posted. =A0And we need to focus on that and accomplish > it soon, for a vague but near-term value of "soon". We had a good bit of discussion in early April. Now that we're at the end of April, and the discussions seem to have stopped for the last couple of weeks, I'd like a progress report. Has there been any work on coming to consensus on the direction the group wants to take? Any progress on consensus for the contents of an intro/overview document? Barry, as chair