Subject: [mmox] Requirements for new xxSD specification

From: Catherine Pfeffer <[email-masked]>
Date: Tue, 24 Feb 2009 16:29:43 +0100

Infinity wrote:
> so my response would be:
>        1.a. can we look at the effect before making this change? my
> suspicion is that message sizes will be much more affected by turning
> on compressed content encoding than with the change from one DTD to
> another.

Of course. Whatever we come up with, it must meet the following requirements
:
1 - be easy to validate with a schema or DTD
2 - be easy to parse and transform  with XSLT and XPath
3 - have low "angle bracket tax" price to pay
(and that should be expressed as a precise "bloat ratio" relative to the
binary serialization for the same set of data)
4 - be future-proof, i.e. allow for things that have been identified as
missing, like lack of alternative sizes for integers and floats, and lack of
unsigned.

I also have a detail question/concern about the current LLSD serialization.
What is the intention on how to serialize big amounts of data, like an
avatar mesh or a PNG picture? Are they supposed to go into a big
<binary>...</binary> blob? Because, if that is true, the binary data encoded
so will have to be base64-encoded inside of the <binary> tags, and that's a
point that might make the whole XML serialization almost unusable, because
the angle bracket tax would probably become unacceptable in typical data
exchanges.

-- 
Cathy

---

From: David W Levine <[email-masked]>
Date: Tue, 24 Feb 2009 11:04:45 -0500

After chewing through the entire mailing list the past week, I've banged 
out something which *might* help structure our discussions a bit. I offer 
the following as an attempt to distill and focus some of our thinking.  We 
are roughly 4 weeks from a face to face, and while i do not expect a 
charter to emerge directly from that BOF, I think we need to end the face 
to face with enough of an agreed broad framework, that we can imagine 
generating a consensus charter on the mailing list prior to the next IETF 
face to face in July. 

I am posting this as a complete document. I am looking for broad consensus 
and proposed revisions, and will take them and spin back subsequent 
versions on a hopefully daily turn around. I don't expect the document to 
survive close to unchanged, but I'd like to try and manage it as a series 
of successive drafts, so we can have something consistent to talk about. I 
look at this as "If we can get rough consensus on this" then we can use it 
as a basis for driving forward on a set of charter level tasks. 

I am attaching the input as a .txt and a (sigh) Microsoft  word document. 
I am also posting it in line as plan text. (tho ugly, I'll work on that 
for future versions)
There has been a fair bit of discussion on the MMOX mailing list, and in 
casual 
discussions about what we are actually trying to achieve. In service of a 
better answer, I 
am going to try and summarize:

1.      The problem space we are tackling
2.      An Enumeration of interoperability goals in the problem space
3.      Some approaches to solving these goals
4.      How to both make concrete progress within the IETF approach and 
end up with a 
                solution that people will actually want to adopt. 
5.      Some things which fall out of scope 

I will try to cast both the problems and solutions separately from any 
specific virtual 
worlds or MMOS and instead draw on several underlying models as I describe 
things. 
Please view this as a strawman intended to provoke discussion, but also 
think of it as 
intended to evolve into something we can actually use to structure our 
work going 
forward. 
v
I am taking as a given that we are all professionals, engaged in a 
respectful, and 
thoughtful exercise to generate good engineering solutions. I welcome 
engaged, 
constructive, on topic discussion. Please read the IETF NOTEWELL notice: 
http://www.ietf.org/NOTEWELL.html  Our goal, is a code driven, process, 
anchored in 
the ability to prove that specifications we create actually interoperate 
and work as 
described.  Specifications do not advance in the IETF in the absence of 
demonstrated 
interoperability based on running code. 

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

------------------------------------------- 

The Problem Space:

I take MMOX as Massively MultiParty Online eXperiences (Since Meadbh 
didn't define 
X, we all get a shot at it) Lets take this one bit at a time. Massively, 
as in experiences 
intended to be shared by tens, hundreds, thousands, and over time, a 
significant fraction 
of the interne community. Online, focusing our attention on the concurrent 
shared portion 
of the experiences and eXperience as a shorthand for (Games, Applications 
and shared 
experiences.) 

The group's name and remit is intentionally broad, focused on a general 
set of Games and 
Applications, not any single game, application or experience.  The group's 
roots, and 
interests are largely, but not exclusively shaped by Virtual Worlds, 
including MMO 
games, Virtual worlds, Collaboration and Simulation Environments and 
shared online 
streaming environments. Examples of these platforms include, but are not 
limited to 
World Of Warcaft, ProtonSphere, Eve Online, Forterra's  OLIVE platform, 
Club 
Penguin,  Linden Lab's Second Life,  IMVU, There.com, Croquet, 
OpenSimulator.org, 
Weblins. 

The common thread across all of these environments is a concurrent shared 
experience, 
often, but not exclusively rendered in a three dimensional space.  Here's 
one attempt to 
scope what these environment share:

1.      One or more virtual spaces
2.      A set of users
3.      A representation of the users projected into the space
4.      A shared experience of the events in the space projected back to 
all the users 
                currently in the space. (Text, Voice, and the results of 
actions) 

Many of these environments will also include one or more of:

5.      Objects which can be dynamically created and modified to form part 
of the 
                space's setting
6.      Persistent state in the virtual space(s)
7.      Mechanisms to associate external streams of media with portions of 
the 
                immersive space 
