Subject: [vwrap] Comments on http://tools.ietf.org/html/draft-ietf-vwrap-intro-00

From: Cristina Videira Lopes <[email-masked]>
Date: Tue, 07 Sep 2010 08:56:26 -0700

This is my first time participating in an IETF WG, so apologies in 
advance for any mis-steps on the process. I believe it's ok to send 
comments at this point. But I understand that the work has been going on 
for about a year without me being involved, so my comments may be out of 
order. This is one year's worth of comments, long and heavy email :-)
I leave to the Chairs of this WG the right to dismiss them, and I'll 
accept it if that happens.

I'm still not entirely sure the world is ready for "standards" for 
virtual world interoperability, but given that this working group 
exists, I hope my comments help strengthen the technical aspects of the 
work that has been going on here, so that, in the end, this document 
will appeal to others who have absolutely nothing to do with the Linden 
Lab family of virtual worlds -- so as to make good on the word 
"interoperability."

The document seems to be establishing the underlying assumptions and 
scope for the protocols recommended by this group. That's great.

The gist of my comments is that the particular assumptions established 
by the document do not accurately reflect the underlying assumptions and 
goals of the OpenSimulator platform in important ways, and I suspect 
they also don't reflect many other VW platforms. I don't know if that is 
a good thing or a bad thing or an irrelevant thing for the purposes of 
this working group; I'm just making this observation. Assuming that the 
Chairs accept my commentary for discussion, I delegate to the group the 
judgment on the consequences of this observation.

Let me expand on it by going through the document, and pointing out the 
differences in assumptions and goals, as well as the parts of the text 
that aren't clear to me, the parts that I think are good, and some 
general technical commentary.

----- Comment 1 -----
Section 1: "...This document introduces the
   Virtual World Region Agent Protocol (VWRAP) suite.  This protocol
   suite is intended to carry information about a virtual world: its
   shape, its residents and objects existing within it.  VWRAP's goal is
   to define an extensible set of messages for carrying state and state
   change information between hosts participating in the simulation of
   the virtual world."

This starting statement offers the concept of a single virtual world; 
reading further  it seems to mean that the ecosystem of VWRAP is, 
indeed, treated here as one single system involving a multitude of 
organizations. Section 2.1, par 5:
"The VWRAP suite assumes network hosts, likely operated by distinct
   organizations will collaborate to simulate the virtual world."

The OpenSimulator platform has been designed with a plurality of virtual 
worlds in mind, not just one. This plurality is a fundamental assumption 
of our platform, as it makes aggressive use of plugins for two important 
aspects of virtual worlds: (1) the scene server -- scene renderer client 
interaction; (2) the scene service -- resource services interaction.

What the use of these plugins means is that we strongly believe that 
each virtual world is an independent system that should be designed and 
implemented in a way that best fits that world's goals. We believe this 
for OpenSimulator-based worlds already by providing those important 
aspects as plugins, so we also believe it for virtual worlds that aren't 
based in OpenSimulator software. The decisions made by, say, Blue Mars, 
with respect to how to send scenes to client software and how to manage 
their resources, are to be respected and treated independently of the 
decisions made by, say, ReactionGrid. But that doesn't mean that worlds 
operated by these organizations can't interoperate. They can, given a 
minimum interoperability protocol. In summary, and this will recur 
throughout my commentary:

OpenSimulator does not assume the existence of one single virtual world 
involving a multitude of organizations; it assumes the existence of 
multiple virtual worlds, each one under the authority of one single 
organization -- which, in turn, may make its own internal decisions 
about sharing ownership and resources of parts of that world with other 
organizations, but that is an internal decision that is irrelevant for 
purposes of virtual world interoperability.
For some background on the virtual world model assumed by OpenSimulator, see
http://opensimulator.org/wiki/Virtual_World_Model

----- Comment 2 -----
Section 2.1, the list of 3 characteristics:

"1. The virtual world exists independent of the participating
   clients." ... "VWRAP assumes the state virtual world is "always on"... "

OpenSimulator does not make these assumptions. While OpenSimulator 
worlds are usually run on servers to which clients connect over the 
network, it is possible to take the OpenSimulator framework and merge it 
with a renderer component, producing a virtual world that is both a 
client and, eventually, a server if that virtual world is to support 
multiple users over a network.

Also, OpenSimulator does not assume that the virtual world is "always 
on", on the contrary. Many OpenSimulator-based virtual worlds that 
already exist seem to be ran on people's personal computers in their 
home networks, which are often turned off.

"2. Avatars have a single, unique presence in the virtual world."

OpenSimulator does not make this assumption. It is possible to have 
multiple presences (sessions) for the same user on the same virtual 
world. This supports use cases of users wanting to be in two different 
places of the world at the same time, e.g. for attending two different 
events. The decision on whether to allow this or not pertains entirely 
to the virtual world operator.

----- Comment 3 -----
Section 2.2, architectural patterns:

"1. Systems implementing virtual world services must be distributed."
...
"But however large (or small) a virtual world deployment is, or
       how many distinct organizations contribute to its operation,
       software implementing virtual world services MUST assume
       resources required to perform its function are distributed
       amongst multiple hosts."

OpenSimulator does not impose this. In fact, the most popular 
configuration of OpenSimulator-based worlds is a "standalone" 
configuration where both the scene service and all the resource services 
of that world execute in one single process of one machine. In a 
standalone VW system, none of the services (e.g. assets, inventory, etc) 
are "distributed." Furthermore, as explained above, the OpenSimulator 
framework also supports the existence of single-process virtual worlds 
that include the renderer itself.

The only two requirements imposed by OpenSimulator, and indeed by any 
software system, are: (1) in cases where these worlds wish to serve 
multiple users over the network, then network endpoints must exist that 
serve the scene to the clients used by those users; (2) in cases where 
these worlds wish to interoperate, then network endpoints must exist 
that serve certain resources from those worlds to other worlds.

"2. Services supporting collaboration are hosted on 'central'
   systems."

No such assumption in OpenSimulator. The way that virtual world 
operators decide to design and implement their collaborative features 
are entirely up to them.

For example, in OpenSimulator the default implementation of Instant 
Messaging is peer-to-peer, with only presence being looked up centrally; 
there is no central IM server. This feature is implemented as a plugin, 
so other implementations (e.g. centralized) are possible.

Maybe this architectural pattern pertains to inter-world collaboration? 
If that is the case, then this is clearly not a desired goal, as most 
OpenSimulator virtual worlds want to operate their own collaboration 
sub-systems, and do not wish to depend on third parties, unless there is 
no alternative. As an example, take the Groups service, which is 
implemented outside of the OpenSimulator core distribution. While there 
is an instance of that group service ran by an individual (the original 
developer) that can support groups for many virtual worlds, most grid 
operators choose to run their own instance.

"3. Virtual world services default to being 'open'."
...
"In other words, requiring
       two services (e.g. - physics simulation and asset storage) be
       managed by the same organization's servers is an issue of local
       policy, not of protocol."

I don't understand what 'open' means. Does it mean that they default to 
being available on the internet? The quoted sentence doesn't seem to 
relate to the headline, so I'm not sure what this architectural pattern 
is saying, I think it needs to find its message.

----- Comment 4 -----
Section 3.1:

This is the best section of the document, but it needs a lot more depth. 
I would go as far as suggesting that protocol flexibility (and not just 
data presentation flexibility) may very well be the single most 
important contribution that an interoperability standard in this area 
might make.

Indeed, this document fails to address one critical question: what 
assumptions do we make wrt how the server serves scenes to the clients? 
Do we assume that this is a fixed part for interoperability (i.e. 
there's only one protocol for doing this in the entire collection of 
interoperable virtual worlds) or so we assume that each virtual world 
does it in whichever way it wants?

To illustrate the issue, let me point out the spectrum of possibilities.

On one extreme we have what is currently emerging on the Web: on-line, 
multi-user 3D scene servers that simply send their "viewer code" to the 
web browsers in JavaScript. You go from one game to another, and you get 
radically different pieces of JavaScript code that get the data from the 
servers and render it; these JavaScript "viewers" are black boxes that 
have nothing to do with each other.

