Subject: [vwrap] Call for a vote on interop BETWEEN independent virtual worlds or not

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

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

secondly, VWRAP is not now, nor has it ever been a protocol to enable
interoperability BETWEEN 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.

This does not reflect any consensus expressed in this group whatsoever.

Neither one walled garden nor multiple walled gardens are what this working
group is targeting, but the interoperability BETWEEN virtual worlds.  VWs
that do not wish to interoperate are catered for in VWRAP by a *deployment
pattern* in which they deny external connections from anywhere except the
hosts of their own network and do not use shared services.  Ever since David
wrote his document on deployments, we have always asserted that walled
gardens are simply a subset deployment of our general interop case.  Denying
communication is trivial, while achieving interop is hard.

Barry, since Meadhbh is working toward an entirely different goal than the
one that numerous people have repeatedly affirmed on this list, and is
writing documents to that effect, I suggest that you settle this matter once
and for all.  Please request a rough consensus on whether VWRAP is concerned
with interop BETWEEN virtual worlds, or is concerned merely with building
non-interacting walled gardens.

Without this decision, we will continue to have drafts that evade the key
interop question.

Morgaine.

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

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

> 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:
> > 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.
> >>
> >> 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.
> >>
> >> _______________________________________________
> >> vwrap mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/vwrap
> >
> >
> > _______________________________________________
> > vwrap mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/vwrap
> >
> >
>

---

From: Mike Dickson <[email-masked]>
Date: Mon, 20 Sep 2010 09:51:32 -0400

On 09/19/2010 10:41 PM, Morgaine wrote:
> On Sun, Sep 19, 2010 at 5:09 AM, Meadhbh Hamrick <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
I suspect we're getting wrapped around the axle on terminology and what 
"single virtual world" means.  At least I'd like to interpret it that 
way as it then matches the discussion over the past months.  Put another 
way we're not specifying a mechanism for interconnection between very 
different technologies (or more appropriately approaches to virtual 
worlds).  It's a single virtual world because it shares a single set of 
assumptions about how the services that make it up work together to 
provide services.  If I change in a significant way a service that 
doesn't match what VWRAP documents then I'm not able to participate in 
the VWRAP virtual world any longer.

The comment about a singleton is on target I think with this 
interpretation.  I can create a walled garden that doesn't interconnect 
with other "services".  It's using VWRAP and so a part of the VWRAP 
"Virtual World".

If thats not a correct interpretation then yes we have a huge issue.  If 
it is correct then perhaps we need to refine how we define terms since 
its caused alot of confusion.

Mike

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 20 Sep 2010 07:23:34 -0700

yup. i think we're definitely winding ourselves around the terminology axel.

kk. sounds like you're using the "web" terminology analogy. HTTP(S) is
the protocol used by browsers to create "the web." so you're saying
VWRAP should be the protocol suite that creates "the virtual world"?

but if i understand morgaine's issue correctly, she wants to force a
definition of "the virtual world." this would, it seems to me, to be
the equivalent of forcing HTTP(S) to include a definition of "the
web."

i'm fine with enumerating some use cases, and then building a model to
describe the different use cases, then building a protocol that fits
the model. that way we leave it up to individual deployers as to how
they wish to use the protocol.

so we have second life, opensim (classic), hypergrid and the tourist
model as use cases. we build a model that can represent protocol flows
for trust and service establishment in these use cases, and then we
build a protocol that specifies the format and semantics of these
protocol flows.

then software peeps implement these flows. i myself am interested in
implementing a more "middleware" approach, where policy decisions are
implemented as callouts or config files. once we have compatible
software, we can build deployments where people actually go out and
build virtual worlds.

-cheers
-meadhbh

On Mon, Sep 20, 2010 at 6:51 AM, Mike Dickson <[email-masked]> wrote:
> "single virtual world" means.  At least I'd like to interpret it that way as
> it then matches the discussion over the past months.  Put another way we're
> not specifying a mechanism for interconnection between very different
> technologies (or more appropriately approaches to virtual worlds).  It's a
> single virtual world because it shares a single set of assumptions about how
> the services that make it up work together to provide services.  If I change
> in a significant way a service that doesn't match what VWRAP documents then
> I'm not able to participate in the VWRAP virtual world any longer.
>
> interpretation.  I can create a walled garden that doesn't interconnect with
> other "services".  It's using VWRAP and so a part of the VWRAP "Virtual
> World".
>
> If thats not a correct interpretation then yes we have a huge issue.  If it
> is correct then perhaps we need to refine how we define terms since its
> caused alot of confusion.
>
> Mike
>
>
>

---

From: Morgaine <[email-masked]>
Date: Mon, 20 Sep 2010 16:20:08 +0100

On Mon, Sep 20, 2010 at 2:51 PM, Mike Dickson <[email-masked]> wrote:

Put another way we're not specifying a mechanism for interconnection between
very different technologies (or more appropriately approaches to virtual
worlds).

Unfortunately, no Mike, it's much worse than that.  Even if the technologies
of the worlds in question are not only compatible but *IDENTICAL*, Meadhbh
claims that we are not creating a protocol for interop BETWEEN those
worlds.  At all, whatsoever.

This cannot be allowed to stand, otherwise the entire purpose of VWRAP as an
interop protocol disappears, and instead VWRAP becomes a protocol for
building standalone, isolated worlds.  That is not what we're here for, and
it has never been --- we have affirmed the goal of interoperation between
VWs time and again on this list, repeatedly.

This issue needs to be cleared up without ambiguity.  We can't have a
prolific draft writer writing drafts that do not reflect the goals voiced by
almost everyone in this group since OGPX/VWRAP began.  Crista's post is
merely the latest expression of concern of many.

There is a clear disconnect here between the goal of non-interoperating
worlds, and the much more useful goal of VW interoperation that virtually
everyone else has been discussing and desiring.  We already have
non-interoperating worlds, lots of them!  Note that even Joshua mentions
interoperation of VWs in his latest post a few weeks ago, in which he
welcomed discussion of "*protocols for data transport between virtual world
instances*" --
http://www.ietf.org/mail-archive/web/vwrap/current/msg00253.html .

This needs resolving formally, otherwise our progress on resolving the
issues of VW interop is completely blocked.

Morgaine.

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

---

From: Jonathan Freedman <[email-masked]>
Date: Mon, 20 Sep 2010 11:27:15 -0400

Hello everyone,

>From what I can tell the drafts do support interoperability between the same
*class* of virtual world. The catch is that the language needs to be
significantly clearer. In fact, I would go so far as to say that the
introduction document should drop all references to use cases, focus on
describing the context (sandbox virtual worlds) and then be merged with the
foundation document.

I have approached editing the Intro document several times and it always
ended in despair. I believe the only rational way to move forward is to
integrate it into the Foundation document as a simple overview of the
context and proceed from there. If others support this direction, I would
be honoured to proceed with the first cut of such a merge.

I do want to state that interoperability between the *same class* of virtual
worlds seems like the proper end goal. The language needs to be unambiguous
and there is no point in distracting the consumer (of the ID)  with
discussions of use cases. Use cases, deployment strategies and the like
should be left up to interpretation. The formal documentation needs to focus
on the protocol rather than implementation.

Regards,

Jonathan Freedman

On Mon, Sep 20, 2010 at 11:20 AM, Morgaine
<[email-masked]>wrote:

> Put another way we're not specifying a mechanism for interconnection
> between very different technologies (or more appropriately approaches to
> virtual worlds).
>
>
> Unfortunately, no Mike, it's much worse than that.  Even if the
> technologies of the worlds in question are not only compatible but *
> IDENTICAL*, Meadhbh claims that we are not creating a protocol for interop
> BETWEEN those worlds.  At all, whatsoever.
>
> This cannot be allowed to stand, otherwise the entire purpose of VWRAP as
> an interop protocol disappears, and instead VWRAP becomes a protocol for
> welcomed discussion of "*protocols for data transport between virtual
> world instances*" --
>> it is correct then perhaps we need to refine how we define terms since its

-- 
Jonathan Freedman
President
Open Metaverse Foundation
+1 (514) 582-1533

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 20 Sep 2010 08:49:12 -0700

jonathan,

there was some discussion about dropping the use cases last year.

we can't simply say "this protocol is for OpenSim or Second Life"
because that would mean that any time those implementations change,
the scope of the protocol changes along with it.

so we came up with the idea of documenting those aspects of the type
of virtual world we were interested in so we would have bounds for our
protocol discussions. we wanted to focus on a relatively small set of
use cases and in david's words, "boil the ocean one thimbleful at a
time."

the list of virtual world features the group wanted to support turned
into the "deployment patterns" draft, portions of which got integrated
into the intro.

-cheers
-meadhbh

