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

[Dave CROCKER <[e-mail]>]

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