Subject: [ogpx] Tourist use case

From: Vaughn Deluca <[email-masked]>
Date: Fri, 16 Oct 2009 09:34:02 +0200

The "tourist use case" has been brought up several times, but the concept is
not always used in the same way, and needs to be more precisely defined.

Morgaines original definition of the "Free Worlds Tourist use case" in
http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html
mentions two characteristics:

1. Travel requires no prior arrangement.
2. Your avatar is defined by you, not by the target worlds, and it appears
in those worlds with no prior arrangement.

Point 1 is only dependent the policies of the users AD as well as that of
the destination region. It is not dependent on the protocol, so in principle
solved.

The second point is actually extending the SL use case beyond what is in my
view needed for a basic tourist model (and that is why the post was in the
mmox list).  In my view  a basic tourist use case has two main
characteristics:

1.  Travel requires no prior arrangement.
        2.  Agent domains can use external asset services

Point 2 requires that assets services expose an interface (in the current
ogp description of the AD that is not the case).

Note that this models does *not* assumes that all assets in a services
should be useable by the agent in all domains, but only that an interface is
available so an asset service in one domain can be contacted by another AD.

I think exposing the asset service interface directly is essential for
meaningful interop.  I think it would benefit the discussion if some
diagrams were added to
http://wiki.secondlife.com/wiki/Structural_Designand/or to the VWRAP
wiki to document this possibility.

-Vaughn

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Fri, 16 Oct 2009 01:16:34 -0700

i had assumed that the "tourist model" also implied that the client
assumes no transitive trust on behalf of the agent domain, or includes
the agent domain as part of a client implementation.

also. we should tighten up the language. i would argue that from the
client's perspective, teleporting between Sim 1 and Sim 2 requires no
prior arrangement (for the client.) it does, however, require the
agent domain to trust both sims.

maybe we could define the various models in terms of who trusts whom
and how service endpoint addresses are resolved?

so the "second life" model [1] would essentially be that the client
and the agent domain trust each other, and the agent domain and all of
the region domains trust each other. service endpoints for agent
services are given to the client by the agent domain, while region
service are given to the client by the agent domain or the region
domain.

in the "tourist model" you would have no trust, and the client is
responsible for resolving the address of all services.

in the "cable beach" model, you have the same trust as the "second
life" model, but you bring the asset service into it's own domain
which is explicitly trusted by the agent domain, the region domains
and the client. asset service endpoints are resolved by the client.

-cheers
-meadhbh

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

On Fri, Oct 16, 2009 at 00:34, Vaughn Deluca <[email-masked]> wrote:
> diagrams were added to http://wiki.secondlife.com/wiki/Structural_Design
> and/or to the VWRAP wiki to document this possibility.
> -Vaughn
> _______________________________________________
> ogpx mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Fri, 16 Oct 2009 01:16:59 -0700

also. just a show of hands. who's planning on implementing the tourist model?

---

From: Morgaine <[email-masked]>
Date: Fri, 16 Oct 2009 09:51:39 +0100

On Fri, Oct 16, 2009 at 9:16 AM, Infinity Linden (Meadhbh Hamrick) <
[email-masked]> wrote:

also. just a show of hands. who's planning on implementing the tourist
> model?

Almost everybody who will operate virtual worlds, I assume --- that could be
hundreds of thousands of world operators, if not millions, mostly small.  We
certainly can't foretell!  And we can't get them to raise a show of hands
either. :-)

I doubt that it will be common to operate walled gardens once everyone else
is allowing their users to travel freely among the huge diversity of the
metaverse.  It certainly seems like a recipe for failure to deny tourism to
one's residents as a matter of policy, given that tourism is so popular in
the physical world today.

However, this is a policy issue of course, and therefore not something that
VWRAP will dictate.  We merely provide the mechanisms to allow tourism when
desired, not mandate or deny it to any given world operator.

Morgaine.

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

---

From: Vaughn Deluca <[email-masked]>
Date: Fri, 16 Oct 2009 12:16:51 +0200

> the agent domain as part of a client implementation.

Not in the most basic case, Morgaine indeed defined it that way, but i feel
that that is a more complicated use case, and we would benefit from treating
 it separately from the more basic case.

> agent domain to trust both sims.

Yes, but note that the asset service will have its own policy in this model,
so the needed reasons to distrust the destination region are limited. One
obvious reason would be that promises were made to the user to protect the
avatar from exposure to adult material.
But if the user indicates is has no problem, i would think in the majority
of cases the Agent service can trust the region. In the worst case the
avatar would have to be ruthed because the avatar shape can not be exported.

> and how service endpoint addresses are resolved?

Yes, i like that suggestion.

> service are given to the client by the agent domain or the region

Yes, although you specify a bit more trust that is needed in my view because
you do not    allow assets services there own policy, distinct from the
agent service policy, but if you want to make a blanket statement this is
correct.

> responsible for resolving the address of all services.

No, you loose me here. The client *does*  trust the agent service, there is
no difference here with the SL case. The client logs in to an AD, and by
definition trusts that service.
that AD has its own asset service,  just like in the SL case, and the user
can use those assets (as far as the Asset service allows the assets to go
out to other domains).
In addition to using its own asset services the Agent service can use other
Asset services.

> and the client. asset service endpoints are resolved by the client.

I did not yet look in detail at cable beach, but I clearly  should, since
this sounds a lot like what i was thinking of.  However,  I do not think its
needed to put the asset service in its own domain, because by definition a
domain is under a different administration, and in many cases the asset
service will be in some domain. So the critical point is that the asset
service in some domain exposes an interface to the world so its assets *can*
be used, if by anybody if policy allows it.

-Vaughn

---

From: Morgaine <[email-masked]>
Date: Fri, 16 Oct 2009 13:00:12 +0100

Vaughn,

You've correctly represented my MMOX post, thanks!  (
http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html )

I must stress, as you did yourself, that the "*Free Worlds Tourist*" use
case which I described there in MMOX is *different * to the simpler "tourist
use case" which we have been discussing here.  It's great that you're
shining some light into this corner.  Hopefully this will allow us to affix
labels to the various cases to keep our discussions simple yet clear.

Before addressing your actual point, I should first state that I consider it
unfortunate that the "*Free Worlds Tourist*" use case is not considered an
integral part of VWRAP requirements --- this is a practical conclusion on my
part.  On the basis of our discussions so far, I think it would be too much
to expect that a mode of operation offering such a high degree of freedom of
travel and of avatar appearance would achieve rough consensus in the group,
given that its considerable distance from Second Life policies would almost
certainly lead to intense opposition.  This is not a battle I wish to fight.

As a practical matter then, "*Free Worlds Tourist*" as defined above is not
a use case that I am pushing in VWRAP at this time, despite it being
entirely compatible with the SL/Opensim model and hence deserving
inclusion.  I'm simply going to express regret that it is likely to be a
bridge too far on political grounds and leave it at that.  I would wish it
were otherwise.

With that disclaimer, I'll answer your point about our more constrained
"tourist use case" (which perhaps needs a better name), this being a much
easier target but still a very useful one.  I will however answer it in the
immediately following post, because I don't want to get this confused with
the "*Free Worlds Tourist*" case that I described in MMOX.

Morgaine.

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

On Fri, Oct 16, 2009 at 8:34 AM, Vaughn Deluca <[email-masked]>wrote:

> The "tourist use case" has been brought up several times, but the concept
> is not always used in the same way, and needs to be more precisely defined.
>
>  2. Your avatar is defined by you, not by the target worlds, and it
> appears in those worlds with no prior arrangement.
>
> diagrams were added to http://wiki.secondlife.com/wiki/Structural_Designand/or to the VWRAP wiki to document this possibility.
>
> -Vaughn
>

---

