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

Meadhbh Hamrick <> Mon, 29 March 2010 21:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 574FE3A6B82; Mon, 29 Mar 2010 14:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.123
X-Spam-Level: *
X-Spam-Status: No, score=1.123 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HTcTi8eR5Epy; Mon, 29 Mar 2010 14:42:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A26E43A6B7A; Mon, 29 Mar 2010 14:42:11 -0700 (PDT)
Received: by with SMTP id 9so415864qwb.31 for <multiple recipients>; Mon, 29 Mar 2010 14:42:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:received:message-id:subject:to:cc:content-type; bh=UJDcjFci1piB3CpJRrQR7t2RgK08HisyjcbKtZjiETc=; b=veF9bQridV+Sox8ngmX9FKulxOB3fPHiZum4c1W0GZgSuJ28BJuBx2na3MGiie7e5w NAEe8vvYlKeA1FVC+FVE+dbMejPvbpWugFrWd0Jr+MxZq+591orrJEb3YzegrWVvo+PD 1dla/NF2P8hCdIMgADLs63O/Tdomo6Icxg/aI=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=MY0zjkQBgICcmu1QInEu3E64lmAmf67Mt0jwURMRBKjmDR6WdtiWvICz4QSAeUgym8 HsdQJFMzBRhWZGZEJg1rrJuCjAmjaRxriUIM1czmRwQizIKZxa9gnFg578hBBG44Ix2v ewPqNq9DsorIXKfkuoGrrYDKs5xBkfp+mOpRA=
MIME-Version: 1.0
Received: by with HTTP; Mon, 29 Mar 2010 14:42:17 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Meadhbh Hamrick <>
Date: Mon, 29 Mar 2010 14:42:17 -0700
Received: by with SMTP id q3mr664926qco.56.1269898957183; Mon, 29 Mar 2010 14:42:37 -0700 (PDT)
Message-ID: <>
To: David W Levine <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc:, ogpx <>
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 21:42:13 -0000

in other words, "we've been saying 'agent domain' for at least two
years and this is the thing we're hung up on????"

meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * *

On Mon, Mar 29, 2010 at 2:41 PM, Meadhbh Hamrick <> wrote:
> On Mon, Mar 29, 2010 at 2:14 PM, David W Levine <> wrote:
>> [stuff removed]
>>> the terms "asset domain" and "region domain" are used to identify the
>>> domain of certain types of transactions in the protocol. their use
>>> underscores the potential separation of the roles each domain plays.
>> In some deployments mayhap. Not in all. The roles the domain plays in these
>> examples is a deployment choice, nothing more. There may be some trust/admin
>> patterns which are common, but then we need to focus on those rather than
>> thinking calling it an "agent domain" is clarifying.
> i don't agree with this statement. it is confusing that a region
> domain would host agent services and an agent domain host region
> services. it doesn't seem confusing that a domain could be
> simultaneously a region domain and an agent domain.
> the term "agent domain" identifies the domain that begins certain
> types of protocol transactions. if your deployment choice is to have
> the agent and region domains be the same domains, then bully for you.
> but it doesn't change the fact that there is a collection of hosts
> (possibly with a single member, but probably not) that will initiate
> certain types of protocol interchanges, and a collection of hosts
> (possibly with a single member, but probably not) that will respond to
> these interchanges.
>>> so the terms "agent domain" and "region domain" are "positional" and
>>> describe the function in a protocol transaction, NOT a requirement
>>> that a group of machines implement a particular cluster of services.
>>> --
>>> meadhbh hamrick * it's pronounced "maeve"
>>> @OhMeadhbh * *
>> But, positional terms which describe specific patterns, which are deployment
>> choices rather
>> than functional requirements actually confuse not clarify.
> what? no matter what you do, you will have a deployment pattern. no
> matter what you do, you will have a host that a request initiates from
> and a host that is the target of the request. calling one an "agent
> host in an agent domain" clarifies the role the host and domain play,
> not the deployment pattern.
> if you wanted to deploy chargen, VWRAP authentication and gopher on a
> single host, it's still an agent host for the purposes of the
> authentication transaction.
>>> so we would say, "the agent domain initiates the process of placing an
>>> agent in a region domain's simulator" rather than "the first service
>>> initiates the process of placing an agent in a region."
>> It might. Or the authentication service might give you NOTHING more than a
>> sheaf of
>> seed caps each on a stand-alone service which is separately deployed. (I
>> think that's
>> not going to be the most common deployment pattern, but its certainly one
>> you could deploy,
>> and one we need to be able to describe.
>> Unless we can say "This is a term which always cuts things into separable
>> parts", I think we're
>> confusing deployment with architecture. To the degree you can say why "Agent
>> Domain" is more
>> explanatory than saying "This common cluster of services" in which case I'm
>> perfectly happy saying that. But
>> I'm thinking that beyond a very small cluster (Auth, IM endopint, Presence
>> broadcast, and even those could be delegated) I'm not sure what HAS to be in
>> an Agent Domain, rather than what many people will CHOSE to put in one.
> my recommendation is that the term "agent domain" be "positional"
> indicating the role of an actor in a protocol transaction. it DOES NOT
> imply service deployment clustering.
> a domain is an agent domain for the purposes of authentication if it
> responds to the authentication protocol. it is a region domain for the
> purposes of teleport if it responds to the teleport protocol. etc.
> etc. if you want to put both services on one machine, it is
> simultaneously an agent domain and a region domain.
> note also that there's nothing in this description that demands that
> there be a single agent domain. you could have an agent domain for
> authentication or an agent domain for IM and they could be the same or
> different agent domains.
> -cheers
> -meadhbh
>> Please note I think this is exactly the discussion we *should* be having. We
>> need to make it clear what the term
>> is actually buying us, and how we could benefit from it.
>> - David
>> ~Zha