Re: [ogpx] where does VWRAP fit?

[Marshall Eubanks <[e-mail]>]

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