Subject: [mmox] MMOX Progress tracking

From: Morgaine <[email-masked]>
Date: Wed, 4 Mar 2009 10:56:53 +0000

I think it's fair to say that we have had a very interesting last few days
in MMOX.  As the deadline for new Internet Drafts for consideration at the
BoF has come and nearly gone (last day noted by
Lisa<http://www.ietf.org/mail-archive/web/mmox/current/msg00909.html>),
documents have been appearing thick and fast.  In order of appearance:

   - MMOX Problem and Scope
statement<http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.txt>--
David W. Levine
   - Live Entity State Stream (LESS) protocol
description<http://www.ietf.org/proceedings/staging/draft-ietf-mmox-less-protocol-00.txt>--
Jon Watte
   - Open Grid Protocol:
Foundation<http://www.ietf.org/internet-drafts/draft-lentczner-ogp-base-00.txt>--
Mark Lentczner

David's document is particularly useful owing to its broad definition of the
MMOX problem space and its clear scoping of how MMOX can be expected to
assess and define eventual solutions.  It provides an excellent (extended)
analysis upon which a good (short) MMOX charter can be based, doubly
"excellent" by virtue of the high amount of support that it has received on
the list.

(With respect to work on the charter, the original draft charter is now
marked as "*THe following is out of date. It was posted for consideration
during the process of approving the MMOX BOF. The BOF is approved and
charter discussions continued on the MMOX mailing list.")

*Jon's submission of the LESS protocol is, I believe, crucial to the success
of MMOX, as it provides the only "official" counterpoint to the OGP proposal
and so hopefully ensures that our focus is a broader, more vendor-neutral,
and more architecture-neutral one than OGP alone would encourage.

Mark's submission of the OGP: Foundation (loosely, "OGP Base") protocol is
of course the "official" conerstone of the ongoing work on OGP.  (That work,
incidentally, continues apace at LL/AWG alongside the efforts here at
MMOX).  In the AWG, it has sometimes been hard to disentangle pure OGP
concepts from the legacy concepts of Second Life with which it is
compatible, so this independent publication is extremely important:
attempting to implement this spec will highlight those things that are
currently missing or SL-referential.

(It is worth pointing out that LESS and OGP do not define the maximum extent
of MMOX interop:  they merely provide the two official IETF draft protocol
proposals for consideration at the BoF.)

I think that the above documents can give us a reasonable basis for the BoF
meeting.  The details are of course subject to further examination and
refinement on the mailing list, both before and after the BoF and the
creation of the workgroup, as per normal IETF procedure.

Morgaine.

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Wed, 4 Mar 2009 03:13:03 -0800

mmm... as i read it, we have the following drafts:

LLSD : http://tools.ietf.org/html/draft-hamrick-llsd-00
LESS : http://tools.ietf.org/html/draft-jwatte-less-protocol-00
OGP BASE : http://tools.ietf.org/html/draft-lentczner-ogp-base-00
OGP AUTH : http://www.ietf.org/internet-drafts/draft-hamrick-ogp-auth-00.txt

but i don't see David's "MMOX Problem and Scope Statement" on the list  
of IDs submitted. my suspicion is that the filename needs to be  
changed from "draft-ietf-mmox-problem-00.txt" to "draft-levine-mmox- 
problem-00.txt" (or some such.)

David... can you double-check the status of your submission? it's not  
showing up on the list at https://datatracker.ietf.org/drafts/current/?sort=date 
  .

On Mar 4, 2009, at 2:56 AM, Morgaine wrote:

> I think it's fair to say that we have had a very interesting last  
> few days in MMOX.  As the deadline for new Internet Drafts for  
> consideration at the BoF has come and nearly gone (last day noted by  
> Lisa), documents have been appearing thick and fast.  In order of  
> appearance:
>
> MMOX Problem and Scope statement -- David W. Levine
> Live Entity State Stream (LESS) protocol description -- Jon Watte
> Open Grid Protocol: Foundation -- Mark Lentczner
>
> David's document is particularly useful owing to its broad  
> definition of the MMOX problem space and its clear scoping of how  
> MMOX can be expected to assess and define eventual solutions.  It  
> provides an excellent (extended) analysis upon which a good (short)  
> MMOX charter can be based, doubly "excellent" by virtue of the high  
> amount of support that it has received on the list.
>
> (With respect to work on the charter, the original draft charter is  
> now marked as "THe following is out of date. It was posted for  
> consideration during the process of approving the MMOX BOF. The BOF  
> is approved and charter discussions continued on the MMOX mailing  
> list.")
>
> Jon's submission of the LESS protocol is, I believe, crucial to the  
> success of MMOX, as it provides the only "official" counterpoint to  
> the OGP proposal and so hopefully ensures that our focus is a  
> broader, more vendor-neutral, and more architecture-neutral one than  
> OGP alone would encourage.
>
> Mark's submission of the OGP: Foundation (loosely, "OGP Base")  
> protocol is of course the "official" conerstone of the ongoing work  
> on OGP.  (That work, incidentally, continues apace at LL/AWG  
> alongside the efforts here at MMOX).  In the AWG, it has sometimes  
> been hard to disentangle pure OGP concepts from the legacy concepts  
> of Second Life with which it is compatible, so this independent  
> publication is extremely important:  attempting to implement this  
> spec will highlight those things that are currently missing or SL- 
> referential.
>
> (It is worth pointing out that LESS and OGP do not define the  
> maximum extent of MMOX interop:  they merely provide the two  
> official IETF draft protocol proposals for consideration at the BoF.)
>
> I think that the above documents can give us a reasonable basis for  
> the BoF meeting.  The details are of course subject to further  
> examination and refinement on the mailing list, both before and  
> after the BoF and the creation of the workgroup, as per normal IETF  
> procedure.
>
>
> Morgaine.
>
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox

---

From: Morgaine <[email-masked]>
Date: Wed, 4 Mar 2009 12:21:03 +0000

> OGP AUTH :
> http://www.ietf.org/internet-drafts/draft-hamrick-ogp-auth-00.txt
>
>

The above document is a brand new one, dated 3rd March 2009 but not
mentioned previously in any email on this list.  I'm adding it to my
tracking list now and look forward to its analysis on-list! :-)

Morgaine.

On Wed, Mar 4, 2009 at 11:13 AM, Meadhbh Hamrick (Infinity) <
[email-masked]> wrote:

> OGP AUTH :
> http://www.ietf.org/internet-drafts/draft-hamrick-ogp-auth-00.txt
>
> but i don't see David's "MMOX Problem and Scope Statement" on the list of
> IDs submitted. my suspicion is that the filename needs to be changed from
> "draft-ietf-mmox-problem-00.txt" to "draft-levine-mmox-problem-00.txt" (or
> some such.)
>
> showing up on the list at
> https://datatracker.ietf.org/drafts/current/?sort=date .
>
> BoF has come and nearly gone (last day noted by Lisa<http://www.ietf.org/mail-archive/web/mmox/current/msg00909.html>),
>    - MMOX Problem and Scope statement<http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.txt>-- David W. Levine
>    - Live Entity State Stream (LESS) protocol description<http://www.ietf.org/proceedings/staging/draft-ietf-mmox-less-protocol-00.txt>-- Jon Watte
>    - Open Grid Protocol: Foundation<http://www.ietf.org/internet-drafts/draft-lentczner-ogp-base-00.txt>-- Mark Lentczner
>
>
> David's document is particularly useful owing to its broad definition of
> the MMOX problem space and its clear scoping of how MMOX can be expected to
> *Jon's submission of the LESS protocol is, I believe, crucial to the
> success of MMOX, as it provides the only "official" counterpoint to the OGP
> proposal and so hopefully ensures that our focus is a broader, more
> vendor-neutral, and more architecture-neutral one than OGP alone would
> encourage.
>
> (It is worth pointing out that LESS and OGP do not define the maximum
> extent of MMOX interop:  they merely provide the two official IETF draft
> protocol proposals for consideration at the BoF.)
>

---

From: Jon Watte <[email-masked]>
Date: Wed, 04 Mar 2009 10:31:23 -0800

Morgaine wrote:
> the AWG, it has sometimes been hard to disentangle pure OGP concepts 
> from the legacy concepts of Second Life with which it is compatible, 
> so this independent publication is extremely important:  attempting to 
> implement this spec will highlight those things that are currently 
> missing or SL-referential.
>

I still don't understand how OGP is considered a vendor neutral interop 
protocol.
If I implement it in OLIVE today, I can only interop with other OLIVE 
systems.
If I implement OGP in a system, then all clients of that system need to 
understand all servers that it wants to interop with, leading 
necessarily to the adoption of a "universal client" model of 
interoperability.
I asked these questions before, and haven't actually gotten an answer -- 
it's also not clarified at all in the OGP Foundation proposal.

If the group charter were to drop the term "vendor neutral" and specify 
that the group is about standardizing, for example, how external 
entities can "interact with the Second Life grid, and systems like it" 
(almost a direct quote from a previous post by Linden Lab), the scope 
would be simple, and work could proceed quickly. Those of us who don't 
believe OGP is an interoperability protocol could then find another venue.

Sincerely,

jw

---

From: Dan Olivares <[email-masked]>
Date: Wed, 4 Mar 2009 14:54:59 -0500

vp-identity http://www.ietf.org/proceedings/staging/draft-wolf-vp-identity-00.txt
was also formally proposed

Best Regards

Dan

On Wed, Mar 4, 2009 at 1:31 PM, Jon Watte <[email-masked]> wrote:
> Morgaine wrote:
>>
>> the AWG, it has sometimes been hard to disentangle pure OGP concepts from
>> the legacy concepts of Second Life with which it is compatible, so this
>> independent publication is extremely important:  attempting to implement
>> this spec will highlight those things that are currently missing or
>> SL-referential.
>>
>
> understand all servers that it wants to interop with, leading necessarily to
> the adoption of a "universal client" model of interoperability.
> If the group charter were to drop the term "vendor neutral" and specify that
> the group is about standardizing, for example, how external entities can
> "interact with the Second Life grid, and systems like it" (almost a direct
> quote from a previous post by Linden Lab), the scope would be simple, and
> work could proceed quickly. Those of us who don't believe OGP is an
> interoperability protocol could then find another venue.
>
> Sincerely,
>
> jw
>

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Wed, 4 Mar 2009 15:03:50 -0800

it's interoperable in the "definition 5" form of interoperability.

it allows some virtual worlds to share some protocol implemented by  
multiple, genetically distinct code bases.

so rather than try to make an OLIVE instance talk to WoW or SL, we're  
specifying the protocol by which web browsers, client applications (my  
preferred euphemism for "viewer") and server-based protocol endpoints  
may communicate application state with one another.

On Mar 4, 2009, at 10:31 AM, Jon Watte wrote:

> Morgaine wrote:
>> the AWG, it has sometimes been hard to disentangle pure OGP  
>> compatible, so this independent publication is extremely  
>> important:  attempting to implement this spec will highlight those  
>> things that are currently missing or SL-referential.
>>
>
> I still don't understand how OGP is considered a vendor neutral  
> interop protocol.
> If I implement it in OLIVE today, I can only interop with other  
> OLIVE systems.
> If I implement OGP in a system, then all clients of that system need  
> to understand all servers that it wants to interop with, leading  
> I asked these questions before, and haven't actually gotten an  
> answer -- it's also not clarified at all in the OGP Foundation  
> proposal.
>
> If the group charter were to drop the term "vendor neutral" and  
> specify that the group is about standardizing, for example, how  
> external entities can "interact with the Second Life grid, and  
> systems like it" (almost a direct quote from a previous post by  
> Linden Lab), the scope would be simple, and work could proceed  
> quickly. Those of us who don't believe OGP is an interoperability  
> protocol could then find another venue.
>
> Sincerely,
>
> jw
>

---

From: Charles Krinke <[email-masked]>
Date: Wed, 4 Mar 2009 15:09:51 -0800

Infinity, that makes a reasonable amount of logical sense to me.

I also have to say that I sense some significant angst from folks like
JHurliman over LLSD and would really like to know he and others with similar
maintenance issues of low-level protocol libraries feel comfortable.

If the folks doing the existing implementation of the low-level protocol
libraries that allow two distinct virtual worlds to interop now, that is
SecondLife and OpenSim are having angst over LLSD and OGP, then I would
think that is sufficient reason to step back and listen to them carefully.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Wed, Mar 4, 2009 at 3:03 PM, Meadhbh Hamrick (Infinity) <
[email-masked]> wrote:

> preferred euphemism for "viewer") and server-based protocol endpoints may
> communicate application state with one another.
>
>
>> that the group is about standardizing, for example, how external entities
>> can "interact with the Second Life grid, and systems like it" (almost a
>> direct quote from a previous post by Linden Lab), the scope would be simple,
>> and work could proceed quickly. Those of us who don't believe OGP is an

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Wed, 4 Mar 2009 16:00:15 -0800

oh! right!

this is probably my cue to go off and make sure there's time on the  
agenda to discuss LLSD, OGP, LESS _and_ VPI (and any other protocol  
that's been proposed since i last checked the ID web page)

On Mar 4, 2009, at 11:54 AM, Dan Olivares wrote:

>>> concepts from
>> interop
>> necessarily to
>> answer --
>> specify that

---

From: Jon Watte <[email-masked]>
Date: Wed, 04 Mar 2009 16:42:10 -0800

Maybe we're talking about semantics here -- which unfortunately are 
important in chartering.
I understand what the protocol does, for you, and for the Second Life 
derived/compatible sphere.
However, I believe the protocol does nothing for the greater cause of 
vendor neutral interoperability.
If proposals that go through the group don't need to enable vendor 
neutral interoperability, then that's fine -- but that's not the 
currently proposed charter.

Sincerely,

jw

---

From: Jesrad <[email-masked]>
Date: Thu, 5 Mar 2009 15:38:32 +0100

Jon, if multiple vendors agree on a specific technology/vendor in the
cadre of this interoperability protocol creation, would you consider
it to be vendor neutral or not ?

On Thu, Mar 5, 2009 at 1:42 AM, Jon Watte <[email-masked]> wrote:
> However, I believe the protocol does nothing for the greater cause of vendor
> neutral interoperability.
> If proposals that go through the group don't need to enable vendor neutral
> interoperability, then that's fine -- but that's not the currently proposed
> charter.
>
> Sincerely,
>
> jw
>
>

---

From: Jon Watte <[email-masked]>
Date: Thu, 05 Mar 2009 12:02:53 -0800

> it to be vendor neutral or not ?

If the protocol allows two vendors with significantly different platform 
stacks (say, OLIVE and Metaverse, or There.com and Second Life) to 
connect to each other and achieve user-visible interoperability, then yes.

The problem with OGP is that it assumes that there is only one 
object/sim/client platform stack involved in any one scenario. That's 
why it's actually counter to the goals of vendor neutral 
interoperability. Note that it also necessarily involves the client 
machines, and thus drives towards a "universal client" model, which I 
think is a bad idea for reasons I have already described.

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Fri, 6 Mar 2009 06:17:25 +0000

On Thu, Mar 5, 2009 at 8:02 PM, Jon Watte <[email-masked]> wrote:

> object/sim/client platform stack involved in any one scenario. That's why
> it's actually counter to the goals of vendor neutral interoperability. Note
> that it also necessarily involves the client machines, and thus drives
> towards a "universal client" model, which I think is a bad idea for reasons
> I have already described.
>
>

We've addressed the issue of "universal client" many times before, and yet
you keep on bringing it up again.  Shall we examine it in detail once and
for all, so that it doesn't keep getting thrown in to dilute otherwise
logical discussions?

   - VW providers will provide whatever clients they like, and it's not up
   to us to say whether they should be one-service clients or multi-service
   clients.
   - The open-source community has the colossal benefit of unencumbered
   access to multiple libraries and middleware solutions, and frequently
   deploys them in generic clients with multi-service capability.  It is not up
   to us to forbid nor discourage that.
   - The degree to which generic clients can bloom into some theoretical
   "universal" client is severely limited by practical issues such as available
   manpower and machine limits such as memory size.  Raising the specter of
   "universal client" is therefore not even discussing reality.
   - Generic clients are certainly not "bad".  They provide the basis of
   "client-based interop", and empower their users tremendously.
   - We are creating an open *protocol*.  It's not up to us what kind of
   systems people design and implement around that protocol.
   - The web has acquainted users with the web browser, the quintessence of
   a generic client that has a natural tendency towards becoming universal.
   Whether we personally favour it or not, it is not up to us to prevent that
   happening in virtual worlds.
   - It is rather easy to speculate that, in due course, generic open-source
   VW clients will drive the metaverse towards de facto commonality and
   standardization.  Many would regard that as a good thing, and in a group
   formed for the purpose of protocol standardization, that seems a worthy goal
   to support.

Morgaine.

On Thu, Mar 5, 2009 at 8:02 PM, Jon Watte <[email-masked]> wrote:

> stacks (say, OLIVE and Metaverse, or There.com and Second Life) to connect
> to each other and achieve user-visible interoperability, then yes.
>
> object/sim/client platform stack involved in any one scenario. That's why
> it's actually counter to the goals of vendor neutral interoperability. Note
> that it also necessarily involves the client machines, and thus drives
> towards a "universal client" model, which I think is a bad idea for reasons
> I have already described.
>
> Sincerely,
>
> jw
>
>

---

From: Morgaine <[email-masked]>
Date: Fri, 6 Mar 2009 06:25:51 +0000

On Thu, Mar 5, 2009 at 8:02 PM, Jon Watte <[email-masked]> wrote:

> object/sim/client platform stack involved in any one scenario.
>

Could you explain the above point further please?

Morgaine.

---

From: Jon Watte <[email-masked]>
Date: Mon, 09 Mar 2009 11:50:26 -0700

Morgaine wrote:
> On Thu, Mar 5, 2009 at 8:02 PM, Jon Watte <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>

It's evident from just reading the protocol. If you try to think through 
two different technology stacks (say, Torque and Open Sim) trying to 
achieve interop using OGP, you immediately realize the problem.

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Mon, 09 Mar 2009 12:01:09 -0700

Morgaine wrote:
> We've addressed the issue of "universal client" many times before, and 
> yet you keep on bringing it up again.  Shall we examine it in detail 
> once and for all, so that it doesn't keep getting thrown in to dilute 
> otherwise logical discussions?

There are several people on this list who are explicitly saying that the 
goal is to create the "universal browser/viewer," similar to how a web 
browser is universal for static 2D text. Some of them have said it 
on-list; others have said it off-list. Also, the OGP proposal, in its 
design, assumes that there will be a universal browser/viewer. Thus, 
furthering OGP, means that you further the assumption that there will be 
a universal browser.

I believe a universal virtual world browser is a harmful meme for a few 
reason:

1) It either means that one protocol/technology stack is accepted as "de 
facto" standard, and everyone else will have to adapt (not vendor 
neutral), OR the entire client/server stack, including UI, simulation, 
update, rendering etc will have to be re-implemented by everyone. 
Neither case is acceptable by the larger world of VW providers.

