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

"Robert G. Jakabosky" <bobby@sharedrealm.com> Mon, 29 March 2010 23:09 UTC

Return-Path: <bobby@sharedrealm.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAFA53A6AF9 for <ogpx@core3.amsl.com>; Mon, 29 Mar 2010 16:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.191
X-Spam-Level: *
X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, SARE_SUB_ENC_UTF8=0.152]
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 TIUegY3j2hwR for <ogpx@core3.amsl.com>; Mon, 29 Mar 2010 16:09:41 -0700 (PDT)
Received: from mail.neoawareness.com (ns2.sharedrealm.com [IPv6:2001:470:1f05:4f4::13]) by core3.amsl.com (Postfix) with ESMTP id 68B433A68F0 for <ogpx@ietf.org>; Mon, 29 Mar 2010 16:09:41 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=[10.200.0.30]) by mail.neoawareness.com with esmtpa (Exim 4.69) (envelope-from <bobby@sharedrealm.com>) id 1NwO5w-0005dC-NG for ogpx@ietf.org; Mon, 29 Mar 2010 16:10:08 -0700
From: "Robert G. Jakabosky" <bobby@sharedrealm.com>
To: ogpx@ietf.org
Date: Mon, 29 Mar 2010 15:10:04 -0800
User-Agent: KMail/1.9.10
References: <b325928b1003291016i5c07e6d9na0feda9faf930aeb@mail.gmail.com> <b325928b1003291119m4b2e6233w3b2d237adc04abac@mail.gmail.com> <e0b04bba1003291336y40661e7dtc29852c1834304a0@mail.gmail.com>
In-Reply-To: <e0b04bba1003291336y40661e7dtc29852c1834304a0@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <201003291610.04868.bobby@sharedrealm.com>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: bobby@sharedrealm.com
X-SA-Exim-Scanned: No (on mail.neoawareness.com); SAEximRunCond expanded to false
Subject: Re: [ogpx] verbiage : domain, agent domain, region domain, trust domain , service, etc.
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Mar 2010 23:09:42 -0000

+1 on using "services" instead of "domains".

On Monday 29, Morgaine wrote:
> 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



-- 
Robert G. Jakabosky