Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds

[Charles Krinke <[e-mail]>]

I think we need to view different virtual worlds in the Metaverse in a manner analagous to countries. For instance, OSGrid and SecondLife are independent virtual worlds administered by different groups.

The act of moving from one virtual world to another is analagous to traveling from one country to another. There are certain protocols that must be performed at ports between each virtual world.

The notion of a 'full handoff' seems appropriate here as this implies a peer relationship between two virtual worlds, and I think that is where the confusion is coming from. As we look forward into the future, we look towards a series of independent virtual worlds, much like countries, as opposed to an overwhelming beauracracy controlled by one virtual world.

Charles Krinke




________________________________
From: Dave CROCKER <[e-mail]>
To: Meadhbh Siobhan <[e-mail]>
Cc: [e-mail]
Sent: Thursday, July 23, 2009 6:52:12 AM
Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds



Meadhbh Siobhan wrote:
> morgaine. thanks for the intro into this subject.
> 
> OGP defines interoperability between the hosts implementing "a"
> virtual world. this virtual world may be "the" virtual world if there
> are none other apropos to the conversation at the time. 

Can a single host run two instances of OGP, to support two different -- that is, independent -- virtual worlds?  Can a single OGP client access two different OGP worlds?  That is, VWs that have different names and administration and do not talk to each other?

For example, by supporting different domain names an the exchange details of protocol, a single host can run different, independent web or email services.[1]


>  OGP is not a protocol for providing interoperability between
> different virtual worlds (such as between a Croquet virtual world and
> an OpenSIm instance.) it is a protocol that communicates application
> state transitions about THE SAME virtual world.

These two sentences are extremely helpful.  For a VW-naive reader like me, they make a basic point clear.

In reading the draft charter, I also had wondered about the use of "the" and level of interoperability being sought.  The web, email, X.500 and the DNS are examples of having a single integrated service. For email, there is an acknowledgment of other services, by virtue of having "gateways" in the model, but they are entirely secondary to email technical work.  The core model is a single integrated service.  And that's the usual approach for Internet protocols.

But it makes sense that virtual worlds would need to support multiple, INDEPENDENT worlds as discrete instances that do not interoperate.  (One could imagine adding some ability to interoperate later, I guess, but I also suspect it would be hugely distracting to make it a goal now.)


> when the OGP specifications use the term "the virtual world" it is
> assumed they are talking about THE virtual world under discussion to
> differentiate it from other virtual worlds that might exist.

As minor as it might seem, changing the text to say "a" rather than "the" could also help clarify things, since it moves the entire charter's text over to the perspective that there is more than one and that the work defined by the charter is for a capability that provides a common way to deal with each of multiple instances, albeit separately.


> note that this usage is in keeping with several previous standards
> efforts. X.500, for instance, describes "the directory" yet it is not
> assumed that there will be a singleton instance of a directory. this

Actually, that is exactly what it means, as I noted above.[2]  Internet protocols usually define a single technical service, but with independent /administration/.  Here you are defining multiple services that have a wall between them.

Anyhow, this is just the sort of confusion that it helps to have a charter clarify, because it is such a basic point.  And your two sentences above (and maybe some very minor wording swapping) clarify things completely, IMO.


> the authors of the OGP specification believe that OGP is capable of
> providing an "internet scale" virtual world, so who knows, in a decade
> we may be talking about "the virtual world" the same way we talk about
> "the web" today.

That meshes nicely with the approach that has worked well for some other Internet enhancements:  rather than requiring everyone to adopt all of a capability from the start, permit incremental adoption, with eventual integration later.


> so... to recap... the objective of the OGPX working group is to focus
> on the OGP family of protocols. it is not to attempt to bridge all
> virtual worlds with a common access protocol. this may one day happen,
> but that work is more appropriate for the MMOX group. the definite
> article in OGP specifications underscores this focus. protocol
> endpoints in an OGP protocol transaction are concerning themselves
> with state transitions or queries in the same virtual world, not
> distinct virtual worlds.


[1] The original Web did not support this, since they didn't include the target domain name in HTTP. Email had this same limitation when first developed. It assumed that the lower-layer transport would do all the work of distinguishing between instances, but that doesn't work.  That's why SMTP says explicitly who it is trying to talk to, during session initiation.

[2] LDAP was developed as a reaction to adoption problems with X.500.  SOme of this was about X.500's complexity, but one of the other problems -- and in some folks' view the much greater one -- was that X.500 put forward a model of complete integration across the Internet. However organization's weren't willing to make their corporate data bases fully integrated with each others'. Worse, there are national laws that constrain this.  So, the server-to-server integration that would have created a single, global directory service was dropped.

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
ogpx mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ogpx