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

From: Morgaine <[email-masked]>
Date: Tue, 21 Jul 2009 09:46:28 +0100

A number of weaknesses in the current OGPX charter have been described by
others.  Here I would like to point out one more.  It might be merely the
result of inconsistent wording, or it might reflect an important scoping
issue for the protocol suite -- it's hard to tell.  Either way, the
ambiguity should be addressed and removed.

The problem arises because of ambiguous use of the terms "Virtual World" and
"Virtual Worlds" without explicitly stating whether they are both one and
the same or distinct.  When we read this loosely with the help of our 2-year
prior backround in OGP, the charter seems understandable, but when analysed
for independent meaning (as newcomers to the project will need to do) it is
more confusing than enlightening in its terminology, as I'll explain.

At the heart of the problem is that the key reference document
http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 (Open Grid Protocol:
Introduction and Requirements) refers to just a single "virtual world", and
hence it is out of step with the more common notion that there is a
multiplicity of virtual worlds which wish to interoperate.  "Virtual world"
seems to be conflated with "virtual universe of virtual worlds" or
metaverse.

To illustrate, http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 refers
to a single virtual world as follows (taken from various paragraphs):

"This protocol is intended to carry information about the *virtual world*:
its shape, its residents and manipulatable objects existing inside the *
world*.  The objective of the protocol is to define an extensible set of
messages for carrying state and state change information between
*hosts*participating in the simulation of the
*virtual world*."

"OGP assumes *hosts* operated by multiple organizations will collaborate to
simulate the *virtual world*.  It also assumes that services originally
defined for other environments (like the world wide web) will enhance the
experience of the *virtual world*."

"The OGP suite assumes that multiple *hosts* will participate in simulating
the *virtual world*."

"The *virtual world created by OGP* is intended to be hosted on systems from
several different administrative domains."