From: Vaughn Deluca <[email-masked]>
Date: Fri, 16 Oct 2009 15:35:57 +0200

Well, for what its worth, i would  :),  *Raises hand*

But I see this use case in the first place as a vehicle for our thinking,
and a way to spot implict assumptions that would limit the general usability
of VWRAP.

I think that just based on good design principles a strong argument can be
made for asset services that expose their interface, rather than keeping
them internal to the agent domain.
Especially since there is nothing to prevent a configuration that works
exactly as the current SL use case. So nothing  has to be sacrificed, yet a
much richer set of deployment patterns becomes possible.

-Vaughn

On Fri, Oct 16, 2009 at 10:16 AM, Infinity Linden (Meadhbh Hamrick) <
[email-masked]> wrote:

> is
> appears

---

From: Meadhbh Hamrick <[email-masked]>
Date: Fri, 16 Oct 2009 06:39:49 -0700

On Fri, Oct 16, 2009 at 1:51 AM, Morgaine
<[email-masked]> wrote:
> On Fri, Oct 16, 2009 at 9:16 AM, Infinity Linden (Meadhbh Hamrick)
> <[email-masked]> wrote:
>

you mean you think they're all going to be implementing their own
software? i think that's unrealistic. even with the http servers,
which i think we could agree is slightly less complicated than any
virtual world protocol would be, web site operators use one of a
handful of implementations: (Apache, IIS, WebSTAR?, ...)

> the physical world today.

well. the examples of large virtual worlds that exist today are, as
you call them, walled gardens.

> desired, not mandate or deny it to any given world operator.

i think it _is_ definitely important. we've set dates for the
publication of standard documentations, and i think it's unrealistic
to say that we are going to develop a standard that is infinitely
flexible. we will need to focus on a small collection of deployment
models. again, i have no problem including models that _will_ actually
be used. i'm just not sure it behooves us to spend a fair amount of
time ensuring our protocol flows work in deployment models that no one
is currently planning on deploying.

there's very clearly interest from linden for the "second life" [1]
deployment model; intel has show a clear interest in the "cable beach"
deployment model; OpenSim's UGAIM/Grid Mode and standalone deployment
models. i'm just curious who is going to be coding software for the
"tourist model."

-cheers.
-meadhbh/infinity

---

From: Meadhbh Hamrick <[email-masked]>
Date: Fri, 16 Oct 2009 06:44:11 -0700

but didn't we say that we were going to focus on "second life-like"
worlds in this WG? isn't that why it was formed? shouldn't the tourist
model be an effort of the MMOX group? i thought that was the reason we
kept the MMOX mailing list up, so work could continue on that type of
virtual world.

-meadhbh/infinity

On Fri, Oct 16, 2009 at 5:00 AM, Morgaine
<[email-masked]> wrote:
> I must stress, as you did yourself, that the "Free Worlds Tourist" use case
> which I described there in MMOX is different  to the simpler "tourist use
> case" which we have been discussing here.  It's great that you're shining
> some light into this corner.  Hopefully this will allow us to affix labels
> to the various cases to keep our discussions simple yet clear.
>
> unfortunate that the "Free Worlds Tourist" use case is not considered an
> As a practical matter then, "Free Worlds Tourist" as defined above is not a
> use case that I am pushing in VWRAP at this time, despite it being entirely
> compatible with the SL/Opensim model and hence deserving inclusion.  I'm
> simply going to express regret that it is likely to be a bridge too far on
> political grounds and leave it at that.  I would wish it were otherwise.
>
> the "Free Worlds Tourist" case that I described in MMOX.
>
>
> Morgaine.
>
>
>
>
>
>> The second point is actually extending the SL use case beyond what is in
>> my view needed for a basic tourist model (and that is why the post was in
>> the mmox list).  In my view  a basic tourist use case has two main
>> characteristics:

---

From: Vaughn Deluca <[email-masked]>
Date: Fri, 16 Oct 2009 16:29:16 +0200

On Fri, Oct 16, 2009 at 3:44 PM, Meadhbh Hamrick
<[email-masked]>wrote:

> worlds in this WG?

I strongly believe the basic  mode *is* "second life like", even much more
so than some of the other use cases considered in Davids layering draft.

Also i do not think this needs to delay us much *at all*, since the basics
idea has  always been part of the deployment pattern considered. Look at the
description of "adding a Organization domain" on the wiki:
http://wiki.secondlife.com/wiki/Multiple_Domains#Adding_a_Organization_Domain
.

The figure legend states:

> [...] The blue dotted line means that an agent can be linked
> to another agent (e.g. the more public agent from the SL Agent domain
> (== Linden Lab's grid)). This can mean the following:
>
> The company agent can access the inventory from the
> company agent domain and from the SL Agent Domain

This is in principle the tourist use case i have been describing!
However, the wiki is not clear about the way to actually implement the
restrictions:

>So what we need here is a list of what should be restrictable
>and a means of how to define it.

My suggestion is to define the restrictions at the level of the services,
completely analogous to the discussion we had about the Region Domain i.e.
All policy is local -but the regions can use a global policy derived from
the domain if they wish to do so).

I therefore argue strongly for a design were Agent service and Asset service
are both expressing policy, and both exposing an interface to the world.
In this way it becomes fairly easy to configure any type of domain
behaviour.

I really see very few problems here, but maybe i am naive  :)

-Vaughn

> isn't that why it was formed? shouldn't the tourist
> http://wiki.secondlife.com/wiki/Structural_Design

---

From: Sean Hennessee <[email-masked]>
Date: Fri, 16 Oct 2009 08:43:58 -0700

> handful of implementations: (Apache, IIS, WebSTAR?, ...)

I think this is completely realistic. With the progress that OpenSim is 
making towards standalone (SL Like) grids, there will very likely be 
services popping up all over the interweb providing standalone virtual 
worlds for free or at a very low cost, much like services today provide 
blog spaces, photo spaces, and a host of other web based services for 
free and for fee. I don't have to host my own Apache web server just to 
have a tumblr.com blog or a flickr.com photo site. The blog and photo 
site of the future will be SL like virtual worlds, (or perhaps more 
accurately, "virtual homes").

> you call them, walled gardens.

This is only because the idea of treating your "virtual home" as its' 
own space that can have "virtual tourists" come and visit is only now 
being implemented in OpenSim with standalones and hypergrids. In the 
past the focus was more on creating a system too much like SL in the 
sense that SL is one huge virtual world. I would assume that "SL Like" 
implies the 3d experience that is SL and not also the hugeness that is SL.

Peace,
Sean

-- 

Sean Hennessee
Central Computing Support
Office of Information Technology
UC Irvine

... . .- -. /  .... . -. -. . ... ... . .

---

From: Joshua Bell <[email-masked]>
Date: Fri, 16 Oct 2009 10:03:33 -0700

On Fri, Oct 16, 2009 at 8:43 AM, Sean Hennessee <[email-masked]> wrote:

> worlds for free or at a very low cost,
>

Before this gets out of hand, let's clarify the meaning of "implement"

There are two distinct definitions in extremely common use on the 'net:

(1) to implement: write the code for something
(2) to implement: configure and deploy code for something

With definition #1, as an example, the Apache Software Foundation is the
only implementer of the apache HTTP server (ignoring any distro/site
customizations for the moment) - those millions of web sites that operate
services using apache are NOT implementers.

Definition #2 is used a lot as well, e.g. "our corporate IT department
implemented Microsoft Exchange Server for our mail and calendar services".
With this definition, ANYONE who rolls out the code (with configuration on
top of it) is considered an implementer.

So far as I can tell, IETF discussions almost exclusively use meaning #1.

With this definition, we would expect a small number of initial implementers
of VWRAP-based software (the usual suspects - OpenSim, Linden Lab, and so
forth), orders of more magnitude more people deploying services based on
that software, and over time more VW providers with independent code bases
adopting the protocol either during their initial design phase or to enable
interop.