On Mon, Sep 20, 2010 at 8:27 AM, Jonathan Freedman
<[email-masked]> wrote:
> On Mon, Sep 20, 2010 at 11:20 AM, Morgaine <[email-masked]>
> wrote:
>>
>> technologies of the worlds in question are not only compatible but
>> IDENTICAL, Meadhbh claims that we are not creating a protocol for interop
>> welcomed discussion of "protocols for data transport between virtual world
>> instances" --

---

From: "Hurliman, John" <[email-masked]>
Date: Mon, 20 Sep 2010 09:59:11 -0600

This sounds like a reasonable approach to me. It seems to me that the reasons for having separate intro and foundation docs are historic, and a new iteration could merge these.

John

On Sep 20, 2010, at 8:27 AM, "Jonathan Freedman" <[email-masked]<mailto:[email-masked]>> wrote:

Hello everyone,

From what I can tell the drafts do support interoperability between the same *class* of virtual world. The catch is that the language needs to be significantly clearer. In fact, I would go so far as to say that the introduction document should drop all references to use cases, focus on describing the context (sandbox virtual worlds) and then be merged with the foundation document.

I have approached editing the Intro document several times and it always ended in despair. I believe the only rational way to move forward is to integrate it into the Foundation document as a simple overview of the context and proceed from there. If others support this direction, I would be honoured to proceed with the first cut of such a merge.

I do want to state that interoperability between the *same class* of virtual worlds seems like the proper end goal. The language needs to be unambiguous and there is no point in distracting the consumer (of the ID)  with discussions of use cases. Use cases, deployment strategies and the like should be left up to interpretation. The formal documentation needs to focus on the protocol rather than implementation.

Regards,

Jonathan Freedman

On Mon, Sep 20, 2010 at 11:20 AM, Morgaine <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
On Mon, Sep 20, 2010 at 2:51 PM, Mike Dickson <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

Put another way we're not specifying a mechanism for interconnection between very different technologies (or more appropriately approaches to virtual worlds).

Unfortunately, no Mike, it's much worse than that.  Even if the technologies of the worlds in question are not only compatible but IDENTICAL, Meadhbh claims that we are not creating a protocol for interop BETWEEN those worlds.  At all, whatsoever.

This cannot be allowed to stand, otherwise the entire purpose of VWRAP as an interop protocol disappears, and instead VWRAP becomes a protocol for building standalone, isolated worlds.  That is not what we're here for, and it has never been --- we have affirmed the goal of interoperation between VWs time and again on this list, repeatedly.

This issue needs to be cleared up without ambiguity.  We can't have a prolific draft writer writing drafts that do not reflect the goals voiced by almost everyone in this group since OGPX/VWRAP began.  Crista's post is merely the latest expression of concern of many.

There is a clear disconnect here between the goal of non-interoperating worlds, and the much more useful goal of VW interoperation that virtually everyone else has been discussing and desiring.  We already have non-interoperating worlds, lots of them!  Note that even Joshua mentions interoperation of VWs in his latest post a few weeks ago, in which he welcomed discussion of "protocols for data transport between virtual world instances" -- <http://www.ietf.org/mail-archive/web/vwrap/current/msg00253.html> http://www.ietf.org/mail-archive/web/vwrap/current/msg00253.html .

This needs resolving formally, otherwise our progress on resolving the issues of VW interop is completely blocked.

Morgaine.

On Mon, Sep 20, 2010 at 2:51 PM, Mike Dickson <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
On 09/19/2010 10:41 PM, Morgaine wrote:
On Sun, Sep 19, 2010 at 5:09 AM, Meadhbh Hamrick <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

This does not reflect any consensus expressed in this group whatsoever.
I suspect we're getting wrapped around the axle on terminology and what "single virtual world" means.  At least I'd like to interpret it that way as it then matches the discussion over the past months.  Put another way we're not specifying a mechanism for interconnection between very different technologies (or more appropriately approaches to virtual worlds).  It's a single virtual world because it shares a single set of assumptions about how the services that make it up work together to provide services.  If I change in a significant way a service that doesn't match what VWRAP documents then I'm not able to participate in the VWRAP virtual world any longer.

The comment about a singleton is on target I think with this interpretation.  I can create a walled garden that doesn't interconnect with other "services".  It's using VWRAP and so a part of the VWRAP "Virtual World".

If thats not a correct interpretation then yes we have a huge issue.  If it is correct then perhaps we need to refine how we define terms since its caused alot of confusion.

Mike

_______________________________________________
vwrap mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/vwrap>https://www.ietf.org/mailman/listinfo/vwrap

_______________________________________________
vwrap mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/vwrap>https://www.ietf.org/mailman/listinfo/vwrap

---

From: Cristina Videira Lopes <[email-masked]>
Date: Mon, 20 Sep 2010 09:04:18 -0700

That sounds like a good idea, Jonathan, but keep in mind that the 
foundation document suffers from the same problem of the intro document.

I agree that part of the issue is terminology. But part isn't. There's 
the deeper issue on whether VW interop needs anything more than 
client-server architectures powered by HTTP and [mostly] stateless thin 
clients, and then some additional protocols that work on, and with, this 
architecture. The documents leave no doubt that VW interop needs 
something *else* entirely, a new model and a VWRAP protocol suite, that 
is different, and in par, with HTTP(S); one where the client happens to 
play a much more active role than web browsers usually do.

I happen to disagree with that premise, but that's because one of my 
drives for interop is to stay as close to the Web as possible, and that 
includes trying to make the most of web browser clients, which have 
really interesting properties that foster diversity (and which the rest 
of the world uses).

But I understand that the world of technology doesn't stop with 
client-server and HTTP, and that lots of other distributed systems can 
be designed that are quite different from the Web. It seems that the 
charter of this group is to engage in the design of one such system. 
Which is both ambitious and slightly orthogonal to the issue of VW 
interop [on the Web].

WRT how to proceed. First, there should be one intro document only, not 
two. At the very least, if breaking away from the Web is what this group 
wants, that should be made clear somewhere in the intro document. If 
not, that intro document needs to commit a lot less than what the two 
documents do now. There's things in there that simply will not happen on 
the Web, period -- they won't happen in Unity-based web applications, 
and they won't happen in lots of other web-based VWs. They will only 
happen in a class of VWs that uses some version of the Linden Lab viewer 
as client. Maybe.

Jonathan Freedman wrote:
> Hello everyone,
>
> From what I can tell the drafts do support interoperability between 
> the same *class* of virtual world. The catch is that the language 
> needs to be significantly clearer. In fact, I would go so far as to 
> say that the introduction document should drop all references to use 
> cases, focus on describing the context (sandbox virtual worlds) and 
> then be merged with the foundation document.
>
> I have approached editing the Intro document several times and it 
> always ended in despair. I believe the only rational way to move 
> forward is to integrate it into the Foundation document as a simple 
> overview of the context and proceed from there. If others support this 
> direction, I would be honoured to proceed with the first cut of such a 
> merge.
>
> I do want to state that interoperability between the *same class* of 
> virtual worlds seems like the proper end goal. The language needs to 
> be unambiguous and there is no point in distracting the consumer (of 
> the ID)  with discussions of use cases. Use cases, deployment 
> strategies and the like should be left up to interpretation. The 
> formal documentation needs to focus on the protocol rather than 
> implementation.
>
> Regards,
>
> Jonathan Freedman
>
>
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Mon, Sep 20, 2010 at 2:51 PM, Mike Dickson <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     Put another way we're not specifying a mechanism for
>     interconnection between very different technologies (or more
>     appropriately approaches to virtual worlds).
>
>
>     *IDENTICAL*, Meadhbh claims that we are not creating a protocol
>     for interop BETWEEN those worlds.  At all, whatsoever.
>
>     This cannot be allowed to stand, otherwise the entire purpose of
>     VWRAP as an interop protocol disappears, and instead VWRAP becomes
>     a protocol for building standalone, isolated worlds.  That is not
>     what we're here for, and it has never been --- we have affirmed
>     the goal of interoperation between VWs time and again on this
>     list, repeatedly.
>
>     This issue needs to be cleared up without ambiguity.  We can't
>     have a prolific draft writer writing drafts that do not reflect
>     the goals voiced by almost everyone in this group since OGPX/VWRAP
>     began.  Crista's post is merely the latest expression of concern
>     of many.
>
>     There is a clear disconnect here between the goal of
>     non-interoperating worlds, and the much more useful goal of VW
>     interoperation that virtually everyone else has been discussing
>     and desiring.  We already have non-interoperating worlds, lots of
>     them!  Note that even Joshua mentions interoperation of VWs in his
>     latest post a few weeks ago, in which he welcomed discussion of
>     "/protocols for data transport between virtual world instances/"
>     -- http://www.ietf.org/mail-archive/web/vwrap/current/msg00253.html .
>
>     This needs resolving formally, otherwise our progress on resolving
>     the issues of VW interop is completely blocked.
>
>
>     Morgaine.
>
>
>
>
>
>     On Mon, Sep 20, 2010 at 2:51 PM, Mike Dickson <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>>         On Sun, Sep 19, 2010 at 5:09 AM, Meadhbh Hamrick
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>
>         I suspect we're getting wrapped around the axle on terminology
>         and what "single virtual world" means.  At least I'd like to
>         interpret it that way as it then matches the discussion over
>         the past months.  Put another way we're not specifying a
>         mechanism for interconnection between very different
>         technologies (or more appropriately approaches to virtual
>         worlds).  It's a single virtual world because it shares a
>         single set of assumptions about how the services that make it
>         up work together to provide services.  If I change in a
>         significant way a service that doesn't match what VWRAP
>         documents then I'm not able to participate in the VWRAP
>         virtual world any longer.
>
>         interpretation.  I can create a walled garden that doesn't
>         interconnect with other "services".  It's using VWRAP and so a
>         part of the VWRAP "Virtual World". 
>
>         If thats not a correct interpretation then yes we have a huge
>         issue.  If it is correct then perhaps we need to refine how we
>         define terms since its caused alot of confusion.
>
>         Mike
>
>
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Morgaine <[email-masked]>
Date: Mon, 20 Sep 2010 17:43:30 +0100