2) It doesn't actually solve the interoperability problem. If I have 
some objects on system 1, and some objects on system 2, then a universal 
browser doesn't help me actually mash those together into a single space 
where I can use both of them.

3) Virtual worlds are real-time, interactive, communication types of 
systems. The web is a batch-centric, asynchronous, static type of 
system. The Virtual World model maps much better to the requirements for 
a cell phone provider, or an instant messaging system, than to a web 
server system. Thus, saying that "browsing 3D sites" is similar to 
"browsing 2D sites" totally discounts all of the actual value you get 
out of virtual worlds, which is about online, real-time interaction. If 
you look at how cell phones, or IM, or similar communications systems 
are delivered (even POTS!) then you see that the model is that the 
customer gets service from one service provider, and that service 
provider interops with other service providers. Each service provider 
can provide an integrated stack (say, cell phone network, handsets, 
services, etc), yet allows you to interop with other systems (such as 
calling your friend who has a different cell phone service provider). I 
believe that trying to make "the 3D web" look or work like the 2D web 
actually addresses just a fraction of the actual utility of the 
integrated virtual world, and inherently makes capturing the full 
utility much harder. If you don't believe me, then look at all the ghost 
towns created by companies that tried to create a "3D web site" in 
Second Life. The only destinations that work, are those that are about 
real-time interaction, not about "browsing."

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Mon, 9 Mar 2009 20:10:00 +0000

