Re: [ogpx] Cable Beach + VWRAP update

[Carlo Wood <[e-mail]>]

Morgaine, with long posts like this, it's a problem for me that
I cannot see who wrote what.

I ask you to add some quotation character, at least, or better,
that you do not use html posts, but reply in plain text. This will
also help for archiving purposes imho.

On Tue, Jan 19, 2010 at 08:11:16AM +0000, Morgaine wrote:
> David, your very interesting reply highlights very well why discussions behind
> closed doors are not a good idea in VWRAP.  You now know things that the rest
> of us had to guess at, as is evident here:
> 
> 
> On Mon, Jan 18, 2010 at 6:13 PM, David W Levine <[e-mail]> wrote:
> 
> 
> 
> I read John's post as "This is what we have built, how it works, and how you
> can think about it mapping onto the OGPX/VWRAP design. I certainly don't read
> it as "We should all build and deploy this."
> 
> Policy Enforcement Points are where you find them. I actually think that having
> one or many inventory services per avatar is not a control point. Inventory is
> a list of references to virtual goods.
> 
> 
> If inventory is just a list of references in VWRAP, in other words the
> inventory itself is free of content-based semantics (a bit like symbolic links
> in a Unix filestore), then you are absolutely right, the inventory will not be
> a Policy Enforcement Point (PEP), to a first degree anyway.  That would remove
> almost entirely the biggest problem that stems from allowing only a single
> inventory, since the entries could point to anything and cannot be blocked by
> the AD based on type or origin.
> 
> However, as we have discussed on various occasions, inventory in SL in badly
> entangled with type semantics, so the above is not the conclusion that comes
> naturally when one hears that VWRAP using a Cable Beach mechanism would have
> only a single inventory which lives in the AD.  It looked to me very much like
> a content type or origin control point --- very bad news indeed for VWRAP.
> 
> Not surprisingly, I am much heartened by what you have written!
> 
> (Also, John has now clarified on his article that the inventory service could
> run anywhere and in more than one place  --- the diagram showing a single
> inventory in the AD was just an example.  This of course means that more than
> one inventory deployment pattern is possible, which is much more flexible than
> it appeared at first glance.  I'm sure that open discussions would have
> prevented my misunderstanding this point, but I'm very glad to see the
> clarification now.  If VWRAP takes on the CB inventory mechanism then we will
> need to ensure that these various deployment pattern options are provided.)
> 
> 
> That decision isn't going to happen in the inventory service. It isn't going to
> happen in the Agent Domain. That decision is going be the subject of policies
> which affect the interaction between the services ... and the Asset server
> holding the asset.
> 
> 
> Excellent!  With that clarified, the Agent Domain will indeed not be
> controlling region policies such as access to region assets.  That separation
> is what we need for genuine tourism to happen, where the places visited
> determine what an agent can do in them (the good ol' DDP principle).  The AD
> can at most only disallow the travel, and it's up to asset services and the
> region to determine what happens to assets.
> 
> 
> My personal expectation is that we will have many asset servers, and most
> people will have one, or a few inventory services associated with their avatar.
> Since the inventory is nothing more than a list of asset pointers, Splitting it
> across multiple servers feels similar to splitting one's bookmark file. One
> could do it. (And one might well put a backup copy someplace) but. the
> bookmarks file has no  impact on the services I invoke. No matter where I get a
> URL, the server hosting the web page gets to determine if
> I see it, and if I need to pass it credentials to fetch it.
> 
> I don't see Regions, or Agent Domains as unique gatekeepers to asset server
> seedcaps. I fully expect that virtual world hosters will create convenient
> paths between their regions and any asset services they host. I also expect
> that for assets hosted
> outside of their span of trust, seedcaps will be granted by the asset host, as
> it sees fit. The place where all of this plays out is in the protocols to
> permit a user to rez an item from a third party asset server, and the policies
> which influence the
> use of those protocols.
> 
> 
> That fits in perfectly with the direction of VWRAP discussions at the tail end
> of last year, so I'm glad to hear it. :-)
> 
> I'll point out now why I said "to a first degree" in answer to your point about
> PEPs.  An inventory service could be semantic-free on asset type and origin,
> yet still place unwanted constraints on inventory size, shape, or which
> operations allowed on inventory items.  It could also be running on poorly
> resourced or unreliable hardware or provide poor uptime.  In all these cases,
> inability to use a different inventory service when authenticated with a given
> Agent Domain would have bad ramifications, and could exert a sort of
> second-order policy control, especially in the context of sizes.  This may be
> seen as less important than the usual context for discussion about PEPs, but
> nevertheless it's still a good reason for allowing non-AD inventories in the
> protocol.
> 
> Thanks for these clarifications, David.  I think I'm reassured that we're still
> on course for a protocol with sufficient flexibility.  :-)
> 
> 
> Morgaine.

-- 
Carlo Wood <[e-mail]>