Subject: [mmox] I hate to be a kill joy here and, put the horse before the cart

From: Dan Olivares <[email-masked]>
Date: Sat, 21 Feb 2009 03:18:18 -0500

Greetings everyone

The positive discussion so far has been interesting and will move us
forward in the future, however..   I remind everyone that technically,
there is no MMOX working group yet.  There is currently only a
proposed working group.   We also have not voted on a draft charter.
There have been several proposals and revisions however, without a
working group charter, there is no working group.  Is it really in our
best interest to be discussing implementation details when we're not
even past the draft charter step?   We have a limited time here, lets
make sure to use it as best we can.   I propose that our priority
until it's approved should be the charter including the deliverables
and milestones of the proposed working group and drumming up interest.

Working groups exist to address specific problems or produce
deliverables. There are several things that the IETF will be looking
for in the formation of MMOX

1. A solid draft charter where rough consensus has been reached and
the area director approves.
2. Express the issues that the working group plans to address in a
clear way that also demonstrates that it's relevant to the internet
community.
3. Express, clearly, the milestones and deliverables that the working
group will complete and demonstrate that they can be achieved within a
reasonable time frame.
4. Express the importance and urgency of the work.
5. Demonstrate that the working group doesn't overlap with any other
IETF working groups
6. Demonstrate that there is a base of interested consumers and
developers willing to put in the effort to meet the milestones and
produce the deliverables.
7. Demonstrate that the IETF has a reasonable role to play in the
determination of this standard
(Ref: rfc2418 section 2.1)

The charter is sort of like a contract between the working group and
the IETF.   The working group exists to meet the milestones and
produce the deliverables.   A few important things that the charter
should do;

1.   List relevant administrative aspects of the working group.
2.   Specify the direction or objectives of the working group and
describe the approach that will be taken to achieve the goals.
3.   Enumerate a set of milestones together with time frames for their
completion.

(Ref: rfc2418 section 2.2)

For more information on the working group process, please refer to
rfc2418 (http://www.ietf.org/rfc/rfc2418.txt)

At this point in time, are there any more proposals for the working
group draft? Should we move on to establishing rough consensus and
BOF?

Best Regards

Daniel Olivares

---

From: Gareth Nelson <[email-masked]>
Date: Sat, 21 Feb 2009 09:14:39 +0000

So, why don't we get on with voting on a charter?
As for discussing implementation details now - nothing wrong with
doing so if it's in the same basic area as the formal working group
would be

On Sat, Feb 21, 2009 at 8:18 AM, Dan Olivares <[email-masked]> wrote:
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Sat, 21 Feb 2009 01:32:25 -0800

right. the agenda for the upcoming meeting is essentially:

* what's "in scope" for the charter,
* a brief rap about trust, and
* LLSD

but i can understand why people might want to jump into the deep end  
quickly. all of us who have committed to the source code trees of our  
respective projects or spent time designing aspects of virtual worlds  
have considerable interest in our creations... personal and  
professional.

ultimately this group is about teasing out the best from each of our  
individual approaches and agreeing to standardize those techniques. we  
may want to consider two styles of interop: "interoperability" and  
"INTEROPERABILITY". the latter might imply that any client may connect  
to any sever and expect to get a "reasonable experience." i think we  
all agree this would be hard. the former style might imply a series of  
mechanisms defined for particular tasks with the exact definition of  
which mechanisms and what options to use defined in an  
"interoperability profile." the problem with this technique is it may  
lead to systems that adhere to the specification but are not  
INTEROPERABLE in  any practical sense. but it still has benefit if  
your objective is to build a system with limited "INTEROPERABILITY"  
between virtual world implementations, but is "interoperable" with  
particular tool chains.

so.. i would add to the list of things to think about... where you  
want to be on the "big I" / "little i" spectrum.

-cheers
-meadhbh

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Sat, 21 Feb 2009 01:55:50 -0800

hey gareth...

i think the IETF policy is we want to discuss it f2f before finalizing  
the charter.

and MHO is we're still a ways away from enough consensus to declare  
work on the charter "done".

---

From: Gareth Nelson <[email-masked]>
Date: Sat, 21 Feb 2009 09:59:35 +0000

Well, i'm out of luck then, being on a whole other continent from all you guys.
How much consensus do we need to build a charter? Surely the consensus
on implementation details is different from consensus on what we're
actually doing here?

On Sat, Feb 21, 2009 at 9:55 AM, Meadhbh Hamrick (Infinity)
<[email-masked]> wrote:
> hey gareth...
>
> i think the IETF policy is we want to discuss it f2f before finalizing the
> charter.
>
> and MHO is we're still a ways away from enough consensus to declare work on
> the charter "done".
>

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Sat, 21 Feb 2009 02:14:21 -0800

well... we are planning on broadcasting video of the event via RTSP so  
it's consumable by qwaq, second life and osgrid / open sim regions.

and we're busy trying to put everything in place to allow  
communication from these worlds into the face to face meeting.

so you're not completely out of luck.

and... i am confident conversation will continue after the f2f on the  
mailing list before we declare general consensus achieved.

-cheers
-meadhbh

---

From: Lawson English <[email-masked]>
Date: Sat, 21 Feb 2009 03:35:57 -0700

> mailing list before we declare general consensus achieved.

It seems to me that some aspect of "virtualization" of the MMOX BOF 
meeting can be extended after that meeting, as well.

If we can take video, audio  presence and distribute it to 3 different 
worlds (and a webpage) and hopefully take the video/audio/chat presence 
from each world and make it available in the RL meeting and in the other 
worlds, there's no reason why we can't hold regular in-world meetings in 
multiple worlds at the same time with a virtual video conferencing 
system, bypassing the RL meeting entirely.

Would this be worth doing? Seems that it would be, simply as an ongoing 
test of what we're heading toward which would encourage refinement and 
collaboration in order to make even that primitive virtual video 
conference better and hopefully help us learn more about less obvious 
interop issues while we're doing it.

Besides it would be just plain fun, IMHO.

Certainly, Metanomics and Science Friday would embrace a multi-world 
venue and publicize it for us (1.25 million NPR listeners hearing about 
mmox every week can't be a bad thing, eh?) and hopefully get more people 
interested in contributing to the project.

Lawson

---

From: Morgaine <[email-masked]>
Date: Sat, 21 Feb 2009 11:10:23 +0000

On Sat, Feb 21, 2009 at 9:14 AM, Gareth Nelson <[email-masked]> wrote:

> doing so if it's in the same basic area as the formal working group

That work has already started, Gareth, although the discussion might have
preceded your joining the list. :-)

To help your navigation, I'll unpick the messy email threading for you:

1) John Hurliman first pointed out the inappropriateness of references to
OGP in the charter of a workgroup whose mission it is to examine what is
appropriate in the first place:
http://www.ietf.org/mail-archive/web/mmox/current/msg00012.html

2) I agreed, and affirmed that we are definitely not here to rubberstamp
Linden proposals, and hence that we should start immediately on improving
the charter:
http://www.ietf.org/mail-archive/web/mmox/current/msg00013.html

3) Infinity responded extremely positively and noted that the initial draft
was highly LL/IBM-specific since they were the two authors of the draft, but
invited John and myself (and everyone else on the list of course) to submit
concrete proposals for improvements:
http://www.ietf.org/mail-archive/web/mmox/current/msg00015.html

4) I responded with an offer to help directly:
http://www.ietf.org/mail-archive/web/mmox/current/msg00016.html

5) Based off the LL/IBM original (#1), John provided the first improved
draft charter (#2):
http://www.ietf.org/mail-archive/web/mmox/current/msg00032.html

6) Based off John's draft #2, I made improvements for clarity and removed an
ambiguity, to give us draft #3:
http://www.ietf.org/mail-archive/web/mmox/current/msg00036.html

7) Infinity and I then exchanged several emails in the list to narrow down
whether the word "proprietary" was substantive, or just a residue from the
initial version.  The clear conclusion was that it was *highly* substantive,
and therefore I further modified my version with a clear statement that we
are in the business of defining open, non-proprietary standards, which
became draft #4:
http://www.ietf.org/mail-archive/web/mmox/current/msg00066.html

