Subject: [ogpx] Cable Beach + VWRAP update

From: "Hurliman, John" <[email-masked]>
Date: Fri, 15 Jan 2010 18:13:22 -0700

My post got a bit long and includes some pictures, so I put the Cable Beach + VWRAP update in a blog post at http://www.jhurliman.org/2010/01/merging-vwrap-and-cable-beach/

The comments on that post are closed to encourage discussion to move to the appropriate IETF mailing list (OAuth-WG or VWRAP).

John

---

From: Morgaine <[email-masked]>
Date: Sat, 16 Jan 2010 04:09:13 +0000

I spoke at length with John about his blog post.

Unfortunately, it seems that his model has some serious restrictions as a
result of hardwired service coupling, with only a single deployment model
being allowed.  This is a deployment in which the AD dictates region asset
policies to RDs or regions through central inventory policy.  This appears
to be much less flexible than the multiple deployment models that we have
been discussing here, where we gained much flexibility by using multiple
asset services and keeping agent and region policies separate.

In addition, the model adds communication between ADs, whereas in our VWRAP
discussions there was no communication with AD2 when an agent from AD1
teleported from RD1 to RD2.  Ie. we needed no prior federation, whereas
John's model does.  In effect this proposal just extends the world
controlled by AD1 with additional regions that have no say in local asset
policy, as in the original OGP.  We've gone beyond that in VWRAP to allow
for tourism between worlds with different region policies, in which only the
agent identity and multi-world assets are common.

Also, in John's model there are no independent asset services, instead you
can use only a single inventory service which is tightly coupled to the
Agent Domain with which you have authenticated.  All your assets are
accessed through this centralized inventory service, which means that your
AD controls the region asset policy of the regions you visit, since whether
you are allowed to acquire objects from the foreign RD2 is dictated by AD1
instead of by RD2.  In other words, there can be no useful cross-world
tourism for your agent except with worlds that have assets allowed by your
AD.

To a first degree then (and bearing in mind that I've already discussed this
extensively  with John so this understanding is at least partially correct),
this appears to be just the original "let's grow SL" OGP protocol but with
OpenID added.  It doesn't appear to offer the cross-world interop that we've
been working towards in VWRAP, since that requires Destination Determines
(Local) Policy, just like in the real world.

I'll have to see the model in action to understand it fully, but at first
glance this is a recipe for creating walled gardens with no interop at all
except to federated worlds.  There is no deployment option in it to do any
more, whereas we've been talking about many more deployment options because
of the independence of VWRAP services.

As a footnote, this really highlights why such things should be discussed
here on this list first before being added to a draft spec --- I'm very glad
to see John doing that here and giving us the opportunity for comments prior
to spec time.

PS. The above problems are "fixable" (but awkwardly) by making John's
hardwired AD inventory extensible on the client.  Whenever a dictatorial AD
disallows placing a foreign region's assets in its restricted inventory
service, the client could automatically use a more flexible inventory
service instead, extending symmetrically the user's perception of inventory
contents beyond that of the AD.  I don't advocate this approach though, as
it's a fix to a problem that shouldn't be there.  We should begin with a
clean model from the start by keeping services decoupled so that a user
controls which assets she references in inventory, and not her identity
provider.

Morgaine.

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

On Sat, Jan 16, 2010 at 1:13 AM, Hurliman, John <[email-masked]>wrote:

>  My post got a bit long and includes some pictures, so I put the Cable
> Beach + VWRAP update in a blog post at
> http://www.jhurliman.org/2010/01/merging-vwrap-and-cable-beach/
>
>
>
> The comments on that post are closed to encourage discussion to move to the
> appropriate IETF mailing list (OAuth-WG or VWRAP).
>
>
>
> John
>
> _______________________________________________
> ogpx mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

---

From: Carlo Wood <[email-masked]>
Date: Sat, 16 Jan 2010 14:17:41 +0100

On Fri, Jan 15, 2010 at 06:13:22PM -0700, Hurliman, John wrote:
> My post got a bit long and includes some pictures, so I put the Cable Beach +
> VWRAP update in a blog post at http://www.jhurliman.org/2010/01/
> merging-vwrap-and-cable-beach/

I beg you to change this line:

The group name was later changed to Virtual World Region Access Protocol (VWRAP) to reflect that 

The meaning of VWRAP is and has always been:

Virtual World Region Agent Protocol

-- 
Carlo Wood <[email-masked]>

---

From: Carlo Wood <[email-masked]>
Date: Sat, 16 Jan 2010 14:39:00 +0100

