Subject: Re: [vwrap] Status and future of the VWRAP working group

From: Barry Leiba <[email-masked]>
Date: Wed, 23 Mar 2011 16:10:43 -0400

Reminder: If anyone's done anything related to what's below, please
post here and get some discussion going.  There's still about two and
a half weeks to get something ready.

Barry, as chair

On Sun, Feb 27, 2011 at 1:52 PM, Barry Leiba <[email-masked]> wrote:
> On Wed, Jan 19, 2011 at 3:15 PM, Barry Leiba <[email-masked]> wrote:
>>> As for timescales, we already started work on a new Intro in October and
>>> November, as I described in my first email in this thread.  It was being
>>> done informally, not as an official draft but as input to a totally new
>>> draft.  It was not being done as a revision because the previous Intro
>>> simply did not meet key requirements for many contributors, as was clear
>>> from the group's very intense discussions of September.
>>
>> Can you see if you can get it into reasonable shape to introduce
>> publicly, and then submit it as draft-morgaine-vwrap-intro-00 ?  That
>> would give people something concrete to work from.
>
> I haven't seen any activity on this, so let me repeat this with a deadline:
>
> The chairs ask the proponents to please get a new intro document into
> reasonable (not final) shape to introduce publicly, and to submit it
> as an Internet Draft with a name like "draft-SOMEONE-vwrap-intro-00"
> by 10 April (the significance of which will be left for the reader to
> research, should s/he care to).  There may, of course, be any
> (reasonable) number of authors listed on the draft, and any one may be
> the name chosen to live in the draft name.
>
> If we're not able to do that, I think we need to seriously question
> whether there's enough real energy to continue.
>
> Barry, as chair
>

---

From: Vaughn Deluca <[email-masked]>
Date: Fri, 25 Mar 2011 16:42:37 +0100

Absolute radio silence on the list...
VWRAP is clearly in a crisis.  The major players have all moved on,
and those who are left do not seem to be able to generate the needed
energy to carry the project forward.

I have always been in the fringe of this group. I am not a profesional
in the field, and i dont feel capable of leading the project. However
simply letting it die does not feel right either...

So it seems its time to take a vote, how many of us are *at all*
interested in keeping VWRAP alive? I cant believe we will simply give
up. Are we really forced to conclude we no longer have enough core
participation?

On 3/23/11, Barry Leiba <[email-masked]> wrote:
> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>

---

From: Nexii Malthus <[email-masked]>
Date: Fri, 25 Mar 2011 16:03:02 +0000

Chiming in here my own agreement with Vaughn along similiar lines.

- Nexii

---

From: Izzy Alanis <[email-masked]>
Date: Fri, 25 Mar 2011 16:33:33 -0400

If you're interested in automated *testing* of web applications with
browser quirks and behavior in mind, I've heard really good things
about Watir.

If you're interested in automated access to web pages from java for
something like data scraping, and if it was just for a particular
website... I'd probably hack around the javascript requirements of the
login page in question and just use curl or apache's HttpClient
libraries (ah the heresy!).

If you're interested in automated *rendering* of HTML pages from Java,
I've had some success with the Lobo project's Cobra toolkit, but that
project is pretty stagnant (and if you're C/C++ minded, run straight
to WebKit!).

Personally, I make extensive use of httpunit's ServletUnit
functionality for unit testing servlets -- primarily for web-services
and the like. It's great! But I don't really ever find myself in need
of the built in javascript features. This is a bit philosophical, but
I consider Unit testing separate from Integration testing, and if
you're testing on a live running server, it feels a lot more like
integration testing to me... That's just my personal opinion though.

