Re: [ogpx] Cable Beach + VWRAP update

[Morgaine <[e-mail]>]

On Tue, Jan 19, 2010 at 1:11 PM, Carlo Wood <[e-mail]> wrote:

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.


Carlo, both the Gmail copy of my reply to David and the IETF web archive
copy at http://www.ietf.org/mail-archive/web/ogpx/current/msg00729.html have
quotation blocks defined and identified with their originator, and they both
match each other too.

This makes me think that you have a problem with your mail client, as it
appears to be losing information somewhere.  The post that you've enclosed
does suggest this, as it shows David's text and mine at the same level of
indentation, which is incorrect.  It's clearly not what I sent, since the
IETF archive copy shows the post structured properly.

I've also asked others how they see the post, and they confirm that the
indented quotation blocks are present.  While Gmail is far from perfect,
it's rather widely used, so I doubt that there's a major problem there.

If you know of some Gmail setting that might help, I would be happy to try
it out.  I won't switch all replies to plain text though unless it's
officially required here and everyone else on the list does too.  Personally
I use block quoting, italics, bold and URLs as my only Gmail "rich"
features, which is pretty minimal and much less than some others are using.
That tiny set is completely IETF mailman compatible, as the above URL
proves.


Morgaine.







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

On Tue, Jan 19, 2010 at 1:11 PM, Carlo Wood <[e-mail]> wrote:

> 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]>
>