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

[Meadhbh Hamrick <[e-mail]>]

but what about the trust issue?

are we going to explicitly trust services?

it doesn't make sense that a service is what's trusted as it implies
that something MUST be a vwrap service in order to be trusted.

we created the domain as an abstraction to represent these notions and
again, the idea that there is a domain is INDEPENDENT of how services
are deployed.

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [e-mail]



On Mon, Mar 29, 2010 at 4:10 PM, Robert G. Jakabosky
<[e-mail]> wrote:
>
> +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 <[e-mail]>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/ * [e-mail]
>> >
>> >
>> >
>> > On Mon, Mar 29, 2010 at 11:17 AM, James Hughes <[e-mail]>
>> >
>> > 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)
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/ogpx
>
>
>
> --
> Robert G. Jakabosky
> _______________________________________________
> ogpx mailing list (VWRAP working group)
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>