Re: [vwrap] Statements of Consensus. Flexibity First.
Morgaine <morgaine.dinova@googlemail.com> Tue, 05 April 2011 23:30 UTC
Return-Path: <morgaine.dinova@googlemail.com>
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 <vwrap@core3.amsl.com>; 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 <vwrap@core3.amsl.com>; 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 <vwrap@ietf.org>; Tue, 5 Apr 2011 16:30:10 -0700 (PDT)
Received: by qyk7 with SMTP id 7so599407qyk.10 for <vwrap@ietf.org>; 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: <BANLkTi=hX1ne=hvFqPh_EwTV_Urryxbp_A@mail.gmail.com>
References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <20110401161332.37ca0f9e@hikaru.localdomain> <AANLkTimcMbrJzXYTvs0cszn+rhH4ygEPvzvLwu94gr-4@mail.gmail.com> <BANLkTi=hL5YTAW9_V7EA3C3fiknU0o_ARA@mail.gmail.com> <20110405152025.26ba8f77@hikaru.localdomain> <4D9B4586.9080004@gmail.com> <BANLkTi=hX1ne=hvFqPh_EwTV_Urryxbp_A@mail.gmail.com>
Date: Wed, 06 Apr 2011 00:31:52 +0100
Message-ID: <BANLkTi=HJMTaERF5y7zZah_2HSqEhZv78w@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
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 <vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 23:30:13 -0000
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 <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/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. > > > > >
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Boroondas Gupte
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dickson, Mike (ISS Software)
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- [vwrap] Statements of Consensus. Flexibity First. Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Mike Dickson
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Mike Dickson
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Mike Dickson
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Mike Dickson
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Boroondas Gupte
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Mike Dickson
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Izzy Alanis
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Izzy Alanis
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Carlo Wood
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Izzy Alanis
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Izzy Alanis
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Morgaine
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Dzonatas Sol
- Re: [vwrap] Statements of Consensus. Flexibity Fi… Izzy Alanis