"Initial placement and movement in the *virtual world* is an intricate
interaction between *hosts* in the agent domain (which maintain information
about the avatar's presence) and *hosts* in the region domain."

"If an avatar moves out of the *virtual world region* managed by a
particular *simulator* and into a new *simulator*, the client must initiate
the transit to the new *simulator*."

The above are just a few examples, but there are many others.  Tthe document
is completely self-consistent in this use of "virtual world" throughout:
there is no mention of *interop between virtual worlds* at all, but only
between regions of a single virtual world, or worse, between
implementation-dependent "simulators".

In other words, draft-hamrick-ogp-intro-00 describes the *one-world paradigm
of Second Life*, and not the interop between SL and an Opensim-based grid,
nor interop between Opensim-based grids, nor interop between single
Opensim-based worlds or anything else.

That's the background to this.  Now let's look at the draft charter.

The charter starts off by talking about "Virtual Worlds (VWs)", clearly
acknowledging that there are many, and referring to them as "applications".
In paragraph 2 it then declares that a goal of OGPX is "to provide an
application-layer wire protocol for Virtual Worlds to enable
interoperability between applications", and then immediately in the same
paragraph jumps into the SL-speak of draft-hamrick-ogp-intro-00:  "The Open
Grid Protocol (OGP) will describe semantics and protocol interaction for the
virtual world".  The mixing of "world" and "worlds" continues in paragraph
3, and then the 5 bullet points refer to a single world, but the points are
introduced by the sentence "The Open Grid Protocol will define virtual
worlds with the following assumptions."  Confusion reigns.

This might be the result of nothing more than typos and/or inconsistency of
wording, rather than any intended one-world agenda.  Whichever it is, it's
very confusing when one is trying to establish the intended meaning of what
is written.  For the charter to be useful to the group, its meaning should
be plain and the phraseology consistent.

First of all, the *intent of OGPX* needs to be clarified.  Then the charter
needs to be improved to reflect this intent unambiguously.  And finally, the
various drafts will need revision if they are inconsistent with the amended
charter.

Morgaine.

==============================================================
*Reference*:   *OGPX DRAFT CHARTER* (including here as the MIME type on the
original file appears to be broken):

*Area and Area Directors:*

Applications Area

Lisa Dusseault <[email-masked]>

Alexey Melnikov <[email-masked]>

*Responsible Area Director:*

TBD

*Mailing List:*

[email-masked]

http://www.ietf.org/mailman/listinfo/ogpx

*Description of Working Group:
*
Virtual Worlds (VWs) and other Massively Multi-Party Online
Applications (MMOs) are of increasing interest to the Internet
community. Innumerable examples exist of such applications, most
using proprietary protocols. With their roots in games and social
interaction, Virtual Worlds are now being used increasingly in
business, education and information exchange. With a growing user
base, creators of such systems are interested in developing a
standard virtual worlds protocol to enable interoperability.

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.

The core work of the group will be the production of the Open
Grid Protocol suite (OGP), a set of application protocols to
communicate and interact with the state of Virtual World
applications. The Open Grid Protocol will define virtual worlds with
the following assumptions:

   - The Virtual World exists independent of the participating clients.
   - Users have a single, unique presence in the virtual world.
   - The virtual world contains persistent objects.
   - The virtual world may be partitioned.
   - Presence, state and simulation occur on authoritative hosts.

Further details regarding the structure of and requirements for virtual
worlds described by this group may be found at the document Open
Grid Protocol : Introduction and Requirements

Foundational components of the Open Grid Protocol include the publication of

   1. an abstract dynamic structured data system, suitable for describing
   the application protocol in a transport-neutral manner,
   2. clear semantics and mechanisms for carrying OGP messages over
   message-oriented transports with request/response semantics,
   3. guidelines and mechanisms for host and user authentication and
   confidentiality,
   4. an application-layer protocol for establishing the user's presence,
   5. an application-layer protocol for moving a user's presence from one
   authoritative host to another,
   6. format descriptions for objects and avatars in the virtual world, and
   7. an application-layer protocol for identifying agents, and requesting
   information about them.

*Goals and Milestones:*

   - December 2009 "OGP: Requirements and Introduction" to the IESG as an
   Informational RFC
   - December 2009 "OGP : Abstract Dynamic Structured Data" to the IESG as
   Proposed Standard
   - December 2009 "OGP : Foundational Concepts and Request-Response
   Transport Bindings" to the IESG as Proposed Standard
   - April 2010 "OGP : Guidelines for Host Authentication" to the IESG as an
   Informational RFC
   - April 2010 "OGP : Service Establishment" to the IESG as Proposed
   Standard
   - April 2010 "OGP : Client Application Launch Message" to the IESG as an
   Informational RFC
   - April 2010 "OGP : Simulation Presence Establishment" to the IESG as
   Proposed Standard
   - August 2010 "OGP : Primitive Object Format" to the IESG as Proposed
   Standard
   - August 2010 "OGP : Digital Asset Access" to the IESG as Proposed
   Standard
   - December 2010 "OGP : Entity Identifiers" to the IESG as Proposed
   Standard

============================ END =========================

---

From: Meadhbh Siobhan <[email-masked]>
Date: Tue, 21 Jul 2009 08:34:31 -0700

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. the intro
document uses the term "the" virtual world to emphasize the fact that
within an OGP protocol interaction, for the purpose of that
interaction the endpoints are concerned with THE SAME virtual world.

that is, for the purpose of protocol interactions, both endpoints are
assumed to be participating in the simulation of the same virtual
world. 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.

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.

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
is different from "the web" which in common usage seems to imply a
single collection of protocol endpoints (even though we're probably
all aware that some clients have access to intranet web sites that
clients outside a specific administrative domain do not have access
to.)

that being said...

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.

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.

-cheers
-meadhbh

On Tue, Jul 21, 2009 at 1:46 AM, Morgaine<[email-masked]> wrote:
> "This protocol is intended to carry information about the virtual world: its
> shape, its residents and manipulatable objects existing inside the world.
> The objective of the protocol is to define an extensible set of messages for
> carrying state and state change information between hosts participating in
> the simulation of the virtual world."
>
> "OGP assumes hosts operated by multiple organizations will collaborate to
> simulate the virtual world.  It also assumes that services originally
> experience of the virtual world."
>
> "The OGP suite assumes that multiple hosts will participate in simulating
> the virtual world."
>
> "The virtual world created by OGP is intended to be hosted on systems from
> "Initial placement and movement in the virtual world is an intricate
> interaction between hosts in the agent domain (which maintain information
> about the avatar's presence) and hosts in the region domain."
>
> "If an avatar moves out of the virtual world region managed by a particular
> simulator and into a new simulator, the client must initiate the transit to
> the new simulator."
>
>
> there is no mention of interop between virtual worlds at all, but only
> In other words, draft-hamrick-ogp-intro-00 describes the one-world paradigm
> of Second Life, and not the interop between SL and an Opensim-based grid,
> First of all, the intent of OGPX needs to be clarified.  Then the charter
> Reference:   OGPX DRAFT CHARTER (including here as the MIME type on the
> Area and Area Directors:
> Responsible Area Director:
>
> TBD
>
> Mailing List:
>
> [email-masked]
>
> Description of Working Group:
>
> The Virtual World exists independent of the participating clients.
> Users have a single, unique presence in the virtual world.
> The virtual world contains persistent objects.
> The virtual world may be partitioned.
> Presence, state and simulation occur on authoritative hosts.
>
> an abstract dynamic structured data system, suitable for describing the
> application protocol in a transport-neutral manner,
> clear semantics and mechanisms for carrying OGP messages over
> guidelines and mechanisms for host and user authentication and
> confidentiality,
> an application-layer protocol for establishing the user's presence,
> an application-layer protocol for moving a user's presence from one
> format descriptions for objects and avatars in the virtual world, and
> an application-layer protocol for identifying agents, and requesting
> information about them.
>
> Goals and Milestones:
>
> December 2009 "OGP: Requirements and Introduction" to the IESG as an
> Informational RFC
> December 2009 "OGP : Abstract Dynamic Structured Data" to the IESG as
> Proposed Standard
> December 2009 "OGP : Foundational Concepts and Request-Response Transport
> Bindings" to the IESG as Proposed Standard
> April 2010 "OGP : Guidelines for Host Authentication" to the IESG as an
> Informational RFC
> April 2010 "OGP : Service Establishment" to the IESG as Proposed Standard
> April 2010 "OGP : Client Application Launch Message" to the IESG as an
> Informational RFC
> April 2010 "OGP : Simulation Presence Establishment" to the IESG as Proposed
> Standard
> August 2010 "OGP : Primitive Object Format" to the IESG as Proposed Standard
> August 2010 "OGP : Digital Asset Access" to the IESG as Proposed Standard
> December 2010 "OGP : Entity Identifiers" to the IESG as Proposed Standard
>
> _______________________________________________
> ogpx mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 23 Jul 2009 06:52:12 -0700

Meadhbh Siobhan wrote:
> 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

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

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

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

> we may be talking about "the virtual world" the same way we talk about

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.

> with state transitions or queries in the same virtual world, not

[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

---

From: Charles Krinke <[email-masked]>
Date: Thu, 23 Jul 2009 07:23:30 -0700 (PDT)

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 <[email-masked]>
To: Meadhbh Siobhan <[email-masked]>
Cc: [email-masked]
Sent: Thursday, July 23, 2009 6:52:12 AM
Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds

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

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

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

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

> we may be talking about "the virtual world" the same way we talk about

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.

> with state transitions or queries in the same virtual world, not

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

---

From: David W Levine <[email-masked]>
Date: Thu, 23 Jul 2009 11:31:11 -0400

[email-masked] wrote on 07/23/2009 09:52:12 AM:

> Dave CROCKER <[email-masked]> 
> Sent by: [email-masked]
> 
> 07/23/2009 09:52 AM
> 
> Please respond to
> [email-masked]
> 
> To
> 
> Meadhbh Siobhan <[email-masked]>
> 
> cc
> 
> [email-masked]
> 
> Subject
> 
> Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual 
Worlds
> protocol, a single host can run different, independent web or email 
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)

> capability from the start, permit incremental adoption, with eventual 

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.

---

From: David W Levine <[email-masked]>
Date: Thu, 23 Jul 2009 13:26:10 -0400

Dave CROCKER <[email-masked]> wrote on 07/23/2009 12:05:19 PM:

> Dave CROCKER <[email-masked]> 
> 07/23/2009 12:05 PM
> 
> To
> 
> David W Levine/Watson/IBM@IBMUS
> 
> cc
> 
> [email-masked]
> 
> Subject
> 
Worlds
> David W Levine wrote:
> > to host totally separate instances. 
> 
> I needed to be clearer:  I am not talking about the underlying mechanism 
that 
> gets a particular client stream to a particular server instance.
> 
> I am talking about OGP self-identifying which particular instance ofa 
virtual 
> world is the target.

I think we're getting a confusion here.. because that question sounds 
slightly ill posed. 

OGPX aspires to describe internet addressable services. Those services, 
broadly fall into
four buckets. Region services, which describe how to interact with a 
portion of virtual land.
Agent Services which describe how to interact with an agent representing a 
user, asset and inventory
services which focus on storing virtual entities to be used by users and 
regions, and the services
specific to the viewer. (The Linden Lab deployment pattern tends to 
conflate Agent and inventory/asset services)

One assembles a "world" out of some set of the services described in OGPX. 
Domains also described in the base
specs help demarcate trust/admin boundaries. From the perspective of a 
user, a "world" is a collection of regions
which share a map and consistent set of services. (such as Second Life, or 
the OSGrid or even more precisely, ReactionGrid, or
the Rezzable grid.)

At the protocol and addressing level, tho, the major addressing construct 
is URI, mostly mapped onto URLs. If one wants to
interact with the OsGrid, for example, one points one's client at OSGrid's 
Authentication and Login Service, and gives the URI of a region (or says, 
to the service "Last region I was in" 

For added fun, one can imagine Regions which are their own little domains, 
and by default users visiting get agent, asset and inventory services
from their home worlds. 

The underlying mechanism which gets you associated with a region is that 
you log in an Agent Service, and ask for you avatar to be rezzed
in a region. At the protocol level, the region is named as a URI. 

> 
> By saying 'port' you are clearly referring to reliance on TCP, or 
> the like, to 
> do the differentiation.  And indeed, it does help to have the (n-1) 
layer do 
> differential delivery.
> 
> But that's not enough.
> 
> Relying solely on the lower layers to do the multiplexing was a 
> mistake that was 
> made for email in the 70s and the web in 1989.[1]   Each needed to add a 

> within-protocol construct for identifying sources and sinks 
> independent of the 
> lower layer.
> 
> This is an example of an apparently non-intuitive aspect of what it 
> really means 
> to be transport independent, which is a stated goal of OGP.
> 
> And as long as we've (or I've) backed into that independence topic, I 
should 
> also ask about the reliance on REST.  That would seem to make OGP 
entirely 
> dependent on the Web, no?
> 
> d/
> 
REST as a design pattern. And, certainly, in the early going, most 
deployers are likely
to deliver services on http/https endpoints. The specifications explicitly 
aspire to
permit endpoints to be hosted on XMPP, or RTP, or any message oriented 
transport. 

Mind you, the basic message oriented HTTP style REST pattern does impose 
*some* constraints
in hosting an endpoint. But, the goal is to keep the resources defined as 
message sources
and sinks, which follow simple RESTish semantics. 

> [1] Oddly, this surfaced when a network link was set to loop-back and a 
host 
> delivered mail to itself, although it was intended for elsewhere...  But 
its 
> server had no way of knowing that the mail was intended for elsewhere. 
And 
> confounding this was that open relaying was acceptable then, so thatthe 
fact 
> that the RCPT-TO field had a different domain name didn't help.
> 
> -- 
> 
>    Dave Crocker

---

From: Charles Krinke <[email-masked]>
Date: Thu, 23 Jul 2009 11:25:24 -0700 (PDT)

Dear Zha:

That is my understanding also. As we move forward, I can see that the notion of OGP most likely will entail a connection back to the virtual world that one teleported via 'interop' from for certain asset & inventory connections. After all, a user in OSGrid or ReactionGrid will be unknown to SecondLife and the converse is also true.

Whether we call these 'grids' or 'virtual worlds' may not matter very much. Personally, I tend to visualize all collections of regions using some sort of common User/Agent/Inventory as a 'grid' rather then a 'virtual world', but that is a small matter of semantics.

Charles

________________________________
From: David W Levine <[email-masked]>
To: Dave CROCKER <[email-masked]>
Cc: [email-masked]
Sent: Thursday, July 23, 2009 10:26:10 AM
Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds

Dave CROCKER <[email-masked]> wrote on 07/23/2009

Worlds 
> 
> 
> 
> David W Levine wrote:
> >  > 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]
> I needed to be clearer:  I am not talking about the underlying
mechanism that 
> I am talking about OGP self-identifying which particular instance
ofa virtual 
> world is the target.
 
I think we're getting a confusion here.. because that
question sounds slightly ill posed.  

OGPX aspires to describe internet addressable services.
Those services, broadly fall into 
four buckets. Region services, which describe how
to interact with a portion of virtual land. 
Agent Services which describe how to interact with
an agent representing a user, asset and inventory 
services which focus on storing virtual entities to
be used by users and regions, and the services 
specific to the viewer. (The Linden Lab deployment
pattern tends to conflate Agent and inventory/asset services) 

One assembles a "world" out of some set
of the services described in OGPX. Domains also described in the base 
specs help demarcate trust/admin boundaries. From
the perspective of a user, a "world" is a collection of regions 
which share a map and consistent set of services.
(such as Second Life, or the OSGrid or even more precisely, ReactionGrid,
or 
the Rezzable grid.) 

At the protocol and addressing level, tho, the major
addressing construct is URI, mostly mapped onto URLs. If one wants to 
interact with the OsGrid, for example, one points
one's client at OSGrid's Authentication and Login Service, and gives the
URI of a region (or says, to the service "Last region I was in"  

For added fun, one can imagine Regions which are their
own little domains, and by default users visiting get agent, asset and
inventory services 
from their home worlds.  

The underlying mechanism which gets you associated
with a region is that you log in an Agent Service, and ask for you avatar
to be rezzed 
in a region. At the protocol level, the region is
named as a URI.  

> do the differentiation.  And indeed, it does help to have the
(n-1) layer do 
> And as long as we've (or I've) backed into that independence topic,
I should 
> also ask about the reliance on REST.  That would seem to make
OGP entirely 
> dependent on the Web, no?
REST as a design pattern. And, certainly, in the early
going, most deployers are likely 
to deliver services on http/https endpoints. The specifications
explicitly aspire to 
permit endpoints to be hosted on XMPP, or RTP, or
any message oriented transport.  

Mind you, the basic message oriented HTTP style REST
pattern does impose *some* constraints 
in hosting an endpoint. But, the goal is to keep the
resources defined as message sources 
and sinks, which follow simple RESTish semantics.  

> [1] Oddly, this surfaced when a network link was set to loop-back
and a host 
> delivered mail to itself, although it was intended for elsewhere...
 But its 
 And 
fact

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 23 Jul 2009 13:24:24 -0700

> to host totally separate instances. 

I needed to be clearer:  I am not talking about the underlying mechanism that
gets a particular client stream to a particular server instance.

I am talking about OGP self-identifying which particular instance of a virtual
world is the target.

By saying 'port' you are clearly referring to reliance on TCP, or the like, to
do the differentiation.  And indeed, it does help to have the (n-1) layer do
differential delivery.

But that's not enough.

Relying solely on the lower layers to do the multiplexing was a mistake that was
made for email in the 70s and the web in 1989.[1]   Each needed to add a
within-protocol construct for identifying sources and sinks independent of the
lower layer.

This is an example of an apparently non-intuitive aspect of what it really means
to be transport independent, which is a stated goal of OGP.

And as long as we've (or I've) backed into that independence topic, I should
also ask about the reliance on REST.  That would seem to make OGP entirely
dependent on the Web, no?

d/

[1] Oddly, this surfaced when a network link was set to loop-back and a host
delivered mail to itself, although it was intended for elsewhere...  But its
server had no way of knowing that the mail was intended for elsewhere.  And
confounding this was that open relaying was acceptable then, so that the fact
that the RCPT-TO field had a different domain name didn't help.

-- 

   Dave Crocker

---

From: Infinity Linden <[email-masked]>
Date: Fri, 24 Jul 2009 07:08:45 -0700

On Thu, Jul 23, 2009 at 11:25 AM, Charles Krinke<[email-masked]> wrote:
> Dear Zha:
>
> That is my understanding also. As we move forward, I can see that the notion
> of OGP most likely will entail a connection back to the virtual world that
> one teleported via 'interop' from for certain asset & inventory connections.
> After all, a user in OSGrid or ReactionGrid will be unknown to SecondLife
> and the converse is also true.
>
> Whether we call these 'grids' or 'virtual worlds' may not matter very much.
> Personally, I tend to visualize all collections of regions using some sort
> of common User/Agent/Inventory as a 'grid' rather then a 'virtual world',
> but that is a small matter of semantics.

+1. i like the term "grid" because it's a slightly newer term than
"virtual world" and has less baggage.

---

From: Infinity Linden <[email-masked]>
Date: Fri, 24 Jul 2009 06:59:34 -0700

On Thu, Jul 23, 2009 at 6:52 AM, Dave CROCKER<[email-masked]> 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?"

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?

> protocol, a single host can run different, independent web or email

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.

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

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

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

???

> /administration/.  Here you are defining multiple services that have a wall

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.

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

> capability from the start, permit incremental adoption, with eventual

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

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

---

From: David W Levine <[email-masked]>
Date: Fri, 24 Jul 2009 23:11:02 -0400

Infinity mentioned this, and I thought I'd chime in and agree. The OGPX 
specifications are built to be incremental. All of the coding work I've 
done using early versions of the specs confirms this. In fact, the biggest 
challenge probably isn't going to be permitting incremental change and 
experimentation, but making sure that we put in enough (and not too much) 
stuff to manage the consequences of the flexibility. 

In general, the entire flavor of the specifications is "You start here, 
and you get handed back details about how the services you want to access 
are deployed. In particular, the capabilities mechanism is very good at 
permitting a deployment to map its services onto network endpoints as it 
sees fit. There are a few, necessarily fixed starting points, from which 
the dance begins, but, the overall pattern is authenticate, ask for 
services, and get handed short term use capabilities to access those 
services. Since the protocols and the design don't dictate any requirement 
that that the capabilities be serviced on the machine where a client made 
the request, we get a lot of flexibility. 

That said, we have no desire to re-create a general distributed computing 
fabric. The bulk of the specifications are about the bits we believe we 
need to move to support virtual worlds, not the details of moving those 
bits. There has been a fair bit of real thinking about how the design 
patterns are laid out so that you *could* deploy the protocol sequences 
over different messaging layers than the http(s)  The number of actual 
RESTish web service deployments over XMPP, RTP, or other plausible 
messaging oriented protocols is pretty small. My personal take is that we 
have covered most of the bases, but that any real world deployment of the 
OGPX specifications over  a protocol such as XMPP would require a specific 
RFC on the exact adaptation, and I wouldn't be shocked if it tripped over 
at least one hidden assumption in the current design. We're trying very 
hard to stay focused on specifying from working code, with an eye to the 
future, not the other way around. 

- David W. Levine
~ Zha Ewry (In Second Life)

---

From: Morgaine <[email-masked]>
Date: Sat, 25 Jul 2009 05:38:34 +0100

On Sat, Jul 25, 2009 at 4:11 AM, David W Levine <[email-masked]> wrote:

>
> In general, the entire flavor of the specifications is "You start here, and
> you get handed back details about how the services you want to access are
> deployed. In particular, the capabilities mechanism is very good at
> sees fit. There are a few, necessarily fixed starting points, from which the
> dance begins, but, the overall pattern is authenticate, ask for services,
> and get handed short term use capabilities to access those services. Since
> the protocols and the design don't dictate any requirement that that the
> capabilities be serviced on the machine where a client made the request, we
> get a lot of flexibility.

That's an excellent approach, and I'd say *mandatory*, given that we don't
know what the future holds in this rapidly changing scene and we don't want
to paint ourselves into a corner.  Flexibility is crucial, and service
endpoint mapping (for want of a better term) provides much flexibility.

To put a little more meat on the bones, could you please describe how you
see this endpoint mapping working in the area of asset and inventory
services (A+IS)?  A rough sketch to get us started will do, acknowledging
that an actual spec does not yet exist for it.

Also, could you please mention how A+IS endpoint mapping might provide or
aid flexibility in transferred asset data types?  This is an area of very
rapid change, with new data types being continually suggested and created,
and therefore hardwiring of types would almost immediately paint us into a
corner of obsolesence.  (I believe I know your answer to this one, given the
REST approach, but please summarize it again here, since it has not yet been
mentioned on this list and we have new membership.)

Regards,

Morgaine.

On Sat, Jul 25, 2009 at 4:11 AM, David W Levine <[email-masked]> wrote:

> specifications are built to be incremental. All of the coding work I've done
> using early versions of the specs confirms this. In fact, the biggest
> In general, the entire flavor of the specifications is "You start here, and
> you get handed back details about how the services you want to access are
> deployed. In particular, the capabilities mechanism is very good at
> sees fit. There are a few, necessarily fixed starting points, from which the
> dance begins, but, the overall pattern is authenticate, ask for services,
> and get handed short term use capabilities to access those services. Since
> the protocols and the design don't dictate any requirement that that the
> capabilities be serviced on the machine where a client made the request, we
> get a lot of flexibility.
>
> fabric. The bulk of the specifications are about the bits we believe we need
> to move to support virtual worlds, not the details of moving those bits.
> There has been a fair bit of real thinking about how the design patterns are
> laid out so that you *could* deploy the protocol sequences over different
> messaging layers than the http(s)  The number of actual RESTish web service
> deployments over XMPP, RTP, or other plausible messaging oriented protocols
> is pretty small. My personal take is that we have covered most of the bases,
> but that any real world deployment of the OGPX specifications over  a
> protocol such as XMPP would require a specific RFC on the exact adaptation,
> and I wouldn't be shocked if it tripped over at least one hidden assumption
> in the current design. We're trying very hard to stay focused on specifying
> from working code, with an eye to the future, not the other way around.
>
> - David W. Levine

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 25 Jul 2009 00:08:17 -0700

David W Levine wrote:
>      The number 
> of actual RESTish web service deployments over XMPP, RTP, or other 
> plausible messaging oriented protocols is pretty small. 

David,

My impression is that while REST was first defined as a generic computer science 
construct, it's reality applies only to the Web.  Your own language, above, 
encourage this impression.  While I can imagine have "web service deployments 
over XMPP" I am quite sure it's not going to happen.  So say "web service 
deployment" is to invoke a very elaborate set of services.

As soon as we talk about operating over xmpp, RTP or some other transport, we 
are no longer talking about the web.  If OGP is a web service, then it is tied 
to the web and the web uses HTTP for transfer.  If OGP is not tied to the web, 
then any reference to transfer needs to be independent of web terminology and 
mechanisms.

If indeed transport independence is a goal -- and FWIW it's a goal I'm in favor 
of -- then anything having to do with the web needs to be carefully partitioned, 
with literally no direct OGP reference to it.  The partitioning would provide a 
distinct OGP-over-the-web encapsulation specification.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 25 Jul 2009 00:52:32 -0700

> address) run a single revision of the OGP protocol, possibly in a

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?

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

