Re: [ogpx] verbiage : domain, agent domain, region domain, trust domain, service, etc.

Morgaine <> Mon, 29 March 2010 20:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A5CEE3A680F for <>; Mon, 29 Mar 2010 13:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.754
X-Spam-Level: *
X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eaOzYJgt129O for <>; Mon, 29 Mar 2010 13:36:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E0A003A65A6 for <>; Mon, 29 Mar 2010 13:36:08 -0700 (PDT)
Received: by wyb29 with SMTP id 29so5234360wyb.31 for <>; Mon, 29 Mar 2010 13:36:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=XPb6LsqsQe/Q2bSM6+V2urg9EVSPEcaEawhBaeEHgLw=; b=RBcpV8GCHOxLfT4hPehRNHPrdnUs2ukqfmxBS0NjZtx+gm1CG3oPq/uHrjGIFW6SbJ s7UC2M6BnoSX3whmofZc1C/wJMz9r1kfTSAxT946Gjp1eTfAvFisN/+V6Q/Hy7weexBB SOE3Nn4z5V6Cl5fVpRowGij/ezuha8XHSjSr0=
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=uDD5ZA0gh7dxNyufmwTb8udW06L9An0gt9JkLAfDQl/bgOuEecEN3kjkte2TtooCml bX1UqcoG2reXlvRL1gc2IlEFBwQJC/yv3d5D2smwoYuVJXZWgDOz3IfQKv+dzSmZ+mEQ aE7VY/rT0Ds/hMfNXRsSLuu41CxQK+3X0nuW8=
MIME-Version: 1.0
Received: by with HTTP; Mon, 29 Mar 2010 13:36:33 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Mon, 29 Mar 2010 21:36:33 +0100
Received: by with SMTP id u2mr654391wee.49.1269894993958; Mon, 29 Mar 2010 13:36:33 -0700 (PDT)
Message-ID: <>
From: Morgaine <>
To: ogpx <>
Content-Type: multipart/alternative; boundary="0016e6d640820456420482f678d3"
Subject: Re: [ogpx] verbiage : domain, agent domain, region domain, trust domain, service, etc.
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, 29 Mar 2010 20:36:10 -0000

David dissected the "domain" terminology for us thoroughly last year.  He
very nicely highlighted how the term provides almost no additional value,
because everything is ultimately a "service", and the whole point of VWRAP's
services is that they are highly decoupled to provide a large number of
possible deployments.  "Domain" suggest a stronger coupling than actually

The idea of "domain" as a control element is not enforceable, nor useful,
when services can be external and the set is expandable.  The notion of
"trust domain" is particularly weak when you don't control external
services, but merely use them.  Drawing circles around sets of services and
calling them "domains" is largely wishful thinking when they are
independent.  You are merely their client rather than their owner:

As an analogy, it's like drawing an "Email domain" circle around an MTA
service and the external DNS services that it uses.  Drawing the circle
provides nothing of value.  All the value is held in the services
themselves, and how they are each configured.

Asset services will exist in their thousands, or millions if the metaverse
catches on.  What this means in VWRAP deployments which support tourism
between worlds is that any given region may contain visitors from arbitrary
many worlds, each visitor bringing references to their own asset services
with them.

So what does "asset domain" mean in this high-interop context?  Virtually
nothing, because the alleged "asset domain" encompasses the whole Internet.
It's a term that belongs with clouds drawn on whiteboards, and doesn't
contribute anything significant to our protocol specifications, because the
domains don't actually exist, only the services.



On Mon, Mar 29, 2010 at 7:19 PM, Meadhbh Hamrick <>wrote:

> to clarify, i'm not talking about the capability of using a 3rd party
> asset service (which i think we've all agreed is something we should
> support) but the use of the term "asset domain" to identify a domain
> that exports an asset service.
> --
> meadhbh hamrick * it's pronounced "maeve"
> @OhMeadhbh * *
> On Mon, Mar 29, 2010 at 11:17 AM, James Hughes <>
> wrote:
> > On 03/29/2010 01:16 PM, Meadhbh Hamrick wrote:
> > ...
> >> 1. there's a high quality implementation of an asset service out there
> >> (cable beach) which _could_ be deployed independently of an OpenSim or
> >> LL instance. does this mean we should have an "asset domain"?
> >>
> >>
> > It would make sense to me to have that capability. The 3rd party asset
> > services will need to provide functions to interact with both agent and
> > region domains according to subscription rules and agreements entered
> > into by operating entities and users. Depending on the rule-set, maybe
> > the avatar can or cannot see particular inventory items on certain
> > grids. Or, perhaps, region domains will need to negotiate the ability to
> > rez or distribute objects based on the rule-sets applied at the 3rd
> > party service.
> >
> > It seems pretty complex to administrate with a 3rd party. And, in my
> > opinion, defining an asset domain to operate in would be useful. Just my
> > OS$2.
> >
> > regards
> > James  (BlueWall)
> >
> >
> >
> _______________________________________________
> ogpx mailing list (VWRAP working group)