On Mon, Mar 9, 2009 at 7:01 PM, Jon Watte <[email-masked]> wrote:

> goal is to create the "universal browser/viewer,"
>

That is inaccurate --- nobody is claiming such a goal.  Indeed the word "*
universal*" has not appeared as a goal at all except from yourself, which
makes it look remarkably like a straw man.

Instead, there are several people (myself included) explaining that *generic
* browsers/viewers are *inevitable*, and they are not in our power to
disallow.  My detailed analysis of the reasons is given
here<http://www.ietf.org/mail-archive/web/mmox/current/msg01016.html>---
feel free to highlight where that logic is incorrect.

In addition to the above, please be aware that interop is easily achieved
between systems adhering to both approaches, for the following reason:

*A browser/viewer that contains knowledge of specific world architectures is
not in any way precluded from taking part in interop with worlds that
require no such knowledge.  Such browsers/viewers are a superset of the
clients that you advocate.*

Therefore the presence of such viewers in one proposal does not prevent
interop under contrary proposals at all.  Knowledge of world specifics in a
client is merely an *accelerator*, nothing else.

Morgaine.

On Mon, Mar 9, 2009 at 7:01 PM, Jon Watte <[email-masked]> wrote:

> browser is universal for static 2D text. Some of them have said it on-list;
> others have said it off-list. Also, the OGP proposal, in its design, assumes
> that there will be a universal browser/viewer. Thus, furthering OGP, means
> that you further the assumption that there will be a universal browser.
>
> facto" standard, and everyone else will have to adapt (not vendor neutral),
> OR the entire client/server stack, including UI, simulation, update,
> rendering etc will have to be re-implemented by everyone. Neither case is
> acceptable by the larger world of VW providers.
>
> 2) It doesn't actually solve the interoperability problem. If I have some
> objects on system 1, and some objects on system 2, then a universal browser
> doesn't help me actually mash those together into a single space where I can
> use both of them.
>
> systems. The web is a batch-centric, asynchronous, static type of system.
> The Virtual World model maps much better to the requirements for a cell
> phone provider, or an instant messaging system, than to a web server system.
> Thus, saying that "browsing 3D sites" is similar to "browsing 2D sites"
> totally discounts all of the actual value you get out of virtual worlds,
> which is about online, real-time interaction. If you look at how cell
> phones, or IM, or similar communications systems are delivered (even POTS!)
> then you see that the model is that the customer gets service from one
> service provider, and that service provider interops with other service
> providers. Each service provider can provide an integrated stack (say, cell
> phone network, handsets, services, etc), yet allows you to interop with
> other systems (such as calling your friend who has a different cell phone
> service provider). I believe that trying to make "the 3D web" look or work
> like the 2D web actually addresses just a fraction of the actual utility of
> the integrated virtual world, and inherently makes capturing the full
> towns created by companies that tried to create a "3D web site" in Second
> Life. The only destinations that work, are those that are about real-time
> interaction, not about "browsing."
>
> Sincerely,
>
> jw
>
>

---

From: Charles Krinke <[email-masked]>
Date: Mon, 9 Mar 2009 12:34:44 -0800

I concur Morgaine.

There are number of browser/client projects and products now. And they have
some differences in their interoperability which I believe will evolve over
the next few months.

SecondLife Client and Hippo Client - These appear to be very interoperable
with SecondLife and most OpenSim worlds.

IdealistViewer - Usable on SecondLife & most OpenSim worlds and includes
MXP.

OpenViewer - Usable on SecondLife and most OpenSim worlds

Xenkii - A web browser plugin just barely functional for SecondLife and
OpenSim worlds

AjaxLife - A SecondLife client that I have not heard of any testing with
OpenSim worlds yet.

RexViewer - Modestly intereoperable with Rex-derived OpenSim

OpenLife Client - Only usable with OpenLife.

These and others are evolving now and helping to guide that evolution is a
useful service we can provide. There are hundreds of thousands of folks in
total using this list of clients, so there is significant momentum being
gained.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Mon, Mar 9, 2009 at 12:10 PM, Morgaine <[email-masked]>wrote:

> Instead, there are several people (myself included) explaining that *
> generic* browsers/viewers are *inevitable*, and they are not in our power
> to disallow.  My detailed analysis of the reasons is given here<http://www.ietf.org/mail-archive/web/mmox/current/msg01016.html>--- feel free to highlight where that logic is incorrect.
>
> *A browser/viewer that contains knowledge of specific world architectures
> is not in any way precluded from taking part in interop with worlds that
>>> yet you keep on bringing it up again.  Shall we examine it in detail once
>>> and for all, so that it doesn't keep getting thrown in to dilute otherwise
>>> logical discussions?
>>>
>>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Jon Watte <[email-masked]>
Date: Mon, 09 Mar 2009 14:05:14 -0700

Morgaine wrote:
> On Mon, Mar 9, 2009 at 7:01 PM, Jon Watte <[email-masked] 
>     There are several people on this list who are explicitly saying
>     that the goal is to create the "universal browser/viewer,"
>
>
>
> Instead, there are several people (myself included) explaining that 
> /generic/ browsers/viewers are /inevitable/, and they are

To me, the terms "universal browser" and "generic browser" are 
synonymous, insofar as they affect the direction of virtual world 
standardization.

To make my point regarding them very clear: Furthering the development 
of a universal/generic browser is, at best, orthogonal to vendor neutral 
virtual world interoperability (which is synonymous with 
cross-architecture virtual world interoperability, as shown previously). 
Quite likely, it actually runs counter to that goal, because it 
de-focuses from the efforts that are actually required to get such 
interoperability off the ground. As a worst case, furthering the 
development of a universal/generic browser as part of the MMOX groups 
runs the risk of endorsing a systems approach that is actively harmful 
to vendor neutral virtual world interoperability.

Therefore, I don't think it's the role of the MMOX group to further 
those developments. I think those developments should be done in some 
separate venue -- just like I think "specifying ways that third parties 
can interoperate with the Second Life grid" should be done in a separate 
venue.

Sincerely,

jw

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Mon, 9 Mar 2009 14:47:19 -0700

<disclaimer>