My interpretation of this thread is that Infinity is using definition #1,
Sean and Morgaine are using definition #2. Infinity is asking specifically:
"who will write the code that adds support for the protocol to a piece of
software?" not "who will make use of software that implements the protocol?"

---

From: Meadhbh Hamrick <[email-masked]>
Date: Fri, 16 Oct 2009 11:01:46 -0700

> Well, for what its worth, i would  :),  *Raises hand*

cool! code is always welcome. more comments to follow.

> and a way to spot implict assumptions that would limit the general usability

sure. i kinda see the tourist model as being one end of the spectrum
and the standalone sim being the other. once you bracket the two ends
of the design space, you can start working to the middle where you'll
find cable beach and second life.

> them internal to the agent domain.

absolutely! one of the things jhurliman and i have been discussing is
the concept of having a unified access protocol to reference assets in
someone's inventory AND assets that are rezzed in a simulator. having
the asset server expose an API directly would allow third party tools
to interact with and modify assets in one's inventory. obviously we
want to be very careful about this for security reasons, but i think
you could do some very compelling things (like integrate facebook and
your inventory. that way i would be able to rez all those pink
elephants people keep giving me and shoot at them in damage enabled
sims.)

and a use case for exposing the "asset service" on the simulator for
rezzed objects is it would allow them to expose a web interface like
the current http-in function in SL today. that way you could have your
online google docs presentation signal a presenter in world to change
slides so you can more easily do mixed reality presentations.

the decision to expose any or all of an asset service's interfaces to
systems outside the agent or region domains is entirely a policy
matter. i absolutely agree we should design a protocol that COULD
expose everything publicly, though i would suggest that it's unlikely
anyone would ever deploy a service without reasonable access controls.
well. not on the public intarwebz directly.

> much richer set of deployment patterns becomes possible.

agreed.

any dissenting voices?

-meadhbh/infinity

---

From: Meadhbh Hamrick <[email-masked]>
Date: Fri, 16 Oct 2009 11:13:38 -0700

> Well, for what its worth, i would  :),  *Raises hand*

okay. cool. as long as we don't put anything in a normative document
that requires a particular deployment pattern, i think we're good.

knowing that someone who's taken the time to participate in the list
discussion is interested in coding "tourist deployment model" software
is probably good enough justification to include it in the intro doc
(which is non-normative) as an identified use case.

i don't want to speak for david, but i think he would be hip to
defining deployment models as "who trusts whom directly, what domain
services are in, and how does the initiator of protocol get the
address for a service's resources."

david is working on typing up the descriptions of deployment models
for inclusion in the intro document, and since we have a finite amount
of space in the doc (i understand it that the IETF frowns on infinite
length drafts,) i propose we focus on a finite number of deployment
models. as i see it we have four deployment models: SL, OpenSim
Standalone, Cable Beach and Tourist. if we find this list is
insufficient, we can always revisit it later. if we find we've exposed
a new deployment model after the intro draft is published, we can
publish it's details in a subsequent draft / RFC. if the model is
important enough, i'm sure we can negotiate with our Area Director to
have it added to the list of "official" WG deliverables.

the reason i suggest this is we _do_ have a deadline, and we have to
start typing. lemme kick off a discussion of the details of the
deployment models in a different thread.

---

From: Charles Krinke <[email-masked]>
Date: Fri, 16 Oct 2009 12:39:35 -0700 (PDT)

Is it reasonable to consider that in some (or all) of the normal use cases, that when some key element fails in the protocol related to authentication, inventory or the like, that we can consider completing the teleport as a "Tourist" ??

That might simplify debugging this monster we are creating.

Charles

________________________________
From: Vaughn Deluca <[email-masked]>
To: Infinity Linden (Meadhbh Hamrick) <[email-masked]>
Cc: [email-masked]
Sent: Friday, October 16, 2009 3:16:51 AM
Subject: Re: [ogpx] Tourist use case

On Fri, Oct 16, 2009 at 10:16 AM, Infinity Linden (Meadhbh Hamrick) <[email-masked]> wrote:

>the agent domain as part of a client implementation.

Not in the most basic case, Morgaine indeed defined it that way, but i feel that that is a more complicated use case, and we would benefit from treating  it separately from the more basic case.

>agent domain to trust both sims.

Yes, but note that the asset service will have its own policy in this model, so the needed reasons to distrust the destination region are limited. One obvious reason would be that promises were made to the user to protect the avatar from exposure to adult material.
But if the user indicates is has no problem, i would think in the majority of cases the Agent service can trust the region. In the worst case the avatar would have to be ruthed because the avatar shape can not be exported.

>service are given to the client by the agent domain or the region

Yes, although you specify a bit more trust that is needed in my view because you do not    allow assets services there own policy, distinct from the agent service policy, but if you want to make a blanket statement this is correct. 

>responsible for resolving the address of all services.

No, you loose me here. The client *does*  trust the agent service, there is no difference here with the SL case. The client logs in to an AD, and by definition trusts that service.
that AD has its own asset service,  just like in the SL case, and the user can use those assets (as far as the Asset service allows the assets to go out to other domains).
In addition to using its own asset services the Agent service can use other Asset services.
  
>and the client. asset service endpoints are resolved by the client.

I did not yet look in detail at cable beach, but I clearly  should, since this sounds a lot like what i was thinking of.  However,  I do not think its needed to put the asset service in its own domain, because by definition a domain is under a different administration, and in many cases the asset service will be in some domain. So the critical point is that the asset service in some domain exposes an interface to the world so its assets *can* be used, if by anybody if policy allows it.

-Vaughn

---

From: Charles Krinke <[email-masked]>
Date: Fri, 16 Oct 2009 12:44:45 -0700 (PDT)

+1 to Sean on this one. I think he accurately describes some of the ongoing notions happening now.

Charles

________________________________
From: Sean Hennessee <[email-masked]>
To: [email-masked]
Sent: Friday, October 16, 2009 8:43:58 AM
Subject: Re: [ogpx] Tourist use case

> handful of implementations: (Apache, IIS, WebSTAR?, ...)

I think this is completely realistic. With the progress that OpenSim is making towards standalone (SL Like) grids, there will very likely be services popping up all over the interweb providing standalone virtual worlds for free or at a very low cost, much like services today provide blog spaces, photo spaces, and a host of other web based services for free and for fee. I don't have to host my own Apache web server just to have a tumblr.com blog or a flickr.com photo site. The blog and photo site of the future will be SL like virtual worlds, (or perhaps more accurately, "virtual homes").

> you call them, walled gardens.

This is only because the idea of treating your "virtual home" as its' own space that can have "virtual tourists" come and visit is only now being implemented in OpenSim with standalones and hypergrids. In the past the focus was more on creating a system too much like SL in the sense that SL is one huge virtual world. I would assume that "SL Like" implies the 3d experience that is SL and not also the hugeness that is SL.

Peace,
Sean

---

From: Vaughn Deluca <[email-masked]>
Date: Sat, 17 Oct 2009 00:46:52 +0200

On Fri, Oct 16, 2009 at 7:03 PM, Joshua Bell <[email-masked]> wrote:

>>>>  [...]

> software?" not "who will make use of software that implements the protocol?"

*ahum* I was most definitely using  definition #2. Yet, i *can* code, and
given the importance of this aspect, i am certainly willing to assist in
making this use case happen. However, i am not a professional programer, but
just a scientist, coding my own analysis softeware. So i am likely to need a
bit of help from some friends :)