On Fri, Mar 25, 2011 at 2:31 PM, Dee Ayy <[email-masked]> wrote:
> I'm trying httpunit because I am trying to login via script to a
> website that I assume is running JavaScript as part of its
> authentication method and I needed something to run the returned
> JavaScript which CURL does not run.
>
> I got an error:
> org.mozilla.javascript.EcmaError: TypeError: Cannot find function
> addEventListener. (httpunit#19)
>
> Then noticed "addEventListener" is not listed here
> http://httpunit.sourceforge.net/doc/javascript-support.html
>
> Then I added HttpUnitOptions per
> http://httpunit.sourceforge.net/doc/faq.html#unsupported
> and saw many more errors with the first displaying as:
> failed: org.mozilla.javascript.EcmaError: TypeError: Cannot find
> function addEventListener. (httpunit#19)
>
> Are the "httpunit#" 's known unsupported TODO features?
> Are they listed anywhere? -- probably in the httpunit source.
>
> On my first target page, I have many 19's, so I'd vote for that as a
> priority, but I also have:
> 19
> 32
> 9
> 838
> 624
> 226
> 1
>
> I suppose I am at a dead end regarding my script login task.
>
> Can anyone recommend a different free offering that may be able to
> login via "automation"?
>
> But I was also considering Google V8 JavaScript Engine
> http://code.google.com/p/v8/ "V8 is Google's open source JavaScript
> engine."
>
> The httpunit developers may want to consider using V8 for their
> JavaScript support.  I may try V8 myself with either CURL or httpunit.
>  I saw that getDOM method which I believe is the data V8 wants.
>
> Regards,
> Dee
>
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software
> be a part of the solution? Download the Intel(R) Manageability Checker
> today! http://p.sf.net/sfu/intel-dev2devmar
> Httpunit-develop mailing list
> [email-masked]
> https://lists.sourceforge.net/lists/listinfo/httpunit-develop
>

---

From: Izzy Alanis <[email-masked]>
Date: Fri, 25 Mar 2011 16:34:39 -0400

... retract that last... I'm having a bad e-mail day...
What I meant to send was:

I feel similarly. I would hate to see VWRAP die.

But on a separate, somewhat related, note; every time I even *think*
... "Hmm... what would I like to see in that draft WRAP intro
document?", I start to think about the abstract type system, the very
first bullet point in the charter, and I think about the crap that is
LLSD (no offense to the folks at Linden Labs) and then I think about
protocolbuffers and Thrift and think... why on earth would we ever
continue with LLSD. Yuck! And then I get wrapped up in those projects
instead. (I've very fickle).

---

From: Meadhbh Hamrick <[email-masked]>
Date: Fri, 25 Mar 2011 14:06:15 -0700

so what would you replace LLSD with?

--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 25 Mar 2011 15:33:18 -0700

> so what would you replace LLSD with?

There is no reason to replace LLSD. If I did, it wouldn't be with JSON. 
It strange to see how JSON was suppose to be simple eval(), yet now how 
turned into the same direction SQL statements have with injection 
problems. JSON has become complex, and maybe now people see why XML is 
simpler.

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

---

From: Izzy Alanis <[email-masked]>
Date: Fri, 25 Mar 2011 18:52:49 -0400

No, not JSON.

If protobuf/protocol buffers were a formal standard, I would
unhesitatingly say protocol buffers. Since it's not a formal standard,
I say... protocol buffers. Just with hesitation.

To be fair, the binary serialization of LLSD + LLIDL isn't all that
different from protobuf (at least at some level). But it feels wrong
to rely on a serialization format made specifically for virtual
worlds.

We don't want to re-invent the transport level protocols, why do we
want to invent our own data serialization and interface definition
formats? LLSD implementations aren't going to be as thoroughly
reviewed, bug fixed, optimized, and readily available as an
actively-developed protocol-agnostic format like protobuf. Maybe there
was a good argument for LLSD when LL was still involved, but why now?
Other than historical reasons?

On Fri, Mar 25, 2011 at 6:33 PM, Dzonatas Sol <[email-masked]> wrote:
> There is no reason to replace LLSD. If I did, it wouldn't be with JSON. It
> strange to see how JSON was suppose to be simple eval(), yet now how turned
> into the same direction SQL statements have with injection problems. JSON
> has become complex, and maybe now people see why XML is simpler.
>
> --

---

From: "Patnad Babii" <[email-masked]>
Date: Fri, 25 Mar 2011 19:03:26 -0400

The more the protocol is standard the more it will attract new user to it, I
mean if we choose XML, there's alot of people who already know / use XML.
It will be easier for them without learning a completely new set of tools.

What is important for VWRAP is that in the end it get adopted by as many
game developer as possible. So using the standards the industry has to offer
seem just the right thing to do.

-----Message d'origine----- 
From: Izzy Alanis
Sent: Friday, March 25, 2011 6:52 PM
To: Dzonatas Sol
Cc: [email-masked] ; Meadhbh Hamrick ; Barry Leiba
Subject: Re: [vwrap] Status and future of the VWRAP working group

No, not JSON.

---

From: Izzy Alanis <[email-masked]>
Date: Fri, 25 Mar 2011 20:55:07 -0400

Was that an argument for or against LLSD?

Of course this all may not matter unless somebody actually addresses the underlying issue: That the group needs to start producing documents.

  - Izzy

On Mar 25, 2011, at 7:03 PM, "Patnad Babii" <[email-masked]> wrote:

> -----Message d'origine----- From: Izzy Alanis

---

From: Vaughn Deluca <[email-masked]>
Date: Sat, 26 Mar 2011 10:41:06 +0100

Right, we need to produce documents. Part of the reason we are stalled
is that the current drafts were critisized, most notably by Morgaine,
but no concrete steps were taken to follow up on the critisism.

So, i agree with Katherine her proposal (in another tread) and suggest
we keep working within the current charter. What we could do is the
absolute bare minimum of change to the drafts to keep us floating, and
start a campaign for new blood. This is such a cool project, i simply
can't imagine we wont be able to attract some new people that can help
to make it happen.

-- Vaughn

On 3/26/11, Izzy Alanis <[email-masked]> wrote:
> Of course this all may not matter unless somebody actually addresses the
> underlying issue: That the group needs to start producing documents.
>
>   - Izzy
>
>
>>> It

---

From: Carlo Wood <[email-masked]>
Date: Sat, 26 Mar 2011 14:36:53 +0100

> energy to carry the project forward.
[...]
> up. Are we really forced to conclude we no longer have enough core

The reason I abandonned this project (as in: stopped replying and
even reading it) is because (back then) certain "major players"
completely dominated the whole effort.

This effort was clearly carried by a few companies at the time,
and major decisions were made behind the scenes, not on the list.
They were made by individuals with enough company behind them to
be taken (too) seriously; but individuals nevertheless (I don't
believe(d) for a second that they really were backed up by other
PEOPLE).

If people take airplanes to meet somewhere face to face while
staying in hotels and then claim that that is the only place
where "real work can be done" then they shut people like me
completely out.

If people write HUGE documents with exclusively their own ideas,
claiming it is really what their (huge) commercial companies wants
and basically dooming the project without the support of that
company, and mostly ignoring the "little people" on this list...

It clearly made no difference how much effort I'd put into this
project. I'd alway be considered to be a nobody and not be listened
to these "major players".

What is wrong here is that I *AM* a major player (or could be):
I have a lot of time, a lot experience and a lot of analytic insight
and understanding of complex communication protocols. I just don't
have a company behind me; so nobody cared if I'd leave; so it was
very easy to just ignore me and only concentrate on making a consensus
with those "who mattered".

The Right Thing to do would be to make all decisions on the list,
after discussions on the list and treating everyone equal; or well,
treating the more intelligent people more equal than those who
don't have an idea what they are saying perhaps - but not only
listening to those who have a lot of weight in commercial terms.

In particular-- and please note that I never said a single word
about this before: I just silently left, but now, in the light of
this post I feel it is required to mention it-- I left because of
the role that Meadhbh Hamrick had taken. At the time he was still
working for Linden Lab and doing all of the above wrong, often in
an almost autistic and certainly self-centered way. He left no room
whatsoever to get into the discussion / project in a reasonable way.
When I decided to give up, the exact words that I thought were:
I might get back if Meadhbh leaves the project, but not before.

There was some short lived hope when he left Linden Lab...
I'm still waiting and have no intention to put (waste) time
here as long as he's part of this team.

Sorry to be this blunt-- but I thought you wanted to know
(from everyone) why they backed out and stopped being responsive.
So here is my story.

-- 
Carlo Wood <[email-masked]>

---

From: Carlo Wood <[email-masked]>
Date: Sat, 26 Mar 2011 14:40:48 +0100

> LLSD (no offense to the folks at Linden Labs) and then I think about

Same here.

If I'd be in charge of this project, we'd start from SCRATCH.
We'd start by making a list of things we want and need, not
start from some old heritage and try to force and mold it
at all costs into VWRAP.

There are a few very essential things wrong with the core
of the current design. It's also not flexible enough.
The current draft is exclusively aimed at defending the
market position of a dieing company and has nothing to do
with what would be technically the best protocol.

---

From: Carlo Wood <[email-masked]>
Date: Sat, 26 Mar 2011 14:53:20 +0100

> but no concrete steps were taken to follow up on the critisism.

I respect Morgaine (although I don't always agree with her) for the
time she has put to keeping people aware of what was going on.
And if her efforts are the reason that the project stalled then YAY!
That was one hell of job. I didn't have the time to it myself, but
I think it's a step forwards. Anything but just one or two people
dominating the list, producing documents and causing anyone who oppose
(like me) to go silent, and then God Forbid - turning that into a standard.

> absolute bare minimum of change to the drafts to keep us floating, and

No... See, that's where you make a fatal mistake of taking a step
backwards. This is not about pushing SOME "standard" at all costs.
It's about designing a standard that is clearly technically the best,
so that everyone agrees with that. Imho, we need to start from scratch.

Oops, no I said 'we'... but count me out. I still see the same people
around here and it's still going to fail just as bad as last time (or,
as I expected the first time around... some "standard" is going to
be produced that sucks; and that is either going to be ignored, or
adopted by a few large "players" who then all get major head aches
and problems that they can't fix; and in the end it will be the users
who suffer most from having a bad protocol of course :/.

---

From: Barry Leiba <[email-masked]>
Date: Sat, 26 Mar 2011 10:40:42 -0400

Hi, Carlo, Vaughn, Izzy, Dzonatas, and everyone else.
I'm glad to see some discussion going.  Izzy is right when he says this:
> Of course this all may not matter unless somebody actually addresses
> the underlying issue: That the group needs to start producing documents.

Indeed.  We, the chairs, need to see real progress on the documents...
particularly the introduction document.

This discussion is a start, and, as I say, I'm pleased to see it, but
it has to turn into real document editing very soon.

> who suffer most from having a bad protocol of course :/.

Carlo, Meadhbh is still around, thought she (note gender) has given up
the editorship of the documents.  Your input is welcome -- encouraged
-- though, of course, if you choose not to participate for whatever
reason, that's your choice.  I think choosing not to participate
because some particular person is also participating is a poor choice,
but it's your choice to make.  I would like to see you reconsider
that, if you're willing to do the work.

What I do *not* want to see, and what we won't tolerate, are personal
attacks on any participant here.  Do not engage in name-calling, do
not question people's integrity, do not malign the companies they work
for, and do not accuse people of malfeasance because they disagree
with you.  If you present your ideas and others agree with what you
say, those ideas will make it forward.  That's how we aim to work,
here, and if this working group can continue and make progress, that's
indeed how we'll work.

So... will we make some progress on the intro document?  Can we get
some real discussion on it, and a draft that shows some level of
consensus within the nest few weeks?

Barry, as chair

---

From: "Patnad Babii" <[email-masked]>
Date: Sat, 26 Mar 2011 11:03:19 -0400

What we should focus on, is this I believe, are we going to keep LLSD (is it 
good enought). Is it really needed or shall we start from scratch, with the 
aim of using some new viewer / browser.

Opensim (open source virtual platform with alot of grids already) is using 
LLSD, especially because the viewer LL made is using LLSD.

To be honest I keep saying since the beginning of these working groups (the 
various ones, ogpx, vwrap, mmox..) we should put aside the existing stuff, 
work more with Opensim, since they are the key to this new journey that is 
open virtual worlds, its good they have HyperGrid already which does some 
amazing stuff!

What we need is a consensus, something we all agree on and go forward with 
the docs.

-----Message d'origine----- 
From: Barry Leiba
Sent: Saturday, March 26, 2011 10:40 AM
To: Carlo Wood
Cc: [email-masked]
Subject: Re: [vwrap] Status and future of the VWRAP working group

Barry, as chair

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 26 Mar 2011 08:39:23 -0700

Patnad Babii wrote:
> To be honest I keep saying since the beginning of these working groups 
> (the various ones, ogpx, vwrap, mmox..) we should put aside the 
> existing stuff, work more with Opensim, since they are the key to this 
> new journey that is open virtual worlds, its good they have HyperGrid 
> already which does some amazing stuff!

OpenSim is not open in direction of development; therefore, we can not 
use opensim and expect to be free from their direction. Just because we 
do not agree with their client/server terminology should be no reason 
for them to assume out-of-bound attitudes towards anybody is ok.

The goal of opensim/lib was to reverse engineer the SL protocol, not to 
develop one from an open basis from scratch.

--

---

From: Izzy Alanis <[email-masked]>
Date: Sat, 26 Mar 2011 11:54:47 -0400

+1 to: put aside the existing stuff

For the purposes of the Intro doc, I think it would be possible to
table the decision between LLSD/LLIDL and something else (protobuf)
for the abstract type system / interface descriptions *if* the doc was
couched in terms of a VWRAP-IDL that we then specify/decide on in the
following IDL/type system doc.

One thing we should make a decision on, and that I think is fuzzy in
the draft-hamrick-vwrap-intro-01 doc, is whether the serializations
are negotiated between services, or whether VWRAP mandates LLSD as the
only approved serialization.

Sections 2.3.1:
 "Web-based applications may choose to use JSON or XML.
Server-to-server interactions may use the VWRAP specific binary
serialization scheme..."

Seems to conflict with (2.3.3):
  " VWRAP uses the LLSD abstract type system and the LLIDL interface
       description language to describe the structure and type semantics
       of elements in messages sent between systems.  Because LLSD makes
       extensive use of variable width, clearly delineated data fields,
       services which consume protocol messages may identify and extract
       only those message elements they know how to handle."

I'd like to take this opportunity to point out that protobuff supports
the same variable width, extensibility, default values, yada yada
yada.

we could couch that in terms of only the IDL, and leave serialization
of messages up to content negotiation between services involved.

On Sat, Mar 26, 2011 at 11:03 AM, Patnad Babii <[email-masked]> wrote:
> -----Message d'origine----- From: Barry Leiba

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sat, 26 Mar 2011 09:53:31 -0700

yup. i'm still around.

the documents are in SVN. check them out and edit them.

there were ( i believe ) reasons why this effort originally had a
focus on SL and OpenSim: the people who organized the working group
and corralled opposing viewpoints into consensus for a charter were
employees of linden and ibm who had write access to linden's code
repository and (at least one) of the code repositories associated with
OpenSim.

we were the two parties who were interested in defining
interoperability for our implementations through this forum. the
charter of the group was not to create an entirely new virtual world
protocol, but to rectify and complete two implementations developed
independently by linden and ibm.

the reason things were done "behind your back" and "off the list" is
that we were trying to develop an interop protocol for two
implementations with differing levels of functionality and
completeness. conversations on the list frequently started with: "hey,
i have some code that does foo? should we still do foo or should we do
bar?" and ended with a number of people talking about how we should
really doing "baz" or "qux", both of which had no relation to the code
or the problem domain described in the intro document and charter.

that being said... having code is not a requirement for a working
group, but it does seem that IETF culture is deferential towards those
who produce code.

now that people with an interest in this group no longer have write
access to the linden code repository, that ability to produce one
independent implementation of the standard has gone away. which is one
of the reasons this group is rebooting.

i have on several occasions offered my assistance to anyone interested
in drafting a new charter or editing new documents. so far no one's
taken me up on my offer. i'm still happy to do a "how to write RFCs
with XML" class in-world. but again, no one's indicated an interest.

barry's been calling for participation for the last couple of months.
but as far as i can tell, morgaine's been the only person who's
produced anything. but even that.. something like 1000 or 2000 words
are probably insufficient to communicate complicated technical
concepts this group is supposed to be manipulating.

the cool thing about this group at this moment is if you want to take
over this group and recharter it, you really have to do only a small
amount of work. and honestly, if you can't manage the effort of
opening a text editor and typing out five or six paragraphs that
define the starting point for a new group charter, you're going to
find the process of actually writing RFCs to bit much.

if this group dies, it's not the end of the world for virtual worlds
and standardization. i think barry's said it several times. this group
failing is not going to be a major hindrance to forming another VW
focused group in the future.

-Cheers
-Meadhbh

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sat, 26 Mar 2011 10:31:40 -0700

fwiw.. i think this discussion indicates a little confusion over what LLSD is.

LLSD is not a transfer syntax. it is an abstract type system and
interface description language that defines three transfer syntaxes.
ProtoBufs is not an abstract type system as it's type semantics are
not defined. The objective of LLSD was to allow us to describe
services independent of any particular technology.

sadly, that was never made abundantly clear in the docs. but in the
list discussion, many of us who had used LLSD mentioned several times
that we were focusing on LLSD serialized with JSON or XML over
HTTP(S), but there was no reason it couldn't be carried over XMPP or
ProtoBufs. it's just that no one seemed to think those use cases were
interesting enough to sit down with a text editor and whip up some
code.

so... even if you dump LLSD moving forward, i would encourage you to
not use ProtoBufs to define service interfaces. my experience with
large systems and protobufs is you have to make everything optional to
cover the use case of two systems running slightly different versions
of an interface.

that being said, producing a map from LLSD to ProtoBufs should be
pretty straight forward.

but that's just my 2 cents.
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

---

From: Izzy Alanis <[email-masked]>
Date: Sat, 26 Mar 2011 14:57:42 -0400

I certainly am confused about what you want LLSD to be.

Many protocols need mechanisms for both describing structured data in a language/technology neutral way (via interface definition language) and a concrete serialized form or forms -- primarily used for transfer, but also for storage/retrieval, archival purposes, etc, etc, etc.

Protobuffs doesn't say anything about transfer protocols (neither does LLSD), protobuffs doesn't say anything about language/technology stack requirements (neither does LLSD).

> my experience with

How was LLSD's extension mechanism different? LLSD and protobuff are not that different except that LLSD allows for multiple serialization forms, which (IMHO) adds confusion and complexity.

For example, serializing LLSD over JSON means you need a specialized LLSD-JSON serializer/deserializer. Why? Because the serializer needs to follow the LLSD imposed rules about default values, required data fields, etc. Explain that to a programmer who thinks, "yay it's JSON, I know how to parse that!" Well, you can use that JSON parser, but you'll end up with incomplete data structs.

- Izzy

---

From: <[email-masked]>
Date: Sat, 26 Mar 2011 15:26:09 -0400

I wouldn't say OpenSim is the future.  This still has to be proven.  Even
SL, even though has a fairly large customer base only fits a narrow set of
use cases and this is why we don't see more advanced virtual world
applications using it.

If fact I think this is one of the main issues with this group.  To justify
its purpose they need to define the use case it is to be used for.  I have
trouble understanding the use case outside of SL.  And since SL has not show
any interest now I find it hard to understand the purpose of this group.

M.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Patnad Babii
Sent: Saturday, March 26, 2011 11:03 AM
To: [email-masked]
Subject: Re: [vwrap] Status and future of the VWRAP working group

-----Message d'origine----- 
From: Barry Leiba
Sent: Saturday, March 26, 2011 10:40 AM
To: Carlo Wood
Cc: [email-masked]
Subject: Re: [vwrap] Status and future of the VWRAP working group

Barry, as chair

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sat, 26 Mar 2011 12:35:47 -0700

actually protobufs says quite a bit about transfer syntax. as does LLSD.

here's a link to an overview of ProtoBuf line encoding.

if you read the document, the entire back half of the document
describes serialization schemes used to concretize abstract data for
transmission over the network. since we use JSON and XML for 2/3 of
our wire format specification, we reference the ECMAscript and XML
standards rather than replicate them in the LLSD drafts.

LLSD and ProtoBufs ARE both transport agnostic, though the only
defined interoperability profile for LLSD was transporting messages
over HTTP. some people said they were interested in XMPP, but they
never produced any documentation for it.

LLSD defines multiple transfer syntaxes because there was a
requirement that it work with existing XML and JSON tools. The binary
format was something added to save space on disk and in packets,
though honestly, transferring XML or JSON with gzip content encoding
gets you to encoding sizes that are pretty close to binary encoding.

and yes, if you use JSON, you have to deal with JSON's flaws. but
guess what? if you use XML, you have to deal with XML's flaws. but at
the end of the day, some people use XML and some people use JSON.
we're not going to tell you which to use, because ultimately it's
pretty insignificant compared to the semantics of messages that flow
between services.

but sure, if you're down with having an argument about why we should
all use ProtocolBuffers, be my guest. I'll check in with you in a
couple years and see how close you are to consensus.

-cheers
-meadhbh

---

From: Vaughn Deluca <[email-masked]>
Date: Sat, 26 Mar 2011 22:43:49 +0100

Carlo writes:

>and understanding of complex communication protocols.

Come on Carlo, grow up. You do yourself a disservice by acting as a
spoiled child.
I fully agree with you that the off-list development was very
demotivating, and at several occasions I have complained loudly about
that. But when i wrote "major players" i was thinking in terms of
input to the group, -of actual work done-, and not at all about
company size. So please, act like  the  professional you are. If you
drop the hurt tone, and take a constructive approach, I am very very
sure you will be listend to, and become a major player in the sense
that i meant it.

>(from everyone) why they backed out and stopped being responsive.

First, yes you were indeed blunt and i think somewhat out of line as
well,  but i do not want to enter into that discussion here and now.
Second No, i did *not* ask why people stopped responding, i asked who
was still willing to do some real work here.  The first and foremost
problem we have is a lack of critical mass, and in particular input
from people that have the needed technical background.  And clearly
you are one of those that we need badly.  So please put whatever
trouble you may have had with meadhbh behind you. She is no longer
editor, and Linden Lab is not interested anymore in VWRAP.
Things have changed, and I can see very little reason to stop you from
participating here again, and that would be a real solid step towards
reviving this group. It would be really nice if you would reconsider
your position.

--Vaughn

---

From: Morgaine <[email-masked]>
Date: Sun, 27 Mar 2011 00:09:27 +0000

I'm glad to see some renewed participation here!  Perhaps the threat of
death sharpens the mind. ;-)

Since there seems to be some fresh thinking in the air, I am going to add
two short points to the discussion.  The first is a matter of procedure, and
the second is related to our technical direction:

   - Notwithstanding that the IETF places certain duties on Barry and others
   to ensure that there is visible progress in the form of documents, I must
   say that "documents at all costs" is not a particularly good way of
   achieving technical progress.  It's the "documents at all costs" push that
   gave us several documents previously, only one of which turned out to be
   usable for interoperation between VWs.  Documents churned out before there
   is agreement on goals and direction are a hindrance to the process, not an
   indicator of progress, and they waste everyone's time.  Progress is
   certainly not a matter of just putting pen to paper, as has been suggested.
   Far from it.  First we must agree as a group on how a given protocol is
   going to meet our goals, and drafts then present that formally with hard
   technical details added.  Done the other way around just results in much
   angst and wasted effort, as happened here.

   - Given the almost unanimous agreement that crystallized around Crista's
   thread of a few months ago which could be paraphrased as "The VWRAP
   documents do nothing for interop between virtual worlds", I would like to
   suggest that instead of continuing to beat the dead horse of OGP that we
   still have on our hands, why don't we focus on delivering something that is
   actually *usable* by compatible groups like Opensim and realXtend and
   iED?  There is a nugget of gold at the heart of the VWRAP concept which can
   provide exactly that:  the idea of *shared asset services*, and a
   protocol for accessing them.

There is a huge amount of activity in our sector of the virtual worlds
community.  There is also no end of interest in interoperation, but the
trouble seems to be that each group is rather narrowly focused on their own
particular code base.  Where I think a group such as ours can contribute is
by providing a lightweight protocol which is easily used by all, without the
previous baggage.  Simple problems demand simple solutions, and while a
massively scalable shared asset service is not exactly simple, it is
nevertheless a lot simpler than the much larger task that we had set
ourselves previously.

Perhaps that would be a good place to start, afresh.

Morgaine.

=====================================

---

From: Izzy Alanis <[email-masked]>
Date: Sat, 26 Mar 2011 20:29:06 -0400

Are you suggesting a re-charter around shared services only?
Or that we shift the deliverables to push that to the forefront? (In
which case, we still really do need an intro doc and to address the
messaging semantics)

I'm not quite convinced that the charter is unsalvageable. I think the
last rev of the intro has a lot of good things in it too -- lots I
would like to see changed, but good stuff too.

On Sat, Mar 26, 2011 at 8:09 PM, Morgaine
<[email-masked]> wrote:
> Notwithstanding that the IETF places certain duties on Barry and others to
> ensure that there is visible progress in the form of documents, I must say
> that "documents at all costs" is not a particularly good way of achieving
> technical progress.  It's the "documents at all costs" push that gave us
> several documents previously, only one of which turned out to be usable for
> interoperation between VWs.  Documents churned out before there is agreement
> on goals and direction are a hindrance to the process, not an indicator of
> progress, and they waste everyone's time.  Progress is certainly not a
> matter of just putting pen to paper, as has been suggested.  Far from it.
> First we must agree as a group on how a given protocol is going to meet our
> goals, and drafts then present that formally with hard technical details
> added.  Done the other way around just results in much angst and wasted
> effort, as happened here.
>
> Given the almost unanimous agreement that crystallized around Crista's
> actually usable by compatible groups like Opensim and realXtend and iED?
> There is a nugget of gold at the heart of the VWRAP concept which can
> provide exactly that:  the idea of shared asset services, and a protocol for
> accessing them.
>

---

From: Izzy Alanis <[email-masked]>
Date: Sat, 26 Mar 2011 20:39:29 -0400

Meant to say "shared *asset* services" there...

---

From: Izzy Alanis <[email-masked]>
Date: Sat, 26 Mar 2011 21:06:26 -0400

Lol, I'd never argue that one tool fits all needs for all purposes.
But this one is a good fit for a LLSD replacement, and it has a good,
active user community, and a corporation with lots of money to back it
up.

I don't feel like I'm hearing good arguments against protobuf though.

> requirement that it work with existing XML and JSON tools.

LLSD imposes extra deserialization rules upon those schemes, so I
don't just need an XML parser, I need an LLSD+XML parser. I don't need
a JSON parser, I need a LLSD+JSON parser/library. And if I need yet
another library anyway, why did it matter that the underlying transfer
re-used a XML or JSON syntax?

Here are some of my own qualms about protobuf:
* What if I want to embed a message inside a container that only
supports XML? Such as inside a SOAP or XMPP message?
* But there isn't an RFC to really define protocol buffers!
* But if it's not specific to VWRAP, what if the protobuf people
decide to add things in there that make it... too complicated,
inappropriate, too weird... (what happens if we give up control?)

I understand you have a vested interest in LLSD and I apologize for my
initial brashness calling it 'crap'.  But the group has enough
problems ahead of it. Trying to invent/standardize a new multi-purpose
"Abstract Type System" isn't something the group really needs to do.

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 26 Mar 2011 18:41:42 -0700

If there was focus only on the login (agent domain) and inventory 
services, then I think we will get some where.

Yes, we know there are issues with inventory that are already in the 
simulator side, so this is the suggestion to build apart from those 
issues. Start from there.

Izzy Alanis wrote:
>> I'm glad to see some renewed participation here!� Perhaps the threat of
>> two short points to the discussion.� The first is a matter of procedure, and
>> technical progress.� It's the "documents at all costs" push that gave us
>> interoperation between VWs.� Documents churned out before there is agreement
>> progress, and they waste everyone's time.� Progress is certainly not a
>> matter of just putting pen to paper, as has been suggested.� Far from it.
>> added.� Done the other way around just results in much angst and wasted
>> provide exactly that:� the idea of shared asset services, and a protocol for
>> accessing them.
>>
>> community.� There is also no end of interest in interoperation, but the
>> particular code base.� Where I think a group such as ours can contribute is
>> previous baggage.� Simple problems demand simple solutions, and while a
>>> post here and get some discussion going. �There's still about two and
>>>>>> November, as I described in my first email in this thread.� It was
>>>>>> being
>>>>>> draft.� It was not being done as a revision because the previous Intro
>>>>> publicly, and then submit it as draft-morgaine-vwrap-intro-00 ? �That
>>>> research, should s/he care to). �There may, of course, be any

--

---

From: Morgaine <[email-masked]>
Date: Sun, 27 Mar 2011 03:11:50 +0100

Indeed, server-side inventories are one of the worst design decisions of the
existing implementations.

They give us no end of problems, such as the impossibility of high-speed
client-side searching and regular lag issues, not to mention being
non-portable because each world provider would implement them differently.
They're also non-scalable because they're centralized, and non supportive of
VW tourism because a given world provider would control what can be put into
them, instead of the traveling user being in control.

Inventories need to be client-side (I refer to the trees of asset metadata,
not the asset data, in case that's not clear), with an auto sync of deltas
to a configured asset service for resilience/backup.  That way only those
people who do not look after their local inventory resources will suffer
client-server transport lag to recreate them, and the full power of
client-side CPUs and client-side databases and scripting can be deployed to
make inventories a real powerhouse.

All we really need are shared asset services that are independent of the
world providers.  That alone is enough to virtually ensure portability,
interoperability, and scalability, as long as a lightweight protocol can be
found that is also extensible to support tomorrow's worlds.  Making a
standard to support only what we're doing today isn't particularly
interesting.

Morgaine.

==================================

On Sun, Mar 27, 2011 at 2:41 AM, Dzonatas Sol <[email-masked]> wrote:

> If there was focus only on the login (agent domain) and inventory services,
> then I think we will get some where.
>
> simulator side, so this is the suggestion to build apart from those issues.
> Start from there.
>
>
>
> Izzy Alanis wrote:
>

---

From: Carlo Wood <[email-masked]>
Date: Sun, 27 Mar 2011 15:18:43 +0200

On Sat, Mar 26, 2011 at 10:43:49PM +0100, Vaughn Deluca wrote:
> you are one of those that we need badly.

The way I'd like to move forward is anything but producing
documents fast however; and that seems to be the requirement.

If you want input from me regarding the survival of this group;
I'd create a wiki that everyone who requests it can edit.
The first and most important part of that wiki would be a glossary
with every word that is frequently used in the discussions.
That list of words should be complete rather quickly, then
people can add their definitions to it. If two people have
different definitions then those definitions should be signed;
Once, for a particular word, everyone has added the definitions
and/or remarks to the wiki (all on one page per word), we can
start a discussion on this list on how to reformulize and change
the definition of that word. Some might have to change their
semantics, but in the end the goal would be that every word
has one defintion, used and understood by everyone -- and
clearly documented on the wiki, with discussion history as
usual. If a discussion gets completely stuck on semantics,
then people can just sign (put their name under) the definition
the want and we'd just count the signatures and pick one.
After all, it's just semantics and has nothing to do with what
the protocol REALLY will do.

Only then, we can take the next step; for which I'd also
use the wiki.

Also, as I wrote in old posts before... I am still CONVINCED that
we can impossibly create a protocol that will address everything
that will be needed in the future. All we can do is create something
that is a good starting point and FOCUS on flexibility: create
a protocol that can evolve. In order to do that, we need (further
completely protocol neutral) protocol negotiation for every p2p
link that is created in the process, which allows such evolution.

The use of XML as basis for a protocol would mean the following:
1) It takes overhead, so it's not possible to use it for
   highbandwidth usage (ie video, or file transfers). But it could
   do at out-of-band control channel.
2) If it's pure XML than we won't have to worry about the
   implementation of serializing/deserializing as much, although
   that only really has it's advantages when we will need VWRAP
   to work for implementations in multiple programming languages
   before it gets accepted widely. As far as I can see, we will
   need C# and C++, and most likely C for religious reasons.
3) The ONLY benefit that XML has (on top of existing serialization
   libraries) is that it is extensible: You can add new parameters
   without confusing old code that doesn't expect it.

