Re: [ogpx] where does VWRAP fit?

[Kari Lippert <[e-mail]>]

+1 for the metaphor  :)


On Sun, Sep 13, 2009 at 2:36 PM, Marshall Eubanks <[e-mail]> wrote:
>
> On Sep 13, 2009, at 2:21 PM, Charles Krinke wrote:
>
>> Well, you bring up some really good points. Personally, what I have been
>> doing is ignoring all the discussion of what the words mean and focusing on
>> my end goal which is the interoperability between similar, autonomous,
>> distinct grids all using compatible protocols.
>>
>
> I think that metaphors can be very important in cases like this, so here is
> one I will throw out for consideration after reading through this mail
> thread. If someone else has made this metaphor, I apologize (but I did
> look).
>
> I look at the "virtual worlds," from an Internet perspective, as analogous
> to Autonomous Systems. An Autonomous System (AS) is a network that has its
> own routing policy, its own internal services, etc. An AS gets to determine
> what happens inside of it, and (in connection with the other party) gets to
> determine peering policies with its peers. (Note that an ASN is not
> necessarily the same as a company, university or other real-world entity -
> some companies have more than one, other ASs aggregate traffic from several
> networks.) At the largest level, the Internet is a network of ASNs connected
> by the Border Gateway Protocol (BGP) .
>
> From this standpoint,  SecondLife, OSGrid,  etc., are Autonomous Virtual
> Systems (AVSs), and, just as BGP determines how packets pass between ASs, it
> seems to me that VWRAP should provide a gateway protocol to determine what
> happens as avatars pass between AVWs. In this metaphor, some services might
> be automatic if you are allowed in, some might require an invitation
> (similar to the way that firewall passage typically requires an invitation
> from the inside), there might be true peering between AVSs of similar size
> (where avatars or services are allowed free interoperation between the two
> AVSs), and relationships between AVSs of different sizes might require
> payment for the smaller AVS).
>
> This metaphor, while similar to the idea of Virtual Worlds as countries or
> nation-states, it seems to me is better aligned with the way things are done
> on the Internet, and close to the realms where we have working code and
> experience.
>
> Regards
> Marshall
>
>> So, ... if the words get in the way, it is my intention to roll right over
>> them and ignore them.
>>
>> If that is an issue, then we need to go back and agree on the words.
>>
>> If that is not an issue, then we move forward and figure out how to
>> interop between similar autonomous grids.
>>
>> Charles
>>
>> From: Morgaine <[e-mail]>
>> To: [e-mail]
>> Sent: Sunday, September 13, 2009 10:48:03 AM
>> Subject: Re: [ogpx] where does VWRAP fit?
>>
>> Charles, I too would be happy with any form of words that would allow us
>> to achieve the goal of interoperation between multiple distinct virtual
>> worlds that support our protocol.
>>
>> Unfortunately the current language precludes that, by overloading the term
>> "virtual world" to mean something different and blocking any reference to
>> multiple VWs.  Other problems abound too, such as not recognizing multiple
>> ToS, separate legal jurisdictions, etc --- a whole raft of problems arise
>> from the chosen "single virtual world" language.  That choice was made
>> wholly without benefit nor justification, and it has led to this problem
>> directly.
>>
>> If "the virtual world" in the OGP documents were replaced by "the
>> communicating parties" or "the participants" or "the participating
>> endpoints" or "the participating services" or "the participating regions" or
>> "the communicating regions" or just plain "the regions", or if a brand new
>> word were coined for "the regions controlled by the interacting ADs", then
>> we would be getting somewhere, because then we could discuss how to make
>> multiple VWs interoperate.
>>
>> Currently we cannot do that, because the documents refer to only one
>> single virtual world owing to the OGP legacy, and hence preclude us even
>> discussing multiple virtual worlds.  The problem is entirely an artifact of
>> the language chosen for the original OGP documents which only sought to grow
>> a single world.  It has no place in a multi-world VWRAP, as it brings no
>> benefits but introduces numerous problems.
>>
>>
>> Morgaine.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ============================================
>>
>> On Sun, Sep 13, 2009 at 4:58 PM, Charles Krinke <[e-mail]> wrote:
>>
>> I agree with Morgaine here. The whole point of this group from my selfish
>> viewpoint is to enhance OGP to allow a more seamless interop between virtual
>> worlds such as SecondLife, OSGrid, ReactionGrid, ScienceSim and others.
>>
>> To the extent that we enable this ability, our Metaverse becomes more
>> diverse and robust.
>>
>> I am not interested in fretting over the wording of this or that document,
>> but what I am interested in is making sure that we are headed in the
>> direction of interoperability between independent virtual worlds such as the
>> four examples above. These are not the only examples, only the four that
>> appear to have significant diversity and robustness to be considered in a
>> list of virtual worlds for interop.
>>
>> With that in mind, I look forward to seeing more OGP interop with things
>> like the 'gridnauts' from the SecondLife Betagrid to IBM OpenSim standalone
>> regions and from the SecondLife Betagrid to OSGrid as was demonstrated a
>> year or so ago.
>>
>> Along the way, the HyperGrid notions will undoubtedly come into play.
>> These notions are also valid and are currently in use between various
>> OpenSim regions and OpenSim grids and as appropriate, the technical details
>> will be discussed as they evolve in a more or less consistent direction.
>>
>> Charles
>> From: Morgaine <[e-mail]>
>> To: [e-mail]
>> Sent: Saturday, September 12, 2009 11:55:21 PM
>>
>> Subject: Re: [ogpx] where does VWRAP fit?
>>
>> Just in case it's not plain, this discussion is now post-charter agreement
>> I believe.  Ie. we're not revisiting the charter, at least for a while, and
>> hence the following is in the context of defining the problem space,
>> solution space, and draft protocol specifications. :-)
>>
>>
>> On Fri, Sep 11, 2009 at 5:15 PM, Joshua Bell <[e-mail]> wrote:
>>
>> And yet, from a formal/legal perspective, things are far more complicated
>> than this, which is why "countries" is a non-technical term and those
>> seeking to be precise use lovely terms like "nation-states". Check out
>> http://en.wikipedia.org/wiki/Nation for some discussion about the
>> terminology, or think about examples like England which is a country by yet
>> not a sovereign state; it is part of the United Kingdom of Great Britain and
>> Northern Ireland, which in turn is a sovereign member state of the European
>> Union (Hopefully I got that right...). Or think of microstates - contested
>> and otherwise. It's not our job as technology implementers and spec writers
>> to dictate policy, or disenfranchise the world-view of others.
>>
>> This is pushing the analogy too far, but I can run with it if you like.
>> ;-)
>>
>> First of all (excuse the use of Second Life here, but it is our primary
>> example), note that the operators of Second Life and all of the residents of
>> Second Life know exactly which virtual world they operate or inhabit.  There
>> is not the slightest shadow of doubt about this in anyone's mind, and
>> therefore the regular suggestions that "virtual world" is ambiguous or
>> undefined or uncertain are extremely ill-founded.  Likewise, exactly the
>> same is true of OSgrid, as another example.  The alleged uncertainty about
>> the meaning of "virtual world" does not exist in the context of OSgrid (nor
>> of the many other similar grids).  They know exactly who and what they are.
>>
>> Consequently, there cannot be any uncertainty about the meaning of
>> "virtual worlds" when we consider interop between two worlds such as Second
>> Life and OSgrid either.  There are two of them, each is a virtual world, and
>> they are distinct.  Linden Lab is not the only party that understands that
>> their virtual world has boundaries and policies that make it distinct and
>> separate from other virtual worlds.  All VW operators and all VW residents
>> understand this too, as perfectly as Linden Lab.  Claiming complexity or
>> complication in this is simply wrong.
>>
>> Nevertheless, I'll run with your idea of inner complication for you, just
>> to show that it is ill-founded for virtual worlds.  Let's consider the case
>> of inner political subdivisions within nation states, and let's examine the
>> analogy of such inner subdivisions with interop between regions as opposed
>> to interop between virtual worlds.
>>
>> Take for example the county of Sussex within the UK and the state of
>> Kansas within the US.  (These are arbitrary choices.)  Can a traveler from
>> Kansas visit Sussex by negociating a permit between the administrative
>> domains of Kansas and Sussex?  Clearly not.  The "interop" that needs to
>> occur is between the United states and the United Kingdom, even if a direct
>> flight is taken from Kansas to Sussex without a single foot being placed
>> outside of the boundaries of Kansas and Sussex.
>>
>> And this is exactly what happens between virtual worlds as well.  Assuming
>> for the sake of the example that policy allows interop between SL and
>> OSgrid, a region from SL and a region from OSgrid cannot interop without
>> their respective virtual worlds being involved, because it is those TWO
>> worlds that determine the policies under which the interop occurs, and it is
>> those TWO worlds that define the sets of VWRAP services that are involved.
>>
>> You can't cut one of those worlds out of the process, unless the idea is
>> to "steal" regions from it, which of course is not the case here.  That 2nd
>> virtual world must be involved if one of its regions is involved.
>>
>> Agreed. Just as the real world is not simply partitioned into "countries",
>> virtual places will express far more organizational variety than we can
>> currently imagine. I don't feel anointed to define terminology for the
>> future users of such technology.
>>
>> Unfortunately OGP did believe itself to be anointed enough to try to sweep
>> the identity of virtual worlds out of the equation altogether by defining a
>> "same virtual world" that bears no relationship whatsoever to any "virtual
>> world" known to any operator or resident anywhere. ;-)  I am hoping that we
>> can dispense with that totally incongruous redefinition of a well understood
>> term in the VWRAP specifications as easily as we eradicated it from the
>> charter. :-)
>>
>>
>> Having removed it, we can then address how VWRAP implements the
>> user-oriented requirement of interop between multiple virtual worlds, since
>> removing the "single VW" will allow us to refer to more than one VW.  We've
>> already been told authoritatively that, as it stands, the protocol will only
>> connect single regions or a region domain of regions to one single virtual
>> world, and not interop with a whole other VW.
>>
>> There is no such authority that could make such a statement. The draft
>> charter does not speak in a normative fashion about virtual worlds,
>> precisely to avoid such claims - based on your feedback!
>>
>> By "authoritatively", I was referring to the statement made by Meadhbh
>> Siobhan on 30 August to the effect that "OGPX is intended to provide
>> interoperability, not between worlds, but between hosts that work together
>> to simulate a virtual world", which I assume was authoritative.  The virtual
>> world being simulated is the point of contention here.  The term either
>> introduces a new single virtual world that did not previously exist and
>> which bears no relationship to any virtual world known to any operator or
>> resident, or else it refers to just one, previously existing and well known
>> virtual world to which an independent region or region domain is being
>> added.
>>
>> What it CANNOT do is to provide interop between two well known VWs, simply
>> because it is not naming them nor specifying any interaction between them.
>>  An interaction between two region hosts does not provide interaction
>> between the two virtual worlds of which they are part --- it is at the wrong
>> level of the "virtual world stack", to make an analogy with layered
>> protocols.
>>
>>
>> VWRAP as a protocol suite should provide the framework for moving agents
>> between regions. Regions are represented as sets of services, which can be
>> provided by multiple service providers, and within multiple trust domains.
>>
>> Given that, if you personally define "virtual world" as a set of regions
>> that are provided by a single service provider, then VWRAP should indeed
>> provide the framework for agents to traverse those multiple virtual worlds,
>> policy permitting.
>>
>>
>> Except that such a redefinition of "virtual world" does not match the well
>> known meaning of the term in common use today.  I assume that you know what
>> "virtual world" means, since you operate the virtual world of SL, and that's
>> the common meaning that should be used here because it's the same meaning
>> that everyone else uses as well.
>>
>> You cannot just arbitrarily redefine a common term like that when creating
>> a protocol designed to work in an area that already has a meaning for that
>> term.  It sows total confusion among those who have been working in virtual
>> worlds for years, people who already know very precisely what "virtual
>> world" means, as I assume you do yourselves in the context of SL.  And with
>> reference to Kari's thread, such a redefinition makes it impossible to
>> address the most significant entities of interest from the perspective of
>> users, which are the distinct virtual worlds themselves.
>>
>>
>> If you personally define "virtual world" as the set of all regions that an
>> agent can visit (provided by one or more providers), then no, VWRAP would
>> not allow traversing multiple worlds because, by that definition, that agent
>> can only experience one such world.
>>
>> Multiple worlds exist.  Defining virtual worlds by reachability is
>> completely inappropriate --- they don't go away just because you can't reach
>> them.
>>
>> And that's the problem with the approach taken by the old OGP documents
>> --- they sought to define a single virtual world by reachability, instead of
>> accepting that multiple distinct virtual worlds exist but wish to
>> interoperate.  The language that was used precluded this most clear and
>> obvious interop semantic from even being addressed.  It overloaded the
>> crystal clear term "virtual world" with an abstract and highly manufactured
>> fiction that does not represent any virtual world that actually exists.
>>  (Don't say that it's not crystal clear --- you operate a virtual world and
>> you know what it is very clearly, as does everyone else.)
>>
>>
>> Again, the draft charter text explicitly avoids talking about social
>> constructs like "virtual worlds" precisely for this reason, based on
>> feedback from you and others.
>>
>>
>> The reason why agreement on the charter was reached relatively quickly was
>> because "virtual world" was almost completely withdrawn from the language
>> used in the charter.  In contrast, that task still lies ahead of us for the
>> next phase where we examine the problem space and draft specifications.
>>  Most importantly, the latest draft of the charter refers to "the state of
>>  a virtual  world", which strongly suggests that there are many virtual
>> worlds, and this was key to making the language of the charter satisfactory.
>>
>> However, the name of the protocol is now "Virtual World Region Agent
>> Protocol", which alludes to Meadhbh's statement that the interop being
>> considered is not between virtual worlds --- it's within a single virtual
>> world as defined by its agent domain.  The regions involved are all part of
>> that single virtual world, not parts of different virtual worlds since no
>> second AD is involved.  This is fine as long as the protocol is indeed not
>> intended for cross-VW interop, but we've been down that road before and
>> apparently there is still a desire to handle multiple VWs as well.
>>
>> Well that's fine, but we can't handle multiple VWs without referring to
>> them, and we can't refer to them currently because the term "virtual world"
>> is blocked from having a plural form by a very curious and wholly
>> unjustified redefinition of the term inside the specifications.
>>
>>
>> Morgaine.
>>
>>
>>
>>
>>
>>
>>
>> ================================================
>>
>> On Fri, Sep 11, 2009 at 5:15 PM, Joshua Bell <[e-mail]> wrote:
>> On Fri, Sep 11, 2009 at 12:36 AM, Morgaine
>> <[e-mail]> wrote:
>> Users of virtual worlds know exactly what the term means, in the same way
>> that they can distinguish one country from another when they go on holiday.
>>  People have been living with the concept of different places ever since
>> they started travelling beyond their village boundary, and nowadays the
>> popularity of tourism embodies that concept most vividly in the form of
>> countries.  Different countries tend to look different and have different
>> cultures and different rules (local policies).  This is entirely natural and
>> instinctive to us.
>>
>> And yet, from a formal/legal perspective, things are far more complicated
>> than this, which is why "countries" is a non-technical term and those
>> seeking to be precise use lovely terms like "nation-states". Check out
>> http://en.wikipedia.org/wiki/Nation for some discussion about the
>> terminology, or think about examples like England which is a country by yet
>> not a sovereign state; it is part of the United Kingdom of Great Britain and
>> Northern Ireland, which in turn is a sovereign member state of the European
>> Union (Hopefully I got that right...). Or think of microstates - contested
>> and otherwise. It's not our job as technology implementers and spec writers
>> to dictate policy, or disenfranchise the world-view of others.
>>
>> That concept doesn't disappear when "places" become digital.  Instead the
>> concept blossoms, because without the constraints of the physical world,
>> virtual places can be so dramatically different.
>>
>> Agreed. Just as the real world is not simply partitioned into "countries",
>> virtual places will express far more organizational variety than we can
>> currently imagine. I don't feel anointed to define terminology for the
>> future users of such technology.
>>
>> Having removed it, we can then address how VWRAP implements the
>> user-oriented requirement of interop between multiple virtual worlds, since
>> removing the "single VW" will allow us to refer to more than one VW.  We've
>> already been told authoritatively that, as it stands, the protocol will only
>> connect single regions or a region domain of regions to one single virtual
>> world, and not interop with a whole other VW.
>>
>> There is no such authority that could make such a statement. The draft
>> charter does not speak in a normative fashion about virtual worlds,
>> precisely to avoid such claims - based on your feedback!
>>
>> VWRAP as a protocol suite should provide the framework for moving agents
>> between regions. Regions are represented as sets of services, which can be
>> provided by multiple service providers, and within multiple trust domains.
>>
>> Given that, if you personally define "virtual world" as a set of regions
>> that are provided by a single service provider, then VWRAP should indeed
>> provide the framework for agents to traverse those multiple virtual worlds,
>> policy permitting.
>>
>> If you personally define "virtual world" as the set of all regions that an
>> agent can visit (provided by one or more providers), then no, VWRAP would
>> not allow traversing multiple worlds because, by that definition, that agent
>> can only experience one such world.
>>
>> Again, the draft charter text explicitly avoids talking about social
>> constructs like "virtual worlds" precisely for this reason, based on
>> feedback from you and others.
>>
>>
>>
>> _______________________________________________
>> ogpx mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>>
>>
>> _______________________________________________
>> ogpx mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ogpx
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>