On the other hand, i am convinced that a proper implementation of the SL use
case (this time in the sense of definition  #1) will generate about  all the
code we need for the tourist case. The difference between the SL model and
the tourist model is largely at the policy level.  But when we get down to
the specs, that will become clear soon enough.

Regarding the coding, i think Agent Domain code was written this summer. Is
that available somewhere? i would like to have a look at that, to get a
better feel for the size of the problem.

-Vaughn

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Fri, 16 Oct 2009 15:47:08 -0700

okay. i think we're heading towards nomenclature communication fail.
what you describe below is part of what i call the "Second Life"
deployment pattern. what i'm calling the tourist pattern is that
"trust is managed by the client; services may be deployed in different
domains or all in the same domain; the client decides which URLs to
use for each service it wants to use for service establishment."

maybe we should be asking, what is the aspect of the tourist model
that differentiates it from the others. based on what i _think_ i hear
people saying (david's deployment and layering doc aside,) it sounds
to me that the fundamental aspect of the tourist model is the ability
for the client application to tell the agent domain to rez in a region
at an arbitrary URI and to use credentials given to it by the client
at the time the user requests placement in a region.

this is contrasted to what i'm calling the "second life model" where
the user establishes a credential for use exclusively between the
client and the agent domain. and the agent domain and different region
domains establish some authentication or authorization regime between
themselves that is distinct from the client <-> agent domain
authenticator. when the user wants their avatar moved into a
particular region, the client provides the URI or an arbitrary map
reference to the agent domain. the agent domain then resolves the map
reference to a service URI if one wasn't provided by the client.
assuming that the destination URI resolves to a host inside a region
domain with whom the agent domain has a trust relationship, it begins
the protocol to place the user's avatar in that region. the
destination region authenticates the agent domain and not the user's
avatar before placing it in the region.

what i'm calling the "cable beach model" is that the client tells the
agent domain where it will find it's preferred asset server. this is
different from the "second life model" where the agent domain provides
caps for inventory access after the client has authenticated itself. i
chatted with jhurliman about this, and he seems big on OAuth to be the
carrier of authorization information. the essential difference here is
that an independent authentication to the asset service is required,
but once that's done, you can use OAuth to give asset access to the
AD, the RD or the client. in fact, you could probably just have the
agent domain authenticate OAuth tokens from the domain containing the
asset service. but the essential notion here is that multiple region
domains and multiple agent domains could use the services of the same
external asset service.

and the standalone mode is basically everything is on one box.

discussion?

-cheers
-meadhbh/infinity

On Fri, Oct 16, 2009 at 07:29, Vaughn Deluca <[email-masked]> wrote:
>
>
> On Fri, Oct 16, 2009 at 3:44 PM, Meadhbh Hamrick <[email-masked]>
> wrote:
>>
> http://wiki.secondlife.com/wiki/Multiple_Domains#Adding_a_Organization_Domain.

---

From: Lawson English <[email-masked]>
Date: Fri, 16 Oct 2009 16:38:27 -0700

> kept the MMOX mailing list up, so work could continue on that type of

It seems to me that the MOST touristy mode we will ever see is the 
free-for-all from the original OGP test where
simple TP and naught else was supported.

Will all worlds be willing to support that one? Obviously not (e.g 
firewalled corporate site), but I think many will, including LL on the PG
section of its main grid.

Lawson

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Fri, 16 Oct 2009 16:39:21 -0700

> bit of help from some friends :)

okay. my bad. i was just kinda shocked by what i perceived as an
assertion by morgaine that there was going to be a 1:1 relation
between developers and users. i'll let her make that case if that's
what she really believes, but will assume she interpreted my question
to be "who's interested in deploying services that implement protocol
transactions in accord with the tourist model?" rather than "who's
interested in implementing the tourist model in code?" as it was
intended to mean.

i think one of the most important outcomes of this process will be an
open standard that anyone can implement without royalty payments,
including FLOSS developers. an operator like linden cannot be all
things to all people and implement every feature. but maybe in the
future we'll be able to point people to OpenSim and say "we can't
implement the feature you want, but maybe you can implement it
yourself using this nice codebase the community has put together for
you." and then, "hey look over there! there's an archipelago of
tourist sites or here's our more locked down world. maybe it makes
sense for you to deploy here."

i think if we can do that, we will have won. (and not just SL or
OpenSim or realXtend or whomever, but all of us.)

---

From: Vaughn Deluca <[email-masked]>
Date: Sun, 18 Oct 2009 01:10:25 +0200

> simple TP and naught else was supported.

I find that a deeply depressing thought.  I would *really* hope that at
least  transfer of free to copy assets will also be possible.

---

From: Vaughn Deluca <[email-masked]>
Date: Sun, 18 Oct 2009 01:12:02 +0200

> okay. i think we're heading towards nomenclature communication fail.

Wrong, we were right in the middle of it!

> use for each service it wants to use for service establishment."

In what I called the tourist pattern trust is managed by the services in the
agent domain (or maybe OAuth); services may be deployed in different domains
or all in the same domain; The agent service keeps track of all asset
servers the agent uses; The agent service policy  determines which URLs can
actually be used for TP, Asset servers policies determines what assets can
actually be rezzed in a particular destination region. Agent domain is just
as  Region domain an administrative term, and its main purpose is that of a
 policy server for domain wide policy.

> at the time the user requests placement in a region.

Hmm, the credentials could be managed by the agent service after login of
the user, but might come from a third party service.
Rezzing assets is possible if the asset server is willing to let go of that
particular asset and sent it to the destination region. The key feature of
this model is the distributed way assets are managed, and the fact that not
the TP is the key event (in most cases there is no reason to prevent a TP of
a ruthed tourist avatar) but the transfer of assets based on asset server
policy (and ultimately on characteristics of the asset, i.e. its license)

I need to think about the actual  control flows, look at cable beach in more
detail and study the available documentation more.  Things turn out to be
more complicated than I envisioned.

-Vaughn

> >> > simply going to express regret that it is likely to be a bridge too
> far
> >> > on
> >> > easier target but still a very useful one.  I will however answer it
> in
> >> > the
> >> > On Fri, Oct 16, 2009 at 8:34 AM, Vaughn Deluca <
> [email-masked]>
> >> > wrote:
> >> >>
> >> >> Point 1 is only dependent the policies of the users AD as well as
> that
> >> >> of
> >> >> my view needed for a basic tourist model (and that is why the post
> was
> >> >> in
> >> >> available so an asset service in one domain can be contacted by
> another
> >> >> AD.

---

From: Vaughn Deluca <[email-masked]>
Date: Sun, 18 Oct 2009 01:13:57 +0200

On Sat, Oct 17, 2009 at 3:32 AM, Suzy Deffeyes <[email-masked]> wrote:

> We open sourced an implementation of agent domain recently.
>  http://forge.opensimulator.org/gf/project/ogp/
>
> Also note that OGP functionality is included in the snowglobe viewer. It
> was recently added as jira SNOW-215.
>
> Lastly, these two implementation tidbits have started adding extensions to
> the original OGP spec in the area of inventory and wearables.
>

Great!  *starts reading code*

> Suzy Deffeyes
> Pixel Gausman
> IBM

---

From: Lawson English <[email-masked]>
Date: Sun, 18 Oct 2009 07:12:06 -0700

Vaughn Deluca wrote:
>
>
> On Sat, Oct 17, 2009 at 1:38 AM, Lawson English <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Meadhbh Hamrick wrote:
>
> I find that a deeply depressing thought.  I would *really* hope that 
> at least  transfer of free to copy assets will also be possible. 
>
>

Well, me too. I was merely pointing out that "tourism" was built into 
the system from the start, so to suggest that tourism was MMOX
rather than VRAM was a false dichotomy. We already have an example of 
the "most touristy" mode possible and things will be built
*on top of* it. The idea that few vendors would support it misses the 
fact that it is the _de facto_ model that everything else is built on.

Now, tourism with non-SL-compatible worlds is certainly an MMOX issue, 
but tourism is inherent in ANY interop scenario, period.

It's just the state of NULL trust. Whether NULL trust is allowed is a 
policy issue, but its inherent in the nature of the system.

Lawson

---

From: Vaughn Deluca <[email-masked]>
Date: Sun, 18 Oct 2009 17:31:37 +0200

On Sun, Oct 18, 2009 at 4:12 PM, Lawson English <[email-masked]> wrote:

> Vaughn Deluca wrote:
>
>>
>>
>> On Sat, Oct 17, 2009 at 1:38 AM, Lawson English <[email-masked]<mailto:
>> [email-masked]>> wrote:
>>
>>    Meadhbh Hamrick wrote:
>>
> Well, me too. I was merely pointing out that "tourism" was built into the
> system from the start, so to suggest that tourism was MMOX
> rather than VRAM was a false dichotomy. We already have an example of the
> "most touristy" mode possible and things will be built
> *on top of* it. The idea that few vendors would support it misses the fact
> that it is the _de facto_ model that everything else is built on.
>
> Now, tourism with non-SL-compatible worlds is certainly an MMOX issue, but
> tourism is inherent in ANY interop scenario, period.
>
Mmmm, yes, "tourist" was badly chosen. But somehow i got the impression we
were heading towards a system were assets would only be available from the
Asset server of the world  currently visited, so you would need to either
duplicate assets to different servers to have access, or just live with the
fact that in each visited world you have a different set of assets, like
what we have now when going to OSGrid.  Seems I was a bit too pessimistic.
Anyhow, i realised i need read some more to make a meaningful contribution
here. Also without the new versions of the draft up its hard to discuss
anything. So I will take a pause and study  the backgound documents in some
 more dept.

-Vaughn

---

From: David W Levine <[email-masked]>
Date: Sun, 18 Oct 2009 13:26:19 -0400

Keep in mind the model separates mechanism from policy. The mechanism will 
allow it, how people define policies will determine how easily assets flow 
across the extended grid. My personal guess is that we will end up with 
some sets of assets which flow very broadly across a lot of grids, but it 
will take time for this to settle down. I also equally expect that we will 
see lots of  clusters of walled gardens by policy, for various reasons, 
and that assets from these gardens will live within them. My goal for the 
specifications  to support this range of use cases, and to focus on the 
mechanisms, and keep debates as to which policy is appropriate off this 
list. (Enable the policy choices, and let the real world determine which 
policies are successful)

- David
~ Zha 

Vaughn Deluca <[email-masked]> 
Sent by: [email-masked]
10/18/2009 11:31 AM

To
[email-masked]
cc
Meadhbh Hamrick <[email-masked]>, [email-masked]
Subject
Re: [ogpx] Tourist use case

   Meadhbh Hamrick wrote:

       but didn't we say that we were going to focus on "second
       life-like"
       worlds in this WG? isn't that why it was formed? shouldn't the
       tourist
       model be an effort of the MMOX group? i thought that was the
       reason we
       kept the MMOX mailing list up, so work could continue on that
       type of
       virtual world.

       -meadhbh/infinity

Lawson
Mmmm, yes, "tourist" was badly chosen. But somehow i got the impression we 
were heading towards a system were assets would only be available from the 
Asset server of the world  currently visited, so you would need to either 
duplicate assets to different servers to have access, or just live with 
the fact that in each visited world you have a different set of assets, 
like what we have now when going to OSGrid.  Seems I was a bit too 
pessimistic.

Anyhow, i realised i need read some more to make a meaningful contribution 
here. Also without the new versions of the draft up its hard to discuss 
anything. So I will take a pause and study  the backgound documents in 
some  more dept. 

-Vaughn

---

From: Vaughn Deluca <[email-masked]>
Date: Sun, 18 Oct 2009 20:41:44 +0200

I could not agree more!

On Sun, Oct 18, 2009 at 7:26 PM, David W Levine <[email-masked]> wrote:

> across the extended grid. My personal guess is that we will end up with some
> sets of assets which flow very broadly across a lot of grids, but it will
> take time for this to settle down. I also equally expect that we will see
> lots of  clusters of walled gardens by policy, for various reasons, and that
> assets from these gardens will live within them. My goal for the
>  *Vaughn Deluca <[email-masked]>*
> [email-masked]  cc
> On Sun, Oct 18, 2009 at 4:12 PM, Lawson English <[email-masked]*<[email-masked]>>
> wrote:
> Vaughn Deluca wrote:
>
>
>
> On Sat, Oct 17, 2009 at 1:38 AM, Lawson English <[email-masked]*<[email-masked]><mailto:
> [email-masked]* <[email-masked]>>> wrote:
>
>    Meadhbh Hamrick wrote:
>

---

From: Morgaine <[email-masked]>
Date: Mon, 19 Oct 2009 11:56:34 +0100

On Sat, Oct 17, 2009 at 12:39 AM, Infinity Linden (Meadhbh Hamrick) <
[email-masked]> wrote:

> what she really believes,
>

Is there a need for this kind of wording, fabrication, and targetting of
individuals?

We have a lot of work to do.  Please let's try to focus on the work, not on
people.

Morgaine.

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

---

From: Morgaine <[email-masked]>
Date: Mon, 19 Oct 2009 12:00:57 +0100

+1 Sean!

I've really been enthused and heartened by the rapid progress in Opensim on
such a wide variety of fronts, including multiple forms of interop.

Anyone who's been keeping a finger on the pulse of what's happening in
virtual worlds today can see the pent-up desire for having your own virtual
worlds and allowing good interop between them.  Undoubtedly there is a need
for restrictive worlds as well (often required for business or education),
and here we are of course embracing their needs as much as the needs of
people who wish to enjoy a high degree of inter-world travel.

No party is being excluded in VWRAP.  By focussing on the services that can
be put together in a variety of useful deployment patterns, anyone can
configure a world to their own specification and interoperate with other
worlds in accordance with their own chosen policies.  This includes both
ends of the spectrum, and points between.

As you say, the tourist model is completely realistic, and indeed it is
demanded widely.

Morgaine.

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

On Fri, Oct 16, 2009 at 4:43 PM, Sean Hennessee <[email-masked]> wrote:

> worlds for free or at a very low cost, much like services today provide blog
> spaces, photo spaces, and a host of other web based services for free and
> for fee. I don't have to host my own Apache web server just to have a
> tumblr.com blog or a flickr.com photo site. The blog and photo site of the
> future will be SL like virtual worlds, (or perhaps more accurately, "virtual
> homes").
>
> This is only because the idea of treating your "virtual home" as its' own
> space that can have "virtual tourists" come and visit is only now being
> implemented in OpenSim with standalones and hypergrids. In the past the
> focus was more on creating a system too much like SL in the sense that SL is
> one huge virtual world. I would assume that "SL Like" implies the 3d
> experience that is SL and not also the hugeness that is SL.
>
> Peace,
> Sean
>
>

---

From: Morgaine <[email-masked]>
Date: Mon, 19 Oct 2009 12:04:42 +0100

On Sat, Oct 17, 2009 at 12:38 AM, Lawson English <[email-masked]> wrote:

> free-for-all from the original OGP test where simple TP and naught else was
> supported.
>

There was no "free-for-all" interop in the original OGP test:  there was
merely TP from an SL grid to several separately-administered sims, with no
framework in place for such sims to express their independent policies, nor
any design for such a framework.  This was unable to support a tourism model
at all since that requires DDP otherwise travellers from multiple worlds
having distinct policies can't meet up in a common tourist resort.  It was
very far indeed from a free-for-all.  In fact it was much more like a plan
for region assimilation by an advancing empire. ;-)  All it could ever do is
build walled gardens.

Your comment also needs to be examined in another light.  "The MOST touristy
mode we will ever see" *from whom*?  Your words seem to presuppose that only
the deployments by the current majority provider are relevant.

It's important not to confuse what an individual world provider such as LL
will do, and what the whole set of deployers of the protocol will do.  If we
are successful in specifying VWRAP services flexibly as envisaged by David,
we can expect all the possible deployment patterns to be exercised to
different degrees across the breadth of the Internet by many different
providers and many individuals.

More specifically, it is reasonable to assume that the Opensim developers,
deployers and users who are present in the workgroup are here because they
believe that the protocol can be designed in a manner that is useful to
their intended interop and world models.  They're already working on various
kinds of open interop model, with or without VWRAP, so the need to support
tourism flexibly is not just a theory.

If we do a good job and VWRAP becomes an effective means of implementing the
kind of interop that the very broad Opensim-based community finds useful,
then there is every likelihood that the high-tourism deployments will become
very popular indeed, *in that community*.  That's my answer to the *from
whom* question.

People want to travel to far-off places, in virtual worlds as much as in the
physical world.  This desire is fueled by world *diversity*, not by seeing
more of the same thing within one's own world alone.  We can reasonably
expect this to make tourism between independent worlds hugely attractive,
even exciting, and hence popular.

Morgaine.

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

---

From: Morgaine <[email-masked]>
Date: Mon, 19 Oct 2009 12:36:59 +0100

I agree with this, so I have dealt separately in an earlier email with that
more ambitious use case (which I'm leaving to MMOX), so that we can pursue
this simpler tourist use case here.  I think you're very right to identify
it as distinct.

meaningful interop.

I agree entirely with your suggestion that the asset service interfaces be
exposed.  Indeed, I believed this to be implicit in David's breakdown of
services anyway, as a natural consequence of service decoupling, but it's
good that you're making it explicit.

We looked at one aspect of the issue a few weeks ago with Joshua when we
examined what would happen when world W1's agent A1 was in W2's RD2.  For
the visual mashup of assets on the user's screen to work, the agent would
need to have access to at least two asset services simultaneously, which
gave us a hint of what's to come.

It's this exposing of services (asset services in particular) that is going
to provide the *Destination Determines [Destination] Policy* principle which
allows tourism.  It never existed in the original OGP, because there was no
mechanism by which regions nor RDs could express their own policy, so all
policy expression was through the so-called trust agreements enforced at the
AD which gaves access to the seed caps.  That essentially boiled down to
creating ever-expanding walled garden empires that could never interoperate
except through nil-trust.

In contrast, now we're solidly on the road to allowing RDs to determine
their own policies through their own services, so it's a very different
proposition.  As David has described, once you have multiple service
providers over which individual RDs have policy control, any attempt at
making policy non-local is not likely to bear much fruit.  That's the key
ingredient that allows DD[D]P, and hence tourism.

And for that, the service interfaces need to be exposed.  So +1. :-)

Morgaine.

---

From: Lawson English <[email-masked]>
Date: Mon, 19 Oct 2009 10:51:47 -0700

Morgaine wrote:
> On Sat, Oct 17, 2009 at 12:38 AM, Lawson English <[email-masked] 
>     free-for-all from the original OGP test where simple TP and naught
>     else was supported.
>
>
>
> There was no "free-for-all" interop in the original OGP test:  there 
> was merely TP from an SL grid to several separately-administered sims, 
> with no framework in place for such sims to express their independent 
> policies, nor any design for such a framework.  This was unable to 
> support a tourism model at all since that requires DDP otherwise 
> travellers from multiple worlds having distinct policies can't meet up 
> in a common tourist resort.  It was very far indeed from a 
> free-for-all.  In fact it was much more like a plan for region 
> assimilation by an advancing empire. ;-)  All it could ever do is 
> build walled gardens.

Since the test required no agreements of any kind, but merely announcing 
the relative position of the sim on the grid to avoid technical issues 
with overlapping coordinates, I'm not sure how you can say that it was 
NOT a free-for-all. With no room for policy implementation, there's no 
policy period.
>
> Your comment also needs to be examined in another light.  "The MOST 
> touristy mode we will ever see" /*from whom*/?  Your words seem to 
> presuppose that only the deployments by the current majority provider 
> are relevant.

I would HOPE that any tourism mode that is implemented in the future by 
some provider for interop between two or more separate services will 
provide more than a default avatar with no asset sharing, no policy 
agreements, no appearance sharing, no nuttin'. Are you implying that we 
will see LESS features in a future service from someone or another? How 
low can we go? Tourism mode is, in my mind, the lowest common 
denominator of services that a minimal VWAP protocol will support.

>
> It's important not to confuse what an individual world provider such 
> as LL will do, and what the whole set of deployers of the protocol 
> will do.  If we are successful in specifying VWRAP services flexibly 
> as envisaged by David, we can expect all the possible deployment 
> patterns to be exercised to different degrees across the breadth of 
> the Internet by many different providers and many individuals.

Well, no policy agreement, no money, no assets, no individual 
appearance, etc., seems like a pretty low bar to shoot for. I hope that 
the most minimal VWRAP definition will include at least as much as the 
original OGP test provided.

Lawson (Saijanai ISL)

---

From: Morgaine <[email-masked]>
Date: Mon, 19 Oct 2009 20:33:30 +0100

On Mon, Oct 19, 2009 at 6:51 PM, Lawson English <[email-masked]> wrote:

> the relative position of the sim on the grid to avoid technical issues with
> overlapping coordinates, I'm not sure how you can say that it was NOT a
> free-for-all. With no room for policy implementation, there's no policy
> period.
>

Policy was established by the AD controlling the authentication and being
the only source of seed caps.  No interop was possible *except* that allowed
by the AD.  That's a "free-for-all" where only one side has any say, which
is quite the opposite of the usual meaning of "free-for-all". :-)