On the other extreme of this spectrum, we have systems like Second Life 
and World of Warcraft, with customized, non-programmable viewers that do 
things in exactly one way, tightly coupling the protocol with the fixed 
game-specific UI.

Somewhere in the middle, we have Flash-based worlds (and others) that 
run on the general-purpose Web browser and that are identified by 
certain MIME types (e.g. application/x-shockwave-flash).

So where does this group stand wrt this critical issue?

As I said above, in principle, OpenSimulator assumes that each virtual 
world has its own client-server protocol -- so in line with what is 
emerging on the Web. Unfortunately we still don't have viewers capable 
of doing this well: Web browsers still can't render the kinds of content 
we need, and existing VW clients aren't general enough. But that should 
not be an impediment to accepting the underlying principle of letting VW 
systems do it their way, and having that be a programmable component of 
a possible interoperability framework.

With this, we set up an interoperabilty framework that accommodates the 
variety of protocols that already exist, and that are unlikely to be let 
go by their implementers. We also set up the stage for accommodating the 
variety of protocols that still don't exist but that are bound to happen 
as the Web starts experimenting with 3D immersion.

----- Comment 5 -----
Section 3.2:

This section expands more on the basic VWRAP premise of "the single 
virtual world" composed of multiple services under the authority of 
multiple organizations. As explained before, this is very different from 
the VW model assumed by OpenSimulator, where a myriad of virtual worlds, 
each under one authority, are assumed to exist, and where the internals 
of those virtual worlds are out of scope.

----- Comment 6 -----
Section 3.3:

This section is contrary to the design philosophy of OpenSimulator, 
where very few conditions are imposed on the internal implementation of 
virtual worlds.

----- Comment 7 -----
Section 4.1:

This section seems to be a summary of the document
http://tools.ietf.org/html/draft-ietf-vwrap-authentication-00

That document seems to describe a straightforward login procedure, 
similar to all login procedures out there that authenticate a user onto 
a service running on a server. It defines specific on-the-wire data 
representations, and a specific protocol for error handling.

I understand that the introduction of the seed CAP, and subsequent 
invocation, is a new thing that most login procedures don't have.

But I'm at loss as to why this matters for interoperability purposes. 
Each virtual world should be free to do the initial user authentication 
in whichever way it finds most suitable, and to send whichever 
information it needs to send, in whichever way, to the client.

Maybe CAPs has a special role in inter-world authentication in VWRAP? 
Unfortunately, I read all the available documents, and I couldn't find 
anything that explains inter-world authentication in VWRAP.

----- Comment 8 -----
Section 4.2:

This section introduces concepts that haven't been explained before and 
that aren't explained here either, specifically "agent domain" and 
"region domain". I know what these are, as I've read the AWG documents 
on the Web; but another  less informed reader won't know.

Many other things in this section are unclear because of the 
non-existence of referenced materials e.g. "VWRAP Teleport 
specification", so perhaps these summaries shouldn't be in this intro 
document at all. But since they are, let me offer some comments.

In 4.2.2: unclear, but I'm assuming this section pertains to inter-world 
movements? That should be made clear. Because intra-world movements 
should be out of scope for interoperability purposes: the way that 
virtual worlds choose to move the agents within themselves, if they do 
at all, is irrelevant.

I believe there is some confusion here between model and mechanism, but 
maybe I know too much. I'm assuming that the word "capability" in VWRAP 
means "capability URL"; if I'm wrong, and if it means just "capability" 
as given by the Webster dictionary (roughly, authorization), then that 
would be great!

Also in 4.2.2 there is an underlying assumption that the client keeps a 
direct connection to the "agent domain". For example "The client signals 
to the agent domain its desire to move..."
The standard Linden client does not do this. But more important than the 
Linden client, Web browsers, i.e. stateless clients, also don't keep 
state. So if we ever were to have a Web-browser-based viewer for a web 
of virtual worlds, we wouldn't be able to do what is suggested in this 
entire section.

These protocols hinted at in this section are the crux of 
interoperability. I understand this is just the intro document, and it's 
not supposed to have all the details, that's fine. If you go ahead with 
the protocol hinted at here, then it is important to note somewhere in 
this intro document that it assumes stateful clients, and that Web 
browser viewers (that aren't browser plugins) are N/A.

As I said in comment #4, I would like to see a better analysis of what 
virtual world inteoperability demands from the viewer software. I used 
to think that web browsers were an evolutionary dead-end, but with the 
introduction of HTML5 and all the exciting work that is going on with 
running verifiably-secure native code on Web browsers, I came to change 
my mind about this. Since the Web browser is the ubiquitous client 
software, it seems like a bad move to exclude this client from 
interoperability for virtual worlds, because we're only going to see 
more 3D immersion, not less, on web browsers.

----- Comment 9 -----
Section 4.3:

This has nothing to do with interoperability and seems to be focusing 
exclusively on how the Linden Lab world works. Statements like "The host
   in the region domain responsible for managing spatial chat applies a
   proximity algorithm to the chat to determine which avatars or objects
   are close enough to hear it."
are too specific to be worth mentioning in this document. Other virtual 
worlds may apply different schemes wrt chat.

----- Comment 10 -----
Section 4.4:

I suggest replacing the ad-hoc terminology "at rest" and "in world" with 
more standard terminology. Assets are stored in persistent storage. 
There's technical terminology for "in world":  assets that are 
referenced by a 3D scene. There's also technical terminology for "at 
rest": assets that are not referenced by a 3D scene directly but that 
are referenced by other resources like a user's inventory or scripts.

This section is full of details that should not be here:
(1) how the scene server decides to manage the assets is an internal 
decision of each virtual world. The scene server may have its own 
assets, or it may have its own asset storage server on the same data 
center, or it may use amazon. It may pre-fetch or may perform lazy 
fetch. It may cache or it may not. It doesn't matter for the purposes of 
interoperability.
(2) how the scene server decides to make the assets available to the 
clients is an internal decision of each virtual world; in fact, a 
central part of the client(viewer)-server protocol, of which there 
should be many. It may send them on-line via UDP; it may zip them up in 
a zip file and send them; it may tell the client to fetch them from 
another server. It doesn't matter.

Interoperability should not impose any conditions whatsoever on how 
these things are done, or the word "interoperability" will start moving 
into the realm of internal virtual world architecture, which is 
something this group probably should not be doing, lest alienating 
potential parties. Even in the small ecosystem of OpenSimulator, we are 
already seeing a variety of new clients being developed that have 
nothing to do with the Linden Lab client (e.g. Unity3D). That's a 
direction that we very much encourage.

----- Comment 11 -----
Section 4.2.2:

This section seems to be implying that host based trust carried by X.509 
/ PKIX certificates will ensure that the receiving party will honor the 
asset's metadata. These (i.e. certificates and honoring the metadata) 
are two different things. It should be made clear that, just because all 
parties are who they say they are, it doesn't mean that they will honor 
the metadata.

Again, I wish I knew more of what people in this group have in mind for 
authentication, but I couldn't find any information.

---

From: Morgaine <[email-masked]>
Date: Sun, 19 Sep 2010 01:00:22 +0100

Welcome Cristina to the working group!  And without further ado, let me say
that you are spot on.

I had made it known previously that I was trying to rewrite the intro
document.  Those who have followed my specific areas of interest throughout
the 3-year process of AWG/OGP/MMOX/OGPX/VWRAP will have known what to
expect:  a complete dismissal of any attempt to create a single world, a
focus on interop between multiple worlds, separation of world policies, and
a specific use case that embodies all of these:  the direct support for
tourism between virtual worlds.

David spoke to me yesterday to find out how my document editing work was
going, and I admitted to him that I was somewhere between desperation and
failure.  I had started off making relatively small changes to eradicate
"single world" thinking from the document, but after some pages' worth of
such changes, I realized that this was applying band aids to cure a broken
leg.  The document is simply wrong in its entire approach.  I asked for
David's advice and offered to explain the problem I saw to the group this
weekend, at which point I noticed Crista's post.

I believe that you are 100% right in your observations, Crista.  The intro
document is way off base as an introduction to the work of a group whose
fundamental purpose is to provide protocol standards for VW interop.  It
doesn't even mention interop between VWs at all!  It's hard to imagine how
it could be further from the intended goal.

This problem is with us because it all started with *OGP*, a product of a
single-minded desire to grow Second Life by adding individual or multiple
regions to the existing SL world (or similar walled garden worlds), without
any policy rights of their own and without interoperability between such
worlds.  I'm not guessing about this.  I've been with the process from the
start, and attempts to discuss asset sharing for VW interop were rejected in
OGP.  In the last half year we have at least managed to put multi-world
deployments on the agenda through the help of David's "deployment patterns",
but nowhere is this reflected in the existing protocol documentation.  The
core (legacy) documents which originated with OGP do not reflect our goals,
at all.

A few words on the scope of our "VWRAP deployments".  These are expected to
cover the entire gamut from individual walled garden worlds through to a
metaverse full of interoperating but otherwise independent virtual worlds.
Clusters of access-controlled worlds of various kinds would fall somewhere
in the middle, perhaps the VW counterparts of business VPNs.  Because of the
OGP legacy, we have been unable to document anything but the closed worlds
part of this spectrum.  We haven't even established a vocabulary for
examining the key process of VW interop, which is the shared access to
assets that gives rise to the visual client-side mashup which is the end
product of all this.

I've tried on numerous occasions to bring our discussions to focus on the
worlds tourist use case, because this is the one that highlights the areas
of difficulty.  Restricting a full-interop protocol to create walled gardens
is easy, whereas expanding a protocol for walled gardens into one that
handles VW interoperation is not, so we need to focus on the larger issue
first and only create mechanisms for restriction in passing.  Just in case
this point isn't clear, we should note that even in the most tightly
controlled networks (such as military ones), there is always a need to
interoperate with the world outside.  Thinking about only the closed system
as your primary requirement just gets you in trouble later.

Thank you Crista for describing in detail the "impedance mismatch" between
our documents and OpenSimulator's model or goals.  Since OpenSimulator (or
more accurately the worlds that use it) provides our primary example of
worlds for which VWRAP would be expected to be relevant, your observations
are more than just accurate and devastating --- they are also the key to
getting us to where we want to go, if VW interop is our goal.  It certainly
is mine.