Test 1 2

This post was mailed to [email-masked] at 13:39 GMT.

---

From: Carlo Wood <[email-masked]>
Date: Sat, 16 Jan 2010 16:17:51 +0100

> This post was mailed to [email-masked] at 13:39 GMT.

Sorry about that :)... My own mails got lost (I never received them back)
and now finally figured out why: I /dev/null emails that are faked
to come from me, or rather are a reply to "me", while the Message-ID
is not something I'd ever have generated. This filter now failed because
it assume that the message ID's generated by me would start with
200[0-9], and that is no longer the case in 2010 ;)

---

From: Suzy Deffeyes <[email-masked]>
Date: Mon, 18 Jan 2010 07:44:39 -0600

Hi John,

Great blog post on Cable Beach / VWRAP. I'm ecstatic to see your interest in
VWRAP.  I'm especially interested in the different deployment patterns your
viewpoint will bring to the VWRAP discussion, and the expertise in what you
have learned in doing Cable Beach.

I wanted to point you towards our Open Source implementation of agent domain
that we call Agent Service:
http://forge.opensimulator.org/gf/project/ogp/
<http://forge.opensimulator.org/gf/project/ogp>

Suzy Deffeyes / Pixel Gausman
IBM

---

From: David W Levine <[email-masked]>
Date: Mon, 18 Jan 2010 12:54:50 -0500

I'm very excited to see this. A lot of ground work has been laid in the 
past year, I'm really hoping 2010 is the year when we, in several
overlapping communities begin to harvest that work, and see some very 
exciting results. 

I view the current (somewhat stale) OGPX module, the test Agent Domain 
we've been working with and Cable Beach as test beds to
better understand the problem space. None of them are a definitive 
implementation of what a full VWRAP system will look like. I'm not
even sure *anyone* will ever implement every single possible VWRAP 
permutation in a single deployment. In fact, one of the major
points of the specification, is permitting people to build and deploy 
different variations, and permit interoperation. Specifications are
well removed from high level designs. The one lays out a roadmap for many 
systems, the other lays out a design for a single system or 
small set of systems. 

I look forward to seeing a lot of new energy emerge from this development. 

- David
~ Zha

[email-masked] wrote on 01/15/2010 08:13:22 PM:

> [image removed] 
> 
> [ogpx] Cable Beach + VWRAP update
> 
> Hurliman, John 
> 
> to:
> 
> [email-masked]
> 
> 01/15/2010 08:13 PM
> 
> Sent by:
> 
> [email-masked]
> 
> My post got a bit long and includes some pictures, so I put the 
> Cable Beach + VWRAP update in a blog post at http://
> www.jhurliman.org/2010/01/merging-vwrap-and-cable-beach/
> 
> The comments on that post are closed to encourage discussion to move
> to the appropriate IETF mailing list (OAuth-WG or VWRAP).
> 
> John_______________________________________________
> ogpx mailing list
> [email-masked]

---

From: David W Levine <[email-masked]>
Date: Mon, 18 Jan 2010 13:13:15 -0500

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. The control point is 
not when you you say
"Jacob Smith has Item 7896, which is hosted on the BlueDragonsHosting 
Asset Server, with URI "
https://BlueDragonsHosting.Assets.net/private_scheme_for_reference/asset.foo
" Whether that inventory pointer sits on a local
hard drive, in the only Inventory Service Jacob choses to use, or in a 
list in one of several services matters not at all. What is going to 
matter is what various services do with the URI and credentials Jacob 
presents when he wishes to
use the asset. 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 Jacob which to
invoke and the Asset server holding the asset. 

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. 

- David
~ Zha

From:
Morgaine <[email-masked]>
To:
"[email-masked]" <[email-masked]>
Date:
01/15/2010 11:09 PM
Subject:
Re: [ogpx] Cable Beach + VWRAP update
Sent by:
[email-masked]

In addition, the model adds communication between ADs, whereas in our 
VWRAP discussions there was no communication with AD2 when an agent from 
AD1 teleported from RD1 to RD2.  Ie. we needed no prior federation, 
whereas John's model does.  In effect this proposal just extends the world 
controlled by AD1 with additional regions that have no say in local asset 
policy, as in the original OGP.  We've gone beyond that in VWRAP to allow 
for tourism between worlds with different region policies, in which only 
the agent identity and multi-world assets are common.