> 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

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

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

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

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

> the logical / conceptual entities responsible for processing the

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.

> would not be REQUIRED to integrate to the ill founded international

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.

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

> simulation instead of co-simulation, avatars being in one place at one

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?

>> deal with each of multiple instances, albeit separately.
...
> to
...

possibly.

> 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
> run off and modify some draft charter language.

Ack.  tnx.

> current participants are the only ones who can participate.

+1

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

> are all about incremental enhancement."

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

d/

-- 

   Dave Crocker

---

From: David W Levine <[email-masked]>
Date: Sat, 25 Jul 2009 10:13:55 -0400

> Did you start out being all about it, or did you come to it... 
incrementally?
The epigenesis of the OGPX work was Linden Lab's desire to re-structure 
their internal architecture to allow a scalable architecture. They 
realized that what they were going to do would give them a chance to 
actually define the interoperability points at the same time. Since Linden 
runs a multi-thousand server deployment, one of the earliest design points 
was the ability to move stepwise from the current legacy model to the next 
generation architecture. OpenSim is structured as a base platform with a 
set of extensions, such that one can create multiple diverse systems from 
the core parts. Factored interfaces, extensability and incremental change 
is pretty deep in the DNA of the work. 

- David W. Levine

---

From: Morgaine <[email-masked]>
Date: Mon, 27 Jul 2009 06:46:20 +0100