I recommend that we start from scratch on an entirely new intro document, in
which we establish first, very explicitly, that our problem domain is that
of multiple virtual worlds and interoperation between them.  We tried to
approach this in the past, but all attempts were blocked by the incongruous
proposition that "we don't know what virtual worlds are", which verges on
comedy.  More importantly however, as Crista has pointed out, it should be
none of our business "what virtual worlds are" --- all we need to discuss is
how they can interoperate.  After all, SMTP doesn't need to know how MTAs or
MUAs are structured, all that matters is how they communicate, and the same
is true here.

Crista, while our current IETF drafts seem not to address the main issue at
all, you may find that the following article is more closely aligned with
what I believe is our intended direction, written by Joshua, David and
myself for IEEE Internet Computing, published in February.  The article is
embarrassingly over-optimistic in suggesting that the OGP model leads
towards VW tourism despite no such operation having been designed, but at
least it expresses the intent.  We need to go beyond intent though.
http://internetmessagingtechnology.org/pubs/VWRAP-for-Virtual-Worlds-Interoperability-mic2010010073.pdf

Thank you very much for your effective post.  I think we should use it as a
catalyst for affirming our interop direction to be between multiple
independent worlds, and actually getting ourselves on the right road to
achieve it.

Morgaine.

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

On Tue, Sep 7, 2010 at 4:56 PM, Cristina Videira Lopes <[email-masked]>wrote:

