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

[David W Levine <[e-mail]>]

[e-mail] wrote on 07/23/2009 09:52:12 AM:

> Dave CROCKER <[e-mail]> 
> Sent by: [e-mail]
> 
> 07/23/2009 09:52 AM
> 
> Please respond to
> [e-mail]
> 
> To
> 
> Meadhbh Siobhan <[e-mail]>
> 
> cc
> 
> [e-mail]
> 
> 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]
> 
Absolutely. There's no internal coupling, so a host offering a service, 
can either use multiple domain names, or, in fact, multiple ports
to host totally separate instances. In general, world isn't the way I 
would think of it. Think of the specification as defining sets of web
accessible services, which can be hosted, on arbitrary sets of hosts 
(including hosting multiple copies of some services on a single host)


> 
> >  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.

Again, if you think of the OGPX specifications as offering a sheaf of 
deployable services, 
deployers can incrementally move onto the specifications one service at a 
time. 


> 
> 
> > 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