> some provider for interop between two or more separate services will provide
> *more* than a default avatar with no asset sharing, no policy agreements,
> no appearance sharing, no nuttin'. Are you implying that we will see LESS
> features in a future service from someone or another? How low can we go?
> Tourism mode is, in my mind, the lowest common denominator of services that
> a minimal VWAP protocol will support.

That's confusing the word "more" as meaning "implementing services that were
missing in the OGP trial" with the word "more" as meaning "allowing the RD
to determine its own region policy".  The first is a given.  The second was
not in the OGP design at all.

With the old OGP model in which the only source of seed caps was the AD, it
would have changed nothing if the RD had provided additional services,
because the agent would have had no access to them.  The AD's policy control
was *total*.  As such, no foreign tourism would have been possible at all,
only travel within one's own world of regions authenticated by the same AD.
This is because the regions in the intersection between N such AD-controlled
worlds is the empty set, except under nil trust.

That was very different to the inter-world tourism that we've been talking
about here for several weeks now, in which RDs are in effect sections of
autonomous worlds each with their own region policies determined by their
own asset services and other services which they proxy from their own AD.

>
> Well, no policy agreement, no money, no assets, no individual appearance,
> etc., seems like a pretty low bar to shoot for. I hope that the most minimal
> VWRAP definition will include at least as much as the original OGP test
> provided.
>