> This is my first time participating in an IETF WG, so apologies in advance
> for any mis-steps on the process. I believe it's ok to send comments at this
> point. But I understand that the work has been going on for about a year
> without me being involved, so my comments may be out of order. This is one
> year's worth of comments, long and heavy email :-)
> I leave to the Chairs of this WG the right to dismiss them, and I'll accept
> it if that happens.
>
> I'm still not entirely sure the world is ready for "standards" for virtual
> world interoperability, but given that this working group exists, I hope my
> comments help strengthen the technical aspects of the work that has been
> going on here, so that, in the end, this document will appeal to others who
> have absolutely nothing to do with the Linden Lab family of virtual worlds
> -- so as to make good on the word "interoperability."
>
> The document seems to be establishing the underlying assumptions and scope
> for the protocols recommended by this group. That's great.
>
> The gist of my comments is that the particular assumptions established by
> the document do not accurately reflect the underlying assumptions and goals
> of the OpenSimulator platform in important ways, and I suspect they also
> don't reflect many other VW platforms. I don't know if that is a good thing
> or a bad thing or an irrelevant thing for the purposes of this working
> group; I'm just making this observation. Assuming that the Chairs accept my
> commentary for discussion, I delegate to the group the judgment on the
> consequences of this observation.
>
> differences in assumptions and goals, as well as the parts of the text that
> aren't clear to me, the parts that I think are good, and some general
> technical commentary.
>
> ----- Comment 1 -----
> reading further  it seems to mean that the ecosystem of VWRAP is, indeed,
> treated here as one single system involving a multitude of organizations.
> Section 2.1, par 5:
> worlds in mind, not just one. This plurality is a fundamental assumption of
> our platform, as it makes aggressive use of plugins for two important
> What the use of these plugins means is that we strongly believe that each
> virtual world is an independent system that should be designed and
> implemented in a way that best fits that world's goals. We believe this for
> OpenSimulator-based worlds already by providing those important aspects as
> plugins, so we also believe it for virtual worlds that aren't based in
> OpenSimulator software. The decisions made by, say, Blue Mars, with respect
> to how to send scenes to client software and how to manage their resources,
> are to be respected and treated independently of the decisions made by, say,
> ReactionGrid. But that doesn't mean that worlds operated by these
> organizations can't interoperate. They can, given a minimum interoperability
> protocol. In summary, and this will recur throughout my commentary:
>
> involving a multitude of organizations; it assumes the existence of multiple
> virtual worlds, each one under the authority of one single organization --
> which, in turn, may make its own internal decisions about sharing ownership
> and resources of parts of that world with other organizations, but that is
> an internal decision that is irrelevant for purposes of virtual world
> interoperability.
> OpenSimulator does not make these assumptions. While OpenSimulator worlds
> are usually run on servers to which clients connect over the network, it is
> possible to take the OpenSimulator framework and merge it with a renderer
> component, producing a virtual world that is both a client and, eventually,
> a server if that virtual world is to support multiple users over a network.
>
> Also, OpenSimulator does not assume that the virtual world is "always on",
> on the contrary. Many OpenSimulator-based virtual worlds that already exist
> seem to be ran on people's personal computers in their home networks, which
> are often turned off.
>
> multiple presences (sessions) for the same user on the same virtual world.
> This supports use cases of users wanting to be in two different places of
> the world at the same time, e.g. for attending two different events. The
> decision on whether to allow this or not pertains entirely to the virtual
> world operator.
>
> ----- Comment 3 -----
> OpenSimulator does not impose this. In fact, the most popular configuration
> of OpenSimulator-based worlds is a "standalone" configuration where both the
> scene service and all the resource services of that world execute in one
> single process of one machine. In a standalone VW system, none of the
> services (e.g. assets, inventory, etc) are "distributed." Furthermore, as
> explained above, the OpenSimulator framework also supports the existence of
> single-process virtual worlds that include the renderer itself.
>
> software system, are: (1) in cases where these worlds wish to serve multiple
> users over the network, then network endpoints must exist that serve the
> scene to the clients used by those users; (2) in cases where these worlds
> wish to interoperate, then network endpoints must exist that serve certain
> resources from those worlds to other worlds.
>
> No such assumption in OpenSimulator. The way that virtual world operators
> decide to design and implement their collaborative features are entirely up
> to them.
>
> there is no central IM server. This feature is implemented as a plugin, so
> other implementations (e.g. centralized) are possible.
>
> Maybe this architectural pattern pertains to inter-world collaboration? If
> that is the case, then this is clearly not a desired goal, as most
> sub-systems, and do not wish to depend on third parties, unless there is no
> alternative. As an example, take the Groups service, which is implemented
> outside of the OpenSimulator core distribution. While there is an instance
> of that group service ran by an individual (the original developer) that can
> support groups for many virtual worlds, most grid operators choose to run
> their own instance.
>
> being available on the internet? The quoted sentence doesn't seem to relate
> to the headline, so I'm not sure what this architectural pattern is saying,
> I think it needs to find its message.
>
> ----- Comment 4 -----
> Section 3.1:
>
> This is the best section of the document, but it needs a lot more depth. I
> would go as far as suggesting that protocol flexibility (and not just data
> presentation flexibility) may very well be the single most important
> contribution that an interoperability standard in this area might make.
>
> assumptions do we make wrt how the server serves scenes to the clients? Do
> we assume that this is a fixed part for interoperability (i.e. there's only
> one protocol for doing this in the entire collection of interoperable
> virtual worlds) or so we assume that each virtual world does it in whichever
> way it wants?
>
> multi-user 3D scene servers that simply send their "viewer code" to the web
> browsers in JavaScript. You go from one game to another, and you get
> servers and render it; these JavaScript "viewers" are black boxes that have
> nothing to do with each other.
>
> On the other extreme of this spectrum, we have systems like Second Life and
> World of Warcraft, with customized, non-programmable viewers that do things
> in exactly one way, tightly coupling the protocol with the fixed
> game-specific UI.
>
> Somewhere in the middle, we have Flash-based worlds (and others) that run
> on the general-purpose Web browser and that are identified by certain MIME
> types (e.g. application/x-shockwave-flash).
>
> world has its own client-server protocol -- so in line with what is emerging
> on the Web. Unfortunately we still don't have viewers capable of doing this
> well: Web browsers still can't render the kinds of content we need, and
> existing VW clients aren't general enough. But that should not be an
> impediment to accepting the underlying principle of letting VW systems do it
> their way, and having that be a programmable component of a possible
> interoperability framework.
>
> variety of protocols that already exist, and that are unlikely to be let go
> by their implementers. We also set up the stage for accommodating the
> variety of protocols that still don't exist but that are bound to happen as
> the Web starts experimenting with 3D immersion.
>
> ----- Comment 5 -----
> Section 3.2:
>
> This section expands more on the basic VWRAP premise of "the single virtual
> world" composed of multiple services under the authority of multiple
> organizations. As explained before, this is very different from the VW model
> assumed by OpenSimulator, where a myriad of virtual worlds, each under one
> authority, are assumed to exist, and where the internals of those virtual
> worlds are out of scope.
>
> ----- Comment 6 -----
> Section 3.3:
>
> This section is contrary to the design philosophy of OpenSimulator, where
> very few conditions are imposed on the internal implementation of virtual
> worlds.
>
> ----- Comment 7 -----
> Section 4.1:
>
> That document seems to describe a straightforward login procedure, similar
> to all login procedures out there that authenticate a user onto a service
> running on a server. It defines specific on-the-wire data representations,
> and a specific protocol for error handling.
>
> But I'm at loss as to why this matters for interoperability purposes. Each
> virtual world should be free to do the initial user authentication in
> whichever way it finds most suitable, and to send whichever information it
> needs to send, in whichever way, to the client.
>
> that aren't explained here either, specifically "agent domain" and "region
> domain". I know what these are, as I've read the AWG documents on the Web;
> but another  less informed reader won't know.
>
> Many other things in this section are unclear because of the non-existence
> of referenced materials e.g. "VWRAP Teleport specification", so perhaps
> these summaries shouldn't be in this intro document at all. But since they
> are, let me offer some comments.
>
> movements? That should be made clear. Because intra-world movements should
> be out of scope for interoperability purposes: the way that virtual worlds
> choose to move the agents within themselves, if they do at all, is
> irrelevant.
>
> means "capability URL"; if I'm wrong, and if it means just "capability" as
> given by the Webster dictionary (roughly, authorization), then that would be
> great!
>
> direct connection to the "agent domain". For example "The client signals to
> the agent domain its desire to move..."
> Linden client, Web browsers, i.e. stateless clients, also don't keep state.
> So if we ever were to have a Web-browser-based viewer for a web of virtual
> worlds, we wouldn't be able to do what is suggested in this entire section.
>
> These protocols hinted at in this section are the crux of interoperability.
> I understand this is just the intro document, and it's not supposed to have
> all the details, that's fine. If you go ahead with the protocol hinted at
> here, then it is important to note somewhere in this intro document that it
> assumes stateful clients, and that Web browser viewers (that aren't browser
> plugins) are N/A.
>
> virtual world inteoperability demands from the viewer software. I used to
> think that web browsers were an evolutionary dead-end, but with the
> running verifiably-secure native code on Web browsers, I came to change my
> mind about this. Since the Web browser is the ubiquitous client software, it
> seems like a bad move to exclude this client from interoperability for
> virtual worlds, because we're only going to see more 3D immersion, not less,
> on web browsers.
>
> ----- Comment 9 -----
> Section 4.3:
>
> more standard terminology. Assets are stored in persistent storage. There's
> technical terminology for "in world":  assets that are referenced by a 3D
> scene. There's also technical terminology for "at rest": assets that are not
> referenced by a 3D scene directly but that are referenced by other resources
> like a user's inventory or scripts.
>
> decision of each virtual world. The scene server may have its own assets, or
> it may have its own asset storage server on the same data center, or it may
> use amazon. It may pre-fetch or may perform lazy fetch. It may cache or it
> may not. It doesn't matter for the purposes of interoperability.
> clients is an internal decision of each virtual world; in fact, a central
> part of the client(viewer)-server protocol, of which there should be many.
> It may send them on-line via UDP; it may zip them up in a zip file and send
> them; it may tell the client to fetch them from another server. It doesn't
> matter.
>
> Interoperability should not impose any conditions whatsoever on how these
> things are done, or the word "interoperability" will start moving into the
> realm of internal virtual world architecture, which is something this group
> probably should not be doing, lest alienating potential parties. Even in the
> small ecosystem of OpenSimulator, we are already seeing a variety of new
> clients being developed that have nothing to do with the Linden Lab client
> (e.g. Unity3D). That's a direction that we very much encourage.
>
> ----- Comment 11 -----
> Section 4.2.2:
>
> This section seems to be implying that host based trust carried by X.509 /
> PKIX certificates will ensure that the receiving party will honor the
> asset's metadata. These (i.e. certificates and honoring the metadata) are
> two different things. It should be made clear that, just because all parties
> are who they say they are, it doesn't mean that they will honor the
> metadata.
>
> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sat, 18 Sep 2010 21:09:00 -0700

morgaine,

thanks for your viewpoint. i feel compelled to respond with a few points.

first, if you remember from the conversation last year about whether
the VW in VWRAP stood for "Virtual World" or "Virtual Worlds," the
consensus was we wanted to describe mechanism, not policy. that is to
say, an operator of a VWRAP compliant region could make up their own
mind whom they allowed to rez avatars in their region and which
service providers they trust. so if someone like linden wanted to
setup a walled garden, that would be perfectly acceptable. (though i
agree with you that this example is the least interesting type of
thing you could do with a virtual world.)

secondly, VWRAP is not now, nor has it ever been a protocol to enable
interoperability BETWEEN virtual worlds. there is a mailing list for
such discussions: [email-masked]. at the MMOX BoF, we were unable to
find consensus on terminology, much less a consensus view on how to
achieve it. VWRAP is not a mechanism for teleporting between two
worlds (like Second Life or World of Warcraft.) at the end of the MMOX
BoF, you mentioned your interest in this use case and Lisa Dusseault
suggested the MMOX mailing list remain open for discussion of this use
case. the OGPX mailing list and later this group were chartered to
develop a protocol used to communicate information between hosts
simulating one ore more virtual worlds.

in short, the consensus of this group has generally been to describe
the mechanisms one could use to build a single virtual world but does
not dictate that this world be a singleton. in other words, we do not
force operators of virtual world services to play in a single, global
virtual world. if they want to do that, great. but i suspect there may
be governmental, corporate and educational participants who will want
to have "private" virtual worlds, much like enterprises frequently
operate corporate intranets.