Also, in John's model there are no independent asset services, instead you 
can use only a single inventory service which is tightly coupled to the 
Agent Domain with which you have authenticated.  All your assets are 
accessed through this centralized inventory service, which means that your 
AD controls the region asset policy of the regions you visit, since 
whether you are allowed to acquire objects from the foreign RD2 is 
dictated by AD1 instead of by RD2.  In other words, there can be no useful 
cross-world tourism for your agent except with worlds that have assets 
allowed by your AD.

To a first degree then (and bearing in mind that I've already discussed 
this extensively  with John so this understanding is at least partially 
correct), this appears to be just the original "let's grow SL" OGP 
protocol but with OpenID added.  It doesn't appear to offer the 
cross-world interop that we've been working towards in VWRAP, since that 
requires Destination Determines (Local) Policy, just like in the real 
world.

I'll have to see the model in action to understand it fully, but at first 
glance this is a recipe for creating walled gardens with no interop at all 
except to federated worlds.  There is no deployment option in it to do any 
more, whereas we've been talking about many more deployment options 
because of the independence of VWRAP services.

As a footnote, this really highlights why such things should be discussed 
here on this list first before being added to a draft spec --- I'm very 
glad to see John doing that here and giving us the opportunity for 
comments prior to spec time.

PS. The above problems are "fixable" (but awkwardly) by making John's 
hardwired AD inventory extensible on the client.  Whenever a dictatorial 
AD disallows placing a foreign region's assets in its restricted inventory 
service, the client could automatically use a more flexible inventory 
service instead, extending symmetrically the user's perception of 
inventory contents beyond that of the AD.  I don't advocate this approach 
though, as it's a fix to a problem that shouldn't be there.  We should 
begin with a clean model from the start by keeping services decoupled so 
that a user controls which assets she references in inventory, and not her 
identity provider.

Morgaine.

On Sat, Jan 16, 2010 at 1:13 AM, Hurliman, John <[email-masked]> 
wrote:
My post got a bit long and includes some pictures, so I put the Cable 
Beach + VWRAP update in a blog post at 
http://www.jhurliman.org/2010/01/merging-vwrap-and-cable-beach/
 
The comments on that post are closed to encourage discussion to move to 
the appropriate IETF mailing list (OAuth-WG or VWRAP).
 
John

---

From: "Hurliman, John" <[email-masked]>
Date: Mon, 18 Jan 2010 13:07:01 -0700

I think we got wires crossed between two different conversations. Cable Beach as it applies to VWRAP only introduces one new concept, the delegated agent seed capability (the ability for one AD to grant partial service access to another AD). There is no explicit or implied deployment model, inventory policy, or decision about what domain the inventory service(s) should live in. I added a footnote to clarify this since the example images show an inventory service in the AD.

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Morgaine
Sent: Friday, January 15, 2010 8:09 PM
To: [email-masked]
Subject: Re: [ogpx] Cable Beach + VWRAP update

Unfortunately, it seems that his model has some serious restrictions as a result of hardwired service coupling, with only a single deployment model being allowed.  This is a deployment in which the AD dictates region asset policies to RDs or regions through central inventory policy...

---

From: "Hurliman, John" <[email-masked]>
Date: Mon, 18 Jan 2010 13:07:20 -0700

> -----Original Message-----
> From: Carlo Wood [mailto:[email-masked]]
> Sent: Saturday, January 16, 2010 5:18 AM
> To: Hurliman, John
> Cc: [email-masked]
> Beach +

Fixed, thanks!

John

---

From: Morgaine <[email-masked]>
Date: Tue, 19 Jan 2010 08:11:16 +0000

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:

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

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

On Mon, Jan 18, 2010 at 6:13 PM, David W Levine <[email-masked]> wrote:

> 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."
>
> Inventory is a list of references to virtual goods. The control point is not
> when you you say
> "Jacob Smith has Item 7896, which is hosted on the BlueDragonsHosting Asset
> Server, with URI "
> https://BlueDragonsHosting.Assets.net/private_scheme_for_reference/asset.foo<https://bluedragonshosting.assets.net/private_scheme_for_reference/asset.foo>"
> Whether that inventory pointer sits on a local
> hard drive, in the only Inventory Service Jacob choses to use, or in a list
> in one of several services matters not at all. What is going to matter is
> what various services do with the URI and credentials Jacob presents when he
> wishes to
> 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 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.
>
> - David
> ~ Zha
>
>
>
>
>
>  From: Morgaine <[email-masked]> To: "[email-masked]" <
> [email-masked]> Date: 01/15/2010 11:09 PM Subject: Re: [ogpx] Cable Beach +
> VWRAP update
>  Sent by: [email-masked]
> ------------------------------
>
>
>
> correct), this appears to be just the original "let's grow SL" OGP protocol
> but with OpenID added.  It doesn't appear to offer the cross-world interop
> that we've been working towards in VWRAP, since that requires Destination
> Determines (Local) Policy, just like in the real world.
>
> On Sat, Jan 16, 2010 at 1:13 AM, Hurliman, John <[email-masked]*<[email-masked]>>
> wrote:
> My post got a bit long and includes some pictures, so I put the Cable Beach
> + VWRAP update in a blog post at *
> http://www.jhurliman.org/2010/01/merging-vwrap-and-cable-beach/*<http://www.jhurliman.org/2010/01/merging-vwrap-and-cable-beach/>
>
>
>
> ogpx mailing list*
> [email-masked]* <[email-masked]>*
> **https://www.ietf.org/mailman/listinfo/ogpx*<https://www.ietf.org/mailman/listinfo/ogpx>
>