please note that though i am the co-chair of an upcoming BoF regarding  
standardization of some VW protocol, the following statement is  
expressly _not_ IETF gospel. it is derived from my own observations of  
the public workings of the IETF. ergo.. it is non-canonical, but i  
believe reasonably accurate.

</disclaimer>

hmm... well... for what it's worth... i don't think the original  
charter said anything about developing a universal browser that would  
talk to EVERY virtual world or MMO.

and... this _is_ an IETF effort... we're not creating a new product  
definition, we're not writing down the functional specs for a new bit  
of software, we're "standardizing" the messaging and semantics of some  
of the messages that flow between existing and near-term  
implementations of OGP.

and yes, the charter is in flux, but it is HIGHLY UNLIKELY that the  
IETF would approve a WG charter that identified software as an  
objective. the IETF is a standards body... remember? and... a  
universal protocol for a universal browser also doesn't seem like the  
kind of thing the IETF would want to sign itself up for.

sure.. if 95% of the VW operators woke up tomorrow and said...  
"yeah... hey.. universal protocol for a universal browser... that  
sounds like a grand idea!" okay... maybe then the IETF would get  
involved.

but it doesn't seem like that's going to happen anytime soon, which is  
why MMOX in it's current form (without the call for a universal viewer  
or protocol) was proposed.

-cheers
-meadhbh

On Mar 9, 2009, at 2:05 PM, Jon Watte wrote:

> Morgaine wrote:
>> On Mon, Mar 9, 2009 at 7:01 PM, Jon Watte <[email-masked] <mailto:[email-masked] 
>> >> wrote:
>>
>>
>> Instead, there are several people (myself included) explaining  
>> that /generic/ browsers/viewers are /inevitable/, and they are
>
> To make my point regarding them very clear: Furthering the  
> development of a universal/generic browser is, at best, orthogonal  
> to vendor neutral virtual world interoperability (which is  
> synonymous with cross-architecture virtual world interoperability,  
> as shown previously). Quite likely, it actually runs counter to that  
> goal, because it de-focuses from the efforts that are actually  
> required to get such interoperability off the ground. As a worst  
> case, furthering the development of a universal/generic browser as  
> part of the MMOX groups runs the risk of endorsing a systems  
> approach that is actively harmful to vendor neutral virtual world  
> interoperability.
>
> those developments. I think those developments should be done in  
> some separate venue -- just like I think "specifying ways that third  
> parties can interoperate with the Second Life grid" should be done  
> in a separate venue.
>
> Sincerely,
>
> jw
>

---

From: Jon Watte <[email-masked]>
Date: Mon, 09 Mar 2009 15:42:01 -0700

> or protocol) was proposed.

Great, we agree!

This doesn't answer the question, though: If a specific protocol, as 
proposed, makes the assumption that there will be a universal/generic 
browser/viewer involved, should the protocol still be included in our 
efforts? My take on that is "no," for the reasons I explained that 
started this thread.

Sincerely,

jw

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Mon, 9 Mar 2009 15:44:13 -0700

yes, but i think we disagree on a universal server <-> server protocol.

On Mar 9, 2009, at 3:42 PM, Jon Watte wrote:

>> but it doesn't seem like that's going to happen anytime soon, which  
>> is why MMOX in it's current form (without the call for a universal  
>> viewer or protocol) was proposed.
>
> Great, we agree!
>
> proposed, makes the assumption that there will be a universal/ 
> generic browser/viewer involved, should the protocol still be  
> included in our efforts? My take on that is "no," for the reasons I  
> explained that started this thread.
>
> Sincerely,
>
> jw
>

---

From: Jon Watte <[email-masked]>
Date: Mon, 09 Mar 2009 17:08:17 -0700

> yes, but i think we disagree on a universal server <-> server protocol.

I'm very interested in your reasoning. If you do not believe in a 
standardized server<->server protocol, do you believe that such a 
protocol is (check all that apply):

4) Not able to deliver useful vendor neutral virtual world interoperability?
3) Not suitable for standardization in MMOX?
2) Not feasible with current technology/resources?
1) Not interesting to Linden Lab?
0) Something else?

>> If a specific protocol, as proposed, makes the assumption that there 
>> will be a universal/generic browser/viewer involved, should the 
>> protocol still be included in our efforts?

That question is still not answered, though.

Sincerely,

jw

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Mon, 9 Mar 2009 18:28:17 -0700

universal != standardized

On Mar 9, 2009, at 5:08 PM, Jon Watte wrote:

>>> If a specific protocol, as proposed, makes the assumption that  
>>> there will be a universal/generic browser/viewer involved, should  
>>> the protocol still be included in our efforts?
>

---

From: Charles Krinke <[email-masked]>
Date: Mon, 9 Mar 2009 18:22:45 -0800

As I think about this Meadhbh, it seems to me that some sort of
standardization of the existing login sequence of the SecondLife protocol is
not unreasonable. It also seems to me that on form that interop may take is
that of causing a simulator, on behalf of a client, to offer a login
sequence to another simulator in a different virtual world.

Whether this is using LLSD or OGP or LESS or MXP or HyperGrid (or something
else), has yet to be determined. And it is too early to jump to that
conclusion.

As we have discussed, this is a time for discussing the problem-space as
opposed to the solution-space.

I look at some of the virtual worlds and can see that various scripts and
sim modifications are currently used to offer a login to a new and slightly
dissimilar world. This seems like a reasonable direction to pursue. It might
help us to back off from emotion filled acronyms a bit from some quarters
and discuss more of the problem and less of the solution.

One of the mistakes that many folks make at this stage is to go directly to
a solution and thereby blinding themselves to any other possible solutions.
By concentrating on the problem instead of the solution for a while, one can
perhaps get beyond that a bit.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Mon, Mar 9, 2009 at 5:28 PM, Meadhbh Hamrick (Infinity) <
[email-masked]> wrote:

>> standardized server<->server protocol, do you believe that such a protocol
>> is (check all that apply):
>>
>>  If a specific protocol, as proposed, makes the assumption that there will
>>>> be a universal/generic browser/viewer involved, should the protocol still be
>>>> included in our efforts?
>>>>
>>>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Morgaine <[email-masked]>
Date: Tue, 10 Mar 2009 02:31:56 +0000

> That question is still not answered, though.

I can answer it for you:  "Yes it should, for the following reasons:"

   1. The large suite of "You cannot sweep back the
tide<http://www.ietf.org/mail-archive/web/mmox/current/msg01016.html>"
   reasons.
   2. Having a viewer in the solution space is a superset of not having one,
   and therefore provides an avenue for interop.  You can make your endpoints
   entirely server-server while othesr use a combination of endpoint types,
   including client-client for P2P worlds.
   3. By your own advice, forcing people to adopt a foreign architecture is
   inappropriate:  therefore forcing people whose architecture features a
   viewer to lose it is inappropriate.  (Note that nobody is forcing your
   clients to speak the MMOX protocol.)

I am trying to find solution pathways that embrace everyone's needs.  I
cannot do that if you insist that any solution that caters for the needs of
others prevents interop with yourself.  It is very far from the truth.

Remember that the MMOX protocols are not yet defined (OGP is very much a
skeleton), so there is ample room for shaping them as needed to suit diverse
architectures.

Morgaine.

---

From: Jesrad <[email-masked]>
Date: Tue, 10 Mar 2009 10:28:53 +0100

I believe what Morgaine means by "generic/universal client" is a
client that can also double, to some significant extent, as a
MMOX-compliant peer, when needed by the user operating it.

As for me, I see MMOX endpoints occuring in the client and in the
server(s) as each local VW implementation commands, so that's where I
think any genericity and/or universality will predominate from
expectable standardization and reuse of software.

On Tue, Mar 10, 2009 at 3:31 AM, Morgaine
<[email-masked]> wrote:
>>>> will be a universal/generic browser/viewer involved, should the protocol
>>>> still be included in our efforts?
>>
> The large suite of "You cannot sweep back the tide" reasons.
> Having a viewer in the solution space is a superset of not having one, and
> therefore provides an avenue for interop.  You can make your endpoints
> By your own advice, forcing people to adopt a foreign architecture is
>>>> will be a universal/generic browser/viewer involved, should the protocol
>>>> still be included in our efforts?
>>

---

From: Charles Krinke <[email-masked]>
Date: Tue, 10 Mar 2009 06:11:42 -0800

Indeed, Jesrad, I concur.

It seems to me that the notion of interop between existing virtual worlds
tends to concern the client<->sim communication to a significant extent.

After all, what we are really trying to do in a world where there are
multiple, existing, virtual worlds, is to emulate the client login procedure
on differing designs. So, I believe the client<->sim communication is
pertinent to how interop evolves.

I would like to hear more technical details about login steps in detail to
the various virtual worlds like Croquet and Wonderland and less posturing on
how the future may (or may not) evolve.

Charles Krinke
OpenSim Core Developer
OSGrid Director

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: "Mystical Demina" <[email-masked]>
Date: Tue, 10 Mar 2009 18:07:34 -0400