while i understand that your interest is solely in the "tourist
model," i would remind you that supporting only this model would
require us to recharter this working group. pitching the existing
intro draft and starting from scratch would not give you what you
want. the intro draft MUST reflect the working groups charter.

david and i, as authors of the intro draft, have solicited your input
on several occasions to ensure that your interests were reflected in
the documents. i was holding up on publishing a new revision of the
intro because (like i mentioned earlier) i wanted to include your use
case in the next draft revision. what you should probably do now is
provide us (the authors) with a detailed analysis of the text in
question along with recommended changes.

please note, however, you cannot remove other participant's use cases.
but you can more accurately describe the use case you would like to
have added to the text. this is what diva did and her comments will
definitely be taken into consideration.

so please. please. please. if you want your use case added to the
intro, please write down what your detailed concerns are with the
existing document. send those concerns to either david or i in private
or to the list.

-cheers
-meadhbh

i appreciate your comments about the intro draft and am waiting to see
comments on specific sections of the document.
-
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

On Sat, Sep 18, 2010 at 5:00 PM, Morgaine
<[email-masked]> wrote:
> This problem is with us because it all started with OGP, a product of a
>> configuration of OpenSimulator-based worlds is a "standalone" configuration
>> where both the scene service and all the resource services of that world
>> execute in one single process of one machine. In a standalone VW system,
>> none of the services (e.g. assets, inventory, etc) are "distributed."
>> Furthermore, as explained above, the OpenSimulator framework also supports
>> the existence of single-process virtual worlds that include the renderer
>> itself.
>>
>> virtual world" composed of multiple services under the authority of multiple
>> interoperability. I understand this is just the intro document, and it's not
>> supposed to have all the details, that's fine. If you go ahead with the
>> protocol hinted at here, then it is important to note somewhere in this
>> intro document that it assumes stateful clients, and that Web browser
>> viewers (that aren't browser plugins) are N/A.
>>

---

From: "Hurliman, John" <[email-masked]>
Date: Sat, 18 Sep 2010 22:36:31 -0600

You completely lost me. We're not addressing interoperability between virtual worlds, but we are addressing communication between multiple virtual worlds? What is the purpose of the communication if not for interop? And then,

"...consensus of this group has generally been to describe the mechanisms one could use to build a single virtual world..."

I don't remember reaching that consensus. Wasn't Joshua's whole talk about how we don't want to describe the mechanisms to build a virtual world, but only the mechanisms for communication between worlds? And we're calling this something other than interoperability now?

I'm sure this is just a misinterpretation of your e-mail as we've been on roughly the same page this far, I just want to make sure I still understand.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Meadhbh Hamrick
> Sent: Saturday, September 18, 2010 9:09 PM
> To: Morgaine
> Cc: [email-masked]
> Subject: Re: [vwrap] Comments on http://tools.ietf.org/html/draft-ietf-
> vwrap-intro-00
>
> morgaine,
>
> > On Tue, Sep 7, 2010 at 4:56 PM, Cristina Videira Lopes
> <[email-masked]>
> > wrote:
> >>
> advance
> virtual
> scope
> indeed,
> each
> multiple
> >> For some background on the virtual world model assumed by
> OpenSimulator,
> >> see
> worlds
> world.
> configuration
> multiple
> operators
> relate
> emerging
> multiple
> where
> similar
> "region
> should
> state.
> There's
> assets, or
> central
> these

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sat, 18 Sep 2010 22:05:34 -0700

i think it's a language issue. VWRAP does not define interop between
Second Life and World of Warcraft (two different virtual worlds.) it
DOES define mechanisms individual hosts can use to communicate between
each other to simulate a virtual world. it does not require there to
be a single virtual world (like DNS "requires" you to point at the 13
canonical root servers.)

VWRAP allows simulation services to be provided by organizations
distinct from user authentication. in the "original" VWRAP model, the
user authentication service would direct the client to a space server
that defined the shape of the world and the
adjacency of regions. for the sake of discussion, let's call a virtual
world the set of all simulation regions and the adjacency graph that
connects them. so in the "original" model, the user authentication
service effectively dictates the shape of the virtual world the client
sees because it gives the client a capability to the space server.

but VWRAP virtual worlds separate simulation from user authentication;
so it's possible (but not required) that regions may be operated by
organizations other than those that provided the user authentication
service.

but VWRAP is a protocol, not an implementation. it defines mechanism,
but not policy. that means if all the parties are hip to it, a single
simulator could exist in two virtual worlds. that is, it is possibly
for user authentication service 'A' to place region '1' on one place
on the map while authentication service 'B' places region '1' at a
completely different location.

so the question is... if two avatars are in region 1; one of which
logged in with auth service A and the other with auth service B, are
they in the same "virtual world?" what happens when they start walking
together towards a region boundary? when they cross the region
boundary, they could potentially wind up in radically different
places.

the hypergrid solution is to define a single virtual world. regions
live in ONE place on a single global map. there's a single adjacency
map and everyone gets the same map. authentication services do not
direct clients to different space servers, there's only one.

the linden legacy solution is to define a single virtual world.
regions live in ONE place on a single global map, but there's only one
auth service.

the tourist model is that the regions maintain their own adjacency
graph, but it's really the clients that maintain the graph (and can
change it if they really want to.)

so when we say that VWRAP _COULD_ be used to build a single virtual
world, it means that you COULD build the linden model, the "original"
VWRAP model or the tourist model virtual worlds, but there is no
requirement (in the protocol) to do so.

i think the big confusion here is what the word "COULD" means. it
doesn't mean you MUST build in a single virtual world, but that you (a
deployer) COULD build a single virtual world if everyone else wants
to.

hope this clarifies things.

-cheers
-meadhbh
--

---

From: "Hurliman, John" <[email-masked]>
Date: Sun, 19 Sep 2010 00:20:18 -0600

> direct clients to different space servers, there's only one.

It could be another terminology mismatch but I don't think that's accurate. In the Hypergrid model, a collection of simulations share an adjacency graph by connecting to a single space service to form a "world" or "grid". But that space service can also point to simulations in other adjacency graphs or worlds/grids that have a different space service (and live in another administrative domain). So a region lives in one place in the local map and in a different place on other foreign maps. It's vaguely similar to how web hyperlinks work which is where the Hypergrid name came from. You could also change a few protocols bits if you wanted to always communicate with the space service in the same administrative domain as your authentication service and you would get the same behavior as what you describe for VWRAP.

The rest of your e-mail cleared things up; just a terminology issue as I suspected. I have some concerns that we're all in basic agreement but disagreeing over terminology still. No one can point to an actual use case where a participant on this list is saying "I don't think that should be allowed or included in our standardization effort", but every e-mail going back and forth is a warning about ignoring the tourist model or dropping support for the walled garden model.

John

---

From: Fleep Tuque <[email-masked]>
Date: Sun, 19 Sep 2010 08:29:22 -0400

Hi all,

I'm sure I need to go back through and re-read some of these documents to
find definitions, but I must be missing something entirely.  I've been
lurking on this list for some months and the statement that "VWRAP is not
now, nor has it ever been a protocol to enable
interoperability BETWEEN virtual worlds" took me completely by surprise.
I've been under the impression that was the entire point of this effort!

The OpenSim model described by Cristina, and the concerns raised by the
message at the start of this thread, pretty closely reflect my views and
concerns.  A consortia of universities is developing in which each
university will operate its own "world" - using their own access and
authentication schemes, internal system architecture, etc. - but allow our
researchers/students to be able to connect and go to the worlds of other
participating members to collaborate on research projects.  We need
protocols to help establish the ground rules for that connection, and what
the baseline requirements are for our "world" systems to be able to
communicate with one another, but ideally to be as minimally
intrusive/restrictive as possible.

