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

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

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.

Morgaine.

===============================

On Mon, Mar 29, 2010 at 7:19 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com>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 * http://meadhbh.org/ * OhMeadhbh@gmail.com
>
>
>
> On Mon, Mar 29, 2010 at 11:17 AM, James Hughes <jamesh@bluewallgroup.com>
> 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)
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>