Subject: [ogpx] A blog post from the HTML5/Websocket wars worth reading

From: David W Levine <[email-masked]>
Date: Wed, 17 Feb 2010 10:16:07 -0500

For those who don't slog through the Hybi/Websocket traffic a 
blog entry from Tim Bray which I think touches on some issues
for the VWRAP work... 

http://www.tbray.org/ongoing/When/201x/2010/02/15/HTML5 

- David
~ Zha

---

From: Kari Lippert <[email-masked]>
Date: Wed, 17 Feb 2010 11:36:55 -0500

Oh my, thanks for sharing... yes, I see some similarities too... but I think
in the case of VWRAP, we are obliged to provide the protocol and also the
"object(s)" including the semantics and intended interpretation. If it is
rich enough, the future will be able to happen from within. And it the past
is any indication, through thoughtful re-purposing of things well defined!

Kari

On Wed, Feb 17, 2010 at 10:16 AM, David W Levine <[email-masked]> wrote:

> *http://www.tbray.org/ongoing/When/201x/2010/02/15/HTML5*<http://www.tbray.org/ongoing/When/201x/2010/02/15/HTML5>
>
> - David
> ~ Zha
>
> _______________________________________________
> ogpx mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

-- 

http://kjlippert.wordpress.com/
http://community.webshots.com/user/MissGnomer

---

From: David W Levine <[email-masked]>
Date: Wed, 17 Feb 2010 13:03:36 -0500

Kari Lippert <[email-masked]> wrote on 02/17/2010 11:36:55 AM:

> [image removed] 
> 
> Re: [ogpx] A blog post from the HTML5/Websocket wars worth reading
> 
> Kari Lippert 
> 
> to:
> 
> David W Levine, ogpx
> 
> 02/17/2010 11:37 AM
> 
> Oh my, thanks for sharing... yes, I see some similarities too... but
> I think in the case of VWRAP, we are obliged to provide the protocol
> and also the "object(s)" including the semantics and intended 
> interpretation. If it is rich enough, the future will be able to 
> happen from within. And it the past is any indication, through 
> thoughtful re-purposing of things well defined!
> 
> Kari
>  
> 
> 

My personal take away is twofold:

First, describing "what" is sent is the win, not how to process it. So, 
you get to say
"this is a prim who's visual shape is X" not "In order to display this 
prim you must take
and apply the following behavior. "This is an idempotent motion update" 
not "Take motion update 46
and apply it to the following state machine" 

Second, we want layering which follows Tim's notions that we not get into 
the multiple complex framing
thoughts, and hiding what we are doing. The side by side comparison of the 
two specification styles is
illuminating. 

Other take away thoughts as well, but those were my first two big ones. (I 
also plead guilty to wanting
to make people aware of all the websocket/hybi stuff)

- David
~ Zha

---

From: Morgaine <[email-masked]>
Date: Thu, 18 Feb 2010 09:29:23 +0000

I'll add a third observation which I also take from Tim Bray's article:

Defining *world* semantics (which loosely equates to Tim's *object model*)
rather than merely defining *interop protocol* semantics will
unavoidably *reduce
interop*.  If we limit ourselves to defining well every aspect of the
protocol *and only the protocol*, this is enough to guarantee compatibility
for interop.  In contrast, adding details of how worlds should work reduces
the set of candidate worlds that can benefit from the interop protocol, and
worse, acts against evolution and progress in those worlds.

VWRAP is not a protocol to enshrine a particular form of world, but a
protocol to define a particular form of interop.  We often make the mistake
of referring to "SL-like worlds" in these discussions, when what we really
mean is "VWRAP-compatible worlds".  There is certainly no need to be SL-like
nor even SL-compatible when using VWRAP.  For example, VWRAP will
undoubtedly be used by leading-edge worlds with services and assets that
Linden Lab chooses not to handle, as a business choice.

Therefore "SL-like" is a very incorrect phrase here.  We mean
VWRAP-compatible.

Morgaine.

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

On Wed, Feb 17, 2010 at 6:03 PM, David W Levine <[email-masked]> wrote:

> First, describing "what" is sent is the win, not how to process it. So, you
> get to say
> "this is a prim who's visual shape is X" not "In order to display this prim
> you must take
> and apply the following behavior. "This is an idempotent motion update" not
> "Take motion update 46

---

From: Barry Leiba <[email-masked]>
Date: Thu, 18 Feb 2010 12:18:42 -0500

> Therefore "SL-like" is a very incorrect phrase here.  We mean

What she said.

Barry

---

From: Carlo Wood <[email-masked]>
Date: Fri, 19 Feb 2010 15:12:52 +0100

> > Therefore "SL-like" is a very incorrect phrase here.  We mean

Agreed. SL should be VWRAP compatible, but there is no need
for another world that uses VWRAP to really be anything like SL.

-- 
Carlo Wood <[email-masked]>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Fri, 19 Feb 2010 08:17:26 -0800

> for another world that uses VWRAP to really be anything like SL.

well.. actually.. yes there is. (and yes, no there's not.)

people familiar with the history of VWRAP will remember that before VWRAP,
we had the MMOX BoF. MMOX was introduced with a "wide" charter. we wanted to
try to get as many participants as possible, and introduce compatibility
with as many existing systems as possible.

but guess what? it turned into an utter failure. the common ground between
Second Life, Wonderland, Olive, Webkins, et al. was just too small to
produce a meaningful specification.

at the end of the MMOX BoF, the suggestion was made that we have another
BoF, but with a more limited scope. that's where the OGPX BoF came from.
OGPX was an attempt to describe the "problem domain" that SL is the solution
for. a number of us thought long and hard about the social and technical
concerns SL addresses and were able to distill them into the charter and the
intro and goals document.

so we may want to be careful when we say things like "there is no need for
another world that uses VWRAP to really be anything like SL." it's
COMPLETELY true that there could be a lot of things that don't need to be
replicated. for instance, Second Life's use of the Linden game script or the
particular way in which property is represented in SL (parcel, simulator,
estate, etc.)

but if you want to have a chance of interoperability, there must be basic
constraints and processing expectations.

for example. 3d descriptions of assets (either as primitives, collections of
nurbs, sculpties or meshes) are intended to be rendered. there is a use case
that they be rendered as part of a 3d scene. yes, we may also have the use
case of rendering them as part of a web page. or converting them into a JPEG
and printing them on a mug at cafepress.com or ...

so yes. we should not place limitations on where an asset can be rendered.
but we should understand that the asset data for a 3d object is intended to
be rendered. it's not going to be used as the seed to a random number
generator whose output is used to make stock purchase decisions or rendered
as an audio stream. (well. sure. you could. but it SHOULDN'T be a supported
use case.)

so getting back to the description of "Second Life-Like" as a way to
describe VWRAP. this was actually the elevator pitch for OGPX... to
determine the specs for "Second Life-Like" worlds. at the time it was a
shorthand for describing how Second Life and OpenSimulator differed from
projects like Olive or Wonderland. moving forward, this moniker will likely
be both and impediment and a benefit. it's beneficial in that when someone
asks what we're trying to do, we could simply say... "we're making specs for
OpenSim-Like or SecondLife-Like worlds." but these descriptions carry
baggage.

so it's true to a certain degree that there are no requirements that a
virtual world that uses VWRAP look anything like Second Life(tm), Second
Life (tm) and OpenSim were the exemplars of the class from which our
requirements were drawn. so i think we'll see that "VWRAP worlds" will share
a lot of similarities. or not.

but my point is that the stated objective of this group is work on protocols
whose requirements and expected use are radically similar to that of SL and
OpenSim. we no longer use the ostensive definition of "it has to be like
Second Life(tm)." but if we produce a protocol that meets the requirements
set down in the charter, we'll likely find we have something that is similar
in many key respects to SL or OpenSim.

-cheers
-meadhbh

---

From: David W Levine <[email-masked]>
Date: Fri, 19 Feb 2010 11:26:46 -0500

At some level, it's a tautology.  Since the VWRAP spec, not Second Life, 
is going to define VWRAP compatibility, it can't be any other way. 

At the same time, the path from AWG->MMOX->OGPX->VWRAP is all about 
finding a subset of possible virtual worlds which is big
enough to be interesting, and small enough to be manageable. "Second Life 
Like" has been a convenient short hand to scope the 
problem.  What does it mean? I believe its Roughly the following: 
(Glancing at our charter)

        - Avatars representing users
        - Named Persistent areas of virtual space (Regions) 
        - Region centric state management (you can get state from the 
services facaded by a URI)
        - Services delivered over web interfaces
        - Policies 

That's certainly "Second Life like" its certainly "OpenSim Like."

I fully expect that part of the challenge going forward is going to be 
providing sufficient markup
so that world which fit within the broad umbrella of VWRAP, but differ in 
significant ways can signal
those differences, allowing sane interoperation. I also fully expect some 
mighty odd things to happen
when someone teleports from a grid with one physics to a grid with a 
different physics model unless
the client, and the protocols signal properly. But.. I also think if we 
are at that point, we're winning, not losing. 

- David
~ Zha

From:
To:
[email-masked]
Cc:
Date:
02/19/2010 09:13 AM
Subject:
Sent by:
[email-masked]

---

From: Joshua Bell <[email-masked]>
Date: Fri, 19 Feb 2010 09:31:18 -0800

+1

As we have no exemplars of a VWRAP compatible system at the moment, so it's
hard to point at one and say "like that!" Hence the use of SL, as a guiding
example of the abstract theory, if not (currently!) the practice, as
outlined by David's mail.

But yes, we should absolutely be saying "VWRAP-compatible" rather than
"SL-like" when we're discussing anything formally, and point at the Intro
draft (which everyone has read and likes, yes?) to clarify what that means.

On Fri, Feb 19, 2010 at 8:26 AM, David W Levine <[email-masked]> wrote:

>
> At some level, it's a tautology.  Since the VWRAP spec, not Second Life, is
> going to define VWRAP compatibility, it can't be any other way.
>
> At the same time, the path from AWG->MMOX->OGPX->VWRAP is all about finding
> a subset of possible virtual worlds which is big
> problem.  What does it mean? I believe its Roughly the following: (Glancing
> at our charter)
>
> the client, and the protocols signal properly. But.. I also think if we are
> at that point, we're winning, not losing.
>
> - David
> ~ Zha
>
>
>
>
>
>  From:
> To: [email-masked] Cc: [email-masked] Date: 02/19/2010 09:13 AM
> Subject:
> Sent by: [email-masked]
> ------------------------------
>
>
>

---

From: Carlo Wood <[email-masked]>
Date: Sun, 21 Feb 2010 11:56:31 +0100

I'm aware of all that, and I meant it in a mathematical way.
The only conclusion you should draw from my remark is that
the phrase "Second Life-like" has no place in any official
VWRAP document other than the "history" paragraph, once VWRAP
is finished.

As long we're still designing VWRAP, it's a useful term to
stay in-scope, though.

On Fri, Feb 19, 2010 at 08:17:26AM -0800, Meadhbh Hamrick wrote:
> people familiar with the history of VWRAP will remember that before VWRAP, we
> had the MMOX BoF. MMOX was introduced with a "wide" charter. we wanted to try
> to get as many participants as possible, and introduce compatibility with as
> many existing systems as possible.
> 
> Second Life, Wonderland, Olive, Webkins, et al. was just too small to produce a
> meaningful specification.
> 
> at the end of the MMOX BoF, the suggestion was made that we have another BoF,
> but with a more limited scope. that's where the OGPX BoF came from. OGPX was an
> attempt to describe the "problem domain" that SL is the solution for. a number
> of us thought long and hard about the social and technical concerns SL
> addresses and were able to distill them into the charter and the intro and
> goals document.
> 
> another world that uses VWRAP to really be anything like SL." it's COMPLETELY
> true that there could be a lot of things that don't need to be replicated. for
> instance, Second Life's use of the Linden game script or the particular way in
> which property is represented in SL (parcel, simulator, estate, etc.) 
> 
> that they be rendered as part of a 3d scene. yes, we may also have the use case
> of rendering them as part of a web page. or converting them into a JPEG and
> printing them on a mug at cafepress.com or ...
> 
> so yes. we should not place limitations on where an asset can be rendered. but
> we should understand that the asset data for a 3d object is intended to be
> rendered. it's not going to be used as the seed to a random number generator
> whose output is used to make stock purchase decisions or rendered as an audio
> stream. (well. sure. you could. but it SHOULDN'T be a supported use case.)
> 
> so getting back to the description of "Second Life-Like" as a way to describe
> VWRAP. this was actually the elevator pitch for OGPX... to determine the specs
> for "Second Life-Like" worlds. at the time it was a shorthand for describing
> how Second Life and OpenSimulator differed from projects like Olive or
> Wonderland. moving forward, this moniker will likely be both and impediment and
> a benefit. it's beneficial in that when someone asks what we're trying to do,
> we could simply say... "we're making specs for OpenSim-Like or SecondLife-Like
> worlds." but these descriptions carry baggage.
> 
> so it's true to a certain degree that there are no requirements that a virtual
> world that uses VWRAP look anything like Second Life(tm), Second Life (tm) and
> OpenSim were the exemplars of the class from which our requirements were drawn.
> so i think we'll see that "VWRAP worlds" will share a lot of similarities. or
> not.
> 
> OpenSim. we no longer use the ostensive definition of "it has to be like Second
> Life(tm)." but if we produce a protocol that meets the requirements set down in
> the charter, we'll likely find we have something that is similar in many key
> respects to SL or OpenSim.
> 
> -cheers
> -meadhbh

---

From: David W Levine <[email-masked]>
Date: Wed, 24 Feb 2010 12:30:42 -0500

Dear all:

I have updated the deployment patterns and trust draft with
significant new material and (hopefully) typos removed. 

I look forward to comments and feedback. On the list please. I will 
happily take typo nits and formatting suggestions off list, but
substantive feedback should be directed to the list for everyone
to see. 

Text at:

http://www.ietf.org/id/draft-levine-vwrap-deploy-01.txt 

- David W. Levine
~ Zha Ewry (in Second Life)

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Wed, 24 Feb 2010 11:15:02 -0800

good draft... so... since there's no trust model and deployment pattern
deliverable in the charter, do we want to split this one up and put the
deployment stuff in the intro and the trust stuff in the auth draft?

here are some comments:

* eek! you mentioned Linden Lab(tm) and Second Life(tm) in the draft. given
last week's conversation about "second life-like" vs. "vwrap-like" as a
descriptor, shouldn't we avoid such things for fear of people thinking that
if they're SL-compatible, they're automagically VWRAP-compatible?

* i love the picture of User 1 <-> Client 1 <-> service <-> Client 2 <->
User 2. it's kind of an oversight that i didn't put something like that in
the intro doc. (though i would show it with multiple services.. something
like
https://wiki.secondlife.com/w/images/d/da/Vwrap_user_to_service_mapping.png)

in a related issue. we use the term "client application" for an app that
accesses services. the most visible client application is the one that
renders the virtual world for the user. i think this kind of application is
traditionally called a "user agent" in other IETF protocols. so...

question : does it make sense to introduce the concept of a "user agent" as
the client application that is intended to have direct interaction with the
user?  i think it would be good to explain that "clients" or "client
applications" do not always have to be "user agents." if so, lemme modify
the intro doc to reflect it.

* i would argue that the definition of a "domain" IS defined. as we agree'd
on the list, we use the term "domain" in it's classic meaning: "a domain is
a collection of network hosts under the control of a single administrative
authority."

there was an unfortunate confusion of the term "domain" with "administrative
authority" as well as the convolution of the terms "domain" and "network
host." the existing documents describe a domain in this manner, highlighting
an "agent domain" as a domain that includes a user authentication service
and a "region domain" as a domain that includes a region object presence
service. i'm still not sure why we have to change this.

david, i understand that your preference is to have domain mean "the
collection of machines which combine to deliver a service." this is going to
get confusing when a "domain" crosses "trust domains." in other words, if
you have machines owned by one person delivering half of a service and
machines owned by another person delivering the other half of the service,
and you want to call both sets of machines taken together "a domain," then
it will get confusing to also call the set of machines owned by the first
person (even the ones that aren't delivering the service in question) "a
domain."

so... i think we have a couple of different concepts here, and we have to
name them different things. maybe we could compromise... we could say that a
domain is "a collection of hosts that share some common feature" and that a
"trust domain" is a collection of hosts with the same trust characteristics
(defined as being owned by the same entity or for whom there's
a demonstrable privilege implying trust) and a "service domain" is a
collection of hosts that together, deliver a service with the special note
that a service domain may cross trust domains.

ugh. that was a mouthful.

* yup. the glossary in the intro should be beefed up. i'll add some to it.

<comment mode="pedantic">
* why are we mentioning hypergrid? they've publicly said they don't want to
participate. can we remove mentions of hypergrid from these specs? i have no
problem with individuals who participated in hypergrid from participating in
vwrap (like i could do anything to prevent it.) but... vwrap IS NOT
hypergrid. vwrap is also not Second Life. vwrap is also not OpenSim, OSGrid,
reactionGrid, cable beach or realXtend.

i think we need to be very clear about the relationship between this effort
and these projects. as i see it, vwrap is an effort sponsored by the IETF
which is intended to be useful by all of the projects listed above, but not
to "be" them.

in other words, i have a big problem with using the ostensive definition
when describing vwrap service definitions. i don't want to ever have a spec
that says (and i paraphrase here) "readers are referred to hypergrid
specification 3.71 for how vwrap handles authentication to an asset service
and the legacy second life protocol as defined in the beginning of file
llagent.cpp from the snowglobe source code."

on the other hand... getting people from all of the projects mentioned above
together to define protocol and usage profiles is a bag full of win. but we
should be able to define the characteristics of these systems independent of
their names. or rather, we should talk about characteristics of protocol and
use and then maybe say ("like hypergrid" or "like opensim".)

sorry for going all pedantic on people. just think strongly it would be a
train wreck to do this thing that is probably not what david is saying we
should do, but scares me nonetheless.
</comment>

* i think you've got some good ideas WRT trust. however... can we avoid
talking about content management IN the protocol? it's a can of worms and
IMHO is out of scope and needs A LOT more research. that being said... yes,
it's important and we MUST talk about it, but maybe we could add it to a
separate document?

in other words, i propose adding bits about trust between hosts in the
authentication document, but not about content management.

-cheers
-meadhbh

--
  infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
        http://wiki.secondlife.com/wiki/User:Infinity_Linden

On Wed, Feb 24, 2010 at 09:30, David W Levine <[email-masked]> wrote:

> *http://www.ietf.org/id/draft-levine-vwrap-deploy-01.txt*<http://www.ietf.org/id/draft-levine-vwrap-deploy-01.txt>
>
> - David W. Levine

---

From: Lawson English <[email-masked]>
Date: Thu, 25 Feb 2010 00:14:29 -0700

I see an issue where there is a presumption of external "authority" with 
respect to services. A client plugin might provide a vwrap service only 
to a client via a localhost/loopback mechanism, or it may be a proxy to 
a central service or it may be a proxy to a p2p network of services. 
Where does administrative authority lie in this scenario? Does it 
pertain? Who decides? etc...

lawson

Infinity Linden (Meadhbh Hamrick) wrote:
> good draft... so... since there's no trust model and deployment 
> pattern deliverable in the charter, do we want to split this one up 
> and put the deployment stuff in the intro and the trust stuff in the 
> auth draft?
>
> here are some comments:
>
> * eek! you mentioned Linden Lab(tm) and Second Life(tm) in the draft. 
> given last week's conversation about "second life-like" vs. 
> "vwrap-like" as a descriptor, shouldn't we avoid such things for fear 
> of people thinking that if they're SL-compatible, they're 
> automagically VWRAP-compatible?
>
> * i love the picture of User 1 <-> Client 1 <-> service <-> Client 2 
> <-> User 2. it's kind of an oversight that i didn't put something like 
> that in the intro doc. (though i would show it with multiple 
> services.. something 
> like https://wiki.secondlife.com/w/images/d/da/Vwrap_user_to_service_mapping.png 
> )
>
> in a related issue. we use the term "client application" for an app 
> that accesses services. the most visible client application is the one 
> that renders the virtual world for the user. i think this kind of 
> application is traditionally called a "user agent" in other IETF 
> protocols. so...
>
> question : does it make sense to introduce the concept of a "user 
> agent" as the client application that is intended to have direct 
> interaction with the user?  i think it would be good to explain that 
> "clients" or "client applications" do not always have to be "user 
> agents." if so, lemme modify the intro doc to reflect it.
>
> * i would argue that the definition of a "domain" IS defined. as we 
> agree'd on the list, we use the term "domain" in it's classic meaning: 
> "a domain is a collection of network hosts under the control of a 
> single administrative authority."
>
> there was an unfortunate confusion of the term "domain" with 
> "administrative authority" as well as the convolution of the terms 
> "domain" and "network host." the existing documents describe a domain 
> in this manner, highlighting an "agent domain" as a domain that 
> includes a user authentication service and a "region domain" as a 
> domain that includes a region object presence service. i'm still not 
> sure why we have to change this.
>
> collection of machines which combine to deliver a service." this is 
> going to get confusing when a "domain" crosses "trust domains." in 
> other words, if you have machines owned by one person delivering half 
> of a service and machines owned by another person delivering the other 
> half of the service, and you want to call both sets of machines taken 
> together "a domain," then it will get confusing to also call the set 
> of machines owned by the first person (even the ones that aren't 
> delivering the service in question) "a domain."
>
> so... i think we have a couple of different concepts here, and we have 
> to name them different things. maybe we could compromise... we could 
> say that a domain is "a collection of hosts that share some common 
> feature" and that a "trust domain" is a collection of hosts with the 
> same trust characteristics (defined as being owned by the same entity 
> or for whom there's a demonstrable privilege implying trust) and a 
> "service domain" is a collection of hosts that together, deliver a 
> service with the special note that a service domain may cross trust 
> domains.
>
> * why are we mentioning hypergrid? they've publicly said they don't 
> want to participate. can we remove mentions of hypergrid from these 
> specs? i have no problem with individuals who participated in 
> hypergrid from participating in vwrap (like i could do anything to 
> prevent it.) but... vwrap IS NOT hypergrid. vwrap is also not Second 
> Life. vwrap is also not OpenSim, OSGrid, reactionGrid, cable beach or 
> realXtend.
>
> i think we need to be very clear about the relationship between this 
> effort and these projects. as i see it, vwrap is an effort sponsored 
> by the IETF which is intended to be useful by all of the projects 
> listed above, but not to "be" them. 
>
> in other words, i have a big problem with using the ostensive 
> definition when describing vwrap service definitions. i don't want to 
> ever have a spec that says (and i paraphrase here) "readers are 
> referred to hypergrid specification 3.71 for how vwrap handles 
> authentication to an asset service and the legacy second life protocol 
> as defined in the beginning of file llagent.cpp from the snowglobe 
> source code."
>
> on the other hand... getting people from all of the projects mentioned 
> above together to define protocol and usage profiles is a bag full of 
> win. but we should be able to define the characteristics of these 
> systems independent of their names. or rather, we should talk about 
> characteristics of protocol and use and then maybe say ("like 
> hypergrid" or "like opensim".)
>
> sorry for going all pedantic on people. just think strongly it would 
> be a train wreck to do this thing that is probably not what david is 
> saying we should do, but scares me nonetheless.
> </comment>
>
> * i think you've got some good ideas WRT trust. however... can we 
> avoid talking about content management IN the protocol? it's a can of 
> worms and IMHO is out of scope and needs A LOT more research. that 
> being said... yes, it's important and we MUST talk about it, but maybe 
> we could add it to a separate document?
>
> On Wed, Feb 24, 2010 at 09:30, David W Levine <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     Dear all:
>
>     _http://www.ietf.org/id/draft-levine-vwrap-deploy-01.txt_
>
>     - David W. Levine
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Morgaine <[email-masked]>
Date: Thu, 25 Feb 2010 15:53:32 +0000

Lawson, the short answer must be that it's next to impossible to prescribe
this, and that it's not our job to prescribe it either.  Each person who
sets up access to a particular subservice modifies their personal trust map
at that point.

It really harks back to David's excellent "The Domain Has No Clothes"
cautionary suggestions that domains do not actually exist but are merely
arbitrary circles drawn around groups of services.  The actual fact of the
matter is that *every service* creates a trust point, so your trust map
looks identical to your services map.

The trust situation in VWRAP is no different to that in SMTP or in DNS in a
real-world rollout, in which you can configure a multiplicity of internal
and external services and service forwarders that together make your MTA
service or nameservice work, but in which "trust" is actually a diffuse
concept that is spread around the various access controls to and from each
subservice on which you depend.  And there is no GLOBAL trust model at all:
your full trust does not extend beyond own resources, drops the instant a
3rd party is involved, and plummets toward zero along a chain of
dependencies

The original "two fuzzy clouds" model of OGP absolutely does not capture
this complex situation, and was appropriate mainly in the simplistic model
where a single virtual world that controls policy is being grown with
regions belonging to 3rd parties that have no say on policy.  The trust can
be partitioned into two blocks in that simple situation, but it is not
generic.  That model is no longer appropriate for VWRAP as a whole, but is
only appropriate in particular narrow deployments, whereas other deployments
(such as the example you discuss) do not fit into that model.  *Most* will
not fit, because most will involve sharing resources and hence be complex.

I think we really have a problem with shedding the shackles of OGP legacy
here.  The two-Domain model was cute and served its purpose as a starting
point, but in a protocol that embraces interop between multiple independent
worlds it is not generally useful, and worse, it is preventing us from
discussing per-service trust control.

I think a line I gave earlier deserves highlighting as a maxim:

*Your trust map looks identical to your services map.
*

There really isn't any escaping this reality, because that's how we
implement multi-part systems with 3rd party dependencies in practice.

Morgaine.

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

On Thu, Feb 25, 2010 at 7:14 AM, Lawson English <[email-masked]> wrote:

> respect to services. A client plugin might provide a vwrap service only to a
> client via a localhost/loopback mechanism, or it may be a proxy to a central
> service or it may be a proxy to a p2p network of services. Where does
> administrative authority lie in this scenario? Does it pertain? Who decides?
> etc...
>
> lawson
>
>
>
>> given last week's conversation about "second life-like" vs. "vwrap-like" as
>> a descriptor, shouldn't we avoid such things for fear of people thinking
>> that if they're SL-compatible, they're automagically VWRAP-compatible?
>>
>> question : does it make sense to introduce the concept of a "user agent"
>> as the client application that is intended to have direct interaction with
>> the user?  i think it would be good to explain that "clients" or "client
>> agree'd on the list, we use the term "domain" in it's classic meaning: "a
>> domain is a collection of network hosts under the control of a single
>> administrative authority."
>>
>> "administrative authority" as well as the convolution of the terms "domain"
>> and "network host." the existing documents describe a domain in this manner,
>> highlighting an "agent domain" as a domain that includes a user
>> authentication service and a "region domain" as a domain that includes a
>> region object presence service. i'm still not sure why we have to change
>> this.
>>
>> (defined as being owned by the same entity or for whom there's a
>> demonstrable privilege implying trust) and a "service domain" is a
>> * why are we mentioning hypergrid? they've publicly said they don't want
>> to participate. can we remove mentions of hypergrid from these specs? i have
>> no problem with individuals who participated in hypergrid from participating
>> in vwrap (like i could do anything to prevent it.) but... vwrap IS NOT
>> effort and these projects. as i see it, vwrap is an effort sponsored by the
>> IETF which is intended to be useful by all of the projects listed above, but
>> not to "be" them.
>> above together to define protocol and usage profiles is a bag full of win.
>> but we should be able to define the characteristics of these systems
>> independent of their names. or rather, we should talk about characteristics
>> of protocol and use and then maybe say ("like hypergrid" or "like opensim".)
>>
>> On Wed, Feb 24, 2010 at 09:30, David W Levine <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
>>
>>    Dear all:
>>