Part of the interest in this experiment is similar to the "laboratories of
democracy" model in which each institution CAN and SHOULD do its own thing
internally so we can see what sorts of best practices and innovation in
internal system design emerges.  (In fact we have little choice, since each
institution is bound by different laws and policies governing things like
authentication and student data.) In our use case, this is not a "tourist"
model OR a "walled garden" model - it's both!  Each institution
intends/needs to have areas of their "world" that are off limits to other
institutions, and some areas that are accessible to members of the
consortia.  Figuring out which bits we need to pass back and forth to make
this work is, I thought, what VWRAP would be addressing.

I will go back through and re-read the source documents with Meadhbh's
comments in mind, but I wanted to chime in and say Cristina's concerns and
perspective pretty closely represent my interests as well.  And I think it's
a mistake to frame the conversation as a "tourist" model vs a "walled
garden" model even hypothetically, since as far as I can tell, we are much
more likely to see hybrids of the two than any pure implementation of either
in the ecosystem of worlds that Cristina rightly points out are already
developing.  In any case, a protocol that assumes only one world seems on
its face of very little value to _anyone_ if the point is not to have
interoperability between worlds using the protocol!

Confused and befuddled,

- Chris/Fleep

Chris M. Collins (SL: Fleep Tuque)
Project Manager, UC Second Life
Second Life Ambassador, Ohio Learning Network
UCit Instructional & Research Computing
University of Cincinnati
406E Zimmer Hall
PO Box 210088
Cincinnati, OH 45221-0088
(513)556-3018
[email-masked]

UC Second Life:   http://homepages.uc.edu/secondlife
OLN Second Life: http://www.oln.org/emerging_technologies/emtech.php

---

From: Cristina Videira Lopes <[email-masked]>
Date: Sun, 19 Sep 2010 09:37:16 -0700

In defense of Meadhbh's position, the charter for VWRAP does, indeed, 
support what she is saying, down to "a collaborative 3-dimensional 
virtual environment" and "An avatar exists in at most one location 
within a shared virtual space.":
http://tools.ietf.org/wg/vwrap/charters

Charters are the binding goals of working groups, I think. Hence my 
review stated as "this does not reflect the goals of the OpenSimulator 
project, and I don't know what to make of it." I was truly puzzled when 
I read the intro doc.

But now that I thought more about, I think there's a way out of this 
puzzlement. In my spectrum of requirements for clients, there is a point 
in there where one assumes the existence of one, and the same, client. 
Let's make this group focus on that.  We can assume, roughly, the Linden 
Lab client, or some variation of it, since I think that this group does 
not have representatives from other radically different viewers. The 
thing that needs to be revised, I think, is the very strong interference 
that the intro document makes wrt the internals of each virtual world 
server-side system -- that is never going to fly, not even among 
operators of virtual worlds of the same species! We are already seeing 
that in the small ecosystem of OpenSimulator-based virtual worlds.

---
Personally, I'm becoming more and more interested in web-browser-based 
viewers, or something like them. I.e. viewers that are simply shells 
that receive, essentially, a lambda implementing the viewer itself. 
That's the way to go. But that doesn't exist yet, not in production at 
least.

Fleep Tuque wrote:
> Hi all,
>
> I'm sure I need to go back through and re-read some of these documents 
> to find definitions, but I must be missing something entirely.  I've 
> been lurking on this list for some months and the statement that 
> "VWRAP is not now, nor has it ever been a protocol to enable
> interoperability BETWEEN virtual worlds" took me completely by 
> surprise.  I've been under the impression that was the entire point of 
> this effort!
>
> The OpenSim model described by Cristina, and the concerns raised by 
> the message at the start of this thread, pretty closely reflect my 
> views and concerns.  A consortia of universities is developing in 
> which each university will operate its own "world" - using their own 
> access and authentication schemes, internal system architecture, etc. 
> - but allow our researchers/students to be able to connect and go to 
> the worlds of other participating members to collaborate on research 
> projects.  We need protocols to help establish the ground rules for 
> that connection, and what the baseline requirements are for our 
> "world" systems to be able to communicate with one another, but 
> ideally to be as minimally intrusive/restrictive as possible.
>
> Part of the interest in this experiment is similar to the 
> "laboratories of democracy" model in which each institution CAN and 
> SHOULD do its own thing internally so we can see what sorts of best 
> practices and innovation in internal system design emerges.  (In fact 
> we have little choice, since each institution is bound by different 
> laws and policies governing things like authentication and student 
> data.) In our use case, this is not a "tourist" model OR a "walled 
> garden" model - it's both!  Each institution intends/needs to have 
> areas of their "world" that are off limits to other institutions, and 
> some areas that are accessible to members of the consortia.  Figuring 
> out which bits we need to pass back and forth to make this work is, I 
> thought, what VWRAP would be addressing.
>
>
> comments in mind, but I wanted to chime in and say Cristina's concerns 
> and perspective pretty closely represent my interests as well.  And I 
> think it's a mistake to frame the conversation as a "tourist" model vs 
> a "walled garden" model even hypothetically, since as far as I can 
> tell, we are much more likely to see hybrids of the two than any pure 
> implementation of either in the ecosystem of worlds that Cristina 
> rightly points out are already developing.  In any case, a protocol 
> that assumes only one world seems on its face of very little value to 
> _anyone_ if the point is not to have interoperability between worlds 
> using the protocol!
>
>
> Confused and befuddled,
>
> - Chris/Fleep
>
>
> [email-masked] <mailto:[email-masked]>
>
> ------------------------------------------------------------------------
>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sun, 19 Sep 2010 10:50:52 -0700

VWRAP is a protocol. it is not an implementation. the protocol DOES
NOT require you to adhere to any one single deployment model. what
we're discussing here is the degree to which different deployment
models are highlighted as examples and which will be used to define
the problem domain for the protocol.

on this list we have informally use the ostensive definition to
describe deployment patterns for VWRAP. that is, we've said things
like "look at how second life does it." or "we want to do it like
OpenSim."

there's a problem with this in that our protocols need to describe the
mechanisms used to communicate. we cannot say "we're doing things like
HyperGrid" and be finished. rather, we need to identify those features
of hypergrid that we like, then the features of traditional opensim,
then the features of second life. on top of that we can hypothesize
some features we like that are not demonstrated in any existent
system.

morgaine has complained that we have not mentioned "the tourist model"
in the specifications. while it's true we have infrequently used the
term "tourist model," we have defined a system by which the tourist
model, the walled garden model and the hypergrid model can all be
represented. what we don't do is say... "hey look! here's
hypergrid!!!!"

the way we describe different deployment models is by describing
trust, service extent and service establishment.

for the sake of argument, let's call "trust" a collection of
identities, each with "privilege" to perform a set of operations on a
set of "sensitive resources". (let's table the discussion of
capabilities and X.509 certificates, that are carriers of trust, for
the moment.)

now let's call service extent the collection of hosts over which some
_data_ is considered valid.

service establishment is the process by which a client (not always a
user agent) gets a capability to access some data or manipulate state.

so for the traditional linden legacy, walled garden model, it's easy.
all server entities are managed by the same organization and therefore
inherently trust each other. user agents demonstrate their
trustworthiness by providing a username and password. service extent
is also simple; data about region adjacency is shared across the
entire, closed world. service establishment is easy too, the client
logs in and the authentication service (which the client implicitly
trusts) gives the client a list of capabilities for various services.

we can refine this model by adding trusted third party services to the
mix. let's say that i, as a grid deployer, don't want to implement an
asset service (or a chat service or a map tile server or a ... ) so
rather than running my own asset service, i contract with a trusted
third party (call it "assets R' us".) out of band, i make an agreement
with assets R' us and they provide me with some protocol endpoint from
which i can request an interface for specific user's assets. i (the
auth service) turn around and provide the user specific asset access
endpoint to the client.

in both models, the client does not need to be aware that there is a
trust relationship between me (the auth service provider) and assets
R' us (the asset service provider)

this model is vaguely similar to hypergrid or OSGrid where there are
some central services and some services that are distributed.

but this model gives a lot of power to the auth service. it also
relies on a strong trust relationship between the auth service and
other service providers. what if you want to be able to point your
viewer just anywhere and (modulo local region policy) your avatar
would just rez there. the client could tell the region where to find
it's assets (again modulo local region policy like "i won't rez assets
from the pirate bay asset service, but i will rez them from amazon's
asset service.") there's nothing wrong with this model, and despite
what you've heard, it's been supported from day one.