I think that we're aiming for a bit more than that. ;-)

Morgaine.

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

On Mon, Oct 19, 2009 at 6:51 PM, Lawson English <[email-masked]> wrote:

> Morgaine wrote:
>
>> On Sat, Oct 17, 2009 at 12:38 AM, Lawson English <[email-masked]<mailto:
> the relative position of the sim on the grid to avoid technical issues with
> overlapping coordinates, I'm not sure how you can say that it was NOT a
> free-for-all. With no room for policy implementation, there's no policy
> period.
>
>>
>> presuppose that only the deployments by the current majority provider are
>> relevant.
>>
>
> some provider for interop between two or more separate services will provide
> more than a default avatar with no asset sharing, no policy agreements, no
> appearance sharing, no nuttin'. Are you implying that we will see LESS
> features in a future service from someone or another? How low can we go?
> Tourism mode is, in my mind, the lowest common denominator of services that
> a minimal VWAP protocol will support.
>
>
> Well, no policy agreement, no money, no assets, no individual appearance,
> etc., seems like a pretty low bar to shoot for. I hope that the most minimal
> VWRAP definition will include at least as much as the original OGP test
> provided.
>
>
>
>
> Lawson (Saijanai ISL)
>

---

From: Carlo Wood <[email-masked]>
Date: Thu, 29 Oct 2009 14:43:53 +0100