I would suggest not defining things as clients talking to servers but
instead as objects talking to objects, or end points talking to endpoints.
The fact that one implementation of a protocol ends up being a client will
only be one of the many implementations.  If I hire some company to provide
AI robots to run my customer service desk would that not look like clients
to my virtual world even though it is a server talking to a server?

The hard part of this is defining all the possible conversations that can
occur between two end points.  Simple things like 
"Hello, who are you, what do you want? " "Ok I know you, you can create an
object here." need to be defined as message and response sequence.  To me if
we can break these conversations down into atomic components then different
users of the supply chain can implement them as needed for their pool of
users and endpoints.

A step further if you abstract out OGP and LESS I think we find a generic
set of messages and sequences that are occurring kind of like how .NET CLR
is able to implement any C# and VP.  This atomic set of messages and
sequences will let OGP and LESS interoperable way in that one end point may
be talking OGP and the other is talking LESS.

Just the recursive natural of things mean a prim could be a while virtual
world to someone else.  It is all a matter of defining the coordinate system
and your relative or absolute space within it. As such a prim could be a
virtual world if it supported the need interfaces or message squences.

I submit we have a solution for this in how object oriented is defined.  We
know how to do polymorphism and move from general to specific.  In defining
these atomic messages and sequences we can support people to extend them as
need to their specific uses.  If we can do that I see something that will
grow over time and be able to be flexible enough to be the foundation for
interoperability between virtual worlds.  I have started working on this but
I don't have so much time so won't have it right away.

Kevin Tweedy

SL:Mystical Demina

 

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Charles Krinke
Sent: Tuesday, March 10, 2009 10:12 AM
To: Jesrad
Cc: Jon Watte; [email-masked]
Subject: Re: [mmox] MMOX Progress tracking

Charles Krinke
OpenSim Core Developer
OSGrid Director

>>>> will be a universal/generic browser/viewer involved, should the
protocol
>> standardized server<->server protocol, do you believe that such a
protocol
>>>> will be a universal/generic browser/viewer involved, should the
protocol

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Charles Krinke <[email-masked]>
Date: Tue, 10 Mar 2009 14:25:44 -0800

Great point, Mystical.

As we pull the problem apart, defining those objects (or endpoints) and how
a conversation begins with : "May I connect to your sim" and ends with "You
are instanced and ready to fly your virtual F-16 around" will be a
significant part of the puzzle to solve.

Each virtual world that we know of has similar, but not identical
conversations that take place when an object or endpoint wishes to connect.

Those familiar with OpenSim source know how it connects, but dont know how
Croquet or Wonderland connects. And the converse is also true.

So, it seems to me that understanding those conversations for publicly
available virtual worlds that anyone can connect to at no charge will be an
important question to answer for each of those publicly available virtual
worlds.

At that point, one can write scripts, submit patches, petition developers
and all the rest necessary to test and prototype such ideas. Which,
hopefully will become documented in the MMOX protocol.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Tue, Mar 10, 2009 at 2:07 PM, Mystical Demina
<[email-masked]>wrote:

> “Hello, who are you, what do you want? “ “Ok I know you, you can create an
> object here.” need to be defined as message and response sequence.  To me if
> I don’t have so much time so won’t have it right away.
>
>
>
> Kevin Tweedy
>
> SL:Mystical Demina
>
>
>
>
>
>
>
>
>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Charles Krinke
> *Sent:* Tuesday, March 10, 2009 10:12 AM
> *To:* Jesrad
> *Cc:* Jon Watte; [email-masked]
> *Subject:* Re: [mmox] MMOX Progress tracking
>
>
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Morgaine <[email-masked]>
Date: Wed, 11 Mar 2009 11:47:25 +0000

On Tue, Mar 10, 2009 at 9:28 AM, Jesrad <[email-masked]> wrote:

> As for me, I see MMOX endpoints occuring in the client and in the server(s)
> as each local VW implementation commands, so that's where I think *any
> genericity and/or universality will predominate from expectable
> standardization and reuse of software*.
>
>
That's 100% right, Jesrad.  Clients become generic as a result of common *
extensible* handling of a wide range of standard media and object
interchange formats (an ever-growing set), typically reusing standard
libraries.  It is perfectly natural and sound engineering practice to seek
such reuse, and hence, genericity.

This is why I sometimes talk about generic clients as being dumb clients
with added *accelerators*.  If you often visit world X, and world X employs
some object types that can be accelerated with special client-side
handlings, and if your machine is able to support such acceleration (for
example through GPU shaders), then it makes sense to acquire and use such
acceleration if it is available.  This process can be automated so that it
is completely transparent to the end user, and it is a general argument, not
specific to graphics at all.

Such dynamic client accelerators are essential if the interactivity and user
perception of quality in VWs is to track the march of progress in end user
equipment, and to harness its high power.  The concept of dynamic
accelerators also fits in well with the trend towards refactoring monolithic
clients in the "Age of Multicore" that has just started.

This** view is reinforced further by looking at the needs of *Limited
Capability Clients*, which we've discussed before.  They require the ability
to select only a limited number of world features out of the large set
offered by a world --- for example, text chat only.  (Such selection is
supported by OGP through its capability mechanism, in principle.)  Since an
LCC-friendly model regards *everything* as optional, thinking of clients as
dumb communication frameworks plus a range of chosen options and
accelerators fits in perfectly.

Morgaine.

---

From: Jon Watte <[email-masked]>
Date: Wed, 11 Mar 2009 08:44:00 -0700

Morgaine,

You have made arguments for why some people want to standardize a client 
protocol. You have not made an argument for why that should be included 
in a standardization effort that specifically attempts to achieve vendor 
neutral interop. A standardized client protocol is, by definition, not 
vendor neutral, because it cannot be expected to be implemented by all 
systems to achieve interop between all systems -- in fact, it does not 
achieve cross-system interop at all.

So, the question is: "Why should a standardized client protocol be part 
of MMOX, which allegedly attempts to achieve vendor-neutral virtual 
world interop?" Connecting a client to one of many worlds is not virtual 
world interop, because there is never more than one world involved at a 
time, so clearly there's no world interop.

Sincerely,

jw

Morgaine wrote:
> On Tue, Mar 10, 2009 at 12:08 AM, Jon Watte <[email-masked] 
>             If a specific protocol, as proposed, makes the assumption
>             that there will be a universal/generic browser/viewer
>             involved, should the protocol still be included in our
>             efforts?
>
>
>    1. The large suite of "You cannot sweep back the tide
>       <http://www.ietf.org/mail-archive/web/mmox/current/msg01016.html>"
>       reasons.
>    2. Having a viewer in the solution space is a superset of not
>       having one, and therefore provides an avenue for interop.  You
>       can make your endpoints entirely server-server while othesr use
>       a combination of endpoint types, including client-client for P2P
>       worlds.
>    3. By your own advice, forcing people to adopt a foreign
>       architecture is inappropriate:  therefore forcing people whose
>       architecture features a viewer to lose it is inappropriate. 
>       (Note that nobody is forcing your clients to speak the MMOX
>       protocol.)
>
>
> I am trying to find solution pathways that embrace everyone's needs.  
> I cannot do that if you insist that any solution that caters for the 
> needs of others prevents interop with yourself.  It is very far from 
> the truth.
>
> Remember that the MMOX protocols are not yet defined (OGP is very much 
> a skeleton), so there is ample room for shaping them as needed to suit 
> diverse architectures.
>
>
> Morgaine.
>
>
>
>
>
>
>
>
>
>
> On Tue, Mar 10, 2009 at 12:08 AM, Jon Watte <[email-masked] 
>             If a specific protocol, as proposed, makes the assumption
>             that there will be a universal/generic browser/viewer
>             involved, should the protocol still be included in our
>             efforts?
>
>

---

From: Rob Lanphier <[email-masked]>
Date: Wed, 11 Mar 2009 11:15:57 -0700

On 3/11/09 8:44 AM, Jon Watte wrote:
> So, the question is: "Why should a standardized client protocol be
> part of MMOX, which allegedly attempts to achieve vendor-neutral
> virtual world interop?" Connecting a client to one of many worlds is
> not virtual world interop, because there is never more than one world
> involved at a time, so clearly there's no world interop.

Are you claiming there's no value in an IETF standard around virtual
world client-server interop?

Rob

---

From: Morgaine <[email-masked]>
Date: Wed, 11 Mar 2009 18:52:54 +0000

> You have made arguments for why some people want to standardize a client

Wrong.  I have been looking for ways to achieve interop between both camps,
the pro-client camp and the anti-client camp alike.  That can be achieved by
taking the *superset* approach to interop, by noting (and ensuring) that in
your case the clients would not need to talk the protocol --- your servers
alone would do it.