why is there such consternation then? because when people look at the
drafts they're expecting to see functional specifications for virtual
worlds. what they see instead are protocol descriptions. you will not
see us mention "tourist model" or "open sim" or even "linden lab" in
the charter, the intro or the normative specifications. this is
because using the ostensive definition for interoperability is
"wrong." if we said, "VWRAP is just like hypergrid" then we would need
hypergrid to stop evolving. ditto for second life and pre-HG opensim.

so in conclusion, we WANT to support multiple models, not just the
tourist model. not just the linden model. not just the hypergrid
model. we WANT to be able to specify a protocol that is useful for
each of these virtual world models.we WANT people to be able to play
around with the model and use bits and pieces of the protocol as they
see fit.

we WANT to support multiple instances of virtual worlds and give
individual deployers the decision of which bits of the protocol they
wish to support. like if OpenSim decided to use VWRAP auth and asset
access, but not VWRAP teleport, that's still okay.

it does, however, degrade the ability of any system to talk to any
other system using only the protocol defined by this group. but that's
probably okay. for instance, did you know that 802.11b is not exactly
the same as WiFi? WiFi (and WPA) are "profiles" of the 802.11?
protocol series. WiFi specifies which options of 802.11 are acceptable
for interoperability. i think we're probably headed the same way with
VWRAP. VWRAP as a collection of underlying protocols will be specified
to the degree that software developers can write middleware
implementing the standard(s). Deployers or groups of deployers and
other software developers will then step in and say... "okay... for my
grid, we're using these options..."

it's not big-I interoperability, but given the fact that even our
small group is so fractured, i think we may want to shoot for little-i
interop first.

-cheers
-meadhbh

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sun, 19 Sep 2010 11:01:53 -0700

cool!

i think we're all headed towards something resembling consensus.

you've provided me with more than enough input for me to whip out a
new draft of the intro draft. i think we can word it in such a way
that it doesn't alienate anyone on this list.

morgaine, i know you hate the existing draft, but if you could provide
me ANY input, i'll be happy to smush it into the intro draft. i
_think_ i understand your position and what you want with the tourist
model, but after several weeks of promising you're going to get text
to the list, you still haven't produced anything. (yes, that's
dangerously close to throwing rocks in glass houses on my part; i'm
late with several revisions myself.)

but i guess what i'm saying is, i would like to pen another intro
draft that takes recent discussions on the list into account. it will
not be perfect. if i flub it up, please believe me that it's due to me
misunderstanding you rather than me trying to steamroller an agenda.

that being said, i'm going to go start writing now. i hope to be able
to publish something today or tomorrow. then i'll ask everyone to
review it and tell me what you think i got wrong.

-cheers
-meadhbh

On Sun, Sep 19, 2010 at 9:37 AM, Cristina Videira Lopes
<[email-masked]> wrote:
> support what she is saying, down to "a collaborative 3-dimensional virtual
> environment" and "An avatar exists in at most one location within a shared
> virtual space.":
> Charters are the binding goals of working groups, I think. Hence my review
> stated as "this does not reflect the goals of the OpenSimulator project, and
> I don't know what to make of it." I was truly puzzled when I read the intro
> doc.
>
> puzzlement. In my spectrum of requirements for clients, there is a point in
> there where one assumes the existence of one, and the same, client. Let's
> make this group focus on that.  We can assume, roughly, the Linden Lab
> client, or some variation of it, since I think that this group does not have
> representatives from other radically different viewers. The thing that needs
> to be revised, I think, is the very strong interference that the intro
> document makes wrt the internals of each virtual world server-side system --
> that is never going to fly, not even among operators of virtual worlds of
> the same species! We are already seeing that in the small ecosystem of
> OpenSimulator-based virtual worlds.
>
> ---
> viewers, or something like them. I.e. viewers that are simply shells that
> receive, essentially, a lambda implementing the viewer itself. That's the
> way to go. But that doesn't exist yet, not in production at least.
>
> Fleep Tuque wrote:
>
> Hi all,
>
> ________________________________

---

From: David W Levine <[email-masked]>
Date: Sun, 19 Sep 2010 15:54:34 -0400

The "One avatar in place" restriction touches remarkably little of the
working group's remit. I've argued against it, as it's very much a policy
proscription not a protocol design issue. Allowing an agent to project
multiple avatars into the greater grid adds very little complexity to the
collective protocols, and frankly should be a policy choice of the people
deploying the service(s).

If you look at the deploymet patterns document from last spring, you'll see
that I strongly encourage thinking of VWRAP as a set of services which can
be composed to allow many different deployments. In general, the matter of
how the services compose at run time, and which policies are applied at run
time, should be accounted for as "Do we permit people to make choices" and
"MUST we constrain this choice"  When we hit "We must constrain this
choice" I think we need to offer very strong justifications. (e.g. "If you
don't constrain this, you can't really do interpo."

- David
~ Zha

  From:       Cristina Videira Lopes <[email-masked]>                                                                                     
                                                                                                                                             
  To:         "[email-masked]" <[email-masked]>                                                                                              
                                                                                                                                             
  Date:       09/19/2010 01:05 PM                                                                                                            
                                                                                                                                             
  Subject:    Re: [vwrap] Comments	on	http://tools.ietf.org/html/draft-ietf-vwrap-intro-00                                             
                                                                                                                                             
  Sent by:    [email-masked]                                                                                                         

Charters are the binding goals of working groups, I think. Hence my review
stated as "this does not reflect the goals of the OpenSimulator project,
and I don't know what to make of it." I was truly puzzled when I read the
intro doc.

But now that I thought more about, I think there's a way out of this
puzzlement. In my spectrum of requirements for clients, there is a point in
there where one assumes the existence of one, and the same, client. Let's
make this group focus on that.  We can assume, roughly, the Linden Lab
client, or some variation of it, since I think that this group does not
have representatives from other radically different viewers. The thing that
needs to be revised, I think, is the very strong interference that the
intro document makes wrt the internals of each virtual world server-side
system -- that is never going to fly, not even among operators of virtual
worlds of the same species! We are already seeing that in the small
ecosystem of OpenSimulator-based virtual worlds.

---

Fleep Tuque wrote:
      Hi all,

      I'm sure I need to go back through and re-read some of these
      documents to find definitions, but I must be missing something
      entirely.  I've been lurking on this list for some months and the
      statement that "VWRAP is not now, nor has it ever been a protocol to
      enable
      interoperability BETWEEN virtual worlds" took me completely by
      surprise.  I've been under the impression that was the entire point
      of this effort!

      I will go back through and re-read the source documents with
      Meadhbh's comments in mind, but I wanted to chime in and say
      Cristina's concerns and perspective pretty closely represent my
      interests as well.  And I think it's a mistake to frame the
      conversation as a "tourist" model vs a "walled garden" model even
      hypothetically, since as far as I can tell, we are much more likely
      to see hybrids of the two than any pure implementation of either in
      the ecosystem of worlds that Cristina rightly points out are already
      developing.  In any case, a protocol that assumes only one world
      seems on its face of very little value to _anyone_ if the point is
      not to have interoperability between worlds using the protocol!

      Confused and befuddled,

      - Chris/Fleep

---

From: Cristina Videira Lopes <[email-masked]>
Date: Sun, 19 Sep 2010 17:15:20 -0700

Virtual world interoperability should scope itself to the following:
(1) If you want your users to visit other virtual worlds, then you 
should support "these" protocols
(2) If you want to accept visitors from other virtual worlds, then you 
should support "these other" protocols

That's it. Everything else should be off limits for VW interoperability.

This is relatively easy to do under the condition of one single client. 
It's extremely difficult (read impossible) when there are many -- for 
that, we'd be better off using the LESS model/protocol suggested by Jon 
Watte, i.e. we don't really send the user agent there, we send a proxy 
of the the user agent.