Point 3, however, is just a weak attempt to be flexible. Imho,
it is by far not flexible enough. We'd still need a well defined
way for the evolving protocol negotiation, and once that is in
place, we won't really need this feature of XML anymore.

Thus, provided we add "evolving protocol negotiation", we should
probably choose the serialization/deserialization method based on
grounds that I can't judge at this point in the design.

So for the near future:
- Glossary and agreement on definitions of used jargon.
- Abstract agreement on the use of an evolving protocol.
- Definition of all possible p2p connection for which serialization is necessary.
- Choice of what serialization mechanism is used where.
- Abstract discussion (and agreement) of the use of Abelian operators
  for distributed states and identity authorities (see another
  old post from me). If we don't do that before anything else,
  we'd just shoot ourself in the foot.
- etc

This is no doubt the work of years, and won't lead to any document
any time soon.

---

From: Vaughn Deluca <[email-masked]>
Date: Sun, 27 Mar 2011 16:37:15 +0200

Morgaine,

All very well, but you did not answer Izzy's question about rechartering.
I agree with Izzy that it is by no means clear that the current
charter is unsalvageable.

For instance, your post below you write:
>All we really need are shared asset services that are independent of the world providers.

I my view this is square within the current charter were it says:

"Within a VWRAP virtual environment, services may be deployed by
multiple organizations having varying policies and trust domains."