You in contrast are rejecting interop between the two camps entirely, by
insisting that the only way to achieve interop is for everyone else to drop
a key element of their interop architecture and to use your method alone.
What you seek is neither vendor-neutral nor architecture-neutral nor
technology-neutral, and for good measure it's coercive as well since it
seeks to force everyone else to your own model of interop.  (I'm using these
unhelpful motherhood and applie pie
phrases<http://www.ietf.org/mail-archive/web/mmox/current/msg01018.html>only
because you insist on them.)

Instead of rejecting interop except on your own terms, how about taking a
constructive approach and looking for solutions instead?  Here is one
constructive approach:

*Since LESS has no clients in its interop model, a MMOX protocol would be
relevant only to LESS servers.  Therefore, where a MMOX protocol would
involve clients in communication, let's ensure that the protocol is equally
suited for talking to a LESS server to achieve the same goals.
*

There you go --- an approach that would lead to satisfying the requirements
of LESS and everyone else at the same time.

It's not hard to find ways of moving forward.  It just requires a desire to
cooperate.

Morgaine.

On Wed, Mar 11, 2009 at 3:44 PM, Jon Watte <[email-masked]> wrote:

> protocol. You have not made an argument for why that should be included in a
> standardization effort that specifically attempts to achieve vendor neutral
> interop. A standardized client protocol is, by definition, not vendor
> neutral, because it cannot be expected to be implemented by all systems to
> achieve interop between all systems -- in fact, it does not achieve
> cross-system interop at all.
>
> So, the question is: "Why should a standardized client protocol be part of
> MMOX, which allegedly attempts to achieve vendor-neutral virtual world
> interop?" Connecting a client to one of many worlds is not virtual world
> interop, because there is never more than one world involved at a time, so
> clearly there's no world interop.
>
> Sincerely,
>
> jw
>
>
> Morgaine wrote:
>
>> On Tue, Mar 10, 2009 at 12:08 AM, Jon Watte <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
>>
>> On Tue, Mar 10, 2009 at 12:08 AM, Jon Watte <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>

---

From: Charles Krinke <[email-masked]>
Date: Wed, 11 Mar 2009 11:52:59 -0800

I believe that if we concentrate on the commonalities between some of the
virtual worlds and how we can connect or login to them from other virtual
worlds that we can find the beginning of a common solution.

We also need implementations. I have seen OGP, HyperGrid and MXP all work.
There is existing opensource logic for all three. I would urge those
promoting the LESS idea to come up with an implementation in order to gain
some credibility for the idea. When I say implementation, what I mean is
something that some other virtual world can code to and perform some sort of
interop with either a client, a sim, or a hybrid approach.

To the extent we concentrate on the similarities in the problem space, we
can move forward.

So, lets find the common login or interop points between more virtual worlds
and see if we can come up with something.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Wed, Mar 11, 2009 at 10:52 AM, Morgaine
<[email-masked]>wrote:

> taking the *superset* approach to interop, by noting (and ensuring) that
> in your case the clients would not need to talk the protocol --- your
> servers alone would do it.
>
> unhelpful motherhood and applie pie phrases<http://www.ietf.org/mail-archive/web/mmox/current/msg01018.html>only because you insist on them.)
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Wed, 11 Mar 2009 15:30:57 -0700

okay... before we slice into the weeds on the issue of focus and  
terminology.. lemme try to recap..

a. we are at a disadvantage in that we are discussing technical  
matters without a clear charter. i think it's come up in the past,  
let's reiterate... "our objective is to achieve consensus on a  
charter, and this objective is being informed by detailed technical  
proposals." it's a lot easier to say things like "we shouldn't be  
discussing standardized client <-> server protocols" when there's a  
charter that supports such an assertion. for the time being, we'll all  
have to be liberal in the things we consider in an effort to find  
where the consensus for a charter lives.

b. it might be too early to say "we should discount a protocol 'cause  
there are no public implementations." The IETF doesn't standardize  
protocols that aren't implemented, so if LESS doesn't get implemented,  
it won't matter whether it was discussed or not at this early  
stage.That being said, Charles has a point, and i think it was  
something along the lines... "the commentary you get on LESS will be  
more valuable if there's an implementation people can play with in an  
effort to understand where the interop bugbears lurk."

c. even if LESS (or OGP or LLSD or VP-I or HG or ...) don't get  
adopted as working group objectives, the discussion of the ideas  
underlying their design is definitely apropos. For example... LLSDisms  
probably appear strange unless you've been involved in the OGP effort,  
and even then, the benefit of LLSD as a notational syntax may not be  
obvious unless you need to support VW components with multiple  
concurrent versions. likewise... LESS' interop model appears to be  
strongly focused on server to server communications, which probably  
strikes the OGP community as odd.

at the end of the day, our work is less about which sets of  
assumptions are superior (for some definition of the word "superior")  
and more about how we get them to work together. we have discussed the  
"strong assumption" where ALL hosts adhere to a standardized protocol,  
the "weak assumption" where SOME hosts adhere to SOME protocol and the  
"semi-weak assumption" where SOME hosts adhere to ALL protocol. at the  
end of the day, what we're trying to figure out here is how we want to  
partition the problem. should LESS be carved off and placed in it's  
own working group? should OGP? are the representational and info flow  
differences between the LESS and OGP models so different they can't be  
bridged?

i would think it isn't in our best interest to argue whether a  
standardized protocol between client and server or between server and  
server is a "good idea." or that a protocol completely specify the  
interaction between components (i.e. - the protocol is not-extensible  
and cannot be embedded in a larger protocol). there are enough people  
here to justify work on a client <-> server protocol. there also  
appear to be at least two camps for server <-> server interaction at  
the moment: OGP and LESS (with room for HG and others to delurk in the  
future.) there's no reason both can't exist, and even a hybrid  
solution using OGP for client/server and LESS for server/server  
interactions. i think the question is more like... how do we want to  
proceed? are OGP and LESS assumptions insurmountable?

On Mar 11, 2009, at 12:52 PM, Charles Krinke wrote:

> I believe that if we concentrate on the commonalities between some  
> of the virtual worlds and how we can connect or login to them from  
> other virtual worlds that we can find the beginning of a common  
> solution.
>
> We also need implementations. I have seen OGP, HyperGrid and MXP all  
> work. There is existing opensource logic for all three. I would urge  
> those promoting the LESS idea to come up with an implementation in  
> order to gain some credibility for the idea. When I say  
> implementation, what I mean is something that some other virtual  
> world can code to and perform some sort of interop with either a  
> client, a sim, or a hybrid approach.
>
> To the extent we concentrate on the similarities in the problem  
> space, we can move forward.
>
> So, lets find the common login or interop points between more  
> virtual worlds and see if we can come up with something.
>
> Charles Krinke
> OpenSim Core Developer
> OSGrid Director
>
>
> On Wed, Mar 11, 2009 at 10:52 AM, Morgaine <[email-masked] 
> > wrote:
> You have made arguments for why some people want to standardize a  
> client protocol.
>
>
> Wrong.  I have been looking for ways to achieve interop between both  
> camps, the pro-client camp and the anti-client camp alike.  That can  
> be achieved by taking the superset approach to interop, by noting  
> (and ensuring) that in your case the clients would not need to talk  
> the protocol --- your servers alone would do it.
>
> You in contrast are rejecting interop between the two camps  
> entirely, by insisting that the only way to achieve interop is for  
> everyone else to drop a key element of their interop architecture  
> and to use your method alone.  What you seek is neither vendor- 
> neutral nor architecture-neutral nor technology-neutral, and for  
> good measure it's coercive as well since it seeks to force everyone  
> else to your own model of interop.  (I'm using these unhelpful  
> motherhood and applie pie phrases only because you insist on them.)
>
> Instead of rejecting interop except on your own terms, how about  
> taking a constructive approach and looking for solutions instead?   
> Here is one constructive approach:
>
>
> Since LESS has no clients in its interop model, a MMOX protocol  
> would be relevant only to LESS servers.  Therefore, where a MMOX  
> protocol would involve clients in communication, let's ensure that  
> the protocol is equally suited for talking to a LESS server to  
> achieve the same goals.
>
>
> There you go --- an approach that would lead to satisfying the  
> requirements of LESS and everyone else at the same time.
>
> It's not hard to find ways of moving forward.  It just requires a  
> desire to cooperate.
>
>
> Morgaine.
>
>
>
>
>
>
>
>
>
>
> You have made arguments for why some people want to standardize a  
> client protocol. You have not made an argument for why that should  
> be included in a standardization effort that specifically attempts  
> to achieve vendor neutral interop. A standardized client protocol  
> is, by definition, not vendor neutral, because it cannot be expected  
> to be implemented by all systems to achieve interop between all  
> systems -- in fact, it does not achieve cross-system interop at all.
>
> not virtual world interop, because there is never more than one  
> world involved at a time, so clearly there's no world interop.
>
> Sincerely,
>
> jw
>
>
> Morgaine wrote:
> On Tue, Mar 10, 2009 at 12:08 AM, Jon Watte <[email-masked] <mailto:[email-masked] 
> >> wrote:
>
>
>      architecture features a viewer to lose it is  
> inappropriate.      (Note that nobody is forcing your clients to  
> speak the MMOX
>      protocol.)
>
>
> I am trying to find solution pathways that embrace everyone's  
> needs.  I cannot do that if you insist that any solution that caters  
> for the needs of others prevents interop with yourself.  It is very  
> far from the truth.
>
> Remember that the MMOX protocols are not yet defined (OGP is very  
> much a skeleton), so there is ample room for shaping them as needed  
> to suit diverse architectures.
>
>
> Morgaine.
>
>
>
>
>
>
>
>
>
>
> On Tue, Mar 10, 2009 at 12:08 AM, Jon Watte <[email-masked] <mailto:[email-masked] 
> >> wrote:
>