On Fri, Oct 16, 2009 at 03:35:57PM +0200, Vaughn Deluca wrote:
> Especially since there is nothing to prevent a configuration that works exactly
> as the current SL use case. So nothing  has to be sacrificed, yet a much richer
> set of deployment patterns becomes possible.
> 
> -Vaughn 

+1

I think that as soon as a user runs into "sorry, can't do-- because we don't
trust this or that service", they will be ANNOYED, and nothing else.

As a result, people will find the path of least resistance where apparently
two demands can be conflicting:

1) Being able to TP to that other destination
2) Being able to access ones inventory

Personally I feel not very confident that the combination of both is
going to work anywhere satisfactory given the intentions shown so far;
therefore I think it will be very important to have the possibility of
separate asset services.

Suddenly I see a glimpse of light: why can't it be possible to run
my OWN (personal!) inventory? Surely nobody is going to forbid me to
put FULL-PERM stuff in it? And even more surely nobody is going to
stop others from accessing my inventory when I use it (ie, to see
my attachments; or to see what I just rezzed).

I'd be very happy with my own personal inventory, even if on some
worlds they only allow me to put 'full perm' stuff in it. At least
I'll know what I can use everywhere: if I can put it in my inventory,
I will have it at my disposal everywhere.

Dream or not, this is definitely not going to happen if VWRAP
demands that the asset service is part of the agent service.

-- 
Carlo Wood <[email-masked]>

---

From: Morgaine <[email-masked]>
Date: Fri, 30 Oct 2009 07:29:44 +0000

> therefore I think it will be very important to have the possibility of

Very true.  This is of course why we headed down the path of giving RDs
control over their own region policies, reinforced by David's observation
that ADs could not impose non-local policies even if they wished.  ADs won't
exercise control over region policies anyway but stick to agent policies
alone, according to previous discussions, so the assets present in a region
are of no concern to the AD at all.

This directly implies that asset services must be quite separate from ADs.
Although we haven't spelled it out, clients must have access to an arbitrary
list of asset services, because as agents travel around the VWRAP-compatible
metaverse, the regions they visit will contain objects from an arbitrary
number of asset service providers.

*Without access to these asset services, the visited regions would not be
visualizable at all.  And denying visualization is no business of the AD's.
* This makes it clear that access to asset services should not be mediated
by the AD at all --- the AD's role should be limited to allowing or denying
entrance to a region.  Once inside a region, it is the region that offers
capabilities for access to the asset services of assets within the region.

> I will have it at my disposal everywhere.

I think it's quite clear that SL's single-world / single asset service /
single inventory model is not appropriate to the needs of VWRAP.  As you
suggest, an agent's inventory needs have very little to do with the asset
service of the single world in which the agent is registered.  It's very
difficult to extrapolate from that monolithic model to a multi-world
setting.

> demands that the asset service is part of the agent service.

Indeed, but fortunately it hasn't been proposed that asset services be part
of the agent service in VWRAP.  The legacy SL model of assets and
inventories clearly doesn't apply in our extended scenarios, and the OGP
documents never covered asset services at all, so we're defining the asset
services and inventory model of VWRAP as we speak. :-)

Morgaine.

On Thu, Oct 29, 2009 at 1:43 PM, Carlo Wood <[email-masked]> wrote:

> exactly

---

From: Joshua Bell <[email-masked]>
Date: Fri, 30 Oct 2009 10:23:43 -0700

On Fri, Oct 30, 2009 at 12:29 AM, Morgaine
<[email-masked]>wrote:

>  * This makes it clear that access to asset services should not be
> mediated by the AD at all --- the AD's role should be limited to allowing or
> denying entrance to a region.  Once inside a region, it is the region that
> offers capabilities for access to the asset services of assets within the
> region.
>

After reading this a few times, I agree with the high level sentiment - but
be careful regarding the terminology, as specific wording tripped me up the
first few times through.

In the SL protocol today, clients only ever communicate with a region. It's
the region's responsibility to provide the data for what the agent sees.
This occurs both for items that would be considered aspects of the region
(chairs, buildings, trees, waterfalls) and "transient" items (other avatars
with attachments). The region exposes a data source (today, the
byte-efficient but fairly grotesque family of UDP packets) of the
description of objects (prims, textures, sourds, animations, ...) which the
client consumes.

Behind the scenes, the region may be pulling those object definitions from
an asset service, or they may be present in the region definition itself.
The client is unaware of this - it's hidden behind the services the region
exposes.

Now for the terminology bit: we can call the services the region is exposing
"asset services" but these could be quite distinct from the sorts of things
present in an agent's inventory. One phrase that's potentially confusing is
"the regions they visit will contain objects from an arbitrary number of
asset service providers" - while I agree with the high-level interpretation
of that statement, I think it paints a picture that as you're exploring a
region, the client is *necessarily* going off and making connections to a
variety of asset servers to fetch the data.

I don't think VWRAP should *preclude* that (I imagine it's only sensible for
things like textures to be referenced by URLs which could be coming off of
any old place), but my initial reading of your text was that the client
would necessarily be fetching things from external asset services. For
example, if I buy a chair on FooGrid and drop it on BarGrid, when you visit
BarGrid you're having to ask FooGrid's asset service for the description.
Again, I think that's *conceivable*, but shouldn't be *necessary*. (And I
don't think you're claiming that - but my first read-through came away with
that impression.)

And, of course, one can conceive of clients that implement a policy of not
trusting FooGrid for anything and wouldn't make such a connection - FooGrid
could be blacklisted by some large search company, my ISP, or perhaps my AD.

> services and inventory model of VWRAP as we speak. :-)

Be careful about blurring the use of "asset services" between "stuff in
regions" and "stuff I have". I think there is a big intersection - and may
have the same characteristics and/or protocols, but I also think they are
are distinct. I would guess that there will be asset services associated
with both agents and regions - off the top of my head:

Uses of an agent-associated "asset" service:
* content to client app (inspect your inventory)
* content from client app (upload/import to inventory)
* content to region (rez something)
* content from region (buy/take something)
* content to agent (give something)
* content from agent (receive something)

Uses of an region-associated "asset" service:
* content to client app (see the world)
* content from client app (upload/import to region)
* content to region (during teleport/region crossing)
* content from region (during teleport/region crossing)
* content to agent (buy/take something)
* content from agent (rez something)

I'm using "asset" in quotes since that term may be overloaded. "Content"
might be a better term.

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Fri, 30 Oct 2009 10:33:04 -0700

though.. should probably point out. that code implements the OGP auth
spec from early summer '08, not the one that was published earlier
this year. however... they are pretty similar.
--
   infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
         http://wiki.secondlife.com/wiki/User:Infinity_Linden

---

From: Morgaine <[email-masked]>
Date: Sat, 31 Oct 2009 13:53:07 +0000

Great post Joshua, leading to many key issues!

On Fri, Oct 30, 2009 at 5:23 PM, Joshua Bell <[email-masked]> wrote:

> On Fri, Oct 30, 2009 at 12:29 AM, Morgaine <[email-masked]
> > wrote:
>
>>
>> This directly implies that asset services must be quite separate from
>> ADs.  Although we haven't spelled it out, clients must have access to an
>> arbitrary list of asset services, because as agents travel around the
>> VWRAP-compatible metaverse, the regions they visit will contain objects from
>> an arbitrary number of asset service providers.
>>

My writing style tends to be preoccupied with precision, and readability can
suffer, sorry. ;-)

I did however mean exactly what I wrote, and I chose the term
*mediate*deliberately for its breadth of coverage, because I wanted to
convey
strongly that the AD should have nothing whatsoever to do with allowing or
denying access to *specific* asset services relevant to a region, directly
or indirectly, in any manner at all other than by permitting entry in the
first place.

This may seem like major anathema from a centrally-controlled, single asset
service perspective.  However, it falls out naturally when you consider:

   - David's point about no AD policy control over remote services,
   - Carlo's point about users having control over their own inventory,
   - the quite widespread support for an agent/region split in policy
   controls,
   - John's support for strongly decoupled asset services as in Cable Beach,
   - my point about not breaking region visualization once in a region.

All of these points shout loudly that considering assets and inventory to be
part of the agent service is badly structured because it creates unnecessary
constraints.  It seem far more appropriate to consider asset services as
independent, so that whoever needs them can gain access to them if the
services permit it.  (This doesn't imply a free-for-all, to be clear, but
only that there should be no *a priori* barriers *by design*, such as would
occur if ADs were given exclusive power to grant caps for all asset
services.)

Instead, if an AD provides an inventory service (a policy choice), then this
is just one contributor to the client's inventory.  [*I'll cover this
explicitly further below.*]

> The client is unaware of this - it's hidden behind the services the region

That's fine. :-)   Right from the earliest days of the AWG, it has many
times been said that the proxying performed by SL sims is merely a design
choice or implementation detail, and that other implementations of the same
protocols could choose to proxy fewer services, or none at all.

This is actually a very important issue for the protocol, because proxying
has a major impact on the scalability and availability of a sim, and also on
the scalability and availability of any services that it proxies, so
flexibility of choice is crucial.

If services are decoupled then such flexibility can be achieved with nothing
more than appropriate configuration of service endpoint locations to permit
the whole gamut of proxying choices to be expressed, including no proxying.
And REST was chosen among other reasons for its flexibility in allocation of
endpoints, so we already have the means to do this. :-)

> Now for the terminology bit: we can call the services the region is
> exposing "asset services" but these could be quite distinct from the sorts
> of things present in an agent's inventory. One phrase that's potentially
> confusing is "the regions they visit will contain objects from an arbitrary
> number of asset service providers" - while I agree with the high-level
> interpretation of that statement, I think it paints a picture that as you're
> exploring a region, the client is *necessarily* going off and making
> connections to a variety of asset servers to fetch the data.
>
> I don't think VWRAP should *preclude* that (I imagine it's only sensible
> for things like textures to be referenced by URLs which could be coming off
> of any old place), but my initial reading of your text was that the client

I certainly agree on the principle of deployment choice!  :-)

We periodically tell each other that we're interested in defining only
mechanisms, not policies, but this is implied all the time, I hope.  The
principle is so clear and uncontested that it's widely seen as universal in
IETF protocol work, although the latter is my own personal reading of it.
For us here it means that nothing important is precluded, and that a given
provider may choose not to implement or configure a given feature or
facility, yet the mechanism that we provide should allow it.  In the current
case, it means that service proxying must be a deployment choice, neither
required nor precluded by the protocol.

Perhaps I should explain further the phrase that gave you trouble above.  I
was trying to indicate that once an agent is in a region, denying the user
the ability to visualize the world around her would be a very bad idea, as
it would break the intended perceptual mashup.  "Breaking the perceived
world" is such a poor idea on many fronts that nobody has proposed it as far
as I know, and if we have a legacy design that may be interpreted as
suggesting exactly this then it should raise immediate red flags with us.
(I'm not saying that it does.)

The original OGP idea was almost always described with the AD as sole
provider of seed caps, but the caps concept is of course not actually
limited in this regard, and I've been working towards a flexible
interpretation.  In my preferred interpretation stemming from our
discussions about tourism, it *includes* the semantic that *the AD can
provide cap access to other sources of seed caps*.  It is through this
mechanism that we would implement the variously described key concept
of "*separation
of agent and region policies*" or "*policies are local*" or "*no policy
export*", and it is this that would allow us to support the DDP principle
through which we achieve tourism in those VWRAP deployments where it is
desired.

I hope that this explains it better.  Such choices are not precluded nor
mandated -- the AD doesn't have to provide a cap to any given region or RD,
that's a policy decision.  But if it chooses to grant the cap for access to
a particular region then that region's policies now apply within the
region.  It is then up to the region to grant the seed caps that give access
to the assets that allow the region to be visualized, as one crucial
operation.

Here is is my design principle for a caps system that would meet multiple
requirements:

*Gaining access to resources via caps is akin to exploring a caps tree.
Each inner node (region) provides a seed cap that gives access to any number
of leaf nodes (asset services) and to any number of child nodes (other
regions).  What distinguishes the AD is that it's the root node of the tree.
*

Now I can fill in my earlier forward reference to how inventories should be
structured:  if the AD provides an inventory service (a policy choice), then
the items in the inventory offered by the AD are the items delivered by the
asset services linked at the leaf nodes of the AD's initial caps tree.  Not
only is this elegant and extensible through tree-structured design, but it
also supports an unlimited set of policies and deployments without
prescribing nor proscribing anything.

> could be blacklisted by some large search company, my ISP, or perhaps my AD.

Definitely.  That's a policy choice, just don't grant the region cap!  :-)

> I'm using "asset" in quotes since that term may be overloaded. "Content"

This is a great analysis, which we hadn't approached previously.  I think
your list could be used directly to drive our use case analysis to be sure
that we're covering all the bases.

Note that at this stage I'm considering all resources to be accessible
through caps, not only for symmetry and simplicity but because we haven't
defined any other access mechanism yet, so my reference to "assets" was
intended to apply to all "content" in the widest sense.  This broad use of
the word "asset" stems from our choice of phrase "asset service" --- if we
don't use the broad meaning then we're precluding storage of data such as
objects and terrain on asset services, which would be a bad idea as we'd
have to invent yet another type of storage service.

I think this hints at the problem caused by using SL-defined terms in our
wider setting.  Perhaps we should spend a week revising the terminology that
applies to VWRAP.  (We did this at the start of AWG to create an AWG
Glossary, and it was very illuminating.)

Morgaine.

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

On Fri, Oct 30, 2009 at 5:23 PM, Joshua Bell <[email-masked]> wrote:

> On Fri, Oct 30, 2009 at 12:29 AM, Morgaine <[email-masked]
> > wrote:
>
>>
>> This directly implies that asset services must be quite separate from
>> ADs.  Although we haven't spelled it out, clients must have access to an
>> arbitrary list of asset services, because as agents travel around the
>> VWRAP-compatible metaverse, the regions they visit will contain objects from
>> an arbitrary number of asset service providers.
>>
> Now for the terminology bit: we can call the services the region is
> exposing "asset services" but these could be quite distinct from the sorts
> of things present in an agent's inventory. One phrase that's potentially
> confusing is "the regions they visit will contain objects from an arbitrary
> number of asset service providers" - while I agree with the high-level
> interpretation of that statement, I think it paints a picture that as you're
> exploring a region, the client is *necessarily* going off and making
> connections to a variety of asset servers to fetch the data.
>
> I don't think VWRAP should *preclude* that (I imagine it's only sensible
> for things like textures to be referenced by URLs which could be coming off
> of any old place), but my initial reading of your text was that the client