On Sat, Jul 25, 2009 at 3:13 PM, David W Levine <[email-masked]> wrote:

>
> Since Linden runs a multi-thousand server deployment, one of the earliest
> design points was the ability to move stepwise from the current legacy model
> to the next generation architecture. OpenSim is structured as a base
> platform with a set of extensions, such that one can create multiple diverse
> systems from the core parts.

David, that's an interesting observation, and very pertinent to the issue I
raised about multiple interoperating virtual worlds versus a single world.
There is more to this than just a choice of phrase, and Opensim provides a
good example.

Opensim-based grids and Hypergrid-connected Opensim worlds have the ability
to run a multiplicity of interop protocols, with OGP and SL-legacy being
just a subset.  All such interworking code is being progressively refactored
into alternative modules that sit side by side in Opensim, with new modules
expected to appear in the future, exactly as you say.  It is a modular and
extensible framework by design.

What this means for the topology and character of future Opensim-based
worlds is that we should expect much diversity.  In particular, an Opensim
world that communicates with SL through OGP may be
*simultaneously*connected to some other world via MXP, Hypergrid, or
some other protocol.
This diversity in protocols is very likely to result in world features in
Opensim worlds that are quite foreign to SL for example, as has already
happened with realXtend.

>From this it seems a safe conclusion that two virtual worlds that employ OGP
for interop between them are often going to be very different to each
other.  The only commonality necessary is that they can both speak the same
language of OGP, which after all is just a communications protocol and not a
world specification.  To speak of commonality of worlds is just not
appropriate in this context, since it would be purely coincidental.  We
don't have one world in any real sense of the phrase -- what we have is one
protocol, and multiple worlds will interoperate by speaking it, no matter
how else they differ.