---

From: Jon Watte <[email-masked]>
Date: Wed, 11 Mar 2009 17:46:17 -0700

> world client-server interop?

I am claiming that a client/server protocol does not achieve virtual 
world interop, because there is only one world involved in the 
connection. Thus, there is no interop between virtual worlds (plural). 
Thus, it's not applicable to the "vendor neutral virtual world 
interoperability" that is in the charter for this group, because, by 
necessity, only one vendor and one world is involved at a time. Let's 
call it scope control.

Separately, as I keep having to repeat every week, because new people 
come to the list: I think that a standard client/server protocol solves 
a very small, uninteresting problem. It solves the problem of having to 
install two, three or four clients, which is a small problem. In fact, I 
doubt you could even get very many people to pay a single dollar for the 
convenience of not having to install two clients to be able to visit two 
different worlds (assuming versioning could be solved at all). It 
doesn't solve anything else -- specifically, if I want to be with person 
A, who is in virtual world A, and person B, who is in virtual world B, 
at the same time, a standardized server/client protocol makes no 
difference; I still have to choose one or the other. That is a problem 
we have now, have no good vendor neutral solution for, and need a 
standard for.

If you want a standard for client/server connections that lets you stay 
within the same client while switching connection between different, 
independent worlds, just put a plugin in a browser, and write it in 
Flash or Java. The language and the browser is the standard; it can be 
done today (and has been done). I can, from my browser, easily surf on 
over to another site that uses a different flash/java plug-in, and 
connect to that other world, without losing my browser context. For all 
intents and purposes, this looks to the user as if "the same client" 
connects to those different worlds. The fact that very few implementors 
do that means that that kind of interop simply isn't that interesting.

If you think it's valuable to have a client/server protocol standardized 
through the IETF, then you should do so within a group that is 
appropriately chartered. In my opinion, the MMOX charter is not 
appropriate for that at the current time (and, in my opinion, that's a 
good thing).

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Wed, 11 Mar 2009 17:58:51 -0700

> Here is one constructive approach:

I am, constructively, trying to look for common ground for interop. You 
may note that I am proposing an easily implementable standard that does 
things that can only be done on a per-vendor basis today, solving 
problems that are real and at the front of the mind of many of the users 
I interact with (among those who care for interop). If you have a 
specific problem with the logic behind the LESS protocol, or the 
operational mode of the LESS protocol, or the presentation of the LESS 
protocol, let's hear it! That's how things get better.

>
> */Since LESS has no clients in its interop model, a MMOX protocol 
> protocol would involve clients in communication, let's ensure that the 
> protocol is equally suited for talking to a LESS server to achieve the 
> same goals./
> *
>

LESS is specified as a peer<->peer protocol. It even uses the word 
"peer" in the specification. As I said weeks ago (in a message you 
responded to), when I presented this model at IEEE MMVR 2007, I even had 
slides that showed P2P VW clients participating in the collective 
hallucination. It is, however, easiest to explain in terms of 
server<->server interop, because that maps bets to the models actually 
used by 95% of all current VW providers.

However, there are various capability and trust issues that do differ 
between the server<->server and the client<->server situations. If you 
want to do trusted simulation, then it's easy to verify a given 
server-based peer. However, verifying an arbitrary connecting client is 
not as easy. It's like the Internet: a back-haul provider will peer with 
defined partners under defined conditions; they won't open up their 
center to any random guy off the street. It's not impossible to let 
anyone put up a BGP router and set up peering in your physical locale -- 
it's just not practical (nor that interesting or needed to solve any 
particular problem for end users).

Personally, I don't see anyone building a LESS client, for this reason 
and others. However, if you feel like it, go right ahead! It is, 
however, designed to be easy to drop into most current server 
infrastructures through a translator; it is not designed to solve the 
superset of problems you get into when involving clients, such as GUI, 
patching, etc. You could quite likely add support for those things, but 
I feel that would diffuse the effort too much with too little additional 
near-term value. Personally, I don't feel it's needed to standardize 
those things, and I believe that attempts to standardize those things 
will take away effort from those things I feel will deliver real, 
lasting, solutions to problems that can't be solved today because of 
balkanization.

Sincerely,

jw

---

From: Charles Krinke <[email-masked]>
Date: Wed, 11 Mar 2009 17:19:09 -0800

In the last year, I have seen four different interop demonstrations and all
four of them involved the client and not server to server communication
exclusively. They did use several different clients, and that is a very good
thing.

1. Linden's OGP where avatars, using a slightly modified SecondLife client
were able to move (or teleport, to use the vernacular) from the Linden
"betagrid" to standalone OpenSim regions on IBM servers and then later to
OpenSim regions on OSGrid.

2. HyperGrid teleporting from regions on UC Irvine's grid to OSGrid and back
using both the standard SecondLife client and the Hippo client.

3. HyperGrid teleporting from OSGrid to the PseudoSpace grid using both the
standard SecondLife Client and expedited by a "prim" based script.

4. Two avatars using two different clients, one SecondLife compatible, one
the MXP test client both in one OpenSim region at the same time.

I submit that the client is important in this interop. Additionally, I
submit that it appears that folks prefer to use their current and favorite
client to visit other virtual worlds.

Therefore, my view of interop includes the participation of the client, at
least in the currently demonstrated and functional interop going on right
now and continuing in further development.

There may be server to server connections as well, and I would not preclude
them. I would rather, suggest that both operational modes are reasonable,
valid, and should be part of the charter of this group.

Again, I would urge those with proposed and unimplemented ideas to find ways
to create or motivation the creation of an implementation in order to gain a
bit more credibility in their ideas.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Wed, Mar 11, 2009 at 4:58 PM, Jon Watte <[email-masked]> wrote:

> I am, constructively, trying to look for common ground for interop. You may
> note that I am proposing an easily implementable standard that does things
> that can only be done on a per-vendor basis today, solving problems that are
> real and at the front of the mind of many of the users I interact with
> (among those who care for interop). If you have a specific problem with the
> logic behind the LESS protocol, or the operational mode of the LESS
> protocol, or the presentation of the LESS protocol, let's hear it! That's
> how things get better.
>
>
>> */Since LESS has no clients in its interop model, a MMOX protocol would be
>> suited for talking to a LESS server to achieve the same goals./
>> *
>>
>>
> LESS is specified as a peer<->peer protocol. It even uses the word "peer"
> in the specification. As I said weeks ago (in a message you responded to),
> when I presented this model at IEEE MMVR 2007, I even had slides that showed
> P2P VW clients participating in the collective hallucination. It is,
> however, easiest to explain in terms of server<->server interop, because
> that maps bets to the models actually used by 95% of all current VW
> providers.
>
> between the server<->server and the client<->server situations. If you want
> to do trusted simulation, then it's easy to verify a given server-based
> peer. However, verifying an arbitrary connecting client is not as easy. It's
> like the Internet: a back-haul provider will peer with defined partners
> under defined conditions; they won't open up their center to any random guy
> off the street. It's not impossible to let anyone put up a BGP router and
> set up peering in your physical locale -- it's just not practical (nor that
> interesting or needed to solve any particular problem for end users).
>
> Personally, I don't see anyone building a LESS client, for this reason and
> others. However, if you feel like it, go right ahead! It is, however,
> designed to be easy to drop into most current server infrastructures through
> a translator; it is not designed to solve the superset of problems you get
> into when involving clients, such as GUI, patching, etc. You could quite
> likely add support for those things, but I feel that would diffuse the
> effort too much with too little additional near-term value. Personally, I
> don't feel it's needed to standardize those things, and I believe that
> attempts to standardize those things will take away effort from those things
> I feel will deliver real, lasting, solutions to problems that can't be
> solved today because of balkanization.
>
>
> Sincerely,
>
> jw
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Morgaine <[email-masked]>
Date: Thu, 12 Mar 2009 01:33:01 +0000

On Thu, Mar 12, 2009 at 12:46 AM, Jon Watte <[email-masked]> wrote:

>
> I am claiming that a client/server protocol does not achieve virtual world
> interop, because there is only one world involved in the connection. Thus,
> there is no interop between virtual worlds (plural). Thus, it's not
> applicable to the "vendor neutral virtual world interoperability" that is in
> the charter for this group, because, by necessity, only one vendor and one
> world is involved at a time.
>