---

From: Morgaine <[email-masked]>
Date: Tue, 19 Jan 2010 08:33:55 +0000

On Mon, Jan 18, 2010 at 8:07 PM, Hurliman, John
<[email-masked]>wrote (my highlighting):

I think we got wires crossed between two different conversations. Cable
Beach as it applies to VWRAP only introduces one new concept, the delegated
agent seed capability (the ability for one AD to grant partial service
access to another AD). *There is no explicit or implied deployment model,
inventory policy, or decision about what domain the inventory service(s)
should live in. I added a footnote to clarify this since the example images
show an inventory service in the AD.*

John:  That's very good news, thanks for the clarification!

I replied in more depth on the subject in answer to David a few minutes
ago.  I can summarize it briefly for you here:  "If inventory is just
references free of semantics about content type or origin, then most of the
potential problems vanish."

In other words, I'm much reassured, and also very pleased with your
underlining that VWRAP deployment options would not be curtailed in this
model.

Morgaine.

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

On Mon, Jan 18, 2010 at 8:07 PM, Hurliman, John <[email-masked]>wrote:

>  I think we got wires crossed between two different conversations. Cable
> Beach as it applies to VWRAP only introduces one new concept, the delegated
> agent seed capability (the ability for one AD to grant partial service
> access to another AD). There is no explicit or implied deployment model,
> inventory policy, or decision about what domain the inventory service(s)
> should live in. I added a footnote to clarify this since the example images
> show an inventory service in the AD.
>
>
>
> John
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Morgaine
> *Sent:* Friday, January 15, 2010 8:09 PM
> *To:* [email-masked]
>
> *Subject:* Re: [ogpx] Cable Beach + VWRAP update
>
>
>
> policies to RDs or regions through central inventory policy…
>
>
>

---

From: Carlo Wood <[email-masked]>
Date: Tue, 19 Jan 2010 14:11:43 +0100

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:
> 
> 
> 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.
> 
> 
> 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.
> 
> 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.
> 
> (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.
> 
> 
> 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.
> 
> 
> 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
> 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.

---

From: Morgaine <[email-masked]>
Date: Wed, 20 Jan 2010 00:27:00 +0000

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

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 <[email-masked]> wrote:

> behind
> you
> having
> links
> like
> could
> separation
> avatar.
> server
> host, as
> about
> still

---

From: Carlo Wood <[email-masked]>
Date: Wed, 20 Jan 2010 15:50:40 +0100

> it's rather widely used, so I doubt that there's a major problem there.

If they are using html, of course they do.

> That tiny set is completely IETF mailman compatible, as the above URL

I sent myself a post from gmail using "rich text", a reply to one of the posts
here and then sending it to me only, and that results in indentation for the
quoted text.

Your posts are the only ones that have no indentation or quotation
marks for quoted text... Sorry, but it should work good enough with
gmail.

I looked at the HTML of your posts and it looks like this:

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br></blockquote><div style="margin-left: 40px;"><font face="sans-serif" size="2">I read John&#39;s post as &quot;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&#39;t read it as &quot;We should

etc.

while the post that I send from gmail looks like this:

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Just played with the new &quot;sit here&quot; pie menu and found a small hole in the logic.

As you see, you CLOSE the </blockquote> before the quote even starts. I think that is the problem.

---

From: Morgaine <[email-masked]>
Date: Wed, 20 Jan 2010 18:25:56 +0000

Well it's just Gmail, I guess it's buggy if you say it produces broken
HTML.  But notice that it's NOT broken on the IETF mailman site.  The
indentation is preserved perfectly, even when a quoted mail body is
split into sections for interleaving responses.

Morgaine.

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