Re: [vwrap] Statements of Consensus. Flexibity First.

Morgaine <> Tue, 05 April 2011 23:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 878A23A69AA for <>; Tue, 5 Apr 2011 16:30:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.802
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VpyB2rSWgYyz for <>; Tue, 5 Apr 2011 16:30:10 -0700 (PDT)
Received: from ( []) by (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;; 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;; 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 with SMTP id u17mr253759qcr.71.1302046312712; Tue, 05 Apr 2011 16:31:52 -0700 (PDT)
Received: by with HTTP; Tue, 5 Apr 2011 16:31:52 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <20110401161332.37ca0f9e@hikaru.localdomain> <> <> <20110405152025.26ba8f77@hikaru.localdomain> <> <>
Date: Wed, 6 Apr 2011 00:31:52 +0100
Message-ID: <>
From: Morgaine <>
Content-Type: multipart/alternative; boundary=000e0cd25caef34b6404a034475c
Subject: Re: [vwrap] Statements of Consensus. Flexibity First.
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

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

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



On Tue, Apr 5, 2011 at 7:56 PM, Morgaine <>wrote;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 ---
> , 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.