I have always read that as meaning that an inventory could be
*anywhere* and owned by *anybody*, and that surely covers my own
client side inventory as well (possibly implemented as a personal
asset service running on my own machine?)

The decision to have server side inventory is clearly the choice of
that servers operator, and it is my chose use that inventory if that
suits me.  If client side inventory is superior that will become clear
by users preferring to use it. I fail to see  how our current approach
is an obstacle on this path.

Can you point out what part of the charter needs to be changed, or
better make a proposal for that change so we have something concrete
to work from?

I strongly feel we need to build some consensus in this group, and to
do so we need to be crystal clear about our aims. We should start
front be very top. You had a first attempt at restructuring the intro
document, but we need to address the charter first. My view is that it
is not yet needed to change that, and if you feel different this is
the time to say so.

-- Vaughn

On 3/27/11, Morgaine <[email-masked]> wrote:
>> issues.

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 27 Mar 2011 08:46:50 -0700

As pointed out earlier, there is documentation on client-side REST based 
abilities.

http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources

That doesn't have to be HTTP. It is just easiest to demonstrate with HTTP.

As for who owns inventories, of course it is a mistake to assume the 
server-side owns inventories. The avatar own's their inventories.

We've talked about the manufactured objects in which different people 
own different parts of an object, and how to deal with such issue. The 
current design is not even able to handle this complex.

