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

[Dave CROCKER <[e-mail]>]

Infinity Linden wrote:
>> 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?"

I think I mean something different from that.

Brandenburg (bbiw.net) and DKIM (dkim.org) are hosted on the same machine.
Imagine that each organization wants to run entirely private (independent) 
VW/grids.  I might choose to participate in each, but other than some individual 
participants that they might happen to have in common, nothing else about them 
is visibly shared.

The question is whether a user who is accessing the hosting machine can 
adequately indicate which VW they want, without relying on lower-layer 
information?  What is the technical basis the server users for determining that 
one time my access is to the bbiw.net VW and another time it is to the dkim.org 
one?

Assuming that the server can make the distinction, must it use information from 
outside of OGP, such as transport-specific information?


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

And the comment I made earlier is that HTTP did not initially support this.  The 
only way to indicate different sets of web pages used to be by looking at the IP 
address used to get to the server, where a shared hosting server had to have 
multiple IP addresses.

One of the enhancements to HTTP when it was brought to the IETF was to get the 
target FQDN into HTTP, itself, so that HTTP did not have to rely on the lower 
layers to provide such multiplexing information.


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

Correct.  And I too always like to make sure folks don't confuse software issues 
with protocol architecture.  So, indeed, I mean to be talking strictly about 
protocol architecture, here, not how it is implemented in software.


>    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

By 'revision' do you mean protocol version number or do you mean executing one 
or multiple instances of it, or something else?  (I'm used to 'revision' to 
apply to editing, but suspect that's not what you mean here.)


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

I'm not talking about port numbers.  I guess the implication of the issue I am 
raising -- for those cases where OGP is running over HTTP -- is whether a user 
can access different (and independent) VW/grids when coming to the same IP 
address and TCP port number?  If so, how does the server know which is intended?


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

First, note the embedded reliance on web details.  This is an example of what I 
suspect is the reality, that OGP is a value-add service of the web, tied to 
HTTP, etc.  Not "transport independent".

Second, you are describing the name-to-address resolution method by which a 
client gets to a server.  Whereas I'm talking about the ability of the server to 
know which name was used, since the name-to-address mapping done here is a 
many-to-one mechanism.


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

The question is what establishes that context?  Does it require using 
information from the lower (transport) layers or is it independent of transport? 
  If it uses information from the lower layers, then it is tied to a specific 
transport.


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

It occurs to me that I don't know of any capability-based security mechanism 
having previously been deployed on the Internet.  There's probably a red flag 
needed here, for due diligence.


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

No not required, but as with the earlier X.400 work, out of which the X.500 
effort developed, a single, global infrastructure was the intent.


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

I think there are levels of discussion to have about this.  The first is being 
clear about what this issue means and that it is a relatively fundamental 
service design characteristic (or limitation).  The second is what specific 
choice to make for OGP.  I am trying to pursue the former and wasn't (yet) 
offering an opinion on the latter.


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

So an organization that wants to use OGP for a company-internal service won't be 
able to do it, except perhaps by some lower-layer trick that probably won't work 
if the organization uses a cloud environment on the Net?  Their service must be 
integrated into the global service?


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

possibly.


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

More importantly, the DNS, itself, does not provide a way of knowing what root 
you point to.  That decision is outside of the DNS protocol.  Over the years, 
some common tricks have developed for accomplishing this, but again, they are 
not in the DNS architecture itself. That's  because the DNS presumes global 
integration for ALL DNS entries.

This really is a fundamental design issue for a protocol:  does it have direct 
support for private name-spaces and services or does it assume complete, global 
integration?


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

Ack.  tnx.


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

+1


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

OK.  Now I'm confused again:  I did?  Which list?


i am beginning to get VERY
> worried that we will soon be back at MMOX.

I promise you that I, at least, have much, much more narrow focus for the 
chartering exercise.


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

Did you start out being all about it, or did you come to it... incrementally?


d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net