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

On Thu, Jul 23, 2009 at 6:52 AM, Dave CROCKER<dhc2@dcrocker.net> wrote:
>
>
> 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?

i'm unsure what you mean by "an instance of OGP." I'm assuming you
mean "does the protocol assume that a host (identified by fqdn or ip
address) run a single revision of the OGP protocol, possibly in a
single server process?"

the answer to that would be, of course, "no. there would be no such
requirement."

i would think it would be analogous to the situation with HTTP. it is
possible to run HTTP over any port you like, though port 80 is
traditional. additionally, it's quite common to serve pages for
different fqdn's off the same ip address and port. this is why it's
important for browsers to send a 'Host:' header.

but i'm unsure why we're talking about this. the purpose of the
specification is to define the protocol, not to provide a software
architecture or place limits on the deployment of software which
implements the virtual world. if we use the term "network host" in an
inappropriate way, that implies that a network host MUST deploy
software that implements one and only one revision of the OGP
protocol, we should address those documents. entering into an
open-ended discussion about the nature of protocols and their
relationship to network hosts is probably not in anyone's best
interest.

to summarize my position... there's nothing in 2616 or 2396 that
addresses the issue as to whether it is a violation of the protocol to
run an HTTP responder off a port other than port 80. what's changed
that we now require such verbiage in draft charters?

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

are you implying that software that implements HTTP and XMPP, each of
which use a destination address is somehow incapable of using that
address? i'm very, very confused here. the OGP data formats and
protocol flows define the contents of messages and a scheme for using
HTTP URIs to resolve the network host and port to send messages to.
you are intimating that this is not sufficient, but give examples of
deprecated revisions of HTTP and SMTP.

OGP is not HTTP. nor is OGP SMTP. OGP is not XMPP.

if you are deploying software that implements OGP, and that software
supports multiple, distinct virtual worlds that do not share
information. you should make sure that the protocol endpoints you
publish are sufficiently contextualized to be able to  distinguish
which distinct virtual world the endpoint exposes an interface for.

this is a similar situation to HTTP. many hosting companies will
deploy different sites on a single IP address, the server software is
capable of route incoming messages to different software (or instances
of the same software) based on the Host: header and the path portion
of the URL. the Apache developers, when writing their software, made
sure their software evaluated the Host: header and used it to route
requests to different bits of code that implemented different sites.

OGP is different from HTTP, however, in that it makes extensive use of
capabilities. capabilities are requested through interaction with a
single service URL (like the login URL defined in the auth / service
initiation draft.) but the concept is similar: the IP address of the
message destination by itself is insufficient to route the message to
the logical / conceptual entities responsible for processing the
message.

so, if you are asking "does the protocol allow a network host to
simultaneously support multiple revisions of the OGP protocol?" or
"does the protocol allow a network host to service two independent
virtual worlds?" the answer to both questions is yes, there is nothing
in the protocol that requires a network host to logical virtual world
mapping.

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

hmm.. the revision of the x.500 spec i worked on made it clear that an
entities would be explicitly allowed to have private directories and
would not be REQUIRED to integrate to the ill founded international
DIT.

the example i gave about the web was the example that it is possible
to have web pages that are served off servers hosted on private /
unroutable IP addresses (or whose FQDNs resolve to private IP
addresses, or whose FQDNs are resolved by name resolvers who service
ONLY private networks.) we still find the use of the definite article
for defining protocol acceptable, even though the defined protocol may
clearly be used to implement "a" intranet.

but it sounds like we're in violent agreement, so i'll not belabor the point.

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

mmm.. i would have to argue against that. or at least encourage it's
discussion in the MMOX email list.

OGPX is intended to be a working group that focuses on protocol for
virtual worlds that share a common set of features: centralized
simulation instead of co-simulation, avatars being in one place at one
time, etc.

other protocols (such as Jon Watte's LESS protocol) diverge from this
paradigm significantly. we had a meeting last spring in which we tried
to discuss the possibility, but found it difficult to find consensus.

i would prefer not to repeat that experiment.

so.. yes... it's a great idea. yes... it would be distracting at this
point. yes... we should not do it.

it is sort of the equivalent of getting the NAPLPS, Gopher and HTTP
people in the same room and telling them to integrate their protocols.

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

aha. so change

"The objective of the OGPX working group is to provide an
application-layer wire protocol for Virtual Worlds to enable
interoperability between applications and provide for access and
exchange with other systems on the internet such as web services,
e-mail and other information storage systems. The Open Grid Protocol
(OGP) will describe semantics and protocol interaction for the virtual
world, independent of transport, though bindings for carrying OGP over
HTTP will be defined."

to

"The objective of the OGPX working group is to provide an
application-layer wire protocol for use by Virtual Worlds to enable
interoperability between applications and provide for access and
exchange with other systems on the internet such as web services,
e-mail and other information storage systems. The Open Grid Protocol
(OGP) will describe semantics and protocol interaction for a virtual
world, independent of transport, though bindings for carrying OGP over
HTTP will be defined."

???

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

again. as a participant in the X.500 / X.509 / PEM fiasco, and
implementer of those specs, it always seemed to me the specs allowed
the use of an independent DIT. that being said, if you chose to not
configure your software to add some type of differentiator at the top
of your tree, you could get very, very confused, very, very easily.

i would argue also that even DNS does not REQUIRE that you point to
the same roots, it's just that it's CONSIDERABLY less useful if you
don't. (in fact, the last rev of bind/named i looked at included the
IP addresses of the roots in a hints file.) hmm.. now that people are
getting serious about DNSSEC again, it might even be a discussion
that's not completely self-indulgent. but that's more of a discussion
to have over coffee / alcohol / food.

so with respect to virtual worlds, let me say, "point well taken" and
run off and modify some draft charter language.

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

cool. i think we have two competing forces at work here. on one side
we have the requirement that the draft charter be clear, but on the
other is the requirement that it not define the space so well that the
current participants are the only ones who can participate.

i think i understand what you're getting at now and have no problems
with clarifying language. BUT, we've already removed the list of
features that differentiate OGP virtual worlds from other virtual
worlds from the charter at your request. i am beginning to get VERY
worried that we will soon be back at MMOX.

OGPX IS NOT MMOX. We started this effort explicitly to carve off a
smaller portion of the problem domain.

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

i think i can speak for John Hurliman and David Lavine when i say, "we
are all about incremental enhancement."

>
>
>> 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
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>