significantly clearer.

That sounds reasonable to me, Jonathan.  I believe that your first sentence
reflects everyone's understanding of our goals ever since we formed the
working group.  Only now has this odd "no interop between virtual worlds"
slant been placed on our goals.

Judging by the responses received here, it's clear that everyone else is
affirming in one way or another their interest in virtual worlds that
interoperate.  I certainly am.  I hope that we can confirm it as a matter of
record with the help of the WG Chairs.

Morgaine.

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

On Mon, Sep 20, 2010 at 4:27 PM, Jonathan Freedman <[email-masked]>wrote:

> Hello everyone,
>
> From what I can tell the drafts do support interoperability between the
> same *class* of virtual world. The catch is that the language needs to be
> virtual worlds seems like the proper end goal. The language needs to be
> unambiguous and there is no point in distracting the consumer (of the ID)
>  with discussions of use cases. Use cases, deployment strategies and the
> like should be left up to interpretation. The formal documentation needs to
> focus on the protocol rather than implementation.
>
> Regards,
>
> Jonathan Freedman
>
>
> On Mon, Sep 20, 2010 at 11:20 AM, Morgaine <[email-masked]
> > wrote:
>
>> On Mon, Sep 20, 2010 at 2:51 PM, Mike Dickson <[email-masked]>wrote:
>>
>> IDENTICAL*, Meadhbh claims that we are not creating a protocol for
>> interop BETWEEN those worlds.  At all, whatsoever.
>>
>> On Mon, Sep 20, 2010 at 2:51 PM, Mike Dickson <[email-masked]>wrote:
>>

---

From: Jonathan Freedman <[email-masked]>
Date: Mon, 20 Sep 2010 12:50:02 -0400

Hello,

I believe the key is to have (in completely unambiguous language) a listing
of features that would be supported by the greater VWRAP standard. A
definitive listing of features, rather than use cases, seems like a more
rational way to proceed. This can likely be distilled from the existing
drafts. Also, as Meadhbh points out, it is important to not tie the standard
to any existing protocol suite. As the VWRAP standard evolves, groups will
be able to adopt it. Interoperability between VWRAP and "Second Life" style
virtual worlds (or WoW or Eve Online or Minecraft) is outside the scope of
this process. Which isn't to say it would not be awesome ;)

Also, if we are careful, we do not exclude any type of client. The various
transport and application level protocols needed by VWRAP are accessible
from phat clients and web clients alike. There should be no need to describe
the ideal end clients as we would already have a listing of supported
feature sets.

Cheers,

Jonathan

On Mon, Sep 20, 2010 at 12:43 PM, Morgaine
<[email-masked]>wrote:

>> On Mon, Sep 20, 2010 at 11:20 AM, Morgaine <
>> [email-masked]> wrote:
>>

---

From: Joshua Bell <[email-masked]>
Date: Mon, 20 Sep 2010 10:07:19 -0700

> slant been placed on our goals.

The group's goals are formally described in the charter:

https://datatracker.ietf.org/wg/vwrap/charter/

... which, based on previous iterations of this discussion, we carefully
crafted to not try and nail down what a "virtual world" was so as not to
offend those who have an investment in any particular reading of that term.

> record with the help of the WG Chairs.

I'm having deja vu... no, wait, we have had this discussion before. Here's
one of my notes from Oct 2009:

http://www.ietf.org/mail-archive/web/ogpx/current/msg00509.html
<http://www.ietf.org/mail-archive/web/ogpx/current/msg00509.html>
... which is a response to a thread on exactly the same topic.

At the end of the day, we're attempting to describe protocols that allow
operators of virtual world services to interoperate such that users can
control avatars that move through it with the same client code, assuming
appropriate permissions. That's what's in the charter, and there's never
been disagreement about that that I'm aware of.

What we've learned from this discussion in previous iterations:

* If you call that scenario "multiple operators, multiple virtual worlds",
fine. But someone will disagree with your choice of terminology, and be
unwilling to adopt your terminology.

* If you call that scenario "multiple operators, one virtual world", fine.
But someone will disagree with your choice of terminology, and be unwilling
to adopt your terminology.

If you insist on using such terminology, please learn to recognize when you
are engaged in discussion with someone who uses different terminology and
either mentally translate or fixate on the scenario and technology, not the
label.

There is clear consensus on goals (both from pre-charter discussions, the
chartering itself, and even now if you read the scenarios being discussed in
this thread and ignore the labels). While attempting to standardize on
terminology might be a valuable discussion - and is probably within the
charter for this group, as a means to further the group's goals - please
recognize that there is a distinction between changing terminology and
changing scenarios/goals.

---

From: <[email-masked]>
Date: Mon, 20 Sep 2010 13:08:32 -0400

I agree with this. As an example if you look at the DirectX specification or
Shader 1 specification. It states these are the capabilities you must have
to be compliant.

I could see something like;

VWRAP 0: A space that supports 3d coordinates, maybe time,

VWRAP 1: Simple teleporting, maybe just a URL/URI specification on how to
enter a point in another space.  We do this with web sites, we teleport into
a specific page.

VWRAP 2: Teleporting with continue presence, means you have to be able to
identify yourself, and be kind of a single sign-on kind of flow, maybe give
references to avatar mesh and animations.  (gets more tricky here because of
these can be in different formats) .  We would need to define the avatar
manifest which can be used to define the avatars objects, attachment points,
animation names.

VWRAP 3:  Rez an object that originates from an external source.

These are quick examples.

I do see some challenges with even this, because something like chat may or
may not be available in any of these specifications.

I don't really see the need to mention the term virtual world, I think we
have much more specific terms to use.  Virtual world has something like 17
definitions in the dictionary.

For me the formats of the data are at least as important if not more
important than the protocols.  I have many ways to transfer things.  Also
the protocols and communications can be very scene specific but things like
a definition of an avatar I think can be more easily defined and used across
many protocols.

K.

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Freedman
Sent: Monday, September 20, 2010 12:50 PM
To: Morgaine
Cc: [email-masked]
Subject: Re: [vwrap] Call for a vote on interop BETWEEN independent virtual
worlds or not

Hello,

Cheers,

Jonathan

On Mon, Sep 20, 2010 at 12:43 PM, Morgaine <[email-masked]>
wrote:

Morgaine.

On Mon, Sep 20, 2010 at 4:27 PM, Jonathan Freedman <[email-masked]>
wrote:

Hello everyone,

I have approached editing the Intro document several times and it always
ended in despair. I believe the only rational way to move forward is to
integrate it into the Foundation document as a simple overview of the
context and proceed from there. If others support this direction, I would be
honoured to proceed with the first cut of such a merge.

Regards,

Jonathan Freedman

Unfortunately, no Mike, it's much worse than that.  Even if the technologies
of the worlds in question are not only compatible but IDENTICAL, Meadhbh
claims that we are not creating a protocol for interop BETWEEN those worlds.
At all, whatsoever.

Morgaine.

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

The comment about a singleton is on target I think with this interpretation.
I can create a walled garden that doesn't interconnect with other
"services".  It's using VWRAP and so a part of the VWRAP "Virtual World".  

Mike

---

From: Morgaine <[email-masked]>
Date: Mon, 20 Sep 2010 18:12:07 +0100

Regarding protocol independence, I agree Jonathan.