There have been no specific updates since then.

Needless to say, if you or anyone else requires further changes, then pick
up the baton and run with it!  I look forward to draft #5. :-)

I am sure the text will undergo numerous further iterations before we
finally agree on an effective charter that can be passed at the BoF.  The
MMOX list is currently examining other issues, but it is certain to return
to the charter as the BoF draws nearer.

Morgaine.

---

From: Gareth Nelson <[email-masked]>
Date: Sat, 21 Feb 2009 11:22:58 +0000

Thanks for the overview :)
My only comment with a quick glance is regarding this:

"c) allow network layers to recognize VW traffic and make routing
decisions based on its characteristics."

Is client<>server traffic for individual worlds not primarily
something for individual worlds rather than an interop issue?
For example, you might be on world A, and talking to world B via world
A's servers, but your client<>server traffic is still running A's
protocol. At the server<>server end is this kind of QoS actually
useful?

On Sat, Feb 21, 2009 at 11:10 AM, Morgaine
<[email-masked]> wrote:
> initial version.  The clear conclusion was that it was highly substantive,

---

From: Gareth Nelson <[email-masked]>
Date: Sat, 21 Feb 2009 11:25:37 +0000

2 more comments (Apologies for the multiple replies style, it's a bit
of a habit)

October 2009  Publication of LLSD Draft as an Informational RF

Is there a reason this milestone is set so late? LLSD is already
fairly well defined. I would go so far as to say that the existing
specs and code can be RFC-alised as-is with only some subtle changes
as compatibility dictates.

---

From: Lawson English <[email-masked]>
Date: Sat, 21 Feb 2009 05:04:23 -0700

> as compatibility dictates.

Given the friction that has arisen merely over the name "LL" I think 
that we're a bit far from getting the protocol even semi-ready.

Some want to scratch developing something new and go with an existing 
standard just because it is a standard. LLSD is a standard as well, but 
only used by a handful of companies (with probably as many as a million 
or two active users though).

Lawson

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 21 Feb 2009 09:12:38 -0500

> Well, i'm out of luck then, being on a whole other continent from  

Face to face meetings are good, but in the IETF all decisions are made  
on the mailing lists, as that is
where consensus is determined. Note, too, that even without virtual  
presentations of the IETF meetings there
are audio feeds and jabber rooms, and should be jabber scribes, for  
all sessions, and many sessions have active remote participants.

Regards
Marshall

---

From: Jon Watte <[email-masked]>
Date: Sat, 21 Feb 2009 10:54:35 -0800

> group draft? Should we move on to establishing rough consensus and

Here is a proposal for subjects for standardization and a general 
understanding of what the "common ground" would be. I believe that 
without standardizing at least all of these things, broad and useful 
interoperability cannot be achieved:

- User identity is provided by an identity provider, which may be the 
"home" world of the user, or some other provider. Users should not need 
identity tied to the specific world they want to visit. Some worlds may 
choose to not accept certain specific credentials, just like certain 
real-world stores may not accept Candian dollars for payment. The market 
will work out a few major credential systems in the end (such as OpenID, 
perhaps). As long as each system is accessed uniformly, the specifics of 
the back end don't matter.