Not all clients are the same, though. There are fat clients like LL's, 
Forterra's, WoW, etc. and then there are thin ones like the Web browser. 
The Web browser happens to have the wonderful property of including an 
interpreter for a dynamic programming language, so it can do things like 
taking in entire viewer programs dynamically as it makes its first 
request to a VW server-side. With this, scene server / viewer protocols 
become a non-issue: the client simply gets a new viewer program as it 
moves from world to world.

Interoperability under the web-browser viewer model is as simple as 
putting in place a single sign-on authentication protocol (not the same 
as openid), and then, additionally, agreeing on data formats for asset 
representation and asset exchange protocols if the worlds wish to engage 
in asset exchanges. And that's what the Hypergrid 1.5 does.

(FYI, I'm just finishing an implementation of HG1.5 for non-virtual 
world web-based systems.)

But, again, I'm not sure that this group, as chartered, is about virtual 
world interoperability. It seems that it's about communication and trust 
issues in a generic distributed service composition model, independent 
of what the services do, which seems really ambitious! And that's where 
I got all confused. On the one hand, we should not derail what has been 
chartered long ago and, supposedly, consented by the entire group; on 
the other, the charter and that intro document suggest that what's going 
to come out of here is not going to have a strong impact in the practice 
of virtual worlds, because it makes unacceptable interferences on the 
server side.

But I  suggest that we try to incrementally improve the existing 
documents, rather than making a sharp left turn.

David W Levine wrote:
> working group's remit. I've argued against it, as it's very much a 
> policy proscription not a protocol design issue. Allowing an agent to 
> project multiple avatars into the greater grid adds very little 
> complexity to the collective protocols, and frankly should be a policy 
> choice of the people deploying the service(s).
>
> If you look at the deploymet patterns document from last spring, 
> you'll see that I strongly encourage thinking of VWRAP as a set of 
> services which can be composed to allow many different deployments. In 
> general, the matter of how the services compose at run time, and which 
> policies are applied at run time, should be accounted for as "Do we 
> permit people to make choices" and "MUST we constrain this choice" 
> When we hit "We must constrain this choice" I think we need to offer 
> very strong justifications. (e.g. "If you don't constrain this, you 
> can't really do interpo."
>
> - David
> ~ Zha
>
>
> Inactive hide details for Cristina Videira Lopes ---09/19/2010 
> 01:05:21 PM---In defense of Meadhbh's position, the charter for 
> Cristina Videira Lopes ---09/19/2010 01:05:21 PM---In defense of 
> Meadhbh's position, the charter for VWRAP does, indeed, support what 
> she is saying, d
>
>
> From: 	
> Cristina Videira Lopes <[email-masked]>
>
> To: 	
> Date: 	
> 09/19/2010 01:05 PM
> Subject: 	
> Re: [vwrap] Comments on 
> http://tools.ietf.org/html/draft-ietf-vwrap-intro-00
>
> Sent by: 	
> [email-masked]
>
> within a shared virtual space.":_
> __http://tools.ietf.org/wg/vwrap/charters_
>
> project, and I don't know what to make of it." I was truly puzzled 
> when I read the intro doc.
>
> puzzlement. In my spectrum of requirements for clients, there is a 
> point in there where one assumes the existence of one, and the same, 
> client. Let's make this group focus on that. We can assume, roughly, 
> the Linden Lab client, or some variation of it, since I think that 
> this group does not have representatives from other radically 
> different viewers. The thing that needs to be revised, I think, is the 
> very strong interference that the intro document makes wrt the 
> internals of each virtual world server-side system -- that is never 
> going to fly, not even among operators of virtual worlds of the same 
> species! We are already seeing that in the small ecosystem of 
>             I'm sure I need to go back through and re-read some of
>             these documents to find definitions, but I must be missing
>             something entirely. I've been lurking on this list for
>             some months and the statement that "VWRAP is not now, nor
>             has it ever been a protocol to enable
>             interoperability BETWEEN virtual worlds" took me
>             completely by surprise. I've been under the impression
>             that was the entire point of this effort!
>
>             The OpenSim model described by Cristina, and the concerns
>             raised by the message at the start of this thread, pretty
>             closely reflect my views and concerns. A consortia of
>             universities is developing in which each university will
>             operate its own "world" - using their own access and
>             authentication schemes, internal system architecture, etc.
>             - but allow our researchers/students to be able to connect
>             and go to the worlds of other participating members to
>             collaborate on research projects. We need protocols to
>             help establish the ground rules for that connection, and
>             what the baseline requirements are for our "world" systems
>             to be able to communicate with one another, but ideally to
>             be as minimally intrusive/restrictive as possible.
>
>             "laboratories of democracy" model in which each
>             institution CAN and SHOULD do its own thing internally so
>             we can see what sorts of best practices and innovation in
>             internal system design emerges. (In fact we have little
>             choice, since each institution is bound by different laws
>             and policies governing things like authentication and
>             student data.) In our use case, this is not a "tourist"
>             model OR a "walled garden" model - it's both! Each
>             institution intends/needs to have areas of their "world"
>             that are off limits to other institutions, and some areas
>             that are accessible to members of the consortia. Figuring
>             out which bits we need to pass back and forth to make this
>             work is, I thought, what VWRAP would be addressing.
>
>
>             I will go back through and re-read the source documents
>             with Meadhbh's comments in mind, but I wanted to chime in
>             and say Cristina's concerns and perspective pretty closely
>             represent my interests as well. And I think it's a mistake
>             to frame the conversation as a "tourist" model vs a
>             "walled garden" model even hypothetically, since as far as
>             I can tell, we are much more likely to see hybrids of the
>             two than any pure implementation of either in the
>             ecosystem of worlds that Cristina rightly points out are
>             already developing. In any case, a protocol that assumes
>             only one world seems on its face of very little value to
>             _anyone_ if the point is not to have interoperability
>             between worlds using the protocol!
>
>
>             Confused and befuddled,
>
>             - Chris/Fleep
>
>
>             (513)556-3018_
>             [email-masked] <mailto:[email-masked]>
>
>             UC Second Life: _http://homepages.uc.edu/secondlife_
>             OLN Second Life:
>             _http://www.oln.org/emerging_technologies/emtech.php_
>
>
>
>
>
>
>
>
>
>             [email-masked] <mailto:[email-masked]>
>             _https://www.ietf.org/mailman/listinfo/vwrap_
>               
>

---

From: Morgaine <[email-masked]>
Date: Mon, 20 Sep 2010 03:09:56 +0100

On Sun, Sep 19, 2010 at 5:09 AM, Meadhbh Hamrick <[email-masked]>wrote:
morgaine,

100% incorrect.

(And please stop mentioning World of Warcraft --- nobody has mentioned
interoperating with WoW, and the IETF is the wrong place for straw men.  In
VWRAP we are referring purely to virtual worlds that can share our data
model at this time, and there is no indication that WoW is in any way
relevant.)

Right at the start of the OGPX process, when it looked like draft writers
were trying to create a standard for walled gardens and avoiding VW interop,
I wrote this post in order to try to flush the foxes out of the henhouse:
http://www.ietf.org/mail-archive/web/ogpx/current/msg00112.html .  The
intention was to check that business interests weren't subverting the *
interoperable* part of the IETF mission statement.  There was near unanimity
on the list: apart from yourself, everyone was of the opinion that we were
working towards interop BETWEEN virtual worlds.  Indeed, it goes without
saying that people like Charles Krinke of OSgrid related to OGPX only in the
context of interop between separate virtual worlds.  The VW of OSgrid and
the VW of Second Life are certainly not one and the same world, they merely
share a data model and a protocol, in part.

This is at the heart of the issue.  It is because some people are avidly
writing drafts targeting the walled garden model of Second Life that we have
the situation highlighted by Crista, a working group with documents that
entirely fail to address interop between independent virtual worlds.

Morgaine.

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

On Sun, Sep 19, 2010 at 5:09 AM, Meadhbh Hamrick <[email-masked]>wrote:

> > On Tue, Sep 7, 2010 at 4:56 PM, Cristina Videira Lopes <
> [email-masked]>
> > wrote:
> >>
> by
> that
> of
> for
> on",
> so
> If
> no
> I
> Do
> web
> run
> go
> as
> Each
> non-existence
> as
> not
> to
> my
> /
> are