We've often expressed our desire for independence of protocols and worlds by
saying that the protocol should neither prescribe not proscribe what virtual
worlds should look like.  All that matters to us is that worlds are using
the VWRAP protocol suite to communicate with each other.  Indeed, since we
don't dictate the implementation of virtual worlds, they are defined simply
as some of the server endpoints of our protocols.

The internal implementation details of a virtual world are for that world
alone to define.  That's how we'll get progress, by allowing worlds to
evolve, while they continue to speak a common interop protocol in order to
support the inter-world needs of their users as they evolve.

Morgaine.

On Mon, Sep 20, 2010 at 5:50 PM, Jonathan Freedman <[email-masked]>wrote:

> On Mon, Sep 20, 2010 at 12:43 PM, Morgaine <[email-masked]
> > wrote:
>
>> On Mon, Sep 20, 2010 at 4:27 PM, Jonathan Freedman <[email-masked]
>> > wrote:
>>
>> That sounds reasonable to me, Jonathan.  I believe that your first
>> sentence reflects everyone's understanding of our goals ever since we formed
>> the working group.  Only now has this odd "no interop between virtual
>> worlds" slant been placed on our goals.
>>
>> On Mon, Sep 20, 2010 at 4:27 PM, Jonathan Freedman <[email-masked]
>> > wrote:
>>
>>> Hello everyone,
>>>
>>>> This cannot be allowed to stand, otherwise the entire purpose of VWRAP
>>>> as an interop protocol disappears, and instead VWRAP becomes a protocol for
>>>>> If thats not a correct interpretation then yes we have a huge issue.
>>>>> If it is correct then perhaps we need to refine how we define terms since

---

From: Morgaine <[email-masked]>
Date: Mon, 20 Sep 2010 19:11:39 +0100

Joshua, you're right, this subject has been recycled more times than we can
remember.  What's more, EXACTLY as you wrote back in October 2009, on each
occasion we arrived at the same conclusion, namely that no matter in which
terms we describe our protocol, it will provide what ordinary users of VWs
recognize as interop between their worlds.

In other words, if we have two virtual worlds such as OSgrid and 3rd Rock
Grid, then if those worlds wish it, they could use VWRAP to enable an agent
to teleport from one to the other and to retain avatar properties and assets
after the TP, as one commonly sought example.  The user perspective on this
is extremely simple, and all-important.  It cannot be ignored just because
some document writers profess not to understand the term "virtual world".
(Everyone else does.)

The above kind of interop is either possible with VWRAP or it is not.  The
phrase "no interop BETWEEN virtual worlds" denies the possibility point
blank, and while it's nice to try to smooth it over as an artifact of
terminology, we are faced with diametric opposites here.

While I agree with you entirely that there is (near unanimous) consensus
that we are doing interop between virtual worlds (even if using different
language), the drafts do not reflect that, and as Crista detailed, barely
have any relevance to OpenSimulator-based worlds at all.

As many people have said, we need to fix the language of the drafts so that
it reflects our interop goals clearly, because it fails to do that at the
moment.

Morgaine.

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

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 20 Sep 2010 12:15:29 -0700

jonathan,

can i just ask why you're interested in VWRAP?

OMF has publicly stated it is dropping support for VWARP in favor of
HyperGrid. (unless you want to publicly state OMF is interested in
implementing protocols defined by this group.)

-cheers
-meadhbh

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 20 Sep 2010 12:23:46 -0700

> recognize as interop between their worlds.

um. what's this "we" we're talking about?

> some document writers profess not to understand the term "virtual world".

the issue is not whether we "understand" the concept of a virtual
world, but whether it has meaning to people writing software. i know
you don't understand this since you're not a software developer, but
ultimately someone has to write code. and that code will make certain
assumptions about it's execution environment and which network peers
it trusts.

the assumption in this group was originally that we would have "domain
decomposition." we later changed that to "service decomposition." this
allows software developers to build software for "services" which
deployers can configure into "virtual experiences."

> terminology, we are faced with diametric opposites here.

no. the phrase "no interop BETWEEN virtual worlds" means two things:

a. we are not doing interop between two distinct virtual worlds that
use different protocols (the WoW vs. SL example.)
b. the protocol does not REQUIRE a participant to implement a complete
virtual world. a participant in the protocol may decide to implement
only a single service.

it has always meant this, despite the fact it's not what  you're interested in.

> have any relevance to OpenSimulator-based worlds at all.

repeat after me: VWRAP is not HyperGrid. VWRAP is not OpenSim. VWRAP
is not Linden Lab. VWRAP is not Second Life.

> it reflects our interop goals clearly, because it fails to do that at the

i have requested on several occasions that you provide a list of
issues you have with ANY of the drafts.

when you provide comments of the form: "the document says <this> and i
would prefer it says <that> because ..." then you will find that your
comments are addressed.

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 20 Sep 2010 12:23:46 -0700

---

From: Jonathan Freedman <[email-masked]>
Date: Mon, 20 Sep 2010 15:34:07 -0400

Hello Meadhbh ,

I apologize once again for the continued confusion on this particular subset
of the overall standardization discussion. So we are clear - the Open
Metaverse Foundation is without a doubt interested in the creation,
implementation and adoption of a virtual world interoperability protocol
suite. Overall products aside, this seems like most rational means of moving
the idea (let alone implementations) of relatively freeform virtual worlds
forward.

Given recent iterations of HyperGrid, it seemed prudent to begin
implementation as a preliminary means of experimenting with interoperability
between virtual worlds of approximately the same class. As the VWRAP
protocol suite matures, we will adopt it as appropriate.

I hope this clears up any misconceptions about where the Open Metaverse
Foundation stands with regards to VWRAP / HyperGrid.

Regards,

Jonathan Freedman

On Mon, Sep 20, 2010 at 3:15 PM, Meadhbh Hamrick <[email-masked]>wrote:

> always
> non-interoperating
> way as
> interconnect with

---

From: Morgaine <[email-masked]>
Date: Mon, 20 Sep 2010 21:17:49 +0100

On Mon, Sep 20, 2010 at 8:23 PM, Meadhbh Hamrick <[email-masked]>wrote:

Do we really have to have condescending replies of this kind on the list?

The person concerned knows very well that I'm a software developer of very
long experience, and is doing this for effect.  Please leave personal
references off this forum.  We have more than enough technical issues to
deal with here, and we don't need this at all.

Morgaine.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 20 Sep 2010 16:58:08 -0400

This is a comment on a couple of things that Meadhbh said, but is
directed at everyone; several people have, at one time or another,

> OMF has publicly stated it is dropping support for VWARP in favor of

Despite that Jonathan has answered this, a separate point is that it's
not an appropriate question here.  Everyone, please remember that IETF
participants officially participate as *individuals*.  That means that
participants have interest in the protocols and technology,
independent of the interests of the organizations they work for.

It's perfectly fine to have a respectful conversation about that sort
of thing off-list with a participant.  But as far as this working
group is concerned, each participant has his/her/its own technical
views, and we don't question why someone cares about this or that
protocol because we don't think it's within the person's job
description.

The same goes for this sort of comment:

> i know
> ultimately someone has to write code. and that code will

The point of this was to say the part that begins with "ultimately",
and it could -- and should -- have been said without the demeaning bit
that precedes it, whether or not it was *meant* to be demeaning.  We
like running code, but we don't demand nor expect every participant to
be one who writes the code.

Please, let's not make assumptions about people's job descriptions,
spare-time interests, or motivations.  Address the technical points,
and that should be enough to say what needs to be said.

Thanks, all.
Barry, as chair

---

From: Barry Leiba <[email-masked]>
Date: Mon, 20 Sep 2010 17:08:13 -0400

> offend those who have an investment in any particular reading of that term.

Indeed, and I think we are largely arguing about something we agree
on, and, as Meadhbh and others have said, are stuck on the language.
If we can get to the point where we *do* agree that the issue is just
(or mostly) language, we can work on sorting out the language, and get
un-stuck.

As I understand the charter and the discussion leading up to it, we're
arguing about what we *mean* by "virtual world".  Some want "multiple
virtual worlds" to interoperate using vwrap; others are *defining* a
single virtual world as the set of *regions* that interoperate using
vwrap.

I suggest that these are saying the same thing, that (in this regard,
at least) we have the same goal, and that these two definitions
largely collapse into one.

Am I wrong, here?

Barry, as chair

---