--

---

From: Vaughn Deluca <[email-masked]>
Date: Sun, 27 Mar 2011 19:25:52 +0200

Great!, thanks a lot for the constructive input!

I disagree however that this "won't lead to any document any time
soon" It depends on the definition of "document" I might be a while
before it produces an RFC, but I certainly would call the glossary,
wiki pages documenting group consensus, and Definitions "documents".

 I like the wiki idea, (something along those lines was suggested by
Morgaine also). I just requested a password, and it seems i can edit
the Wiki  :) I will put up a VWRAP glossary page later today.

---

From: Vaughn Deluca <[email-masked]>
Date: Sun, 27 Mar 2011 23:17:57 +0200

Done -- (at least the very first step).

---

From: Fleep Tuque <[email-masked]>
Date: Sun, 27 Mar 2011 18:42:22 -0400

We've discussed the wiki concept several times and several of us started a
wiki some months ago, but Peter reminded us that there is an official wiki
that should be used for these efforts.  See his message below.

- Chris/Fleep

Chris M. Collins (SL: Fleep Tuque)
Project Manager, UC Second Life
Second Life Ambassador, Ohio Learning Network
UCit Instructional & Research Computing
University of Cincinnati
406E Zimmer Hall
PO Box 210088
Cincinnati, OH 45221-0088
(513)556-3018
[email-masked]

---------- Forwarded message ----------
From: Peter Saint-Andre <[email-masked]>
Date: Thu, Jan 20, 2011 at 10:04 PM
Subject: Re: [vwrap] Status and future of the VWRAP working group
To: [email-masked]

With my area director hat on:

a.) I like the idea of collaborative effort at a wiki. This lowers the
barriers to entry. A big +1.

b.) I'd prefer to see this happen at the official working group wiki:

   http://trac.tools.ietf.org/wg/vwrap/trac/wiki

The main factor here is the IETF's policy on contributions, a.k.a. "Note
Well"...

   http://www.ietf.org/about/note-well.html

I am not a lawyer, but I doubt that work happening at a wiki site
somewhere else is covered under "Note Well". The last thing we want is
ambiguity about copyrights and patents, so I strongly encourage folks to
do this work at the Trac URL I posted above.

To request login credentials, go here:

   http://trac.tools.ietf.org/tools/loginmgr/newlogin

Thanks!

Peter

UC Second Life:   http://homepages.uc.edu/secondlife
OLN Second Life: http://www.oln.org/emerging_technologies/emtech.php

---

From: Vaughn Deluca <[email-masked]>
Date: Mon, 28 Mar 2011 00:49:12 +0200

> I'd prefer to see this happen at the official working group wiki:

And that is were it is now.  :)

--Vaughn

---

From: Morgaine <[email-masked]>
Date: Mon, 28 Mar 2011 01:17:32 +0100

I think I may have unconconsciously been evading the question of
rechartering up to now, possibly because it was and is such a pain point.
No more evading though, if we want to get something done.

Re-chartering seems inevitable to me, because the existing charter failed so
very dramatically to guide us towards the requirement that we recently made
explicit, namely interoperation between virtual worlds.

I'm not too surprised at that failure, since it has been very clear from the
start that everybody except the main sponsoring companies expected interop
between virtual worlds to materialize from our work.  Consequently, I could
see the problem coming our way once the realization that it wasn't on the
agenda finally hit home more widely.  Crista did us a great service by
triggering that understanding within the group.

Armed with that understanding now, it is easy to see how the charter sold us
a bridge.  After all, nowhere does it state that the goal is interoperation
between virtual worlds, so it has been wishful thinking alone that made so
many people expect otherwise.  While it mentions asset services being run by
more than one organization, it never stated that these asset services could
serve multiple virtual worlds and hence act as the essential bridge for
interop of assets between them.  Again, it was just wishful thinking that
made some people interpret it that way, but as we now know, it was not the
design goal.

There are many such occurrences in the charter.  It seems to vaguely use the
language of interop, but only in respect of growing virtual worlds by adding
regions to them (ie. it's an *intra*-world protocol, not *inter*-world).  It
does not offer anything to allow such virtual worlds to interoperate in the
way most people expect, for example supporting virtual tourism between them.

Since the charter does not expressly state what we want, it is incorrect, or
worse, misdirecting.

I see no alternative to rechartering if we expect the outcome to be interop
between virtual worlds.  If we do not recharter, it will not describe our
goals, and it will not be meaningful to other readers.

Morgaine.

On Sun, Mar 27, 2011 at 3:37 PM, Vaughn Deluca <[email-masked]>wrote:

> world providers.
> >>>> two short points to the discussion.� The first is a matter of
> procedure,
> >>>> and
> >>>> Notwithstanding that the IETF places certain duties on Barry and
> others
> >>>> to
> >>>> several documents previously, only one of which turned out to be
> usable
> >>>> for
> >>>> on goals and direction are a hindrance to the process, not an
> indicator
> >>>> of
> >>>> First we must agree as a group on how a given protocol is going to
> meet
> >>>> our
> >>>> still have on our hands, why don't we focus on delivering something
> that
> >>>> is
> >>>> provide exactly that:� the idea of shared asset services, and a
> protocol
> >>>> for
> >>>> accessing them.
> >>>>
> >>>> trouble seems to be that each group is rather narrowly focused on
> their
> >>>> own
> >>>> particular code base.� Where I think a group such as ours can
> contribute
> >>>> is
> >>>> by providing a lightweight protocol which is easily used by all,
> without
> >>>> the
> >>>> On Wed, Mar 23, 2011 at 8:10 PM, Barry Leiba <[email-masked]
> >
> >>>> wrote:
> >>>>
> >>>>
> >>>>> On Sun, Feb 27, 2011 at 1:52 PM, Barry Leiba <
> [email-masked]>
> >>>>> wrote:
> >>>>>
> >>>>>
> >>>>>> On Wed, Jan 19, 2011 at 3:15 PM, Barry Leiba <
> [email-masked]>
> >>>>>> wrote:
> >>>>>>
> >>>>>>
> >>>>>>> As for timescales, we already started work on a new Intro in
> October
> >>>>>>>> and
> >>>>>>>> done informally, not as an official draft but as input to a
> totally
> >>>>>>>> new

---

From: Izzy Alanis <[email-masked]>
Date: Mon, 28 Mar 2011 00:21:15 -0400

I definitely agree that the charter reflect (define!) our goals... but
what are those goals?

I prefer to read the existing charter as very ambitious. Trying ...
not to bridge existing worlds, but allow for the creation of new
worlds in which new things are possible. But the rest of the
documentation is littered with implementation details about the
existing virtual worlds.

It's the pull and tug between breaking free with new ideas (and,
Morgaine, you have a lot of cool new ideas) and being tied to the
existing infrastructure that's at conflict here.

When I say that the existing charter was salvageable, I mean this: If
we're going to follow that ambitious goal and forge ahead (possibly
leaving the existing virtual worlds behind)... then yeah, I think we
can work under this charter.  If we need to step back and rein in our
ambition (focus on interoperability and asset sharing between existing
virtual worlds?), then the charter should reflect that to give the
group focus.