Many factors encourage and *require* a model of multiple separate but
interoperating worlds:

   - product differentiation as a part of business,
   - strong separation of worlds as a part of security,
   - world diversity as a part of normal cultural variety,
   - worlds uniqueness stemming from human creativity and sheer
   eccentricity,
   - sovereignty of worlds as a part of politics, and relatedly,
   - the essential demarcation of legal jurisdictions.

Given the above, it is quite wrong that the concept of multiple
interoperating virtual worlds has been dropped in favour of conjuring up a
fictitious "single world" spanning the endpoints.  This is particularly so
when that cute phrase serves no useful purpose in the protocol and
confusingly conjures up a protocol entity that does not actually exist.

Indeed, it is a dangerous turn of phrase, and it is likely to result in
legal issues when differing legal requirements at two communicating OGP
endpoints find themselves applying to the "one world" of the protocol.  I
believe that the "one world" language is an unnecessary complication with no
benefit to protocol users nor to understanding, and should be omitted.

In answer to my earlier post on this subject, "one world" has been portrayed
by some as just a literary element with no strong or binding meaning.  Well
if that is so then the case for removal from the drafts is strengthened even
further, since an Internet standard does not benefit from superfluous
literary adornments.

Morgaine.

On Sat, Jul 25, 2009 at 3:13 PM, David W Levine <[email-masked]> wrote:

> their internal architecture to allow a scalable architecture. They realized
> that what they were going to do would give them a chance to actually define
> the interoperability points at the same time. Since Linden runs a
> multi-thousand server deployment, one of the earliest design points was the
> ability to move stepwise from the current legacy model to the next
> generation architecture. OpenSim is structured as a base platform with a set
> of extensions, such that one can create multiple diverse systems from the
> core parts. Factored interfaces, extensability and incremental change is
> pretty deep in the DNA of the work.
>
> - David W. Levine