From: "Hurliman, John" <[email-masked]>
Date: Mon, 20 Sep 2010 15:24:44 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Barry Leiba
> Sent: Monday, September 20, 2010 2:08 PM
> To: [email-masked]
> >> needs to be significantly clearer.
> >
> > ... which, based on previous iterations of this discussion, we
> > carefully crafted to not try and nail down what a "virtual world" was
> > so as not to offend those who have an investment in any particular reading
> of that term.
> 
> Indeed, and I think we are largely arguing about something we agree on,
> and, as Meadhbh and others have said, are stuck on the language.
> If we can get to the point where we *do* agree that the issue is just (or
> mostly) language, we can work on sorting out the language, and get un-
> stuck.
> 
> As I understand the charter and the discussion leading up to it, we're arguing
> about what we *mean* by "virtual world".  Some want "multiple virtual
> worlds" to interoperate using vwrap; others are *defining* a single virtual
> world as the set of *regions* that interoperate using vwrap.
> 
> I suggest that these are saying the same thing, that (in this regard, at least)
> we have the same goal, and that these two definitions largely collapse into
> one.
> 
> Am I wrong, here?
> 
> Barry, as chair

That's my current interpretation, thank you for attempting to distill this down. I think that any differences between those two sets of terminology will manifest as policy and not protocol.

John

---

From: Morgaine <[email-masked]>
Date: Mon, 20 Sep 2010 22:27:31 +0100

Thank you Meadhbh, but no apology needed, just the will to work together!
:-)

We have so much to do, and sticking to technical issues is so much more
interesting anyway. :-)

Morgaine.

On Mon, Sep 20, 2010 at 10:20 PM, Meadhbh Hamrick <[email-masked]>wrote:

> fair enough. morgaine, please accept my apology for responding to you
> in a manner in which you consider dismissive.
>
> --
> On Mon, Sep 20, 2010 at 1:17 PM, Morgaine
> >> > Joshua, you're right, this subject has been recycled more times than
> we
> >> > can

---

From: Kari Lippert <[email-masked]>
Date: Mon, 20 Sep 2010 17:27:55 -0400

<emerging out of lurk-dom>

Those discussion Barry references were as he remembers. We wanted to avoid
the meaning war and move forward with something that would work from either
(or all) perspectives on what a virtual world is or could be. In that light,
the standard can be used "between" two worlds or parts of worlds. I agree
with John, those aren't protocol differences, but they are differences in
perspective.

Kevin made a good point - we were (at one point) trying to focus on the set
of data that would be necessary for the various "betweeness" we all
envisioned - be it teleportation or tourism or migration. To do that we had
to define a few things... And I thought we had managed to come to a
consensus. I don't recall discussing that interoperability would be between
the same "class" of virtual world though. Can you point me to a document
where that is stated?

I guess it's time to refresh my memory and review all the drafts...

Kari

-- 

http://kjlippert.wordpress.com/
http://community.webshots.com/user/MissGnomer

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 20 Sep 2010 14:38:16 -0700

another quick point..

are we defining interoperability between virtual worlds or between
hosts that implement services that simulate virtual worlds?

my point is that if we are defining interop between virtual worlds,
this does not imply that deploying a single defined service is an
acceptable use case for consideration by this group. but the converse,
that defining a set of services that can simulate a world, allows us
to consider the use case of a service provider delivering a single
service.

in other words, i had thought that we were defining services with
which we could define virtual experiences and not a virtual world
protocol that is comprised of services.

if we are defining a virtual world protocol, we have to enumerate
explicit combinations of services which are suitable for deploying
independently.

if we define services that can be used to simulate a virtual world,
then the services stand on their own. this was, i thought, our plan.
(i mean, after we decided we didn't want to deploy bundles of services
as domains.)

the bit that's frustrating for me is, i am MUCH more interested in
defining interfaces and interfaces that allow us to bridge existing
data sources on the net with virtual worlds than i am about building
complete virtual worlds. at this point, i'm MUCH more interested in
building a Wikipedia User Server <-> VWRAP auth service bridge than i
am to developing a complete new implementation of a virtual world.

so.. to recap.. if we say we're defining services for simulating a
virtual world, as long as we define the right collection of services,
you get a virtual world for free. but if we define a virtual world
interp protocol, there's no guarantee that the interfaces defined by
the protocol will be able to be devolvable into individual service
interfaces.

-cheers
-meadhbh

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 20 Sep 2010 14:44:23 -0700

john. you used to say that you were interested in being able to deploy
individual services, but this last comment seems to imply that you're
more interested in deploying complete virtual worlds.

could you read my recent comment and tell me if you think there's
merit in the idea of defining individual services that can be deployed
individually?

what i really want is to ensure that we don't specify ourselves into a
corner where you have to deploy all services (auth service, presence
service, chat service, object update service, etc.) in order to deploy
any service.

i want to enable a future where someone could, for instance, operate a
"VWRAP Compliant Asset Service" independently of other services (like
auth, presence, simulation, etc.)

-cheers
-meadhbh

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 20 Sep 2010 14:20:37 -0700

---

From: Morgaine <[email-masked]>
Date: Mon, 20 Sep 2010 22:55:30 +0100

Barry, I too think that we are arguing something that we already agree on.
Joshua was undoubtedly right in his latest post, because after all we've
spent hundreds of emails discussing interop between virtual worlds in very
explicit terms, so it's close to impossible that this hasn't been our common
goal.  It must be an issue of terminology or emphasis.

I like the services approach to interop a lot, as it provides a high degree
of decoupling and very natural client-server architectures with which we
have huge experience in building and scaling.

However, our VW use cases are not expressed in terms of services, but in
terms of user-level concepts like virtual worlds, teleports, avatars, and
clothing.  Somehow we are going to have to examine our services-oriented
definitions and protocols in terms of the VW-oriented use cases to determine
whether we are on the right track and fulfilling our requirements.  This
requires us to accept that interop between VWs must be discussable, at least
when examining use cases.

I'm happy to accept that the bulk of our work will be in terms of services,
as long as the general goal of providing interop between virtual worlds is
clearly highlighted in the introduction.  Without that, readers will simply
have no idea what we're trying to achieve.  Besides that, we will have to
continue discussing how services relate to VWs (as we have been for many
months), because that provides us with our user-level requirements.

Beyond that, I think we can stick to the services view entirely.

Morgaine.

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

---

From: "Hurliman, John" <[email-masked]>
Date: Mon, 20 Sep 2010 16:02:03 -0600

Yes, I am definitely interested in the ability to deploy independent services. I don't see how a stated goal of virtual world interoperability will actually preclude that possibility though. Specifically, your quote:

"if we are defining a virtual world protocol, we have to enumerate explicit combinations of services which are suitable for deploying independently."

I understand where you are coming from but I disagree. The acronym of this group (Virtual World Region Agent Protocol) already defines three terms that are highly specific to the simulation of a virtual world, but I don't see that acronym as preventing me from deploying an independent content delivery network that simulates neither regions nor agents (or a virtual world at all) but is still VWRAP-compatible.

I think defining a service-level interop protocol that fails to achieve any measure of virtual world interoperability is a more real concern than a goal of virtual world interop precluding independent service deployments.

John

> From: Meadhbh Hamrick [mailto:[email-masked]]
> Sent: Monday, September 20, 2010 2:44 PM
> To: Hurliman, John
> Cc: [email-masked]
> individual services, but this last comment seems to imply that you're more
> interested in deploying complete virtual worlds.
> 
> could you read my recent comment and tell me if you think there's merit in
> the idea of defining individual services that can be deployed individually?
> 
> what i really want is to ensure that we don't specify ourselves into a corner
> where you have to deploy all services (auth service, presence service, chat
> service, object update service, etc.) in order to deploy any service.
> 
> "VWRAP Compliant Asset Service" independently of other services (like auth,
> presence, simulation, etc.)
> 
> -cheers
> -meadhbh
> --
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Barry Leiba
> >> Subject: Re: [vwrap] Call for a vote on interop BETWEEN independent
> >> virtual worlds or not
> >>
> >> >> From what I can tell the drafts do support interoperability
> >> >> between the same *class* of virtual world. The catch is that the
> >> >> language needs to be significantly clearer.
> >> >
> >> > carefully crafted to not try and nail down what a "virtual world"
> >> > was so as not to offend those who have an investment in any
> >> > particular reading
> >> of that term.
> >>
> >> mostly) language, we can work on sorting out the language, and get
> >> un- stuck.
> >>
> >> As I understand the charter and the discussion leading up to it,
> >> we're arguing about what we *mean* by "virtual world".  Some want
> >> "multiple virtual worlds" to interoperate using vwrap; others are
> >> *defining* a single virtual world as the set of *regions* that interoperate
> using vwrap.
> >>
> > That's my current interpretation, thank you for attempting to distill this
> down. I think that any differences between those two sets of terminology
> will manifest as policy and not protocol.
> >
> > John

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 20 Sep 2010 15:11:50 -0700

morgaine.

some of us on this list are interested in deploying only a subset of
services, so it is FAR from being settled. when you say "we already
agree" i feel you're dismissing my concerns.

i respectfully disagree that we cannot construct use cases useful to
virtual world deployers without high level abstractions like virtual
worlds, teleports, avatars and clothing.

but i do agree that if you are wanting to define interop BETWEEN
virtual worlds, then yes, you do.