8.      Mechanisms to run scripted behaviors in the space
9.      Simulated physics and behavior of objects and projected users in 
the spaace
10.     Mechanisms for users to  move from one virtual space to another 
(by hand off 
                between regions implicitly, or by explicit user request 
(teleport) 
11.     Libraries of material the users can add to the space
12.     Mechanisms for users which are not in a common virtual space to 
interact with 
                each other in some form (be aware of each other's 
locations and online status, 
                message each other, etc) 

Note I've very carefully avoided using most of the common words for the 
shared 
experience. We often speak of Simulators, Avatars, Regions, Assets and so 
forth, for the 
moment, I'm going to keep those terms off the table to think about the 
problem in its 
more general form. 

Note that I'm also very consciously taking a minimal base with optional 
features 
approach to describing the space. This allows us to focus on the core 
overlapping 
features, and then a set of services which add to this core. Think about 
how these goals 
and solutions could be applied to collaborative spaces such as Wikis, 
Micro blogging 
streams and collaborative desktop and application environments. 

Interoperability is not about defining the one true system which satisfies 
these goals. 
Interoperability is about making multiple existing implementation 
interoperate by the use 
of standards we define. 
Goals: 

What sort of interoperability do we desire out of these spaces? 

I will start with some statements from the perspective of user experience, 
and then talk 
about the technical implications of these use cases. I will also start 
with the broadest, 
most expansive goals and then look at how to break these apart into a 
series of sub goals. 

These goals are structured with the intent of listing a range of 
experiences we hope to 
enable.  There sometimes seems to be a strong desire to think about the 
ultimate end 
state, where there is one uber-client, and every single virtual space 
implements every 
single capability in super grid spanning the world. I think that, its 
important to think of 
interoperability as happening over time, and in clusters of increasingly 
integrated services 
and spaces. Some low hanging fruit will come early. Some worlds, which are 
close in 
design will get deeper benefits sooner, others will only gradually become 
more tightly 
integrated. There are many important, useful, and desirable states between 
"nothing 
shares" and "Its one single model of everything."

Note: These goals are not use cases. Ideally, each goal will, over time, 
spawn a set of use 
cases to help define them, and  additionally some "cross goal" use cases 
will be generated 
which will show how multiple goals work together to provide valuable 
results. 

1.      The ability to manage one's identity when interacting in multiple 
MMOX spaces. 
        a.      Allowing presence information to be shared and coordinated 
across 
MMOX spaces
        b.      Permitting friends lists, and IMs to be shared across 
spaces
        c.      Permitting MMOX spaces to share naming 
        d.      Simple ways of allowing a consistent name, managed by the 
user, and 
                verifiable by other users
        e.      Single sign on, mediated by multiple spaces, within the 
policy constraints 
                of the spaces
        f.      A consistent appearance, within the constraints of the 
various systems
        g.      The ability to manage the degree of visibility / coupling 
between identities 
        in MMOX spaces

 Note that for all of these, there is no requirement to couple the systems 
together 
beyond managing identity, and share presence and IM information. These use 

cases don't speak to how you move between spaces. You may have to shutdown 

your client on one system and start another. This also is not a "You must 
enable 
this" this is very much a "Make it easy for spaces which want to enable 
this to do 
it." Also, note that "presence and messaging" speak to user needs, and 
consitent 
appearance and name (when desired by users) again speeks to meeting user's 

desires. 

2.      The ability for the services in an MMOX world to be named, and 
authenticated
        a.      Services to associate virtual places and the services 
which support them 
        with authentication and administrative domains
        b.      Services to permit a service to validate the membership of 
a remote 
        service in one or more authentication and administrative domains

This is needed so that we can do essentially any of the interoperability 
work. 
Without some framework which lets us know who we are talking to, it is 
impossible to trust the behavior of distributed systems. 

3.      The ability to share content between MMOX spaces
        a.      Import and Export of content and models (This may well 
leverage off of 
        existing work such as Collada) Static, import/export of content 
while not 
        terribly dramatic is an important part of the value chain of 
interoperability
        b.      Mark up schemes which recognize the existence of multiple 
presentation 
        environments, but permit the sharing of content
                i.      Shared "type" information for the various types of 
graphical 
                        content which MMOX spaces contain
                ii.     Extensible, with a common registry, so that we can 
understand the 
                        types of contents a client can accept, and a 
virtual space, or virtual 
                        asset store can be asked to provide
        c.      A MMOX based, system independent asset addressing scheme 
which includes
                i.      Content negotiation based on 2b
                ii.     Access Management based on (1) and (2)

This is, to my mind, the key mid term deliverable 

4.      The affordances in MMOX to permit the creation of micro-payment 
economies
        a.      Appropriate spots defined in MMOX protocols for cost 
information
        b.      Appropriate spots defined in MMOX protocols for reference 
to 
                micropayment systems

5.      The ability to share "non immersive streams" between spaces 
        a.      Markup to permit the consistent sharing of stream media 
such as voice, 
                and video, with shared start and synchronization 
information to permit 
                "parallel" events between MMOX space

6.      The ability to express Policy intent between MMOX services and 
virtual spaces
        a.      Places in reserved in the MOX protocols for expressing 
policy intent
        b.      One or more policy languages for expressing policy

The solution space:

Most of the deployed solutions partition the software problem into the 
following chunks.

1.      Some form of a client which permits a user to interact with the 
shared experience
2.      Virtual space servers which manage the state of a portion of 
virtual space
3.      A set of supporting services used by the virtual space servers 

Note that exactly how these three large chunks are assembled and the 
granular nature of 
the services can vary radically, even when serving very similar 
environments. Some 
environments push a large amount of rendering and management onto complex 
clients, 
others perform the bulk of rendering in the server portion of the 
deployment. Some 
implementations combine client and simulation into a single entity which 
does some 
simulation and some user presentation. Some distribute the simulation, 
some centralize it. 

The heart of most of the solutions is managing to accept and merge a 
stream of updates, 
and then distribute the merged updates back to users. This can happen at a 
range of 
granularities. The two ends of the spectrum, are, roughly, sending updates 
as a fully 
merged audio visual stream, which the client merely displays, and sending 
low level 
changes to a underlying mode, which the client uses to assemble a complete 
visual 
representation of the scene.  Variations include croquet and qwaq which 
use an 
underlying distributed object model to pass large amounts of updates, and 
approaches 
such as used by SecondLife and Protonsphere, where voice is managed in a 
separate 
service, with the merged state service merely letting the voice service 
know where the 
users are located. 

Closely related, are issues of representation and format of content. This 
takes several, 
separable forms. Import and Export of material to the core environment, 
and, more 
problematically, run time representations

Approach
Our overall approach should be web centric, and web services oriented. We 
can, and 
should think of sets of related services which can be composed as part of 
different 
solutions which will enable varying degrees of interoperability. We can, 
and should 
attempt to provide as web like an approach to function as possible. 
Content negotiation, 
separation of protocol from security, separation of interface from 
implementation and 
other techniques. 

Our goal is not to enshrine any single virtual world as the standard for 
all MMOX spaces, 
but rather create a flexible, extensible set of services which will allow 
us to grow larger 
and large overlapping sets of capabilities. My expectation is that we will 
see a lot of low 
hanging fruit in the area of identity, authentication, authorization and 
presence 
management (Where a user is, and allowing messaging to them across MMOX 
spaeces) 
and initially, we will find a lot of format and content area addressed by 
gateways, 
markup, and content negotiation. I see nothing wrong with having a URI 
which refers to 
"A pretty maple tree with fall colors" which provides a way to fetch the 
"Collada Style 
version" the "3dMax Mesh version" the "Linden Lab 1.2 sculpty spec 
version"  such that 
a virtual space can select, through content negotiation the one most 
useful to it. 

We get value, when we have consistent ways of referring to all the various 
forms of 
content, and we get more value when we have ways of using existing content 
negotiation 
to allow a web light selection of an appropriate form. It is equally 
possible to imagine 
negotiating between a client and a virtual space, the desired form of 
objects. There are 
some deep challenges lurking, such as when two different approaches have 
radically 
different 

What I would encourage us, as a mailing list to do, is look through the 
problem 
statement, and interoperability goals I've put together here. They are an 
attempt to 
capture the various sentiments in the ongoing discussion. I am sure I have 
missed points, 
and I am sure some people will disagree with some of the points I have 
made. 

I would ask people to look for "No, you missed X" and "Hey, I don't think 
Y" is true. I 
will attempt to capture all of those, and revise the document, until we 
think it represents 
something close to the general group consensus. (I am not looking for 100% 
consensus, 
but a "Yeah, this captures most of what we're trying to do." With that in 
hand, I would 
suggest we could then begin to enumerate the specific services and markups 
we need to 
support our goals, and begin to flesh out use cases to help us understand 
the goals and 
services. 

I do not expect this to yield a set of specs which Linden Lab, or OpenSim, 
Or any one 
virtual world vendor or project would implement whole. What I expect it to 
yield is a set 
of specs, which can be combined with existing projects and code bases to 
drive us 
towards a more interoperable future. 

Out of scope

I also want to begin to accumulate a short list of "No, this is out of 
scope" assertions

1.      We will provide all the affordances necessary to permit a broad 
range of 
interaction policies. Appropriate policies for various deployed solutions 
and 
future deployed solutions is out of scope, beyond providing us use cases 
which 
highlight specific affordances we may wish to consider
2.      Whether or not immersive multi-party spaces are useful and which 
specific 
capabilities are required is out of scope. We aspire to support a broad 
range of 
possible capabilities, and we respect that different organizations will 
have 
different perspectives on what is required. Our goal is to define broad, 
interoperable frameworks which will enable a range of deployments, not to 
define 
the one true model for this space
3.      Propose additional statements here

Closing comments

I don't think our collective goal can be to take any one existing spec or 
solution and 
simply declare it the basis for our work going forward. At the same time, 
we must base 
our work in actually running code, showing real interoperability. Our goal 
must be to 
build supersets of function, based on existing products and solutions 
which demonstrate 
real interoperability. 

The IETF favors working code and growing consensus over blank paper and 
blue sky 
efforts. This is based in a history of success and failure in the industry 
when it comes to 
building, promoting and succeeding at standards work. Work at the IETF is 
grounded in 
working code. 

One way forward is to focus on several clusters of work. One: a clear, 
broad framework, 
which forms the basis for long term broad interoperation. Two: Capturing 
the current set 
of incompatible and overlapping formats and protocols in use, so that we 
can create a 
extensible and shared catalog of artifacts for sharing. (eg. "Here is the 
canonical, 
extensible  list of graphic content types you might want to move on a MMOX 
transport" 
Three grow out  proposed solutions such as LLSD, OGP, and others, as they 
are 
contributed towards a common superset which can be used to as the basis 
for 
demonstrating concrete progress towards interop goals. Four, Identify 
places where we 
simply want to use existing work, such as OpenID, OAuth,  X.509  and 
create a shared 
profile for how we can use these protocols to further interoperability.

---

From: Jon Watte <[email-masked]>
Date: Tue, 24 Feb 2009 11:50:36 -0800

I like the depth of thinking you've put into this. If we can shift the 
overall discussion in this direction, I think that will be very fruitful.

David W Levine wrote:
> 1.        The ability to manage one's identity when interacting in 
> multiple MMOX spaces.

Note that Microsoft tried to do that with Microsoft Passport, for the 2D 
web, where it is a lot easier to do than the 3D web. They didn't 
succeed. It's not yet clear to me that you need an identity, as separate 
from your service provider. After all, if you change mail hosts, your 
e-mail address changes. Thus, I think it would be useful to specify what 
an identity looks like ("an email address is name @ host"), but trying 
to make it so that I can use "[email-masked]" when I sign up for 
HotMail doesn't seem feasible.

>        a.        Import and Export of content and models (This may 
> well leverage off of

Offline and online sharing are, I think, very different. For offline 
sharing, you want as rich a model as possible, and size isn't all that 
important. For online sharing, you want something that gives a 
representative visual, but there are a lot of things you don't need 
(such as built-in scripting, undo history, specific modifier stack 
parameters for your DCC, etc).
Also, for offline sharing, there are several official or de facto 
standards already in place, including AutoCad, COLLADA and X3D (which 
attempts to deliver on the "interactivity/scripting" part of a virtual 
world object).

>                ii.        Extensible, with a common registry, so that 
> we can understand the

I believe that if the standard is just an empty vessel, where different 
systems can put different content, then no true interoperability will 
have been achieved, because something like the Source Engine will put in 
Source Engine format data, and something like Club Penguin will put in 
Club Penguin format data. Yes, you can get the data, but that doesn't do 
you any good, because your system can't understand it. Thus, you get a 
lot of "Hey, I'm compliant with standard X!" without any real 
operability coming out of it. I am strongly for specifying a minimum set 
of content types that have to be supported, whatever they are. Ideally, 
that minimum set is something that maps well to existing content 
repositories, including all the AutoCad models of the world's cities and 
buildings, the Google Warehouse, and ESRI GIS data, for example.

> 4.        The affordances in MMOX to permit the creation of 
> micro-payment economies
>        b.        Appropriate spots defined in MMOX protocols for 
> reference to
>                micropayment systems
>

I'm not so sure this is in scope at all. If I want to do a transaction 
with a service provider, I expect that to be done through a web 
application. There are already fine web application standards. If any 
tie into micro-payments is needed, I think that only the capability to 
tie a web link to a command is necessary -- the fact that that 
link/command is a micro-transaction isn't even necessarily known to the 
VW system.

> 5.        The ability to share "non immersive streams" between spaces

Again, assuming we have a content description, that "ability" can be 
expressed as a simple URL link. In fact, a standard like X3D already 
supports that kind of sharing. I think a much more important problem to 
solve is the sharing of real-time data streams.

Also, there seems to be an implicit assumption that "one space" is 
served by "one system." I think that, long term, that will not actually 
scale. You won't put a simulation of 40,000 avatars on Times Square onto 
a single system. You simply must come up with a way to share the 
simulation of those avatars betwene separate systems. Thus, for both 
scalability, and interoperability reasons, I think that the ability for 
two separate hosts to "share responsibility" of an agreed virtual space 
is important. And, once you have that, each user of each of those 
systems can experience that shared space through the already existing 
infrastructure, without any particular user-side presentation standard 
being needed at all.

Sincerely,

jw

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 24 Feb 2009 13:44:04 -0800

On Tue, Feb 24, 2009 at 7:29 AM, Catherine Pfeffer
<[email-masked]>wrote:

> Of course. Whatever we come up with, it must meet the following
> requirements :

This is something we (in IETF) have found to be a *drawback* in an
extensible standard.  We've hesitated over even providing DTDs in some
cases, worried that implementors would validate incoming messages against
the DTD, and drop messages that didn't validate, even ones that had been
extended according to a new standard.

The example I have the most familiarity with is WebDAV.  In a response to a
query to get the properties of a file in WebDAV, you might see:

     <D:response xmlns:R="http://ns.example.com/boxschema/" xmlns:D="DAV:">
         <D:href>http://www.example.com/file</D:href>
         <D:propstat>
           <D:prop>
             <R:bigboxtype>Box type A</R:bigboxtype>
             <R:author><R:Name>J.J. Johnson</R:Name></R:author>
           </D:prop>
           <D:status>HTTP/1.1 200 OK</D:status>
         </D:propstat>
    </D:response>

The specification says that anything inside the 'response' element should be
ignored if not understood, but if the 'href' element is there it contains
the file address and if the 'propstat' element is there it contains a number
of properties with the same status.  ...etc... Any element inside the 'prop'
element is a property name and inside that element is the property value.

Thus, the list of XML elements you would see inside the 'prop' element can
change for any resource or at any time and the recipient still knows what it
means.

This is reasonably concise (for XML which is not saying much) and extensible
as long as recipients follow the rules of ignoring unknown elements in some
places and treating them as property names in other places.  However, it is
NOT amenable to using DTDs, XML Schema or any form of restrictive
validation.

Someday, somebody could come up with a new metalanguage that does a better
job of this for XML.  RelaxNG is a step in that direction.  Because of the
separation between XML and the various description or schema languages that
work for XML, an argument against or for a description or schema language is
not the same thing as an argument for or against XML.

Lisa

---

From: "Mark P. McCahill" <[email-masked]>
Date: Tue, 24 Feb 2009 18:17:51 -0500

+1

I really like the approach David is taking here. The first two items:

   * managing identity
   * naming and authenticating services in MMOX worlds

are prerequisites for getting anywhere with cross-system  
interoperability,
would benefit users of existing systems, and should be achievable in the
fairly near term. Understanding how to negotiate these services is the
place to start, rather than defining an abstract wire-level protocol, if
the intent is to bring something other than Second Life-like worlds into
the fold.

Mark McCahill

On Feb 24, 2009, at 11:04 AM, David W Levine wrote:
>        a.        Allowing presence information to be shared and  
> coordinated across
> MMOX spaces
>        b.        Permitting friends lists, and IMs to be shared  
> across spaces
>        d.        Simple ways of allowing a consistent name, managed  
> by the user, and
>        e.        Single sign on, mediated by multiple spaces, within  
> the policy constraints
>                of the spaces
>        f.        A consistent appearance, within the constraints of  
> the various systems
>        g.        The ability to manage the degree of visibility /  
> coupling between identities
>        in MMOX spaces
>
>  Note that for all of these, there is no requirement to couple the  
> systems together
> your client on one system and start another. This also is not a "You  
> must enable
> this" this is very much a "Make it easy for spaces which want to  
> enable this to do
> it." Also, note that "presence and messaging" speak to user needs,  
> and consitent
> 2.        The ability for the services in an MMOX world to be named,  
> and authenticated
>        a.        Services to associate virtual places and the  
> services which support them
>        b.        Services to permit a service to validate the  
> membership of a remote
> This is needed so that we can do essentially any of the  
> interoperability work.
>        existing work such as Collada) Static, import/export of  
> content while not
>        b.        Mark up schemes which recognize the existence of  
> multiple presentation
>                i.        Shared "type" information for the various  
> types of graphical
>                ii.        Extensible, with a common registry, so  
> that we can understand the
>        c.        A MMOX based, system independent asset addressing  
> scheme which includes
> 4.        The affordances in MMOX to permit the creation of micro- 
> payment economies
>        a.        Appropriate spots defined in MMOX protocols for  
> cost information
>        a.        Markup to permit the consistent sharing of stream  
> media such as voice,
> 6.        The ability to express Policy intent between MMOX services  
> and virtual spaces
>        a.        Places in reserved in the MOX protocols for  
> expressing policy intent
> Most of the deployed solutions partition the software problem into  
> the following chunks.
>
> 1.        Some form of a client which permits a user to interact  
> with the shared experience
> 2.        Virtual space servers which manage the state of a portion  
> of virtual space
> environments push a large amount of rendering and management onto  
> complex clients,
> implementations combine client and simulation into a single entity  
> which does some
> simulation and some user presentation. Some distribute the  
> simulation, some centralize it.
>
> and then distribute the merged updates back to users. This can  
> happen at a range of
> granularities. The two ends of the spectrum, are, roughly, sending  
> updates as a fully
> merged audio visual stream, which the client merely displays, and  
> sending low level
> changes to a underlying mode, which the client uses to assemble a  
> complete visual
> representation of the scene.  Variations include croquet and qwaq  
> which use an
> underlying distributed object model to pass large amounts of  
> updates, and approaches
> such as used by SecondLife and Protonsphere, where voice is managed  
> in a separate
> service, with the merged state service merely letting the voice  
> service know where the
> users are located.
>
> Closely related, are issues of representation and format of content.  
> This takes several,
> separable forms. Import and Export of material to the core  
> environment, and, more
> Our overall approach should be web centric, and web services  
> oriented. We can, and
> should think of sets of related services which can be composed as  
> part of different
> solutions which will enable varying degrees of interoperability. We  
> can, and should
> Our goal is not to enshrine any single virtual world as the standard  
> for all MMOX spaces,
> but rather create a flexible, extensible set of services which will  
> allow us to grow larger
> and large overlapping sets of capabilities. My expectation is that  
> we will see a lot of low
> hanging fruit in the area of identity, authentication, authorization  
> and presence
> management (Where a user is, and allowing messaging to them across  
> MMOX spaeces)
> and initially, we will find a lot of format and content area  
> addressed by gateways,
> markup, and content negotiation. I see nothing wrong with having a  
> URI which refers to
> "A pretty maple tree with fall colors" which provides a way to fetch  
> the "Collada Style
> We get value, when we have consistent ways of referring to all the  
> various forms of
> content, and we get more value when we have ways of using existing  
> content negotiation
> negotiating between a client and a virtual space, the desired form  
> of objects. There are
> some deep challenges lurking, such as when two different approaches  
> have radically
> different
>
> What I would encourage us, as a mailing list to do, is look through  
> the problem
> statement, and interoperability goals I've put together here. They  
> are an attempt to
> capture the various sentiments in the ongoing discussion. I am sure  
> I have missed points,
> and I am sure some people will disagree with some of the points I  
> have made.
>
> I would ask people to look for "No, you missed X" and "Hey, I don't  
> think Y" is true. I
> will attempt to capture all of those, and revise the document, until  
> we think it represents
> something close to the general group consensus. (I am not looking  
> for 100% consensus,
> but a "Yeah, this captures most of what we're trying to do." With  
> that in hand, I would
> suggest we could then begin to enumerate the specific services and  
> markups we need to
> support our goals, and begin to flesh out use cases to help us  
> understand the goals and
> services.
>
> I do not expect this to yield a set of specs which Linden Lab, or  
> OpenSim, Or any one
> virtual world vendor or project would implement whole. What I expect  
> it to yield is a set
> of specs, which can be combined with existing projects and code  
> bases to drive us
> I also want to begin to accumulate a short list of "No, this is out  
> of scope" assertions
>
> 1.        We will provide all the affordances necessary to permit a  
> broad range of
> interaction policies. Appropriate policies for various deployed  
> solutions and
> future deployed solutions is out of scope, beyond providing us use  
> cases which
> 2.        Whether or not immersive multi-party spaces are useful and  
> which specific
> capabilities are required is out of scope. We aspire to support a  
> broad range of
> possible capabilities, and we respect that different organizations  
> will have
> interoperable frameworks which will enable a range of deployments,  
> not to define
> I don't think our collective goal can be to take any one existing  
> spec or solution and
> simply declare it the basis for our work going forward. At the same  
> time, we must base
> our work in actually running code, showing real interoperability.  
> Our goal must be to
> build supersets of function, based on existing products and  
> solutions which demonstrate
> real interoperability.
>
> The IETF favors working code and growing consensus over blank paper  
> and blue sky
> efforts. This is based in a history of success and failure in the  
> industry when it comes to
> building, promoting and succeeding at standards work. Work at the  
> IETF is grounded in
> working code.
>
> One way forward is to focus on several clusters of work. One: a  
> clear, broad framework,
> which forms the basis for long term broad interoperation. Two:  
> Capturing the current set
> of incompatible and overlapping formats and protocols in use, so  
> that we can create a
> extensible and shared catalog of artifacts for sharing. (eg. "Here  
> is the canonical,
> extensible  list of graphic content types you might want to move on  
> a MMOX transport"
> Three grow out  proposed solutions such as LLSD, OGP, and others, as  
> they are
> contributed towards a common superset which can be used to as the  
> basis for
> demonstrating concrete progress towards interop goals. Four,  
> Identify places where we
> <Scope01C.txt><Scope01C.doc>
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox

---

From: Christian Scholz <[email-masked]>
Date: Wed, 25 Feb 2009 00:31:14 +0100

Mark P. McCahill schrieb:
> are prerequisites for getting anywhere with cross-system interoperability,

+1 and I would actually list:

  - defining an identity endpoint
  - service discovery to find services for this identity such as profile
    definition, friends list, inventory server, ...
  - distributed authorization

Then having a way defined for services to be found and authorized one 
could define the specifics of these services.

I would extend this beyond MMOX worlds though because there is huge 
interest in the web and social networking players as well.

So maybe a seperate working group which has not the focus so much just 
on virtual worlds for this part might make sense. But I have no idea 
about the IETF process anyway at this time and if and how this would be 
possible or wanted.

-- Christian

>>        d.        Simple ways of allowing a consistent name, managed by 
>> the user, and
>> 1.        Some form of a client which permits a user to interact with 
>> the shared experience
>> and then distribute the merged updates back to users. This can happen 
>> at a range of
>> underlying distributed object model to pass large amounts of updates, 
>> and approaches
>> such as used by SecondLife and Protonsphere, where voice is managed in 
>> a separate
>> Our overall approach should be web centric, and web services oriented. 
>> We can, and
>> should think of sets of related services which can be composed as part 
>> of different
>> and large overlapping sets of capabilities. My expectation is that we 
>> will see a lot of low
>> and initially, we will find a lot of format and content area addressed 
>> by gateways,
>> statement, and interoperability goals I've put together here. They are 
>> an attempt to
>> capture the various sentiments in the ongoing discussion. I am sure I 
>> have missed points,
>> something close to the general group consensus. (I am not looking for 
>> 100% consensus,
>> but a "Yeah, this captures most of what we're trying to do." With that 
>> in hand, I would
>> of specs, which can be combined with existing projects and code bases 
>> to drive us
>> interoperable frameworks which will enable a range of deployments, not 
>> to define
>> I don't think our collective goal can be to take any one existing spec 
>> or solution and
>> our work in actually running code, showing real interoperability. Our 
>> goal must be to
>> building, promoting and succeeding at standards work. Work at the IETF 
>> is grounded in
>> working code.
>>
>> of incompatible and overlapping formats and protocols in use, so that 
>> we can create a
>> extensible and shared catalog of artifacts for sharing. (eg. "Here is 
>> the canonical,
>> extensible  list of graphic content types you might want to move on a 
>> MMOX transport"

-- 
Christian Scholz
Blog: http://mrtopf.de/blog
Company: http://comlounge.net
Podcasts: http://datawithoutborders.net, http://openweb-podcast.de

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Tue, 24 Feb 2009 17:00:02 -0800

cool. lemme put on my linden hat and throw out my US$0.02...

in terms of identity, we have a strong preference for authenticating  
application to application. part of the reason we like this is we have  
a requirement that our HTTP traffic be able to flow over proxies (of  
both the SOCKSish variety and the squidish caching variety.) we are  
therefore paranoid that somewhere, somehow, transport layer  
authentication information would be "eaten" by a misconfigured or  
miscoded piece of required infrastructure. we understand that many  
people deploying VW applications may not have this requirement, but we  
kindly ask people to respect our requirements. but... just because we  
have defined an application-layer-endpoint to application-layer- 
endpoint authentication protocol does not mean we're going to try to  
ram it down everyone else's collective throats. OpenID, OAuth, PKIX  
client certs and even *shudder* gss-api all have a place in the world,  
and that place may include authenticating endpoints in virtual world  
interactions.

in terms of non-second-life-like systems... yes... some people may  
remember that Zero and I are both "smalltalk people" and have been  
working with squeak from the early days. i mention it only to  
contextualize the discussion with respect to croquet and some the  
related commercial ventures (like qwaq.) personally, i like croquet  
and have for a while. like any system it has it's benefits and its  
drawbacks, but more germane to this discussion, uses an interaction  
model that is slightly different than the one second life uses.  
however... there's a statement in the draft charter identifying the  
focus of this group as being "application layer wire protocols," and  
to the degree that this statement survives the WG formation process...  
i would hope we could define wire protocols that were independent  
enough of the interaction model to at least allow some reuse of the  
PDUs. if there was a way to make TObjects look like REST-like  
resources we might be able to go further and reuse some of the  
interaction model. (but i'm just offering it as a suggestion! i'm not  
saying croquet has to change to be more SL like before we'll play nice  
with you!) and who knows... maybe after detailed investigation of both  
system's interaction models, we could find a way to denote them both  
with the same representational system.

with respect to service discovery... the "SL mode" right now is to  
assume a list of services. ultimately this has got to change, and we  
know that. that was part of the motivation for the design behind OGP/ 
Auth. At the end of authentication, the client is in possession of a  
capability (protocol endpoint) from which it may request other  
capabilities (protocol endpoints) that address resources which may be  
accessed to request various services. all of the services CS mentions  
below could easily be implementable with this technique. i've heard  
from some quarters that capabilities give some people the willies and  
honestly... they gave me the willies too until i drank the kool-aide  
and started using BREW a couple years back. i would point out,  
however, that they've been in constant use with SL for over 5 years  
now and they tend to work quite well for us. ultimately, however,  
there are likely going to be some people who won't want to use them  
and sure... that's fine... what this means to me vis a vis protocol  
definition is we should separate the acquisition of a service endpoint  
from the service it enables. and this might be was CS was talking  
about below.

or it might have been about service versioning that came up from time  
to time in the PyOGP list. fwiw... we tend to be "chunky" in our  
service deployment, meaning we prefer to not operate several versions  
of related services simultaneously, but i'm sure we can come up with a  
way to create a versioning system in MMOX, and i warn people up front  
that enabling such functionality would likely be a tough sell at  
linden, but we wouldn't stand in the way of other virtual worlds  
operators / client developers wanted to add it to a spec we claim we  
want to adhere to. but just keep in mind we're likely to either  
strongly request the feature was optional or use it in such a way that  
our grid always looks like it only has a single version of each service.

merging social networking sites and virtual worlds sounds like a win,  
but i wonder if it's not a better idea for the two to develop  
separately and allow protocols in each area to reference each other.  
for example, OpenSocial is, as i understand it, currently implemented  
as a set of web-apis. i really like the idea of an opensocial app  
being able to "reach into the virtual world" and i like the idea of  
our virtual world supporting things like existing OpenSocial apps...  
let's just not make it a REQUIRED part of the protocol anytime soon.

so... to paraphrase... to the degree that linden can be the 800 lb.  
gorilla in a room where virtual worlds are being discussed and  
blizzard hasn't shown up... i promise to use my secret powers for  
good. the lab has no interest in scuttling anyone else's product  
roadmap but we ask that the more agile participants in this group give  
us a little slack with what we're able to implement and how fast.  
compared to the open sim peeps, we must seem like dinosaurs, and  
compared to tao, we're probably stromatolites. i just ask that peeps  
here please keep in mind we have an onerous repository of legacy code  
and a large installed base we can't abandon, so there's a reason we're  
moving slower than people might like.

-cheers
-meadhbh

On Feb 24, 2009, at 3:31 PM, Christian Scholz wrote:

> Then having a way defined for services to be found and authorized  
> one could define the specifics of these services.
>
> So maybe a seperate working group which has not the focus so much  
> just on virtual worlds for this part might make sense. But I have no  
> idea about the IETF process anyway at this time and if and how this  
> would be possible or wanted.
>
> -- Christian
>
>
>> Mark McCahill
>>>       e.        Single sign on, mediated by multiple spaces,  
>>> within the policy constraints
>>>               of the spaces
>>> your client on one system and start another. This also is not a  
>>> "You must enable
>>> 2.        The ability for the services in an MMOX world to be  
>>> named, and authenticated
>>> 6.        The ability to express Policy intent between MMOX  
>>> services and virtual spaces
>>> 2.        Virtual space servers which manage the state of a  
>>> portion of virtual space
>>> Note that exactly how these three large chunks are assembled and  
>>> the granular nature of
>>> The heart of most of the solutions is managing to accept and merge  
>>> a stream of updates,
>>> such as used by SecondLife and Protonsphere, where voice is  
>>> managed in a separate
>>> Closely related, are issues of representation and format of  
>>> content. This takes several,
>>> solutions which will enable varying degrees of interoperability.  
>>> We can, and should
>>> attempt to provide as web like an approach to function as  
>>> possible. Content negotiation,
>>> Our goal is not to enshrine any single virtual world as the  
>>> standard for all MMOX spaces,
>>> but rather create a flexible, extensible set of services which  
>>> will allow us to grow larger
>>> hanging fruit in the area of identity, authentication,  
>>> authorization and presence
>>> "A pretty maple tree with fall colors" which provides a way to  
>>> fetch the "Collada Style
>>> a virtual space can select, through content negotiation the one  
>>> most useful to it.
>>>
>>> to allow a web light selection of an appropriate form. It is  
>>> equally possible to imagine
>>> some deep challenges lurking, such as when two different  
>>> approaches have radically
>>> different
>>>
>>> What I would encourage us, as a mailing list to do, is look  
>>> through the problem
>>> capture the various sentiments in the ongoing discussion. I am  
>>> sure I have missed points,
>>> I would ask people to look for "No, you missed X" and "Hey, I  
>>> don't think Y" is true. I
>>> will attempt to capture all of those, and revise the document,  
>>> until we think it represents
>>> virtual world vendor or project would implement whole. What I  
>>> expect it to yield is a set
>>> I also want to begin to accumulate a short list of "No, this is  
>>> out of scope" assertions
>>>
>>> 1.        We will provide all the affordances necessary to permit  
>>> a broad range of
>>> 2.        Whether or not immersive multi-party spaces are useful  
>>> and which specific
>>> simply declare it the basis for our work going forward. At the  
>>> same time, we must base
>>> The IETF favors working code and growing consensus over blank  
>>> paper and blue sky
>>> extensible  list of graphic content types you might want to move  
>>> on a MMOX transport"
>>> Three grow out  proposed solutions such as LLSD, OGP, and others,  
>>> as they are
>>> simply want to use existing work, such as OpenID, OAuth,  X.509   
>>> and create a shared

---

From: Christian Scholz <[email-masked]>
Date: Wed, 25 Feb 2009 16:34:33 +0100

Meadhbh Hamrick (Infinity) wrote:
> application to application. part of the reason we like this is we have a
> requirement that our HTTP traffic be able to flow over proxies (of both
> the SOCKSish variety and the squidish caching variety.) we are therefore
> paranoid that somewhere, somehow, transport layer authentication
> information would be "eaten" by a misconfigured or miscoded piece of
> required infrastructure. we understand that many people deploying VW
> applications may not have this requirement, but we kindly ask people to
> respect our requirements. but... just because we have defined an
> application-layer-endpoint to application-layer-endpoint authentication
> protocol does not mean we're going to try to ram it down everyone else's
> collective throats. OpenID, OAuth, PKIX client certs and even *shudder*
> gss-api all have a place in the world, and that place may include
> authenticating endpoints in virtual world interactions.

What do you mean by eaten? Are there proxies eating e.g. cookies or GET
parameters? E.g. OAuth after all is just some GET parameters or a header
field but you can choose.
I understand that you have lots of infrastructure in place which might
not be that easily compatible with it though. But this will be the case
for everybody for most protocols we develop.
But as said earlier, I would like to see the use cases being written
down first with the requirements if *all* participant and then we can
think about what the best solution might be (and we apparently need
criteria for that where one might be the change costs for vendors,
another interoperability outside the VW space).

> related commercial ventures (like qwaq.) personally, i like croquet and
> have for a while. like any system it has it's benefits and its
> focus of this group as being "application layer wire protocols," and to
> the degree that this statement survives the WG formation process... i
> would hope we could define wire protocols that were independent enough
> of the interaction model to at least allow some reuse of the PDUs. if
> there was a way to make TObjects look like REST-like resources we might
> be able to go further and reuse some of the interaction model. (but i'm
> just offering it as a suggestion! i'm not saying croquet has to change
> to be more SL like before we'll play nice with you!) and who knows...
> maybe after detailed investigation of both system's interaction models,
> we could find a way to denote them both with the same representational
> system.

I think we all need more understanding of how the other systems work. I
know roughly how it's in SL but have no idea about Croquet or OLIVE or ...

> know that. that was part of the motivation for the design behind
> OGP/Auth. At the end of authentication, the client is in possession of a
> below could easily be implementable with this technique. i've heard from
> some quarters that capabilities give some people the willies and
> honestly... they gave me the willies too until i drank the kool-aide and
> started using BREW a couple years back. i would point out, however, that
> they've been in constant use with SL for over 5 years now and they tend
> to work quite well for us. ultimately, however, there are likely going
> to be some people who won't want to use them and sure... that's fine...
> what this means to me vis a vis protocol definition is we should
> separate the acquisition of a service endpoint from the service it
> enables. and this might be was CS was talking about below.

As you know I don't really like caps ;-) I mostly do not like them
because they are very different from what you do on the web and they are
in fact somewhat more difficult to implement with a web framework (at
least if we assume how the SL infrastructure is, OpenSim does it a bit
differently). But that's probably detail and maybe there is even a way
to keep caps for you and maybe add some header field for more web affine
people. And I think if we still want to support the use case in which
e.g. some social network can act as an Agent Domain (or the equivalent
in some future MMOX protocol) then it's not very likely to assume that
they implement caps. They more likely have OAuth and XRD-based service
discovery in place.
But you are right: We should definitely separate the discovery of these
service endpoints from the services themselves and we shouldn't assume
any service (or specific version of it) to be there. This gives us more
flexibility and shouldn't be too hard to implement.

> or it might have been about service versioning that came up from time to
> time in the PyOGP list. fwiw... we tend to be "chunky" in our service
> deployment, meaning we prefer to not operate several versions of related
> services simultaneously, but i'm sure we can come up with a way to
> create a versioning system in MMOX, and i warn people up front that
> enabling such functionality would likely be a tough sell at linden, but
> we wouldn't stand in the way of other virtual worlds operators / client
> developers wanted to add it to a spec we claim we want to adhere to. but
> just keep in mind we're likely to either strongly request the feature
> was optional or use it in such a way that our grid always looks like it
> only has a single version of each service.

It also depends on how granular a service is. If they are relatively
small then it's easier to exchange them, if they are a huge thing which
do everything (like an AgentDomain in OGP) then it's hard.

> but i wonder if it's not a better idea for the two to develop separately
> and allow protocols in each area to reference each other. for example,
> OpenSocial is, as i understand it, currently implemented as a set of
> web-apis. i really like the idea of an opensocial app being able to
> "reach into the virtual world" and i like the idea of our virtual world
> supporting things like existing OpenSocial apps... let's just not make
> it a REQUIRED part of the protocol anytime soon.

Well, you say that it's hard to get changes into your codebase. Would
this be any different if you really want to meet with the web at some
point? I would do it now because I don't really see a win in making our
own thing here. Web protocols might have problems and flaws in our scope
here but those communities are open for discussion and of course cannot
guess all possible use cases. e.g. the multi-service-authorization use
case for OAuth is such a case where right now it's not really well
working. I still think though that it can be made working by talking to
the OAuth folks and proposing some extension.
As for OpenSocial I don't speak about apps. All I am talking about is
the OpenSocial REST API where you can do a simple GET (guarded by OAuth)
to retrieve some persons profile. The OpenSocial Person schema might not
fit our needs but we can again do it as extension and/or start a
discussion on the OpenSocial list to make schemas more extensible
themselves.
We need to transfer profiles anyway and OpenSocial gives us REST and it
gives us some basic schema to build upon. It also enables the
possibility to e.g. import MySpace profiles today already.

But what is required or not is again not a discussion for now but for
sometime after use case definition and requirements capturing. Then we
can really say if it fits or not.

as a sidenote: I wrote down a workflow of an experiment I was coding 2
evenings ago which uses OpenID, OAuth and OpenSocial to import a
profile. You can find it here:
http://socialconnect.info/trac/wiki/WorkflowNumberOne

Code is following soon.

> gorilla in a room where virtual worlds are being discussed and blizzard
> hasn't shown up... i promise to use my secret powers for good. the lab
> has no interest in scuttling anyone else's product roadmap but we ask
> that the more agile participants in this group give us a little slack
> with what we're able to implement and how fast. compared to the open sim
> peeps, we must seem like dinosaurs, and compared to tao, we're probably
> stromatolites. i just ask that peeps here please keep in mind we have an
> onerous repository of legacy code and a large installed base we can't
> abandon, so there's a reason we're moving slower than people might like.

I think protocol definition and implementation are two different things.
 Defining a protocol for VW interoperability is IMHO a very huge
undertaking because the problem domain is so huge and every participant
has their own flavour of what they want, need and can do in a reasonable
time for a reasonable budget.

So everybody needs time to implement changes and they might not be
small. And because of that I hope not that it means just because SL
might be slower in adapting we use more SL related technology just
because it makes it easier for LL.
I am not against using that technology if it makes sense but before that
I really want to know what the other vendors do, why they do it and
what's important to them.
That it already works well can probable be said about the technology of
every vendor participating.

My last point is about the huge problem space. Maybe it really makes
sense to first cut that into pieces. My pet peeve apparently is a
portable identity or in more general maybe data portability and I would
already be happy if I can login with my SL account in There, Kaneva and
so on without creating a new one. Also having my friends from elsewhere
being on my friendlist there automatically would be great. All this of
course under the premise that I can control who can see what data. Other
things like object transfer and making 3D representations compatible
might then come afterwards.

-- Christian

PS: I don't think you are stromatolites ;-) SL came a big way and helped
to make VWs popular. And what now is live deployed is probably all very
much grown and also based in a time where nobody talked about OAuth or
OpenSocial. And I know that changing such a system and keep it running
is a huge task in itself and also risky. So I understand your problems
and I also understand why it's easier for LL to just standardize OGP.

>> about the IETF process anyway at this time and if and how this would
>> be possible or wanted.
>>
>> -- Christian
>>
>>
>>> Mark McCahill

-- 
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: Gareth Nelson <[email-masked]>
Date: Thu, 26 Feb 2009 21:35:31 +0000

Well, I promised i'd give my thoughts on the list, so here they are:

> I am attaching the input as a .txt and a (sigh) Microsoft  word document. I
> am also posting it in line as plan text. (tho ugly, I'll work on that for
> future versions)
A word document about a proposal for discussions of open standards.
That's priceless

> Specifications do not advance in the IETF in the absence of
> demonstrated interoperability based on running code.
This is a good thing(tm), and we should also discuss what languages
any code should be produced in. My vote is for python and C.

> I take MMOX as Massively MultiParty Online eXperiences (Since Meadbh didn't
> define
> X, we all get a shot at it) Lets take this one bit at a time. Massively, as
> in experiences
One thing I would immediately point out is that though I can see how
games are relevant (after all, MMORPGs for example are just huge
virtual worlds with game rules thrown in), I fail to see how networked
applications of a generic type are relevant. For example, if I use
multiuser GNU screen, are we going to discuss interop so I can
teleport from my screen session to SL? This is obviously quite
nonsensical, and is an extreme case, but I must ask "where is the line
drawn?"
Practically everything people do online is "multiuser", and lots of
things are "massively multiuser" - look at any big site such as
wikipedia for example.

> The group's name and remit is intentionally broad, focused on a general set
> of Games and
> games, Virtual worlds, Collaboration and Simulation Environments and shared
> online
> World Of Warcaft, ProtonSphere, Eve Online, Forterra's  OLIVE platform, Club
Tiny nitpicking point - did you mean webkins, the virtual world for
kids with the cute little pets and serial codes from toys? As for
"shared online streaming environments", I presume this means any kind
of interaction where people are streaming "something" such as video,
audio or 3D stuff? If so, would this not also include stuff such as
IRC?
See where i'm going, we don't want "one working group to rule them all".

>                currently in the space. (Text, Voice, and the results of
This mailing list could be considered a virtual space, as could a
forum or an IRC channel.

>                each other in some form (be aware of each other's locations
> and online status,
>                message each other, etc)
Shameless self-plug, have I talked to you about GMMP?
Each channel in GMMP has a set of "channel objects" which contain
persistent state. It's meant as an abstraction of any virtual world or
any other internet protocol in such a way that you could visualise any
arbitary protocol as a virtual world. It's a project i've been working
on-and-off on for the past 1.5 years and I have some draft specs about
30% done.

> moment, I'm going to keep those terms off the table to think about the
Sensible idea :)
Though longterm we do need to agree on terminology. I suggest
"location", "space" or "scene" instead of "region", with "avatar" and
"assets" still being very neutral.

> features, and then a set of services which add to this core. Think about how
> these goals
> and solutions could be applied to collaborative spaces such as Wikis, Micro
> blogging
I'm repeating myself, but I think it's a bad idea to go into any
multiuser collaborative environments with this group. We can't
reasonably hold a remit that large. Ironically in limiting your
specifications of the problem space, you're making it HUGE.

> Interoperability is about making multiple existing implementation
Agreed - I think everyone on this list will agree with that one

I'll continue commenting in another post

---

From: Jon Watte <[email-masked]>
Date: Thu, 26 Feb 2009 14:31:41 -0800

> any code should be produced in. My vote is for python and C.

Let me vote for Lua and C++, and then the OpenSim people can vote for C# 
and Java and we have all the bases covered :-)

> virtual worlds with game rules thrown in), I fail to see how networked

I think that's a common mis-conception. Most (almost all) MMOGs do not 
have much in the way of persistency, other than character possessions 
and stats. They also have a very static world, that generally does not 
allow users to move things around or place new things into the world. 
Finally, they do not support any form of UGC, which I think is more or 
less a requirement for a "real" virtual world. Lacking all three means 
that the technical job of implementing and running the MMORPG is much 
easier, but it also puts them on a lower rung of the expressiveness. A 
VW could express a MMORPG (with significant overhead compared to the 
MMORPG itself), but a MMORPG couldn't express a VW.

> things are "massively multiuser" - look at any big site such as

"What is virtual worlds" has been a general question for a long time, 
but I believe the "rough consensus" answer is that it's at least:

Interactive
Persistent
Identity Based
Collaborative
Supports UGC
(controversial) Based on a 3D Simulation

But, if we believe that we all need to agree on exactly what a virtual 
world is before we can make progress, experience shows we won't be able 
to make progress at all.

Sincerely,

jw

---

From: Lawson English <[email-masked]>
Date: Thu, 26 Feb 2009 17:06:57 -0700

Jon Watte wrote:
> Let me vote for Lua and C++, and then the OpenSim people can vote for 
> C# and Java and we have all the bases covered :-)
>
Objective C. I need to learn that anyway.

Dare I mention Smalltalk?

L

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Thu, 26 Feb 2009 17:32:09 -0800

i don't think we get to mandate what code people implement the  
protocol in, but i would certainly add lisp, smalltalk and occam to  
the list.

seriously thought... remember... we're talking about a wire-protocol,  
not a library that implements the protocol.

On Feb 26, 2009, at 2:31 PM, Jon Watte wrote:

> Let me vote for Lua and C++, and then the OpenSim people can vote  
> for C# and Java and we have all the bases covered :-)
>
>
> I think that's a common mis-conception. Most (almost all) MMOGs do  
> not have much in the way of persistency, other than character  
> possessions and stats. They also have a very static world, that  
> generally does not allow users to move things around or place new  
> things into the world. Finally, they do not support any form of UGC,  
> which I think is more or less a requirement for a "real" virtual  
> world. Lacking all three means that the technical job of  
> implementing and running the MMORPG is much easier, but it also puts  
> them on a lower rung of the expressiveness. A VW could express a  
> MMORPG (with significant overhead compared to the MMORPG itself),  
> but a MMORPG couldn't express a VW.
>
> "What is virtual worlds" has been a general question for a long  
> time, but I believe the "rough consensus" answer is that it's at  
> least:
>
> Interactive
> Persistent
> Identity Based
> Collaborative
> Supports UGC
> But, if we believe that we all need to agree on exactly what a  
> virtual world is before we can make progress, experience shows we  
> won't be able to make progress at all.
>
> Sincerely,
>
> jw
>

---

From: Gareth Nelson <[email-masked]>
Date: Fri, 27 Feb 2009 01:36:28 +0000

A reference implementation is always a handy thing to have :)

On Fri, Feb 27, 2009 at 1:32 AM, Meadhbh Hamrick (Infinity)
<[email-masked]> wrote:
> i don't think we get to mandate what code people implement the protocol in,
> but i would certainly add lisp, smalltalk and occam to the list.
>
> seriously thought... remember... we're talking about a wire-protocol, not a
> library that implements the protocol.
>
>> have much in the way of persistency, other than character possessions and
>> stats. They also have a very static world, that generally does not allow
>> users to move things around or place new things into the world. Finally,
>> they do not support any form of UGC, which I think is more or less a
>> requirement for a "real" virtual world. Lacking all three means that the
>> technical job of implementing and running the MMORPG is much easier, but it
>> also puts them on a lower rung of the expressiveness. A VW could express a
>> MMORPG (with significant overhead compared to the MMORPG itself), but a
>> MMORPG couldn't express a VW.
>>
>> "What is virtual worlds" has been a general question for a long time, but
>> I believe the "rough consensus" answer is that it's at least:
>>
>> Interactive
>> Persistent
>> Identity Based
>> Collaborative
>> Supports UGC
>> world is before we can make progress, experience shows we won't be able to
>> make progress at all.
>>
>> Sincerely,
>>
>> jw
>>

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Thu, 26 Feb 2009 18:04:45 -0800

yes, but a reference implementation is not a work item on the group's  
charter.

and personally... ugh.. i've seen waaay too many times when specific  
implementation decisions for reference implementations were mistaken  
for protocol requirements and pain ensued.

i even prefer the term "example code" instead of "reference  
implementation" for this reason.

-cheers
-meadhbh

On Feb 26, 2009, at 5:36 PM, Gareth Nelson wrote:

>> protocol in,
>>> for C#
>>> not
>>> time, but
>>> virtual

---

From: David W Levine <[email-masked]>
Date: Thu, 26 Feb 2009 21:43:33 -0500

The ITEF really doesn't do reference implementations. The bakeoff approach 
is sort of antithetical to
a singular reference implementation. The bakeoff approach says "You need 
several to prove 
interoperability" and you validate the spec, based on how well they 
interoperate, collectively, not
singurally. Now, of course, you sort out which ones don't meet the spec, 
and thus fail to interoperate,
but.. you also look at the set of interoperating implementatoins, ont a 
singular one.