On Sun, Mar 27, 2011 at 8:17 PM, Morgaine
<[email-masked]> wrote:
> regions to them (ie. it's an intra-world protocol, not inter-world).  It
>> >>>> ensure that there is visible progress in the form of documents, I
>> >>>> must
>> >>>> say
>> >>>> documents do nothing for interop between virtual worlds", I would
>> >>>> like
>> >>>> to
>> >>>> On Wed, Mar 23, 2011 at 8:10 PM, Barry Leiba
>> >>>> <[email-masked]>
>> >>>> wrote:
>> >>>>
>> >>>>
>> >>>>> On Sun, Feb 27, 2011 at 1:52 PM, Barry Leiba
>> >>>>> <[email-masked]>
>> >>>>> wrote:
>> >>>>>
>> >>>>>
>> >>>>>> On Wed, Jan 19, 2011 at 3:15 PM, Barry Leiba
>> >>>>>> <[email-masked]>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>>> simply did not meet key requirements for many contributors, as
>> >>>>>>>> was
>> >>>>>>>> clear

---

From: Izzy Alanis <[email-masked]>
Date: Mon, 28 Mar 2011 00:29:52 -0400

Forging ahead...

Are we commenting on the definitions on the wiki, or in the list? I'm
confused about the process now.

---

From: Morgaine <[email-masked]>
Date: Mon, 28 Mar 2011 16:29:03 +0100

Barry, is there IETF precedent for a WG that has undergone this particular
train of events, namely a major disconnect between its originators'
intentions and the WG's expectations of direction?

If so, our situation may be slightly easier to handle, since the originators
have withdrawn from pressing their case and there appears to be almost no
actual dispute remaining in the group.  Procedurally though, I really don't
know where we stand from the IETF's perspective.  We seem to have a common
goal now, but if the IETF demands paperwork, we're not there yet because the
designs and plans have not been worked out.  I'm hoping for flexibility, but
acknowledge that flexibility has a limit.

That said, reading the IETF Mission Statement leaves no doubt that VW
interoperability is right in the middle of the road for the IETF.  Can the
group be left to work out what needs to be worked out?

Morgaine.

=================================

---

From: Vaughn Deluca <[email-masked]>
Date: Mon, 28 Mar 2011 18:31:16 +0200

A wiki is great for documentation, useful for collaborative work, and
not so good for discussion.
My suggestion would be to put text snippets and proposals on the wiki,
post comments and rationale to the list, and update the wiki to
reflect the results of the discussion (and possibly some motivation).

In principle somebody adding terms and/or text to the wiki should
update those terms and text during/after discussion as well, however,
i am planning to keep an eye on the synchronisation of wiki and list.

--Vaughn

---

From: Dzonatas Sol <[email-masked]>
Date: Mon, 28 Mar 2011 10:32:56 -0700

I'm pretty sure the AWG has left the glossary/defs up on 
wiki.secondlife.com somewhere.

--

---

From: Vaughn Deluca <[email-masked]>
Date: Mon, 28 Mar 2011 21:18:39 +0200

Thanks!, found it here:
http://wiki.secondlife.com/wiki/Second_Life_Grid_Glossary
I will copy it over.
-- Vaughn

On 3/28/11, Dzonatas Sol <[email-masked]> wrote:
>>>>> We've discussed the wiki concept several times and several of us
>>>>> started
>>>>> a

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 28 Mar 2011 12:53:03 -0700

Um. Morgaine. You don't get to define the wg's expectation or direction. As
a member of this wg (and someone who's actually written code related to it's
problem domain) I would like to be included in the development of this
group's consensus.

On Mar 28, 2011 8:29 AM, "Morgaine" <[email-masked]> wrote:

Morgaine.

On Sat, Mar 26, 2011 at 2:40 PM, Barry Leiba <[email-masked]>
wrote:
> Hi, Carlo, Vaugh...

---

From: Morgaine <[email-masked]>
Date: Mon, 28 Mar 2011 22:15:51 +0100

The group's expectation of direction was already manifest at the time of
Crista's intervention a few months ago, at which time it was unanimous that
everybody except one person was seeking interoperation between virtual
worlds as a primary requirement and as a key motivation for the group's
work.

The dissenting opinion was clearly, if unofficially, outvoted by <count of
group members> to 1.  If that direction is *STILL* not accepted by everyone
in the WG, I shall ask Barry to formally call a count of votes and establish
the rough consensus officially.  Without this we will be perpetually
disrupted by a non-representative minority pulling in the opposite direction
to the rest of the group.

Morgaine.

========================

On Mon, Mar 28, 2011 at 8:53 PM, Meadhbh Hamrick <[email-masked]>wrote:

> If so, our situation may be slightly easier to handle, since the
> originators have withdrawn from pressing their case and there appears to be
> almost no actual dispute remaining in the group.  Procedurally though, I
> really don't know where we stand from the IETF's perspective.  We seem to
> have a common goal now, but if the IETF demands paperwork, we're not there
> yet because the designs and plans have not been worked out.  I'm hoping for
> flexibility, but acknowledge that flexibility has a limit.
>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 28 Mar 2011 15:51:51 -0700

if there is consensus in our objectives. can we then recharter or form a new WG?

also. what was this consensus that you assert i agreed to?

-cheers
-meadhbh

On Mon, Mar 28, 2011 at 2:15 PM, Morgaine
<[email-masked]> wrote:
> group members> to 1.  If that direction is STILL not accepted by everyone in
> the WG, I shall ask Barry to formally call a count of votes and establish
>> Um. Morgaine. You don't get to define the wg's expectation or direction.
>> As a member of this wg (and someone who's actually written code related to
>> it's problem domain) I would like to be included in the development of this
>> group's consensus.
>>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 28 Mar 2011 15:58:16 -0700

in other words, what does "interoperation between virtual worlds" mean?

the "service level interoperability" was sufficiently defined such
that i could (and did) go out and write code to demonstrably implement
the specification. does the term "interoperation between virtual
worlds" mean:

a. interoperability between any two existing virtual world or MMO
systems? (i.e. - between second life and world of warcraft?)

b. interoperability between second life, second life / enterprise or
OpenSIm instances?

or

c. interoperability between two OpenSim instances?

if a or b, do we have any interest from any of the implementers of
those systems to adhere to an IETF standard?

-cheers
-meadhbh

---

From: Dzonatas Sol <[email-masked]>
Date: Mon, 28 Mar 2011 16:13:28 -0700

If you want service only, I think there is code implemented already. We 
need the ability for people to own their assets on their own local site 
(and further simulate them with their own local simulator, for like 
opening inventory in looking at the puzzle pieces).

There has been much debate about client/server and exactly what that 
means. Given that even X11 defines client/server backwords from the 
VWinterop concept now, it is a hard battle to people's mind to bend one 
way or another in terminology. I think the progress to define 
multi-point on either client or service side was finally a start to see 
the bigger picture easier. Being able to start up separate client side 
programs is at issue that breaks away from the monolithic design.

There are some that want to stay with the monolithic design purely for 
revenue reasons. I need not mention whom. This causes the main 
bottleneck from the client-side developer. If we define server side in 
such way, and let server-side people "ban" client-side developers 
because it doesn't fit their motif, then there is no equality in vote in 
this working group. I hope we can remedy at least this in any 
"interoperation".

I think it would be easiest to consider the DAE (collada) format as an 
example. Allow one client to start up (point A), and allow another 
client to start up (point B), and allows these to clients to contant an 
agent domain to transfer DAE files back and forth between inventory 
without any region simulators. This A<->B path needs to be in the 
"service level interoperability". This may seem like simple file 
transfer, so be it.

Meadhbh Hamrick wrote:
>> group members> to 1.� If that direction is STILL not accepted by everyone in
>> the rough consensus officially.� Without this we will be perpetually
>>> almost no actual dispute remaining in the group.� Procedurally though, I
>>> really don't know where we stand from the IETF's perspective.� We seem to
>>> yet because the designs and plans have not been worked out.� I'm hoping for
>>> interoperability is right in the middle of the road for the IETF.� Can the

--

---

From: Boroondas Gupte <[email-masked]>
Date: Tue, 29 Mar 2011 01:15:48 +0200

> those systems to adhere to an IETF standard?
How about:

d. interoperability between (instances of) any two virtual world systems
conforming to the (to be defined) VWRAP standard.

Whether implementers of an existing virtual world system want to change
that system so that it becomes conformant to the new standard and thus
potentially interoperable with other conforming ones should be their own
choice, of course.

Cheers,
Boroondas

---

From: Dzonatas Sol <[email-masked]>
Date: Mon, 28 Mar 2011 16:25:20 -0700

Dzonatas Sol wrote:
> If you want service only, I think there is code implemented already. 
> We need the ability for people to own their assets on their own local 
> site (and further simulate them with their own local simulator, for 
> like opening inventory in looking at the puzzle pieces).
>
> VWinterop concept now, it is a hard battle to people's mind to bend 
> one way or another in terminology. I think the progress to define 
> multi-point on either client or service side was finally a start to 
> see the bigger picture easier. Being able to start up separate client 
> side programs is at issue that breaks away from the monolithic design.
>
> because it doesn't fit their motif, then there is no equality in vote 
> in this working group. I hope we can remedy at least this in any 
> "interoperation".
>
> client to start up (point B), and allows these to clients to contant 
> an agent domain to transfer DAE files back and forth between inventory 
P.S. It's not about copybot... it's about being able to work together on 
designs at the local level where people can "manufacture" the colllada 
files. Simplification in the file transfer process, and update, and etc, 
is in mind.  (i.e. "the chair")

--

---

From: Morgaine <[email-masked]>
Date: Tue, 29 Mar 2011 01:00:32 +0100

Responding to two posts:

> If you want service only, I think there is code implemented already.

Exactly as Dzonatas says.  We don't need to work on protocols for internal
use by separate, isolated world services.  We have those already.  The
ingredient that is mostly missing from the Virtual World arena is
interoperability *between* such services, and that is the goal that has
sparked extremely wide interest.

> conforming to the (to be defined) VWRAP standard.

Exactly as Boroondas says.  Indeed, that is the interoperability goal sought
by the majority of contributors here over the years, so this is nothing new.
It's the feature that virtual worlds don't yet have, and that's why it's
worthwhile to work on it.

Morgaine.

=========================

On Tue, Mar 29, 2011 at 12:13 AM, Dzonatas Sol <[email-masked]> wrote:

> need the ability for people to own their assets on their own local site (and
> further simulate them with their own local simulator, for like opening
> inventory in looking at the puzzle pieces).
>
> There has been much debate about client/server and exactly what that means.
> Given that even X11 defines client/server backwords from the VWinterop
> concept now, it is a hard battle to people's mind to bend one way or another
> in terminology. I think the progress to define multi-point on either client
> or service side was finally a start to see the bigger picture easier. Being
> able to start up separate client side programs is at issue that breaks away
> from the monolithic design.
>
> revenue reasons. I need not mention whom. This causes the main bottleneck
> from the client-side developer. If we define server side in such way, and
> let server-side people "ban" client-side developers because it doesn't fit
> their motif, then there is no equality in vote in this working group. I hope
> we can remedy at least this in any "interoperation".
>
> example. Allow one client to start up (point A), and allow another client to
> start up (point B), and allows these to clients to contant an agent domain
> to transfer DAE files back and forth between inventory without any region
> simulators. This A<->B path needs to be in the "service level
> interoperability". This may seem like simple file transfer, so be it.
>
>
> Meadhbh Hamrick wrote:
>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 28 Mar 2011 17:25:04 -0700

i think that's the same thing as "service level interop" with the
added requirement that participants implement all services.

---

From: Boroondas Gupte <[email-masked]>
Date: Tue, 29 Mar 2011 03:41:52 +0200

On 03/29/2011 02:00 AM, Morgaine wrote:
> On Tue, Mar 29, 2011 at 12:15 AM, Boroondas Gupte
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
> Exactly as Boroondas says.  Indeed, that is the interoperability goal
> sought by the majority of contributors here over the years, so this is
> nothing new. It's the feature that virtual worlds don't yet have, and
> that's why it's worthwhile to work on it.

> added requirement that participants implement all services.

Let me get this straight. If we

    * take this "interoperability between VW systems" (as propagated by
      Morgaine),
    * assume these systems are composed from separable services and
    * drop the requirement that each service provider (I'd like to avoid
      the term "participant" here, as that could also refer to end users
      or their user-agents) provides a complete set of services (i.e. a
      "whole" virtual world, that could function on its own), but
      instead allow them to offer single services that only form a
      virtual world when combined with other services from other
      compliant providers

we end up with "service level interoperability" (as propagated by Meadhbh)?

(Please speak up if I'm misreading any of you.)

If that is actually the case, most of the differences within the group
might be merely in nomenclature. Or maybe the difference isn't mainly in
the entities we want to interoperate, but instead in what we mean by
interoperation? Or have we ended up at a formulation abstract enough
that people can agree with it even when they actually have different
goals from each other?

Slightly confused,
Boroondas

---

From: Dzonatas Sol <[email-masked]>
Date: Mon, 28 Mar 2011 19:58:48 -0700

Boroondas Gupte wrote:
> Or have we ended up at a formulation abstract enough that people can 
> agree with it even when they actually have different goals from each 
> other?
>

On this note, let me say that the current data packet contains asset 
data that has too much information. Anotherwords, some of the data 
should stay on the one end or the other and not transferred. Such like, 
creation date of the asset. When the asset is transfered, there should 
be a new creation date. This then easily keeps assets unique and not 
easily copied. (There is others...)

Just sayin'....

--

---

From: Morgaine <[email-masked]>
Date: Tue, 29 Mar 2011 07:38:40 +0100

On Tue, Mar 29, 2011 at 2:41 AM, Boroondas Gupte <[email-masked]
> wrote:Let me get this straight. If we

>
>    - drop the requirement that each service provider (I'd like to avoid
>    the term "participant" here, as that could also refer to end users or their
>    user-agents) provides a complete set of services (i.e. a "whole" virtual
>    world, that could function on its own), but instead allow them to offer
>    single services that only form a virtual world when combined with other
>    services from other compliant providers
>

Boroondas, there has never been any requirement that a party provide a
complete set of services.  Any party can provide as many or as few types as
services as they want, so that has never been an issue.

The interoperability that we're talking about here is the one that every
ordinary user of multiple worlds understands perfectly well when they
discover to their dismay that each world is an isolated walled garden, and
wish it were otherwise.  The introduction of "service level
interoperability" into the discussion is just an attempt to avoid that most
important requirement.

We either have interoperability between worlds, in which an inhabitant can
travel from one world to another and take their avatar and/or possessions
with them, or else we don't have that.  It's black and white, and no amount
of fudging about "service level interoperability" is going to overcome the
lack of VW interoperability as a user would understand it.

This is *NOT* a matter of terminology, as some are trying to portray.  On
the one hand we gain interoperability between worlds, and on the other hand
we don't.

Morgaine.

=======================

On Tue, Mar 29, 2011 at 2:41 AM, Boroondas Gupte <[email-masked]

> nothing new. It's the feature that virtual worlds don't yet have, and that's
> why it's worthwhile to work on it.
>
>
>    - take this "interoperability between VW systems" (as propagated by
>    Morgaine),
>    - assume these systems are composed from separable services and
>    - drop the requirement that each service provider (I'd like to avoid
>    the term "participant" here, as that could also refer to end users or their
>    user-agents) provides a complete set of services (i.e. a "whole" virtual
>    world, that could function on its own), but instead allow them to offer
>    single services that only form a virtual world when combined with other
>    services from other compliant providers
>
> might be merely in nomenclature. Or maybe the difference isn't mainly in the
> entities we want to interoperate, but instead in what we mean by
> interoperation? Or have we ended up at a formulation abstract enough that
> people can agree with it even when they actually have different goals from
> each other?
>
> Slightly confused,
> Boroondas
>

---

From: "Dickson, Mike (ISS Software)" <[email-masked]>
Date: Tue, 29 Mar 2011 12:54:35 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Morgaine
Sent: Monday, March 28, 2011 8:01 PM
To: [email-masked]
Subject: Re: [vwrap] Status and future of the VWRAP working group

Responding to two posts:

On Tue, Mar 29, 2011 at 12:13 AM, Dzonatas Sol <[email-masked]<mailto:[email-masked]>> wrote:
If you want service only, I think there is code implemented already.

Exactly as Dzonatas says.  We don't need to work on protocols for internal use by separate, isolated world services.  We have those already.  The ingredient that is mostly missing from the Virtual World arena is interoperability between such services, and that is the goal that has sparked extremely wide interest.

Right, so we do need to standardize “Service Level Interop”.  As has been pointed out its concrete enough you can actually do it and it would allow the assembly of virtual worlds based upon it.   The point that some of this exists is a good one, there’s some existing practice and knowledge that can be leveraged.

On Tue, Mar 29, 2011 at 12:15 AM, Boroondas Gupte <[email-masked]<mailto:[email-masked]>> wrote:

Exactly as Boroondas says.  Indeed, that is the interoperability goal sought by the majority of contributors here over the years, so this is nothing new. It's the feature that virtual worlds don't yet have, and that's why it's worthwhile to work on it.

Again, this is sensible and it’s achieved via the “standard services” defined above.  I don’t know what it mean to have virtual world interop personally.  It’s a nice ideal but in practice differences in policy, technology, etc, make it practically impossible to specify given the current state of  affairs.    We can’t even agree on a the data description protocol let alone how to handle policy across VW systems.  And that extends past business policy into technical issues like: if an “object”  is scripted how does that transfer to another VW. Who allocates the script resources.  And of course there’s also creator’s rights vs. owner’s rights.  The list is extremely long and we can’t even agree on how services should talk and which there should be in a standard way.

IMO, the effort should focus on Service Level interoperability and the definition of a few fundamental building block services: i.e user service, inventory service, asset service.  I’d leave the simulator piece off for now.  If we get those right you can start to share user information between “virtual worlds”, locate and access inventory and define an objects characteristics inside a simulator.  And the simulator piece can evolve until its ready to be standardized.
Mike

---

From: Barry Leiba <[email-masked]>
Date: Tue, 29 Mar 2011 10:15:59 -0400

I have no time this week, during IETF week, to respond in detail.  And
I'll be on vacation next week.  I'll try to give a full response when
I get back home, after 8 April.  But something quick now:

> technical progress.

So people don't misunderstand, here:  documents are what the IETF
produces.  Therefore, in the end, we need to have documents.  On the
way there, we need to see progress.  We ultimately measure progress by
finished documents, and sometimes measure progress along the way by
progress on documents.  Productive discussion is good, too.

Don't interpret from this that the only thing I or the ADs care about
are getting documents cranked out "at all costs".  The problem is that
we haven't had any progress in a long time, and we need to push things
along.  We can talk forever; I know that.  That talk *eventually* has
to turn into documents, or we might as well close the working group
and just let people chat on the mailing list.

That's why I'm pushing for some visible progress on at least one
document, the introduction/overview one.  I'm not suggesting that we
should be posting documents with individual opinions, at the expense
of group consensus.  What I'm saying is that if, as a group, we can't
talk a bit, tease consensus out of that, write that consensus down,
and post it as a draft proposal... then we're being ineffective.

There's enough going on here that we're not going to shut things down
on 10 April because nothing's been posted.

That said, we need to be leading this discussion on consensus that can
be documented and posted.  And we need to focus on that and accomplish
it soon, for a vague but near-term value of "soon".

Barry, as chair
(Now, my attention is back to the PLASMA BoF....)

---

From: Morgaine <[email-masked]>
Date: Tue, 29 Mar 2011 16:01:54 +0100

Thanks Barry.  That's what I assumed the IETF wants, documents reflecting
the group's technical progress and working towards a consensus, not
documents as an end in themselves even when they do not reflect any
consensus.

We had a round of documents produced by one or more parties who openly and
explicitly confirmed to us here that *interoperation between VWs was not
intended*, but only belatedly after the group exerted intense pressure to
make the issue clear.  Obtaining that fact has been like drawing blood from
a stone, instead of reading an openly stated requirement.

That's how far the documents process has got us so far, and it has been very
unhelpful for the group's progress, effectively wasting some years of our
lives with very little to show for our time and effort.  Let's not let that
happen again.

We need a group consensus on this core issue before we can even begin to
think about documents again, because the nature of most of our documents is
entirely dependent on that choice.

> it soon, for a vague but near-term value of "soon".

Here, here! :-)

Morgaine.

==========================

---

From: Morgaine <[email-masked]>
Date: Tue, 29 Mar 2011 16:37:28 +0100

On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software) <
[email-masked]> wrote:

>
> Right, so we do need to standardize “Service Level Interop”.  As has been
> pointed out its concrete enough you can actually do it and it would allow
> the assembly of virtual worlds based upon it.
>

I think you misunderstood the point that I wrote, since you concluded the
opposite.  No, it does not follow that we need to standardize "service level
interop", because that does not give us interoperation between virtual
worlds.  It only allows us to standardize (as you correctly state) the
"assembly of virtual worlds", one world at a time, instead of standardizing
their interoperation.  We don't need to standardize how VWs are assembled,
it's not even our remit to do that because that's up to each provider.

>
> I don’t know what it mean to have virtual world interop personally.
>

Why?  It's very easy to understand, and I would guess that every VW user
today who is using two or more virtual worlds like (say) OSgrid and InWorldz
can probably describe it very eloquently.  I'll just repaste how I described

> lack of VW interoperability as a user would understand it.

Interoperability between VWs is truly a simple concept, and users are asking
for it continually and woeing its absence daily.  Its lack is so clear and
self-evident and annoying that people even write export-import programs to
try to alleviate the user "suffering" through its absence.  Frankly,
professing not to understand what it means is very bizarre.  All I can
suggest is, I'll try to clarify it further for you if you still don't
understand what it means.

Morgaine.

===========================

On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software) <
[email-masked]> wrote:

> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Morgaine
> *Sent:* Monday, March 28, 2011 8:01 PM
> *To:* [email-masked]
>
> *Subject:* Re: [vwrap] Status and future of the VWRAP working group
>
>
>
> Responding to two posts:
>
>
> Right, so we do need to standardize “Service Level Interop”.  As has been
> pointed out its concrete enough you can actually do it and it would allow
> the assembly of virtual worlds based upon it.   The point that some of this
> exists is a good one, there’s some existing practice and knowledge that can
> be leveraged.
>
> Again, this is sensible and it’s achieved via the “standard services”
> defined above.  I don’t know what it mean to have virtual world interop
> personally.  It’s a nice ideal but in practice differences in policy,
> technology, etc, make it practically impossible to specify given the current
> state of  affairs.    We can’t even agree on a the data description protocol
> let alone how to handle policy across VW systems.  And that extends past
> business policy into technical issues like: if an “object”  is scripted how
> does that transfer to another VW. Who allocates the script resources.  And
> of course there’s also creator’s rights vs. owner’s rights.  The list is
> extremely long and we can’t even agree on how services should talk and which
> there should be in a standard way.
>
>
>
> IMO, the effort should focus on Service Level interoperability and the
> definition of a few fundamental building block services: i.e user service,
> inventory service, asset service.  I’d leave the simulator piece off for
> now.  If we get those right you can start to share user information between
> “virtual worlds”, locate and access inventory and define an objects
> characteristics inside a simulator.  And the simulator piece can evolve
> until its ready to be standardized.
>
> Mike
>
>
>