what about the idea of creating a hypothetical example of a virtual
world that includes these high level abstractions (users, avatars,
teleports, clothing, etc.) but then goes on to define them in terms of
services that do not need these high level abstractions to work.

so for example, we could have the "high level" virtual world
abstraction define data formats for prims, collections of prims,
references to textures, sounds, animations, etc. but at the service
level we simply call them "assets." that way i could put an asset
meta-data server in front of the wikimedia common's web server and
have it serve "assets" in a way that is independent of a virtual
world. if asset access is independent of a virtual world, you could
actually have an asset served directly from the asset service to an
offline editing tool or a web page that simply used WebGL to render
the asset.

-cheers
-meadhbh

On Mon, Sep 20, 2010 at 2:55 PM, Morgaine
<[email-masked]> wrote:
> On Mon, Sep 20, 2010 at 10:08 PM, Barry Leiba

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 20 Sep 2010 15:17:57 -0700

help me understand your statement.

you are interested in the ability to deploy independent services, but
you think that defining services fails to achieve any measure of
virtual world interoperability.

these two statements seem to be in contradiction. either you're
interested in service deployers being able to deploy individual
services or you're not. if you support the use case of people being
able to deploy individual services, then you have to be able to define
those services. if you don't define those services, then how do you
define what a service deployer needs to support?

---

From: "Hurliman, John" <[email-masked]>
Date: Mon, 20 Sep 2010 16:27:59 -0600

Yes, I am interested in service deployers being able to deploy individual services.
Yes, I support the use case of people being able to deploy individual services.
Yes, I wish to define those services.
And finally,
Yes, I wish to define a suite of services that meets some definition of the broader virtual world interoperability goal.

Does that clear up any contradictions?

> Sent: Monday, September 20, 2010 3:18 PM
> To: Hurliman, John
> Cc: [email-masked]
> you are interested in the ability to deploy independent services, but you
> think that defining services fails to achieve any measure of virtual world
> interoperability.
> 
> these two statements seem to be in contradiction. either you're interested
> in service deployers being able to deploy individual services or you're not. if
> you support the use case of people being able to deploy individual services,
> then you have to be able to define those services. if you don't define those
> services, then how do you define what a service deployer needs to support?
> 
> --
> > Yes, I am definitely interested in the ability to deploy independent services.
> I don't see how a stated goal of virtual world interoperability will actually
> preclude that possibility though. Specifically, your quote:
> >
> > "if we are defining a virtual world protocol, we have to enumerate explicit
> combinations of services which are suitable for deploying independently."
> >
> > I understand where you are coming from but I disagree. The acronym of
> this group (Virtual World Region Agent Protocol) already defines three terms
> that are highly specific to the simulation of a virtual world, but I don't see that
> acronym as preventing me from deploying an independent content delivery
> network that simulates neither regions nor agents (or a virtual world at all)
> but is still VWRAP-compatible.
> >
> > I think defining a service-level interop protocol that fails to achieve any
> measure of virtual world interoperability is a more real concern than a goal of
> virtual world interop precluding independent service deployments.
> >
> > John
> >
> >> john. you used to say that you were interested in being able to
> >> deploy individual services, but this last comment seems to imply that
> >> you're more interested in deploying complete virtual worlds.
> >>
> >> what i really want is to ensure that we don't specify ourselves into
> >> a corner where you have to deploy all services (auth service,
> >> presence service, chat service, object update service, etc.) in order to
> deploy any service.
> >>
> >> i want to enable a future where someone could, for instance, operate
> >> a "VWRAP Compliant Asset Service" independently of other services
> >> (like auth, presence, simulation, etc.)
> >>
> >> -cheers
> >> -meadhbh
> >> --
> >> >> Subject: Re: [vwrap] Call for a vote on interop BETWEEN
> >> >> independent virtual worlds or not
> >> >>
> >> >> >> between the same *class* of virtual world. The catch is that
> >> >> >> the language needs to be significantly clearer.
> >> >> >
> >> >> Indeed, and I think we are largely arguing about something we
> >> >> agree on, and, as Meadhbh and others have said, are stuck on the
> language.
> >> >> I suggest that these are saying the same thing, that (in this
> >> >> regard, at least) we have the same goal, and that these two
> >> >> definitions largely collapse into one.
> >> >>
> >> >> Am I wrong, here?
> >> >>
> >> >> Barry, as chair
> >> >
> >> down. I think that any differences between those two sets of
> >> terminology will manifest as policy and not protocol.
> >> >
> >> > John

---

From: Morgaine <[email-masked]>
Date: Mon, 20 Sep 2010 23:48:29 +0100

On Mon, Sep 20, 2010 at 11:11 PM, Meadhbh Hamrick <[email-masked]>wrote:

I had hoped that this wasn't going to be reopened, but I think we're still
OK.  Your concerns ARE being met.  Your preferred deployments are every bit
as important and as relevant and as supported as those of people who wish
their VWs to interoperate.  Single services are a perfectly valid
deployment, one possible subset of the overall picture of multiple
interoperating worlds.

Joshua indicated that he believed that we are settled on a common goal but
are using different terminologies, and Barry indicated that he hoped that we
were arriving at a common goal too.  I believed that to be the case as well.

And the evidence on the list indicates very clearly that we are working
towards common goals.

Since we have been talking about interop BETWEEN virtual worlds in hundreds
of emails, it is clear that this is what we are engaged in, even when using
the terminology of services.  This does not mean that all VWRAP deployments
will involve interop between VWs of course.  Any world that does not wish to
interoperate with others can simply refuse connections and hence operate as
a walled garden.  This is built into David's concept of deployment options,
and it's so easy! :-)

Non-communicating walled gardens are supported just as much as
interoperating worlds.

With regard to examples showing how services map to user concepts, yes
indeed, we will need to do that!  And now that VWs may interoperate, we can.
:-)

Morgaine.

On Mon, Sep 20, 2010 at 11:11 PM, Meadhbh Hamrick <[email-masked]>wrote:

> >> >> same *class* of virtual world. The catch is that the language needs
> to
> >> >> be
> >> >> significantly clearer.
> >> >
> carefully

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 20 Sep 2010 16:01:18 -0700

yes.

i believe we are in agreement on all these points.

now that we know we're in agreement, i'll stop bickering about how we
need "service level interop."

i'm happy to say we need interop between worlds, as long as we write
down that "interop between worlds" includes the four points below.

-cheers
-meadhbh

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 20 Sep 2010 16:01:18 -0700

yes.

-cheers
-meadhbh

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 20 Sep 2010 16:17:09 -0700