- Geometry is based on regular meshes, possibly with LOD switches and 
lower-resolution physics meshes/proxies/hulls. I understand that this 
may be a sticking point for the SL-derived worlds (or do they actually 
support arbitrary meshes as an option now? I haven't kept up.)

- Texturing is based on a regular Phong model with various defined 
texture maps (because HLSL vs GLSL vs some-other-SL are each of them not 
suitable on their own). Turns out, once you have the possibility of 
gloss maps, normal maps, emission maps, opacity maps, diffuse maps and 
ambient maps, you have 90% of the "look" of any one technology, which is 
about as good as you can hope for through interoperability.

- Telemetry (entity movement) needs to be sent on a 
position/orientation/velocity basis, with dead reckoning. Delta 
compression and lower update rates can be used to keep bandwidth usage 
in check. This is a big difference for OLIVE, because we are 
input-synchronous, similar to City of Heroes or Age of Empires. However, 
again, this is the common denominator and experience speaking.

- Animating objects need to use a common, widespread interchange format, 
using named animation clips and skeletal animation. Morph deformation is 
likely too big a payload to make sense, at least in the early stages. 
COLLADA is a good format for this, but there are other possibilities 
(FBX, X3D and X come to mind). I think that making at least one format 
required is a good idea, because that ensures a minimum level of 
interoperability is always present.

- Simulation and script execution for a given object needs to be done on 
the "home" system for that object, because objects may be constructed 
assuming wildly disparate execution environments (X3D with JavaScript; 
Prims with SL Script, C++ with XML, Java with JSR 184, etc).

- Objects need to be marked up with simple, well defined possible 
interactions, so that a user interface can be generated on each client 
based on those interactions. Interactions are typically "set this 
property to this value" or "execute this command." Such interactions 
need to be forwarded to the server that runs the object in question. 
Similarly, specific interactions ("emote animation," "collision," 
"damage," "two-party animation," "flight" etc) need to be defined.

- Non-time-critical requests should go over HTTP and/or HTTPS, using 
XML-RPC or a similarly well understood protocol.

- Time-critical and high-bandwidth data (such as entity telemetry and 
user inputs) should be sent using explicit (separate) schema, and binary 
representation, for the same reason that we don't send streaming video 
as XML, or mark each pixel with a color space identifier.

Sincerely,

Jon Watte
Forterra Systems

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Sat, 21 Feb 2009 11:03:45 -0800

yup. this kind of QoS is definitely useful. in the current  
implementation of second life, there's quite a bit simulator to  
simulator communication. if all the simulators are inside the same  
data center, communicating with each other over a fiber ring, we have  
plenty of bandwidth, so we don't see a lot of QoS related problems.  
however... when two sims are in different data centers and their  
communications have to go over the public internet (rather than some  
private network with guaranteed bandwidth and latency characteristics)  
sim <-> sim QoS becomes VERY important.

of course we're not saying we should standardize the exact same  
protocol we're using today at linden, but it's reasonable to assume  
that we would re-use some of the same design patterns, or at least  
support the same design pattern. ergo, it's probably in our best  
interest to think about QoS between all systems...

-cheers
-meadhbh

---

From: Ryan McDougall <[email-masked]>
Date: Sat, 21 Feb 2009 21:03:07 +0200

On Sat, Feb 21, 2009 at 8:54 PM, Jon Watte <[email-masked]> wrote:
> understanding of what the "common ground" would be. I believe that without
> standardizing at least all of these things, broad and useful
> - User identity is provided by an identity provider, which may be the "home"
> world of the user, or some other provider. Users should not need identity
> tied to the specific world they want to visit. Some worlds may choose to not
> accept certain specific credentials, just like certain real-world stores may
> not accept Candian dollars for payment. The market will work out a few major
> credential systems in the end (such as OpenID, perhaps). As long as each
> system is accessed uniformly, the specifics of the back end don't matter.
>
> lower-resolution physics meshes/proxies/hulls. I understand that this may be
> a sticking point for the SL-derived worlds (or do they actually support
> arbitrary meshes as an option now? I haven't kept up.)
>
> - Texturing is based on a regular Phong model with various defined texture
> maps (because HLSL vs GLSL vs some-other-SL are each of them not suitable on
> their own). Turns out, once you have the possibility of gloss maps, normal
> maps, emission maps, opacity maps, diffuse maps and ambient maps, you have
> 90% of the "look" of any one technology, which is about as good as you can
> hope for through interoperability.
>
> position/orientation/velocity basis, with dead reckoning. Delta compression
> and lower update rates can be used to keep bandwidth usage in check. This is
> a big difference for OLIVE, because we are input-synchronous, similar to
> City of Heroes or Age of Empires. However, again, this is the common
> denominator and experience speaking.
>
> COLLADA is a good format for this, but there are other possibilities (FBX,
> X3D and X come to mind). I think that making at least one format required is
> a good idea, because that ensures a minimum level of interoperability is
> always present.
>
> - Simulation and script execution for a given object needs to be done on the
> "home" system for that object, because objects may be constructed assuming
> wildly disparate execution environments (X3D with JavaScript; Prims with SL
> Script, C++ with XML, Java with JSR 184, etc).
>
> interactions, so that a user interface can be generated on each client based
> on those interactions. Interactions are typically "set this property to this
> value" or "execute this command." Such interactions need to be forwarded to
> the server that runs the object in question. Similarly, specific
> interactions ("emote animation," "collision," "damage," "two-party
> animation," "flight" etc) need to be defined.
>
> - Non-time-critical requests should go over HTTP and/or HTTPS, using XML-RPC
> or a similarly well understood protocol.
>
> - Time-critical and high-bandwidth data (such as entity telemetry and user
> inputs) should be sent using explicit (separate) schema, and binary
> representation, for the same reason that we don't send streaming video as
> XML, or mark each pixel with a color space identifier.
>
> Sincerely,
>
> Jon Watte
> Forterra Systems

Sounds very agreeable to me. :)

Ryan McDougall,
RealXtend.org

---

From: Jon Watte <[email-masked]>
Date: Sat, 21 Feb 2009 11:07:02 -0800

> as compatibility dictates.

I'm of the opinion that LLSD needs to either undergo substantial 
changes, or something else needs to be defined, before it should be 
accepted. Specifically, the XML serialization is not Xpath friendly, and 
there is no "external schema" compact form.

At a minimum, I think that "publication of LLSD draft" should be changed 
to something worded like "publication of a basic data description and 
serialization formats RFC."

Sincerely,

jw

---

From: Charles Krinke <[email-masked]>
Date: Sat, 21 Feb 2009 11:13:43 -0800 (PST)

+1, Infinity. We find a similar thing happening with OpenSim on various grids, of which there must be dozens now.

Of the 2000 sims on OSGrid spread across 500 different servers currently, one finds adjacent sims on opposite sides of the planet where the network RTT becomes significant.

So, considering network RTT in interop will be of some importance, I believe.

Charles

________________________________
From: Meadhbh Hamrick (Infinity) <[email-masked]>
To: Gareth Nelson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Saturday, February 21, 2009 11:03:45 AM
Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the  cart

yup. this kind of QoS is definitely useful. in the current implementation of second life, there's quite a bit simulator to simulator communication. if all the simulators are inside the same data center, communicating with each other over a fiber ring, we have plenty of bandwidth, so we don't see a lot of QoS related problems. however... when two sims are in different data centers and their communications have to go over the public internet (rather than some private network with guaranteed bandwidth and latency characteristics) sim <-> sim QoS becomes VERY important.

of course we're not saying we should standardize the exact same protocol we're using today at linden, but it's reasonable to assume that we would re-use some of the same design patterns, or at least support the same design pattern. ergo, it's probably in our best interest to think about QoS between all systems...

-cheers
-meadhbh

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Sat, 21 Feb 2009 11:28:26 -0800

right. this is a non-starter.

if any protocol that uses LLSD to describe it's protocol interactions  
is to have a hope of being anything other than an informational RFC,  
LLSD must be a standards track document.

this is because normative references in RFCs MUST have the same level  
of maturity as the RFC itself. ergo, you can't have a standards track  
document that references an informational RFC as a normative reference.

but why is it set so late?

first off.. remember it's a draft charter (and in the original draft,  
LLSD was listed as a standards track document but to move from being  
an ID to being an RFC at about the same time.) so there's still time  
to modify stuff.

we were originally going to simply submit LLSD as an information RFC,  
but eventually came around to the believe that the IETF is a great  
place to develop standards. as an informational RFC, we could simply  
have published it and moved on with our lives. instead we wanted to  
include the community as a whole which is where the idea of the MMOX  
working group came from. cause if you're just going to publish  
informational RFCs, why do you need a working group?

okay.. this is probably a lot longer answer than what you were  
expecting to get. let me get back to the answer.

we were thinking that LLSD would require a lot of commentary and  
discussion as peeps implement it in their language of choice, and we  
wanted to have time to get that feedback. so... i figured we would  
have at least one and possibly two more drafts of the LLSD doc with  
three or four months between them. Also... october is just before the  
November IETF meeting, and i was hoping we could have our work on LLSD  
finished by then so we could concentrate on the more interesting  
things (like an actual protocol) in that meeting.

-cheers
-meadhbh

---

From: "Mark P. McCahill" <[email-masked]>
Date: Sun, 22 Feb 2009 08:14:50 -0500

Is it possible that two working groups could come out of this BOF  
process?

The mailing list seems to be split - some are interested in the  
original wire-level protocol
proposal, and another group is talking about higher-level  
interoperability issues such as
identity and other issues including those Jon listed below.

On Feb 21, 2009, at 1:54 PM, Jon Watte wrote:

> - User identity is provided by an identity provider, which may be  
> the "home" world of the user, or some other provider. Users should  
> not need identity tied to the specific world they want to visit.  
> Some worlds may choose to not accept certain specific credentials,  
> just like certain real-world stores may not accept Candian dollars  
> for payment. The market will work out a few major credential systems  
> in the end (such as OpenID, perhaps). As long as each system is  
> accessed uniformly, the specifics of the back end don't matter.
>
> - Geometry is based on regular meshes, possibly with LOD switches  
> and lower-resolution physics meshes/proxies/hulls. I understand that  
> this may be a sticking point for the SL-derived worlds (or do they  
> actually support arbitrary meshes as an option now? I haven't kept  
> up.)
>
> texture maps (because HLSL vs GLSL vs some-other-SL are each of them  
> not suitable on their own). Turns out, once you have the possibility  
> of gloss maps, normal maps, emission maps, opacity maps, diffuse  
> maps and ambient maps, you have 90% of the "look" of any one  
> technology, which is about as good as you can hope for through  
> interoperability.
>
> - Telemetry (entity movement) needs to be sent on a position/ 
> orientation/velocity basis, with dead reckoning. Delta compression  
> and lower update rates can be used to keep bandwidth usage in check.  
> This is a big difference for OLIVE, because we are input- 
> synchronous, similar to City of Heroes or Age of Empires. However,  
> - Animating objects need to use a common, widespread interchange  
> format, using named animation clips and skeletal animation. Morph  
> deformation is likely too big a payload to make sense, at least in  
> the early stages. COLLADA is a good format for this, but there are  
> other possibilities (FBX, X3D and X come to mind). I think that  
> making at least one format required is a good idea, because that  
> ensures a minimum level of interoperability is always present.
>
> - Simulation and script execution for a given object needs to be  
> done on the "home" system for that object, because objects may be  
> constructed assuming wildly disparate execution environments (X3D  
> with JavaScript; Prims with SL Script, C++ with XML, Java with JSR  
> 184, etc).
>
> interactions, so that a user interface can be generated on each  
> client based on those interactions. Interactions are typically "set  
> this property to this value" or "execute this command." Such  
> interactions need to be forwarded to the server that runs the object  
> in question. Similarly, specific interactions ("emote animation,"  
> "collision," "damage," "two-party animation," "flight" etc) need to  
> be defined.
>
> - Time-critical and high-bandwidth data (such as entity telemetry  
> and user inputs) should be sent using explicit (separate) schema,  
> and binary representation, for the same reason that we don't send  
> streaming video as XML, or mark each pixel with a color space  
> identifier.
>
> Sincerely,
>
> Jon Watte
> Forterra Systems
>
>

---

From: Gareth Nelson <[email-masked]>
Date: Sun, 22 Feb 2009 13:46:07 +0000

My point is that the current SL protocol has it's own QoS handled by
application endpoints, not network routers. Do cisco sell traffic
shaping devices that handle the SL protocol?
I think QoS in server<>server links is something that can be
standardised, but client<>server is too unique to the individual
protocol type. In other words, a router can't tag a traffic stream as
being "virtual world stuff", it has to be "SL stuff" or "croquet
stuff" etc.

On Sat, Feb 21, 2009 at 7:03 PM, Meadhbh Hamrick (Infinity)
<[email-masked]> wrote:
> yup. this kind of QoS is definitely useful. in the current implementation of
> second life, there's quite a bit simulator to simulator communication. if
> all the simulators are inside the same data center, communicating with each
> other over a fiber ring, we have plenty of bandwidth, so we don't see a lot
> of QoS related problems. however... when two sims are in different data
> centers and their communications have to go over the public internet (rather
> than some private network with guaranteed bandwidth and latency
> characteristics) sim <-> sim QoS becomes VERY important.
>
> of course we're not saying we should standardize the exact same protocol
> we're using today at linden, but it's reasonable to assume that we would
> re-use some of the same design patterns, or at least support the same design
> pattern. ergo, it's probably in our best interest to think about QoS between
> all systems...
>
> -cheers
> -meadhbh
>

---

From: Christian Scholz <[email-masked]>
Date: Sun, 22 Feb 2009 16:29:17 +0100

Hi!

Mark P. McCahill wrote:
> Is it possible that two working groups could come out of this BOF process?
> 
> The mailing list seems to be split - some are interested in the original
> wire-level protocol

I was wondering actually if those identity related matters are actually
not broader than just virtual worlds and if it then fits into this
working group (lets say if some web site wants to use it it might feel
strange to refer to some VW specific standard).

And "identity related matters" can mean the following:

Authentication
How to use my identity from somewhere else on a new site (here things
like OpenID, YADIS, InformationCards etc. play in. There also is already
a big community around this topic, see [1].

Authorization
How to allow consumer services access to protected resources on service
providers on behalf of the user and without knowing a user's password
(or whatever is used to login). The question here is how we can find a
tradeoff between control and good user experience (e.g. not asking the
user for every service if it's ok to access it). Related work is done
with OAuth[2] which seems to gain traction but still has various
shortcomings which are discussed at the moment.

Service Discovery
A user might have various services associated, such as profile
information, the social graph (contacts), photos, 3d assets in various
places, groups, preferred IM servers, activity streams and so on.
If the user signs up somewhere it would be good if it can be avoided
that all URLs to those services needs to be entered. Instead a service
catalogue might be useful which holds all of the users services sorted
by type. The user could then choose which services to allow access to.
The same is useful for service providers. Like some OpenSim or other
virtual world region might have different sub-components the client
needs to talk to. These can be defined the same way (for OpenSim that's
GridInfo right now IIRC).
There is a spec called XRDS-Simple[3] which is based on XRDS which again
is used for OpenID discovery (YADIS) to find out what identity services
are actually available at the URL the user enters. While XRDS-Simple is
now deprecated[4] a new spec (at OASIS) is being written called XRD
which has is supposed to be a better version of XRDS-Simple. At [5] are
some more thoughts on discovery.

Various formats/APIs for moving data around
Having authentication, authorization and service discovery one can then
go ahead and actually exchange data. There are of course many types of
data one can think about. The most basic thing is usually profile
information though, followed by contacts. This at least is what I have
to enter/find over and over again with each signup to a new service.
In virtual worlds finding your friends might even be more difficulty
because they might not have the same names on every platform (e.g.
because you cannot freely choose your name like in SL).
There are already many solutions to this problem like FOAF/RDF,
Microformats or OpenSocial's REST API. I personally prefer the latter
because REST means that you also can write data back (although right now
no service to my knowledge supports that). Microformats is probably out
due to the requirement of HTML which you might not always have in VWs.
Other possible services might be group management, IM, inventory
management (it would be great to have a standardized REST interface for
that) and so on. The question is though if all this should be in the
scope of such an identity based WG. Probably not.

Synchronisation
It's nice to be able to copy data around to whatever service you want to
but if it cannot be synced it might be worthless after a while. So some
means of synchronisation could be defined, e.g. based on XMPP/ATOM etc.
This might also play into the field of activity streams, another hot
topic on the web right now.

So these are my basic thoughts about this. As a result it would be nice
to have

- one definitive URL (or whatever format) for your identity starting
point (per identity)
- a way for other services to discover which types of data you provide
on the net and a mechanism to get authorization to subscribe to it.
- a way to push back data, e.g. changed email addresses etc. to one of
these services
- users in control of their data.

The latter might also be a problem of TOS/EULAs, as most providers right
now need or want quite broad licenses to use your data in whatever way
they want to. There are some discussions right now around the Facebook
TOS change and how people can be made aware of the restrictions they
face when joining a site. These are more social/legal problems though.
If some sort of Creative Commons like set of licenses comes out of that
it might get technical of course to attach them to data and move them
around. Groups active here are at DataPortability[6| and Project Liberty[7].

The good thing in general for a separate group would be to be able to
embrace more parties having the same problems like many social networks
and Open Stack supporters. That's esp. interesting as there already is a
lot of talk going on.

My €.02

-- Christian

[1] http://identitycommons.org/
[2] http://oauth.net
[3] http://xrds-simple.net
[4]
http://www.hueniverse.com/hueniverse/2009/01/discovery-on-my-mind-new-specification-published.html
[5] http://www.hueniverse.com/hueniverse/2009/02/redefining-discovery.html
[6] http://wiki.dataportability.org/pages/viewpage.action?pageId=4490392
[7]
http://wiki.projectliberty.org/index.php/VolunteeredPersonalInformationSIG

>> "home" world of the user, or some other provider. Users should not
>> need identity tied to the specific world they want to visit. Some
>> worlds may choose to not accept certain specific credentials, just
>> like certain real-world stores may not accept Candian dollars for
>> payment. The market will work out a few major credential systems in
>> the end (such as OpenID, perhaps). As long as each system is accessed
>> uniformly, the specifics of the back end don't matter.
>>
>> of gloss maps, normal maps, emission maps, opacity maps, diffuse maps
>> and ambient maps, you have 90% of the "look" of any one technology,
>> which is about as good as you can hope for through interoperability.
>>
>> input-synchronous, similar to City of Heroes or Age of Empires.
>> However, again, this is the common denominator and experience speaking.
>>
>> deformation is likely too big a payload to make sense, at least in the
>> early stages. COLLADA is a good format for this, but there are other
>> possibilities (FBX, X3D and X come to mind). I think that making at
>> least one format required is a good idea, because that ensures a
>> minimum level of interoperability is always present.
>>
>> - Simulation and script execution for a given object needs to be done
>> on the "home" system for that object, because objects may be
>> constructed assuming wildly disparate execution environments (X3D with
>> JavaScript; Prims with SL Script, C++ with XML, Java with JSR 184, etc).
>>
>> user inputs) should be sent using explicit (separate) schema, and
>> binary representation, for the same reason that we don't send
>> streaming video as XML, or mark each pixel with a color space identifier.
>>
>> Sincerely,
>>
>> Jon Watte
>> Forterra Systems
>>
>>

-- 
Christian Scholz                          Homepage: http://comlounge.net
COM.lounge                                   blog: http://mrtopf.de/blog
Luetticher Strasse 10                                    Skype: HerrTopf
52064 Aachen                             Video Blog: http://comlounge.tv
Tel: +49 241 400 730 0                           E-Mail [email-masked]
Fax: +49 241 979 00 850                               IRC: MrTopf, Tao_T

neuer Podcast: Der OpenWeb-Podcast (http://openweb-podcast.de)
new podcast: Data Without Borders (http://datawithoutborders.net)

---

From: Charles Krinke <[email-masked]>
Date: Sun, 22 Feb 2009 07:34:05 -0800 (PST)

Well, what I "hope" we are really talking about is the beginnings of the 3D internet where we can expect to evolve from "flat web pages" to 3D interactive web communication.

This whole thing feels like the discussions around web browsing about 25 years ago. 

If we do our job right, then we will eventually expect that any 3D client can expect to connect to any 3D server, negotiate a pre-described set of capabilities and services and act in an analagous fashion that a web browser does now.

In order to get there, imagine that there were no HTTP or HTML, but rather a few groups that had defined similar but incompatible web page formats so that only their browser would read their web page. 

In order to get to a common experience, it would be necessary for these groups to agree to a common standard so that the browsers could "interop" with each other.

That is the stage we are at today with the notion of "interop" and 3D interactive web virtual worlds.

So, be it wire protocol, or higher level interoperability issues, I think we all need to work to get past our current biases and find a way to define 3D interoperability so we can get past the "flat web" and evolve into the next part of the internet evolution.

Charles Krinke
OpenSim Core Developer
http://opensimulator.org
OSGrid Director
http://osgrid.org

________________________________
From: Mark P. McCahill <[email-masked]>
To: Jon Watte <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Sunday, February 22, 2009 5:14:50 AM
Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart

The mailing list seems to be split - some are interested in the original wire-level protocol
proposal, and another group is talking about higher-level interoperability issues such as
identity and other issues including those Jon listed below.

On Feb 21, 2009, at 1:54 PM, Jon Watte wrote:

> Here is a proposal for subjects for standardization and a general understanding of what the "common ground" would be. I believe that without standardizing at least all of these things, broad and useful interoperability cannot be achieved:
> 
> - User identity is provided by an identity provider, which may be the "home" world of the user, or some other provider. Users should not need identity tied to the specific world they want to visit. Some worlds may choose to not accept certain specific credentials, just like certain real-world stores may not accept Candian dollars for payment. The market will work out a few major credential systems in the end (such as OpenID, perhaps). As long as each system is accessed uniformly, the specifics of the back end don't matter.
> 
> - Geometry is based on regular meshes, possibly with LOD switches and lower-resolution physics meshes/proxies/hulls. I understand that this may be a sticking point for the SL-derived worlds (or do they actually support arbitrary meshes as an option now? I haven't kept up.)
> 
> - Texturing is based on a regular Phong model with various defined texture maps (because HLSL vs GLSL vs some-other-SL are each of them not suitable on their own). Turns out, once you have the possibility of gloss maps, normal maps, emission maps, opacity maps, diffuse maps and ambient maps, you have 90% of the "look" of any one technology, which is about as good as you can hope for through interoperability.
> 
> - Telemetry (entity movement) needs to be sent on a position/orientation/velocity basis, with dead reckoning. Delta compression and lower update rates can be used to keep bandwidth usage in check. This is a big difference for OLIVE, because we are input-synchronous, similar to City of Heroes or Age of Empires. However, again, this is the common denominator and experience speaking.
> 
> - Animating objects need to use a common, widespread interchange format, using named animation clips and skeletal animation. Morph deformation is likely too big a payload to make sense, at least in the early stages. COLLADA is a good format for this, but there are other possibilities (FBX, X3D and X come to mind). I think that making at least one format required is a good idea, because that ensures a minimum level of interoperability is always present.
> 
> - Simulation and script execution for a given object needs to be done on the "home" system for that object, because objects may be constructed assuming wildly disparate execution environments (X3D with JavaScript; Prims with SL Script, C++ with XML, Java with JSR 184, etc).
> 
> - Objects need to be marked up with simple, well defined possible interactions, so that a user interface can be generated on each client based on those interactions. Interactions are typically "set this property to this value" or "execute this command." Such interactions need to be forwarded to the server that runs the object in question. Similarly, specific interactions ("emote animation," "collision," "damage," "two-party animation," "flight" etc) need to be defined.
> 
> - Non-time-critical requests should go over HTTP and/or HTTPS, using XML-RPC or a similarly well understood protocol.
> 
> - Time-critical and high-bandwidth data (such as entity telemetry and user inputs) should be sent using explicit (separate) schema, and binary representation, for the same reason that we don't send streaming video as XML, or mark each pixel with a color space identifier.
> 
> Sincerely,
> 
> Jon Watte
> Forterra Systems
> 
>

---

From: Christian Scholz <[email-masked]>
Date: Sun, 22 Feb 2009 17:00:05 +0100

Charles Krinke wrote:
> Well, what I "hope" we are really talking about is the beginnings of the
> 3D internet where we can expect to evolve from "flat web pages" to 3D
> interactive web communication.

But what I wouldn't want here is to exclude the web. For my identity I
would like to carry it over to any service be it 1D, 2D, 3D or 4D.

Also I think we should prevent the case where we end up with 2
incompatible ways of a federated identity, one for the web and one for VWs.

> If we do our job right, then we will eventually expect that any 3D
> client can expect to connect to any 3D server, negotiate a pre-described
> set of capabilities and services and act in an analagous fashion that a
> web browser does now.

And I would even put the web browser into the equation. I don't think
the web is dead, it's far away from being that.

For 3D related things of course it would be more useful to have only one
set of protocols defined like HTTP/HTML as you say. Right now (and I
guess this is Jon's point) it might be difficulty to ask everybody to
throw away their technologies and start from scratch with that new
protocol. Also for email it took some while before most of those
gateways were not needed anymore because it's all SMTP now.

-- Christian

> In order to get there, imagine that there were no HTTP or HTML, but
> rather a few groups that had defined similar but incompatible web page
> formats so that only their browser would read their web page.
> 
> In order to get to a common experience, it would be necessary for these
> groups to agree to a common standard so that the browsers could
> "interop" with each other.
> 
> So, be it wire protocol, or higher level interoperability issues, I
> think we all need to work to get past our current biases and find a way
> to define 3D interoperability so we can get past the "flat web" and
> evolve into the next part of the internet evolution.
> 
> Charles Krinke
> OpenSim Core Developer
> http://opensimulator.org <http://opensimulator.org/>
> OSGrid Director
> http://osgrid.org <http://osgrid.org/>
> 
> ------------------------------------------------------------------------
> *From:* Mark P. McCahill <[email-masked]>
> *To:* Jon Watte <[email-masked]>
> *Cc:* "[email-masked]" <[email-masked]>
> *Sent:* Sunday, February 22, 2009 5:14:50 AM
> *Subject:* Re: [mmox] I hate to be a kill joy here and, put the horse
> before the cart
> 
> least one format required is a good idea, because that ensures a minimum
> level of interoperability is always present.
>>
> on the "home" system for that object, because objects may be constructed
>> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Gareth Nelson <[email-masked]>
Date: Sun, 22 Feb 2009 16:29:47 +0000

You've just beautifully summarised a nice argument for standardised
client/server protocols......... so how do we convince providers to
take up a standardised client/server protocol?
I think we need to focus on something that can be added on to an
existing setup, and that does limit a lot of design decisions.

For example:
meshes only, or prims only?
meshes and prims?
How much conversion will a server have to do to implement a prim-only
protocol if it currently uses meshes?

I'm sure there's plenty of other examples, even simple stuff like the
256x256 regions in SL for example. But my basic point is that it may
be simpler to implement stuff that does not require massive internal
changes.

On Sun, Feb 22, 2009 at 3:34 PM, Charles Krinke <[email-masked]> wrote:
> Well, what I "hope" we are really talking about is the beginnings of the 3D
> internet where we can expect to evolve from "flat web pages" to 3D
> If we do our job right, then we will eventually expect that any 3D client
> can expect to connect to any 3D server, negotiate a pre-described set of
> capabilities and services and act in an analagous fashion that a web browser
> does now.
>
> In order to get there, imagine that there were no HTTP or HTML, but rather a
> few groups that had defined similar but incompatible web page formats so
> that only their browser would read their web page.
>
> groups to agree to a common standard so that the browsers could "interop"
> with each other.
>
> So, be it wire protocol, or higher level interoperability issues, I think we
> all need to work to get past our current biases and find a way to define 3D
> interoperability so we can get past the "flat web" and evolve into the next
> part of the internet evolution.
>
> Charles Krinke
> OpenSim Core Developer
> http://opensimulator.org
> OSGrid Director
> http://osgrid.org
>
>> perhaps). As long as each system is accessed uniformly, the specifics of the
>> back end don't matter.
>>
>> assuming wildly disparate execution environments (X3D with JavaScript; Prims
>> with SL Script, C++ with XML, Java with JSR 184, etc).
>>

---

From: Charles Krinke <[email-masked]>
Date: Sun, 22 Feb 2009 08:53:03 -0800 (PST)

Dear Gareth:

You have a very good point. I admit that I over simplified in the interests of trying to get us to focus a bit.

I believe that as a client (or 3D browser) were to attempt to connect to a 3D server, that are currently a series of packets exchanged, perhaps some would call them the login procedure of which we are familiar.

One could easily imagine that the login procedure (or perhaps the clientStack negotiation) would extend to include packets describing the clients capabilities and the server would reply with "+1" to those matching capabilities. Some clients may support prims, some meshes, some both. Some servers may support prims, meshes or both. 

A similar notion would exist for various script engines, physics plugins, graphics capabilities and the like.

So, I think that we can get there from here. I do know that there are groups, including my own, OpenSim working on multiple client support right now. So, to the extent we can find a consensus amongst ourselves, we can de-babelize our future a bit. We will not stop the future, as those who are creating are continuing regardless of what we say or do.

The best we can hope for is to have a minimum of the "Tower of Babel" effect and a maximum of interoperability.

Charles

________________________________
From: Gareth Nelson <[email-masked]>
To: Charles Krinke <[email-masked]>
Cc: Mark P. McCahill <[email-masked]>; Jon Watte <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Sunday, February 22, 2009 8:29:47 AM
Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the  cart

For example:

---

From: Gareth Nelson <[email-masked]>
Date: Sun, 22 Feb 2009 17:14:23 +0000

I can tell you're an opensim dev - clientstak eh?
Anyway, I believe there are 2 basic approaches to the "tower of babel"
problem for client<>server traffic:
1 - new protocol support on the servers
2 - proxies that do dynamic conversion

What we should aim for is to specifiy the common denominator protocol
that all these proxies can convert to and from. The capabilities
should be part of the login procedure, and essentially are already
partly there in the SL-compatible worlds.

On Sun, Feb 22, 2009 at 4:53 PM, Charles Krinke <[email-masked]> wrote:
> I believe that as a client (or 3D browser) were to attempt to connect to a
> 3D server, that are currently a series of packets exchanged, perhaps some
> would call them the login procedure of which we are familiar.
>
> One could easily imagine that the login procedure (or perhaps the
> clientStack negotiation) would extend to include packets describing the
> clients capabilities and the server would reply with "+1" to those matching
> capabilities. Some clients may support prims, some meshes, some both. Some
> servers may support prims, meshes or both.
>
> So, I think that we can get there from here. I do know that there are
> groups, including my own, OpenSim working on multiple client support right
> now. So, to the extent we can find a consensus amongst ourselves, we can
> de-babelize our future a bit. We will not stop the future, as those who are
> creating are continuing regardless of what we say or do.
>
>> 3D
>>> without
>>> texture
>>> compression
>>> (FBX,
>>> Prims
>>> based
>>> user

---

From: Charles Krinke <[email-masked]>
Date: Sun, 22 Feb 2009 09:18:39 -0800 (PST)

+1

Sent: Sunday, February 22, 2009 9:14:23 AM

---

From: Christian Scholz <[email-masked]>
Date: Sun, 22 Feb 2009 18:56:11 +0100

Charles Krinke wrote:
> Dear Gareth:
> 
> You have a very good point. I admit that I over simplified in the
> interests of trying to get us to focus a bit.
> 
> I believe that as a client (or 3D browser) were to attempt to connect to
> a 3D server, that are currently a series of packets exchanged, perhaps
> some would call them the login procedure of which we are familiar.
> 
> clients capabilities and the server would reply with "+1" to those
> matching capabilities. Some clients may support prims, some meshes, some
> both. Some servers may support prims, meshes or both.

That's what I was thinking the service discovery could be used for.
You just check the server's service catalogue for formats/APIs you
support. These might even contain priorities so that you know which ones
are the preferred method. This discovery can span various areas.

Still some MMOX spec should probably define a set of preferred or even
required formats because otherwise we won't get interop anytime soon.

-- Christian

---

From: Gareth Nelson <[email-masked]>
Date: Sun, 22 Feb 2009 18:04:31 +0000

So, now we're back to square 1.
A few thoughts:
Do we do the whole agent/region domain split a la OGP?

If so, then the agent domain can serve up the authentication and
identity stuff, while region domain serves up standard caps
for........ what?

I propose HTTP for assets, with a standard base URL for each region
domain and agent domain, and a basic description of the avatar as
first step in defining the real "meat" of the 3D stuff.

---

From: "Mark P. McCahill" <[email-masked]>
Date: Sun, 22 Feb 2009 13:30:41 -0500

> strange to refer to some VW specific standard).

I think it fits into this working group in a couple ways.

For interoperability across multiple worlds and identity systems, we  
need to
describe how clients and servers negotiate which forms of credentials  
are
acceptable to establish an identity. You cannot do very much in a social
space before an identity has been established for the avatar.

If we accept the idea of federated identity, avatar names as used in
current practice need to change. They would need to include the party  
that
issued the identity - something like this: [email-masked] 
  or
[email-masked].

I agree that this overlaps many of the social networks and other  
internet services.
That is another reason that working on the identity and presence  
problems
now appeals to me - it would have a very large payoff in terms of  
cross-system
interoperability, and could be fairly easy to add to existing services  
and virtual
worlds.

>>> the
>>> and
>>> maps
>>> the
>>> done
>>> with
>>> client
>>> and

---

From: Jon Watte <[email-masked]>
Date: Sun, 22 Feb 2009 11:02:48 -0800

Charles Krinke wrote:
> client can expect to connect to any 3D server, negotiate a 
> pre-described set of capabilities and services and act in an analagous 
> fashion that a web browser does now.
>

I think this is a mistake. Interactive content is very different from 
web content. Consider, instead, e-mail -- An Outlook client cannot 
connect to a Lotus SameTime server, but the Outlook client can send 
messages to a Lotus SameTime client through interoperability between the 
mail servers.

The difference is in interactivity. Interactivity changes the game. 
Interactivity requires constantly running code, which is very different 
from a web server/browser system. Something that gets a little closer to 
that model is Web 2.0, but I think it's still a halting comparison. If 
you want to be able to "connect to any server from any client," then you 
could do that today. Define the client as being Internet Explorer with 
ActiveX controls, and define the server to be Apache, and you're done. 
*We can do that today*. However, nobody is doing it, because it doesn't 
actually provide any additional value.

I believe it's crucially important that interoperability provides 
additional value to users -- it lets users do important new things that 
they cannot conceivably do using the existing paradigm. "Connecting to 
another server" falls very low on that scale.

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Sun, 22 Feb 2009 11:06:21 -0800

> first step in defining the real "meat" of the 3D stuff.

Why is an avatar special?

In fact, I find the idea of putting "rezzing" avatars into OGP very 
second life centric. Bringing an avatar to life is a function internal 
to the virtual world service provider, not something that needs to, 
itself, be interoperable. The question is: how and when does that avatar 
get presented to other systems?

Btw: what does "rezzing" stand for? "Ressurecting"? In general object 
parlance, I think "instantiating" would be better, perhaps.

Sincerely,

jw

---

From: Gareth Nelson <[email-masked]>
Date: Sun, 22 Feb 2009 19:09:35 +0000

Well, we need a description of the avatar itself, or what do we show
to other systems?
Note I didn't mention rezzing an avatar :)

On Sun, Feb 22, 2009 at 7:06 PM, Jon Watte <[email-masked]> wrote:
> In fact, I find the idea of putting "rezzing" avatars into OGP very second
> life centric. Bringing an avatar to life is a function internal to the
> virtual world service provider, not something that needs to, itself, be
> interoperable. The question is: how and when does that avatar get presented
> to other systems?
>

---

From: Gareth Nelson <[email-masked]>
Date: Sun, 22 Feb 2009 19:13:42 +0000

> I think this is a mistake. Interactive content is very different from web
> content. Consider, instead, e-mail -- An Outlook client cannot connect to a
> Lotus SameTime server, but the Outlook client can send messages to a Lotus
> SameTime client through interoperability between the mail servers.
I can take my SMTP and POP3 compatible mail client to any ISP, some
ISPs might offer extra value (spam filtering, webmail, mailing lists,
etc), but the basics are the same.

> Interactivity requires constantly running code, which is very different from
> a web server/browser system. Something that gets a little closer to that
> model is Web 2.0, but I think it's still a halting comparison. If you want
> to be able to "connect to any server from any client," then you could do
> that today. Define the client as being Internet Explorer with ActiveX
> controls, and define the server to be Apache, and you're done. *We can do
> that today*. However, nobody is doing it, because it doesn't actually
> provide any additional value.
Any web browser that supports HTTP and HTML can connect to any httpd.
Everyone does this today :)
The additional value is obvious - any device which implements these 2
standards can be a web browser or a web server. I can browse on my PC
running GNU/Linux or my Sony PSP. I can even post to forums with both
these devices and let windows 98 users read my posts.

> I believe it's crucially important that interoperability provides additional
> value to users -- it lets users do important new things that they cannot
> conceivably do using the existing paradigm. "Connecting to another server"
> falls very low on that scale.
Look at developing the standard protocol as being the enabler, a means
to the end, rather than an end in itself

---

From: Jon Watte <[email-masked]>
Date: Sun, 22 Feb 2009 12:09:53 -0800

Mark P. McCahill wrote:
> issued the identity - something like this: 
> [email-masked] or
> [email-masked].

I agree. I do think there may be a difference between "identity" and 
"presentation" though.

In general, the "label" put over an avatar is "presentation" and might 
be something simple like "jwatte" (my Forterra internal avatar name), or 
something elaborate like "The Guy Your Mother Warned You About." 
Meanwhile, each system would generally have to provide a way to 
query/display the underlying identity of that avatar/presence. Some 
systems may even choose to not use the "presentation" aspect at all, 
choosing to always display the underlying identity.

When it comes to identity, I feel that the following things are needed:

1) Some standard way to identify the identity provider for a given entity.
2) Some token issued by that provider that represents the identity.
3) Some standardized way to contact the identity provider to verify 
identity (detect impersonation.)

Specifically, if your avatar /claims/ to be "mrpresident" with the 
identity provider "whitehouse.gov," then there needs to be a way for me 
to verify that that's actually true, that probably involves contacting 
the whitehouse.gov identity provider, again using some standard 
protocol. Then, in the end, my trust for that entity will be based on my 
trust for the identity provider.

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Sun, 22 Feb 2009 12:16:46 -0800

> these devices and let windows 98 users read my posts.

Why is the value of a standardized virtual world client protocol 
obvious? Why would a protocol separate from HTTP and ActiveX (or Mozilla 
plug-ins) add any value compared to what can be done today?

A protocol is great when it enables additional applications -- when you 
can actually do things when using the protocol, that you couldn't do 
when you didn't have the protocol. The value of the protocol is directly 
proportional to the things you can do with it, that you couldn't do 
without it.

Connecting a given client machine to more than one world is something 
that could be done today, using HTTP and regular web browsers. Adding a 
protocol that is specific to some stand-alone program that's not a web 
browser adds nothing new. We don't need a new protocol for that, because 
we already have HTTP and browser plug-ins.

Meanwhile, connecting different simulation domains so that they can each 
provide to the same user-visible simulation is something new, that 
provides a lot of value. It allows interactive objects developed from 
one system to be presented to and affect simulations in another system, 
without the systems having to agree on things like physics engines, 
scripting languages, or any other implementation details -- only 
presentation.

Sincerely,

jw

---

From: Gareth Nelson <[email-masked]>
Date: Sun, 22 Feb 2009 20:24:57 +0000

The value is that it turns the "3D web" into a commodity just like the 2D web is

On Sun, Feb 22, 2009 at 8:16 PM, Jon Watte <[email-masked]> wrote:
> Why is the value of a standardized virtual world client protocol obvious?
> Why would a protocol separate from HTTP and ActiveX (or Mozilla plug-ins)
> add any value compared to what can be done today?
>
> A protocol is great when it enables additional applications -- when you can
> actually do things when using the protocol, that you couldn't do when you
> didn't have the protocol. The value of the protocol is directly proportional
> to the things you can do with it, that you couldn't do without it.
>
> Connecting a given client machine to more than one world is something that
> could be done today, using HTTP and regular web browsers. Adding a protocol
> that is specific to some stand-alone program that's not a web browser adds
> nothing new. We don't need a new protocol for that, because we already have
> HTTP and browser plug-ins.
>
> provide to the same user-visible simulation is something new, that provides
> a lot of value. It allows interactive objects developed from one system to
> be presented to and affect simulations in another system, without the
> systems having to agree on things like physics engines, scripting languages,
> or any other implementation details -- only presentation.
>
> Sincerely,
>
> jw
>
>

---

From: Jon Watte <[email-masked]>
Date: Sun, 22 Feb 2009 12:50:40 -0800

> The value is that it turns the "3D web" into a commodity just like the 2D web is

How is it doing this differently from already being able to view 3D 
content in a web browser?
To the user, what is the difference in capabilities?

Sincerely,

jw

---

From: Gareth Nelson <[email-masked]>
Date: Sun, 22 Feb 2009 21:32:51 +0000

This is turning into a "what can we do in virtual worlds that can't be
done with web browsers?", to which i'll respond "nothing, since we can
put virtual worlds into browsers", but that's irrelevant essentially.
Proof that plugins can do anything:
http://www.flickr.com/photos/gwengareth/2914357868/
http://www.flickr.com/photos/gwengareth/2828674099/
http://www.flickr.com/photos/gwengareth/2829338568/in/photostream/

But of course, my point was that these plugins still need the standard
protocols, the above example is just SL in a browser for example.

On Sun, Feb 22, 2009 at 8:50 PM, Jon Watte <[email-masked]> wrote:
> How is it doing this differently from already being able to view 3D content
> in a web browser?

---

From: Jon Watte <[email-masked]>
Date: Sun, 22 Feb 2009 14:35:19 -0800

> put virtual worlds into browsers", but that's irrelevant essentially.

That's not actually true, because there are things you can do with a 
virtual world interoperability protocol used between server peers, that 
you can't do in a browser-only world. That server peer system is what 
I'm hoping to accomplish here. Anything that is client-only is unlikely 
to provide much added value, and unlikely to be adopted by most of the 
various vendors in the market, for reasons I've already discussed at 
length on this list. Given the lack of added value in client 
standardization work for virtual worlds, I view work on that as wasted 
effort.

> protocols, the above example is just SL in a browser for example.

They don't need any new standard protocols, because you already have a 
standard execution environment (the browser, with a DOM, JavaScript, and 
a plug-in model), and the standard transport (using HTTP). For anything 
"additional" they can use a custom protocol; there is no need to 
standardize there. To the user, any browser-based VWs will already 
appear "standard" because the user can use the browser to surf from one 
to the other. However, that just doesn't add much value -- as evidenced 
by most systems not actually doing that.

Sincerely,

jw

---

From: Gareth Nelson <[email-masked]>
Date: Mon, 23 Feb 2009 01:09:19 +0000

On Sun, Feb 22, 2009 at 10:35 PM, Jon Watte <[email-masked]> wrote:
> That's not actually true, because there are things you can do with a virtual
> world interoperability protocol used between server peers, that you can't do
> in a browser-only world. That server peer system is what I'm hoping to
> accomplish here. Anything that is client-only is unlikely to provide much
> added value, and unlikely to be adopted by most of the various vendors in
> the market, for reasons I've already discussed at length on this list. Given
> the lack of added value in client standardization work for virtual worlds, I
> view work on that as wasted effort.

My point was that "browser-only" still really involves "browser with
plugins". But going off into web browser plugins is not of relevance
to the question of a standardised client/server protocol. What "value"
does it add to email to have multiple email clients and servers, what
value does it add to IRC to have different IRC clients?
I can answer that one easily:
Bots, automated scripts, different UIs, different platforms

> standard execution environment (the browser, with a DOM, JavaScript, and a
> plug-in model), and the standard transport (using HTTP). For anything
> "additional" they can use a custom protocol; there is no need to standardize
> there. To the user, any browser-based VWs will already appear "standard"
> because the user can use the browser to surf from one to the other. However,
> that just doesn't add much value -- as evidenced by most systems not
> actually doing that.

But they can't go from one to the other using the same UI - the UI is
defined in the HTML and can't be altered most of the time. Nor can
things be automated or easily ported to other platforms where plugins
are required.

To make this even more clear, I often alternate between irssi and
ksirc for using IRC, while connecting to freenode, efnet and my own
network. This is impossible to do with virtual worlds unless they
support one standard protocol for client interaction.

Hence where the value for client<>server standard protocols comes.

---

From: Jon Watte <[email-masked]>
Date: Sun, 22 Feb 2009 20:14:31 -0800

> Hence where the value for client<>server standard protocols comes.

Well, you'd better buy stock in Multiverse, then, because that's exactly 
their approach to the world. Define one client protocol, and let 
developers build whatever they want on the back end.

Personally, I believe that the case of interactive simulation actually 
makes it a different animal entirely from a web browser. I don't think 
you can define a common client protocol, unless you define:

- a common simulation language
- a common simulation API
- a common world semantic
- a common scene graph (good luck on that :-)
- a common user interface language
- a common distribution model

You should know that VRML actually attempted to specify all that back in 
1995 -- it actually solves that particular problem(!). There's a modern 
version of it called X3D, which has been updated since 1995. However, 
most people don't care, because that's not the important problems to 
solve, according to the market.

The applications deployed today have very different approaches to these 
rather heavy-weight areas, for good reason: they serve different 
customers. Trying to unify them all is unlikely to be realistic anytime 
soon. If you think they should be, you should be arguing for VRML/X3D, 
because it's an existing W3C standard that does just that!

Sincerely,

jw

---

From: Lawson English <[email-masked]>
Date: Sun, 22 Feb 2009 21:54:04 -0700

Jon Watte wrote:
> Well, you'd better buy stock in Multiverse, then, because that's 
> exactly their approach to the world. Define one client protocol, and 
> let developers build whatever they want on the back end.
>
> You should know that VRML actually attempted to specify all that back 
> in 1995 -- it actually solves that particular problem(!). There's a 
> modern version of it called X3D, which has been updated since 1995. 
> However, most people don't care, because that's not the important 
> problems to solve, according to the market.
>
> The applications deployed today have very different approaches to 
> these rather heavy-weight areas, for good reason: they serve different 
> customers. Trying to unify them all is unlikely to be realistic 
> anytime soon. If you think they should be, you should be arguing for 
> VRML/X3D, because it's an existing W3C standard that does just that!
>
> Sincerely,

Ah, but does it do prims?

L

---

From: Jesrad <[email-masked]>
Date: Mon, 23 Feb 2009 12:55:49 +0100

I tend to consider avatars as objects just like the others, except
they are capable of a specific form of interaction that is similar
(and should be identical) to vehicles. Given a uniform RPC avatars
could be scripted objects indistinguishable from the rest of the VW
environment. Compare this view with the existence of "bots" in SL,
where a viewer is coded to run without user input, or the client-side
scripts that grind your WoW character without supervision, or a few
hundred other examples.

That's why I see no reason to distinguish between the two categories
at the level of the MMOX-layer.

---

From: Gareth Nelson <[email-masked]>
Date: Mon, 23 Feb 2009 11:59:29 +0000

Well, the "we need to describe it so we need to know how to display it
in other worlds" applies to all objects really

---

From: Lawson English <[email-masked]>
Date: Mon, 23 Feb 2009 05:01:38 -0700

They're special because they encapsulate personal identity.  One 
proposal for the Agent Domain is to allow a separate scripting server to 
feed commands to the simulator separately for avatar attachments, which 
would allow avatars to "take it with them" as far as scripted appearance 
goes (assuming the destination sim is compatible with the scripted 
attachments in the first place) without violating copyright on 
non-Creative Commons scripts.

L

---

From: Gareth Nelson <[email-masked]>
Date: Mon, 23 Feb 2009 12:08:23 +0000

About the only relevance personal identity has is that people will get
annoyed if it's altered too much when rendered elsewhere :)

On Mon, Feb 23, 2009 at 12:01 PM, Lawson English <[email-masked]> wrote:
> They're special because they encapsulate personal identity.  One proposal
> for the Agent Domain is to allow a separate scripting server to feed
> commands to the simulator separately for avatar attachments, which would
> allow avatars to "take it with them" as far as scripted appearance goes
> (assuming the destination sim is compatible with the scripted attachments in
> the first place) without violating copyright on non-Creative Commons
> scripts.
>
>
> L
>
>
> Jesrad wrote:
>>
>>>> second

---

From: Lawson English <[email-masked]>
Date: Mon, 23 Feb 2009 05:39:26 -0700

Which is why they might need to be treated differently.

L

---

From: Jesrad <[email-masked]>
Date: Mon, 23 Feb 2009 14:13:00 +0100

Actually, the capacity to encapsulate identity itself does not seem to
mandate an entire different categorization, IMHO. Player/resident
identity only requires to be tied to a specific inworld viewpoint and
physical location, not a specific kind of objects, as is exemplified
by all the vehicles/mounts in VWs, which take over those
characteristics from the "avatar" object, dynamically. What I see is
that an object may be made capable of holding those characteristics by
being a vehicle (and in some cases, by also being capable of playing
the default animations by having a standard skeleton). Just because
some VWs restrict this dynamic capacity to a special class of objects
in their implementation, does not mean all VWs should. MMOX protocol
shouldn't be constrained by this sort of implementation decision.

I think there's ground for a uniform access method here, seeing as how
there are only so many user input diversity for avatar control across
existing VWs.

---

From: Kajikawa Jeremy <[email-masked]>
Date: Mon, 23 Feb 2009 22:18:22 +0900

Im inclined to agree with the "AV" itself not having any special case at
all
  other than being a "focus" object selected by the user...

My own "Virtual Worlds" vision would allow anything beyond the initial
"viewpoint"
  to be an editable object that has "movement" emulation and triggers
attached.

that the GW client or SL client or <another VW> client treats this as
"special"
  because it is the 3D equivalent to a mouse point ?

Give me a break,  the only "special" property it has is being a "focus"
object
  the same as the mouse you move for using
Linux/Windows/Mac/...etc...all

How is that special?,  it is a focus,  can you change the whole mouse
image? yes
  can you animate it? again yes,  does it respond to input?  no,  its a
drawn item,
  which has its "location" data updated by user input.

There is no need for anything "special" other than some means of
updating an
  objects "motion" to allow simulation of changes...  walking or other
complex
  actions would need to be a set of update events.

What is simpler than selecting an existing or making use of a "focus"
object?

Sincerely,
  Jeremy/Belxjander

---

From: Jesrad <[email-masked]>
Date: Mon, 23 Feb 2009 14:43:22 +0100

>  to be an editable object that has "movement" emulation and triggers

I have the same reason to suggest this... which makes it a case where
being knowledgeable of "The Second Life Way" pushes people to NOT
bless it into a standard ;)

> There is no need for anything "special" other than some means of updating an objects
> "motion" to allow simulation of changes...  walking or other complex actions would
> need to be a set of update events.

Well, I can think of one thing special with this focus, it's that it
determines the visibility volume for the client/endpoint, and
therefore determines a number of things like the breadth of content it
has to fetch in order to build the renderview. But this is probably
better tuck into the Agent domain than built into a special kind of
object class.

---

From: Kajikawa Jeremy <[email-masked]>
Date: Mon, 23 Feb 2009 14:08:15 +0000

What is an Object?
What is an AV? (focus object?)

What part of the system produces the displayable render?
  does each user get a choice for render quality?

are we defining a generic 3D system or a mechanism of
  standardizing agreements using existing data-formats?

some kind of serialization mechanism to allow for a "focus object"
 to be transferred or otherwise re-created specific to a new system?

does anyone have a document listing any of the agreements going forward?
does anyone have a document listing the *disagreements* and concepts
  people have put forward?

Why do people see Identity and the Avatar as the same thing?

the "Avatar" or Focus Object is entirely a representation or "face" to
the Identity,
  where the Identity is not the AV from my understanding...

additionally I will be typing up a draft document for peer review here
and hope to see
  less squabbling dragged in from other MLs to this group...

Sincerely,
  Jeremy