Of course there is "interop between virtual worlds (plural)".

Perhaps you're not thinking broadly enough?  The server to which a client
connects can be viewed as a domain-specific persistent proxy for all the
other virtual worlds to which the server connects, as well as an indirect
proxy for all their remote clients.  There is no good reason to suggest that
interop through a persistent proxy is no longer interop.

Interop is something that is achieved across the complete
client-server-server-client system, not just between two machines.

In any case, the servers are really just a means to an end.  The actual *
goal* of interop is to get *clients* to share experiences beyond the
confines of their single provider's network, so wanting to leave clients out
of the equation seems highly artificial. ;-)

Morgaine.

On Thu, Mar 12, 2009 at 12:46 AM, Jon Watte <[email-masked]> wrote:

> I am claiming that a client/server protocol does not achieve virtual world
> interop, because there is only one world involved in the connection. Thus,
> there is no interop between virtual worlds (plural). Thus, it's not
> applicable to the "vendor neutral virtual world interoperability" that is in
> the charter for this group, because, by necessity, only one vendor and one
> world is involved at a time. Let's call it scope control.
>
> Separately, as I keep having to repeat every week, because new people come
> to the list: I think that a standard client/server protocol solves a very
> small, uninteresting problem. It solves the problem of having to install
> two, three or four clients, which is a small problem. In fact, I doubt you
> could even get very many people to pay a single dollar for the convenience
> of not having to install two clients to be able to visit two different
> worlds (assuming versioning could be solved at all). It doesn't solve
> anything else -- specifically, if I want to be with person A, who is in
> virtual world A, and person B, who is in virtual world B, at the same time,
> a standardized server/client protocol makes no difference; I still have to
> choose one or the other. That is a problem we have now, have no good vendor
> neutral solution for, and need a standard for.
>
> independent worlds, just put a plugin in a browser, and write it in Flash or
> Java. The language and the browser is the standard; it can be done today
> (and has been done). I can, from my browser, easily surf on over to another
> site that uses a different flash/java plug-in, and connect to that other
> world, without losing my browser context. For all intents and purposes, this
> looks to the user as if "the same client" connects to those different
> worlds. The fact that very few implementors do that means that that kind of
> interop simply isn't that interesting.
>
> through the IETF, then you should do so within a group that is appropriately
> chartered. In my opinion, the MMOX charter is not appropriate for that at
> the current time (and, in my opinion, that's a good thing).
>
> Sincerely,
>
> jw
>
>

---

From: Jon Watte <[email-masked]>
Date: Wed, 11 Mar 2009 19:55:20 -0700

Meadhbh Hamrick (Infinity) wrote:
> discussed or not at this early stage.That being said, Charles has a 
> point, and i think it was something along the lines... "the commentary 
> you get on LESS will be more valuable if there's an implementation 
> people can play with in an effort to understand where the interop 
> bugbears lurk."
>

For what it's worth, LESS is based on learning from almost 4 years of 
doing virtual world interop between OLIVE and other systems. It is an 
attempt to re-phrase that learning in non-proprietary terms, and an 
easy-to-implement form.

> interaction between components (i.e. - the

I think it would be very helpful if we could get some clear, solid, 
detailed use cases, from the point of view of an end user, where it is 
clear what the user is doing, what the outcome is, and how the various 
protocols attempt to solve one or more parts of that use case. I think 
that such use cases would serve to illustrate and clarify pretty well 
what's actually going on in each of the proposals. Note that a good use 
case is fairly detailed. "User logs in -- user sees avatar" is probably 
not of sufficient detail (I'm not saying anyone has suggested this, I'm 
just giving an example that's probably below the bar).

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Wed, 11 Mar 2009 20:00:48 -0700

Morgaine wrote:
> Perhaps you're not thinking broadly enough?  The server to which a 
> client connects can be viewed as a domain-specific persistent proxy 
> for all the other virtual worlds to which the server connects, as well 
> as an indirect proxy for all their remote clients.  There is no good 
> reason to suggest that interop through a persistent proxy is no longer 
> interop.
>

That is exactly the model that is proposed in LESS.

However, I don't see how OGP enables that kind of interop at all. When I 
read it, all I can tell is that the client must understand the protocol 
of the server it connects to, and there is a single avatar being 
injected in a single sim; no sharing of state across worlds is expressed.

If OGP actually enables that in the currently proposed version, could 
you be so kind as to write up a use case for how that works, in 
sufficient detail that someone who's not on the Second Life AWG can 
actually follow it, with reference to the OGP protocol?
(It may be that part of the problem is that the OGP protocol draft does 
not seem sufficiently detailed to actually implement from spec yet, 
without having a lot of implicit knowledge and reference code on hand).

Sincerely,

jw

---

From: Morgaine <[email-masked]>
Date: Thu, 12 Mar 2009 14:19:56 +0000

On Thu, Mar 12, 2009 at 3:00 AM, Jon Watte <[email-masked]> wrote:

> read it, all I can tell is that the client must understand the protocol of
> the server it connects to, and there is a single avatar being injected in a
> single sim; no sharing of state across worlds is expressed.
>
> If OGP actually enables that in the currently proposed version, could you
> be so kind as to write up a use case for how that works, in sufficient
> detail that someone who's not on the Second Life AWG can actually follow it,
> with reference to the OGP protocol?
> (It may be that part of the problem is that the OGP protocol draft does not
> seem sufficiently detailed to actually implement from spec yet, without
> having a lot of implicit knowledge and reference code on hand).
>
>
>
Well now we're getting somewhere.  You make a reasonable request.  :-)

A description of the kind that you request is not available --- in AWG we
have merely absorbed how these things *might* work by a kind of osmosis over
a year and a half of weekly discussions with the Senior Systems Architect at
Linden Lab, Mark Lentczner / Zero Linden.  I agree completely that here in
MMOX there is a huge void in the *architectural description* of how OGP
might handle the details of interop.  The drafts presented do not do that,
and barely cover 10% of the picture anyway.

I suggest that your request be passed directly to Mark.  Meadhbh does of
course work with Mark and may be able to provide the missing detailed
descriptions, and David founded AWG along with Mark and has been working on
the OGP login/TP mechanisms for that whole period and so has a good grasp of
those parts of it too.

But for the details of 1's and 0's, the *extended* architectural picture
beyond OGP Base+Auth, and the deepest insight into how OGP is expected to
handle the many aspects of interop, you need Mark's explanation.

Indeed, we all need such detailed descriptions, documented here.  Without
them, our work won't go very far.

To ground your question in something concrete, I'm going to paint a very
common multi-world OGP interop scenario and request an explanation of the
inter-machine pathways that would be involved in handling it, in my next
post.

Morgaine.

On Thu, Mar 12, 2009 at 3:00 AM, Jon Watte <[email-masked]> wrote:

> read it, all I can tell is that the client must understand the protocol of
> the server it connects to, and there is a single avatar being injected in a
> single sim; no sharing of state across worlds is expressed.
>
> If OGP actually enables that in the currently proposed version, could you
> be so kind as to write up a use case for how that works, in sufficient
> detail that someone who's not on the Second Life AWG can actually follow it,
> with reference to the OGP protocol?
> (It may be that part of the problem is that the OGP protocol draft does not
> seem sufficiently detailed to actually implement from spec yet, without
> having a lot of implicit knowledge and reference code on hand).
>
> Sincerely,
>
> jw
>
>
>

---

From: Jon Watte <[email-masked]>
Date: Thu, 12 Mar 2009 09:10:23 -0700

Morgaine wrote:
> I suggest that your request be passed directly to Mark.

I have, in fact, written Mark directly, but never received a reply.
I, and many others, have also previously asked for actual use cases on 
this list, but none have been posted.
One might draw the conclusion that the OGP proponents feel that only the 
AWG members matter in this case, even though the MMOX group is 
supposedly something different. Or one might draw the conclusion that 
the OGP proponents just have so much on their schedule that they have to 
de-prioritize MMOX work -- I have no idea which.

>
> But for the details of 1's and 0's, the /extended/ architectural 
> picture beyond OGP Base+Auth, and the deepest insight into how OGP is 
> expected to handle the many aspects of interop, you need Mark's 
> explanation.
>

I would think that such an explanation should actually be in the I-D 
proposing the protocol.

To ask a related (almost equivalent) question that I've asked before:
If I were to implement the OGP proposal in the OLIVE client today, 
exactly what kind of interop would I achieve, and with whom?
I have not received an answer. My interpretation of the protocol as 
published tells me "no interop, with nobody," which is one of the 
reasons I don't think OGP is an interop protocol. However, again, 
because the protocol proposal isn't even implementable from the OGP 
document as published (as far as I can tell), I'm quite likely missing 
something, which in turn probably means that others on this list who are 
not related to the AWG might be missing the same things.

Sincerely,

jw