okay... and this time copying to the list like i was trying to before
(morgaine, you'll get two copies of this.)

morgaine. thanks for validating my "single service deployment model."
that was the core of what i was after.

also, i _think_ i understand your concern with a "service level"
definition. i _think_ you're concerned that it is easy to define
services in such a way that they might have no practical effect on the
user experience of the "virtual world." or that they might detract us
from describing protocol flows in such a way that information in the
flows needs to eventually affect the scene being rendered on a client.
or something like that.

if i read your comments correctly, you would like to see more verbiage
in the intro doc that correlates architecture and objectives with user
experiences. and that's something i can totally respect.

On Mon, Sep 20, 2010 at 4:15 PM, Meadhbh Hamrick <[email-masked]> wrote:
> morgaine. thanks for validating my "single service deployment model."
> that was the core of what i was after.
>
> also, i _think_ i understand your concern with a "service level"
> definition. i _think_ you're concerned that it is easy to define
> services in such a way that they might have no practical effect on the
> user experience of the "virtual world." or that they might detract us
> from describing protocol flows in such a way that information in the
> flows needs to eventually affect the scene being rendered on a client.
> or something like that.
>
> if i read your comments correctly, you would like to see more verbiage
> in the intro doc that correlates architecture and objectives with user
> experiences. and that's something i can totally respect.
>
> but for what it's worth, i disagree with your characterization of a
> federated collection of services as "a walled garden." certainly if
> you are not a student enrolled in a class and you can't get into a
> region operated by a university, the difference between "federated
> collection" and "walled garden" is moot.
>
> but ultimately, collections of regions that share a federation of
> services can decide for themselves which servers they choose to
> connect to and which users they allow to access their region. i think
> it's unfair to characterize such a deployment model as a "walled
> garden."
>
> -cheers
> -meadhbh
> --
> On Mon, Sep 20, 2010 at 3:48 PM, Morgaine

---

From: Cristina Videira Lopes <[email-masked]>
Date: Mon, 20 Sep 2010 17:10:28 -0700

Maybe I'm missing something, please tell me what it is.

The way people here have been talking about single service deployment,  
it looks like it's something that fundamentally affects the underlying  
interop protocols. It looks to me that it isn't so; it's only  
fundamental if you reinvent it.

For simplicity sake, let's assert that a virtual world is  
indistinguishable from a web application running on a web site, ok? --  
literally, now that HTML5 is here. A web site is under one single  
authority, even if it uses services from other organizations.

There can be independent services for VWs, just like there is, say,  
S3. I don't think we need to reinvent anything for that. I mean, we  
can reinvent, but we really don't have to, the Web already has it;  
that reinvention is an additional piece of intellect that, if not done  
carefully, may hinder, rather than help, integration with what already  
exists.

If you want to tell the client to call web services directly, like the  
capability URLs model suggests, that's ok too. Usually the web browser  
isn't allowed to do that. Now there is CORS, so now it can do that.  
CORS is a way for the web app to place data/computation in the user's  
machine without having to proxy it. Ultimately, it's a choice on the  
part of the web app, and the services that it uses; it's not imposed  
by any protocol for service-level interoperability on the web!

So why is single service deployment so important for VW  
interoperability? What am I missing?

On Sep 20, 2010, at 4:17 PM, Meadhbh Hamrick wrote:

>>> On Mon, Sep 20, 2010 at 11:11 PM, Meadhbh Hamrick <[email-masked] 
>>> >
>>> wrote:
>>>
>>> On Mon, Sep 20, 2010 at 11:11 PM, Meadhbh Hamrick <[email-masked] 
>>> >
>>> wrote:
>>>>
>>>> morgaine.
>>>>
>>>>> Barry, I too think that we are arguing something that we already  
>>>>> agree
>>>>> on.
>>>>> spent hundreds of emails discussing interop between virtual  
>>>>> worlds in
>>>>> very
>>>>> explicit terms, so it's close to impossible that this hasn't  
>>>>> been our
>>>>> common
>>>>> I like the services approach to interop a lot, as it provides a  
>>>>> high
>>>>> degree
>>>>> terms of user-level concepts like virtual worlds, teleports,  
>>>>> avatars,
>>>>> and
>>>>> requires us to accept that interop between VWs must be  
>>>>> discussable, at
>>>>> least
>>>>> as long as the general goal of providing interop between virtual  
>>>>> worlds
>>>>> is
>>>>> clearly highlighted in the introduction.  Without that, readers  
>>>>> will
>>>>> simply
>>>>> have no idea what we're trying to achieve.  Besides that, we  
>>>>> will have
>>>>> to
>>>>>>> crafted to not try and nail down what a "virtual world" was so  
>>>>>>> as not
>>>>>>> to
>>>>>>> offend those who have an investment in any particular reading  
>>>>>>> of that
>>>>>>> term.
>>>>>>
>>>>>> agree
>>>>>> regard,

---

From: David W Levine <[email-masked]>
Date: Mon, 20 Sep 2010 20:27:12 -0400

A lot of words have been spent on this. Let me try to walk through my
perspective.

One.. yes, of course we're about enabling interop. Whether it's interop
between "worlds" "regions" "Services" or "forests" I don't think
changes the specification one whit. What we're about is describing the
set of services and interactions which enable the deployment of a large
collection of systems built in a large number of ways.

The core goal is to allow users to share virtual regions, assets and
services
across a broad set of boundaries. So, just for one, starting small and
working up.

The smallest scenario is a single "stand alone" region, which wishes to
access resources which it doesn't host. To whit, asset, inventory and
agent services allowing the stand alone region to access items and
services hosted by others. This, in and of itself is of course interop.
The stand alone region wants to fetch items and rez them. A user may
wish to log onto the region with an avatar an inventory hosted from
other services. The moment we have a region accessing other services
interopation is occurring. Its not very interesting interoperation
perhaps but useful things happen.

Now, whether one calls this region a "world" a "region" a "virtual
space: doesn't much matter. Its a virtual space which wants to access
services from other service providers.

Multiple virtual regions can be federated to form bigger spaces. The
cogent questions are:

      1) What actual services are needed to support a set of regions

    2) Are any changes required in the underlying protocols used by
       regains to access services because they are assembled into
federations.

    3)  What are the user's expectations when moving between regains
        hosted by separate service providers

Thus far, I've seen several  publically exposed service which relate to
federated regions,

 1) the "map" Service. I could also see a possible service which helps
    regions manage placement and adjacency. (But I'm not sure this isn't
    a per deployment choice, as it may not expose any interface needed
    for Interoperability. This may also include "membership" in a basic
    way.

 2) "Federated Seed Cap" which would get you a set of singletons for
     the federated regions. This might include search, currency, a
     default authentication/agent service if the federated regions
     chose to expose it. In short, it makes perfect sense for a set of
     regions to expose the services they share. (Mind you they can also
     do it on a per region basis,  but this seems sane to do this way)

  I would be delighted to see additional items on this list. The more
  things which distinguishes a federated collection of sims, the more
  clarity is likely to be shed on what we mean when a collection of
  regions is federated.

The second question is "Are there any protocol changes" which are
needed when regions are federated? I ask this in all seriousness.
Does a region's service interface change because it is part of a
federation. If there are specific changes which happen because
regions are federated, then clearly we need to account for this.

The third question is less about how we build protocols then about
how we describe how the bits of the system fit together and how users
experience the systems we build and deploy.

The answer, in short is that users expect to teleport and have magic
happen. They expect that whatever appearance they have at the start of a
teleport will be the same at the end of the teleport. They expect that
they will be able to see everyone and everything in the new region, and
they expect that everyone will be able to seem them.

What has to happen for these desires to be fulfilled? The necessary parts
of the items the avatar is wearing at the time of the teleport need to
be available to both the region, and the clients need to able to access
these items and the inbound avatar's client needs access to all the
items in the region, and all the items worn by the avatars in the
region. (For the purposes of this discussion, assume that data is
passed either in line, or by reference to a remotely hosted service
returning the data)

Will this always be true? Probably not. Does the fact that a region is
part of a federation impact this fact? I'm having a hard time seeing why
it would. The transaction is between the region and the services hosting
the related data. When an avatar wants to teleport into a region, the
data about it is provided whether rhe region is a singleton or part of
a federation. Again, I'm looking for a "how does this change things"
point of distinction. None of this says "Federated collection of
regions" isn't a useful construct, quite the contrary. Its how we build
out collections of regions for lots of reasons, its just important to
look at where the concept manifests in terms of things we can define as
actual services with interfaces.

- David
~ Zha

---

From: Morgaine <[email-masked]>
Date: Tue, 21 Sep 2010 01:52:25 +0100

Cool, Meadhbh!

The services themselves have never been a worry to me.  The great thing
about services is that they're decoupled and potentially external, so any
mistakes or inefficiencies can be corrected quite easily, and they can be
scaled up using standard techniques.

What was worrying me instead was that, although services can be defined to
do anything, the core protocol may not provide enough glue to bring services
together to implement the more complex deployments required by interop
between worlds.  Solutions for tourism do not pop out of the wash without
careful design.  You cannot design a core protocol sufficient for
implementing walled gardens and automatically expect it to be sufficient to
enable more complex interop scenarios.  It may be sufficient, and it may
not.  You have to plan for it, by careful choice of protocol and services,
if you want to be sure that the complex interop cases are met.

And this is why I need us to be able to examine complex use cases such as
tourism from the perspective of user-level elements such as worlds and
possessions and operations between worlds.  It is to allow is to devise a
sufficient set of services and protocol glue to allow those use cases to be
met.  Services are great, but for users they're just a means to an end, and
I want to be sure that the end is achievable with them.

I hope that this outlines my approach to the problem ahead adequately.

Morgaine.

On Tue, Sep 21, 2010 at 12:17 AM, Meadhbh Hamrick <[email-masked]>wrote:

> >>> > requires us to accept that interop between VWs must be discussable,
> at
> >>> > least
> >>> > have no idea what we're trying to achieve.  Besides that, we will
> have
> >>> > to
> >>> >> > crafted to not try and nail down what a "virtual world" was so as
> not
> >>> >> > to
> >>> >> > offend those who have an investment in any particular reading of
> that
> >>> >> > term.
> >>> >>
> we're

---

From: Cristina Videira Lopes <[email-masked]>
Date: Mon, 20 Sep 2010 20:07:01 -0700

> A lot of words have been spent on this. Let me try to walk through my
"Federation of regions" is a poor choice of terms, unless you also call 
the collection of web servers that power Facebook "a federation of web 
servers". That's not how people usually use that word (e.g. 
http://www.ibm.com/developerworks/library/specification/ws-fed/). What 
we have for each virtual world is a collection of simulation servers 
that are all under the same authority -- in all similar to Facebook's 
web servers. In fact, OpenSimulator's simulation servers serve http, so 
the difference between Facebook's infrastructure and an OpenSimulator VW 
with many simulators is only on the applications that they run.