---

From: Izzy Alanis <[email-masked]>
Date: Tue, 29 Mar 2011 11:46:42 -0400

I'll second Mike's comment: I don’t know what it mean to have virtual
world interop personally.

Do I have to be able to teleport from one world to the next within the
same viewer to qualify as "interop"? Or would it be OK if I was able
to log in using different viewers/clients as long as my 'identity' was
maintained? What if I had to have separate identities between virtual
worlds, but could still access my bank of assets? What if I could
maintain the concept of "identity" but not transfer assets/use a
particular asset service? What if I couldn't access my assets from a
particular asset service in a particular virtual world due to policy
reasons (e.g. virtual world "A" doesn't like asset service provider
"B")?

 - Izzy

On Tue, Mar 29, 2011 at 11:37 AM, Morgaine
<[email-masked]> wrote:
> On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software)
> <[email-masked]> wrote:
>>
> On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software)
> <[email-masked]> wrote:
>>
>> Morgaine
>> interoperability between such services, and that is the goal that has

---

From: Morgaine <[email-masked]>
Date: Tue, 29 Mar 2011 17:06:28 +0100

Izzy, it's truly simple, and I see that you understand it.  You have listed
a number of possible restrictions or constraints that could be applied to
limit or modify interop between worlds, but your list of questions is only
meaningful because you already understand what interop between virtual
worlds means at its most open and powerful.

You are there already in your understanding! :-)

When our protocols support such interoperation between virtual worlds,
restrictions can of course be placed on that interoperation by world
providers, just like an email service provider can place restrictions on who
can access their service, where people can send emails, the kinds of content
permitted, and so on.  It's totally normal for services on the Internet to
apply their own restrictions, and it would be no different for interoperable
VWs.

Likewise for us, we know what interoperation between virtual worlds means in
concept (I described it in simple user language in my previous email), but
any individual deployment might reduce or limit that based on local policy.
It's not up to us to mandate local policy, but it is up to us to create a
protocol that provides interoperation between virtual worlds so that it's
available for those worlds that do want to interoperate.

Morgaine.

============================

---

From: Izzy Alanis <[email-masked]>
Date: Tue, 29 Mar 2011 20:01:36 -0400

So, I'm still trying to understand your sentence:
> no amount of fudging about "service level interoperability" is going to overcome the lack of VW interoperability as a user would understand it.
Certainly, a small amount of service level interop would go a long way
to overcome VW interoperability.

In your mind, how does service level interop *not* lead to "VW
Interoperability"? This whole argument between service level interop
and 'full' interop eludes me.

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 29 Mar 2011 17:30:22 -0700

Especially since this is the Virtual World Region-Agent Protocol, I'm 
wondering where is "full" and "service level" in the region/agent 
dissection.

Izzy Alanis wrote:
>> Izzy, it's truly simple, and I see that you understand it.� You have listed
>> permitted, and so on.� It's totally normal for services on the Internet to
>>> I'll second Mike's comment: I don�t know what it mean to have virtual
>>> �- Izzy
>>>>> Right, so we do need to standardize �Service Level Interop�.� As has
>>>>> been
>>>> opposite.� No, it does not follow that we need to standardize "service
>>>> level
>>>> worlds.� It only allows us to standardize (as you correctly state) the
>>>> their interoperation.� We don't need to standardize how VWs are
>>>> assembled,
>>>>> I don�t know what it mean to have virtual world interop personally.
>>>>>           
>>>> Why?� It's very easy to understand, and I would guess that every VW user
>>>> can probably describe it very eloquently.� I'll just repaste how I
>>>> described
>>>> it yesterday:
>>>>
>>>>         
>>>>> with them, or else we don't have that.� It's black and white, and no
>>>>> amount
>>>> for it continually and woeing its absence daily.� Its lack is so clear
>>>> and
>>>> try to alleviate the user "suffering" through its absence.� Frankly,
>>>> professing not to understand what it means is very bizarre.� All I can
>>>>> Exactly as Dzonatas says.� We don't need to work on protocols for
>>>>> internal
>>>>> use by separate, isolated world services.� We have those already.� The
>>>>> Right, so we do need to standardize �Service Level Interop�.� As has
>>>>> been
>>>>> the assembly of virtual worlds based upon it.�� The point that some of
>>>>> this
>>>>> exists is a good one, there�s some existing practice and knowledge that
>>>>> can
>>>>> be leveraged.
>>>>>
>>>>> Exactly as Boroondas says.� Indeed, that is the interoperability goal
>>>>> Again, this is sensible and it�s achieved via the �standard services�
>>>>> defined above.� I don�t know what it mean to have virtual world interop
>>>>> personally.� It�s a nice ideal but in practice differences in policy,
>>>>> state of �affairs.� ��We can�t even agree on a the data description
>>>>> protocol
>>>>> let alone how to handle policy across VW systems. �And that extends
>>>>> past
>>>>> business policy into technical issues like: if an �object� �is scripted
>>>>> how
>>>>> of course there�s also creator�s rights vs. owner�s rights.� The list
>>>>> is
>>>>> extremely long and we can�t even agree on how services should talk and
>>>>> which
>>>>> inventory service, asset service.� I�d leave the simulator piece off
>>>>> for
>>>>> now.� If we get those right you can start to share user information
>>>>> between
>>>>> �virtual worlds�, locate and access inventory and define an objects
>>>>> characteristics inside a simulator.� And the simulator piece can evolve

--