Really, we don't need to reinvent wheel when it comes to large-scale 
decentralized, but interoperating, systems. The Web has been around for 
a while. What we're dealing with here can be modeled as one application 
on top of the Web, even if for the time being we use a phat client 
instead of a web browser, because it renders things faster than WebGL.

> regains to access services because they are assembled into federations.
>

---

From: Morgaine <[email-masked]>
Date: Tue, 21 Sep 2010 04:31:52 +0100

Great post, David!

Your formulation makes it easy to show why our earlier problem was indeed a
problem.

You start off with the premise that we're doing interop regardless of the
level of granularity (reasonable), and then you postulate that by examining
sharing of elements across boundaries from small to large we can cover all
the bases of interop (reasonable).  Yes indeed, but the trouble we
encountered yesterday was that that process from small to large had been
halted at the level of granularity of the virtual world.

It was suggested (merely through unfortunate choice of words as we now know)
that at this largest level of granularity, there would be no interoperation
BETWEEN those granules, that this was not our goal.  Using your form of
words, there would be no sharing across the VW boundaries at this level, so
your reasonable process from small to large was being aborted prematurely.
And that's why it was a show-stopper, since no inter-world tourism would
have been possible at the largest scale.  Fortunately this was just a
misunderstanding.

The reason why it was a show-stopper can be described also in terms of *
services*, in direct answer to your question about what changes would be
required in protocols as regions federate into aggregates.  One big change
occurs at the discontinuity caused by singletons.  Irrespective of size, a
virtual world today is most commonly a walled garden that runs a single
asset service for all its regions, a singleton in the asset-handling
protocol.  The change from a singleton to > 1 is not evolutionary, so a
walled garden would have blocked VW interop technically as well as by
policy.

Tourism typically requires regions to handle N+V asset services
simultaneously, where N is the number of asset services Native to the region
(often just 1) and V is the number of distinct asset services introduced to
the region by Visitors concurrently.  It requires these N+V references in
order to avoid having to copy assets to the native asset services(s) as
visitors arrive, because this would be highly non-scalable if performed by
all M worlds in a fully interconnected Mesh of tourist activity.  (N+V is
actually just one of many possible arrangements, but they share the common
design concept that asset service referencing is required to avoid
non-scalable copying and to distribute asset path load across the breadth of
the Internet.)

I like your formulation, and I expect that we can indeed devise a
size-independent protocol that works for all aggregate sizes, as long as the
full gamut of aggregates is treated uniformly.  I am however worried that
your scheme seems (at first glance) to rely on the dreaded proxying of
everything by the current region on behalf of its host world.  I'm sure that
we'll be discussing this issue a lot more in the future. :-)

Morgaine.

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

---

From: Cristina Videira Lopes <[email-masked]>
Date: Tue, 21 Sep 2010 09:33:43 -0700

The terminology and the model suggested in the documents, and now once 
again reinforced in the emails, are different from the standard  
terminology and model used for the large-scale decentralized system that 
is already mature and well established, known as "the Web."

The web is a large-scale, client-server architecture, system composed of 
millions of independently-operated web sites, each treated as a black 
box of engineering and policy decisions made by one independent 
authority, running applications whose only contract is to use the HTTP 
protocol for interaction with user-driven clients. The HTTP protocol is 
a [mostly] stateless protocol that uses hypermedia as the engine of 
application state (HATEOAS),  including accepting higher-order functions 
as "media", and that explicitly embraces the existence of caches. 
Besides interacting with user-driven clients, these web applications can 
engage in interactions with each other, and that concept is known as web 
services.

Now...

- We can invent a new kind of large-scale decentralized system for 
virtual worlds that is different from the Web, starting with using 
different, and sometimes conflicting, terminology, and continuing to 
modeling individual services as the granularity of interaction.

Or

- We can model virtual worlds as web applications, sticking to standard 
concepts and terminology such as "web sites", "web applications" and 
"web services".

I'm in Academia, so I say: don't let the fact that virtual worlds, and 
all the interop scenarios described here, can be modeled and implemented 
as web applications running on web sites, and using web services, get in 
the way of your wanting to invent something new!

But ultimately, this is a matter of preference. In one case, one can 
make everything from the ground up, and that's fun. In the other, we can 
take advantage of an infrastructure that already exists, and of years of 
accumulated experience and standards. And, eventually, give something 
back to the Web: a simple, secure, configurable mechanism for single 
sign ons and inter-site agent transfers.

This group's choice!

Morgaine wrote:
> Great post, David!
>
> Your formulation makes it easy to show why our earlier problem was 
> indeed a problem.
>
> You start off with the premise that we're doing interop regardless of 
> the level of granularity (reasonable), and then you postulate that by 
> examining sharing of elements across boundaries from small to large we 
> can cover all the bases of interop (reasonable).  Yes indeed, but the 
> trouble we encountered yesterday was that that process from small to 
> large had been halted at the level of granularity of the virtual world.
>
> It was suggested (merely through unfortunate choice of words as we now 
> know) that at this largest level of granularity, there would be no 
> interoperation BETWEEN those granules, that this was not our goal.  
> Using your form of words, there would be no sharing across the VW 
> boundaries at this level, so your reasonable process from small to 
> large was being aborted prematurely.  And that's why it was a 
> show-stopper, since no inter-world tourism would have been possible at 
> the largest scale.  Fortunately this was just a misunderstanding.
>
> The reason why it was a show-stopper can be described also in terms of 
> *services*, in direct answer to your question about what changes would 
> be required in protocols as regions federate into aggregates.  One big 
> change occurs at the discontinuity caused by singletons.  Irrespective 
> of size, a virtual world today is most commonly a walled garden that 
> runs a single asset service for all its regions, a singleton in the 
> asset-handling protocol.  The change from a singleton to > 1 is not 
> evolutionary, so a walled garden would have blocked VW interop 
> technically as well as by policy.
>
> simultaneously, where N is the number of asset services Native to the 
> region (often just 1) and V is the number of distinct asset services 
> introduced to the region by Visitors concurrently.  It requires these 
> N+V references in order to avoid having to copy assets to the native 
> asset services(s) as visitors arrive, because this would be highly 
> non-scalable if performed by all M worlds in a fully interconnected 
> Mesh of tourist activity.  (N+V is actually just one of many possible 
> arrangements, but they share the common design concept that asset 
> service referencing is required to avoid non-scalable copying and to 
> distribute asset path load across the breadth of the Internet.)
>
> size-independent protocol that works for all aggregate sizes, as long 
> as the full gamut of aggregates is treated uniformly.  I am however 
> worried that your scheme seems (at first glance) to rely on the 
> dreaded proxying of everything by the current region on behalf of its 
> host world.  I'm sure that we'll be discussing this issue a lot more 
> in the future. :-)
>
>
> Morgaine.
>
>
>
>
> On Tue, Sep 21, 2010 at 1:27 AM, David W Levine <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     The core goal is to allow users to share virtual regions, assets
>     and services
> On Tue, Sep 21, 2010 at 1:27 AM, David W Levine <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     The core goal is to allow users to share virtual regions, assets
>     and services

---

From: Meadhbh Hamrick <[email-masked]>
Date: Tue, 21 Sep 2010 09:49:19 -0700

kk. i think i understand your heartburn.

i think everyone's objective here was to have services that would
implement a "base level" virtual world. but that being said... there
are lots of reasons why different kinds of services in OpenSim or
Second Life might not want to be part of a spec. the linden dollar
interface, for instance, is bound to be contentious and the only
reason to specify it would be if linden wanted to open the interface
to other grids (which, i'm pretty sure they're not interested in doing
at the moment.) not to mention the outcry by peeps who are using other
game cash systems.

also, i've been wondering about the map service (talking about the
thing that draws the human readable map, not what i've been calling a
"space" server that stores the adjacency graph for region boundaries.)
do we really need a special protocol to access map tiles? maybe it's
enough for a region or collection of regions or whatever to publish a
URL to a HTML/JavaScript based map.

just thinking out loud here.

moral of the story is, _I_ think we got consensus that there were
going to be some features that are in Second Life today that won't
show up in VWRAP. However, we will define enough services to have
something recognizable as a virtual experience.

i predict there will be some disagreement about which services should
be supported by the protocol and which should be left as private
extensions. but i do, however, think it's a good idea to enumerate
them somewhere. we started to do that in the charter, and there are
some services enumerated in the intro draft, but i think we should all
go through the list of services and see what we think should be in /
what should be out.

-cheers
-meadhbh

On Mon, Sep 20, 2010 at 5:52 PM, Morgaine
<[email-masked]> wrote:
>> >>> > spent hundreds of emails discussing interop between virtual worlds
>> >>> > in
>> >>> > very
>> >>> > explicit terms, so it's close to impossible that this hasn't been
>> >>> > our
>> >>> > common