Subject: Re: [mmox] MMOX Protocol Proposals

From: "Frisby, Adam" <[email-masked]>
Date: Sun, 1 Mar 2009 03:07:28 -0500

I haven't yet had a chance to look at LESS in any detail (although I will), however I would like to point out that deterministic simulation only works if there is an accurate and up-to-date copy of the scenegraph on both the client and the server - this precludes 'streaming' in the Scene, whereas dead reckoning allows a partial environment to be displayed.

IMO, a topological distinction between worlds may not actually be ideal at all - it would seem logical to be able to support scenegraphs of infinite dimensions, and there is no reason not to allow them to intersect each other.

If we assume coordinates are relative to the center of each Scene, then any bounds placed upon them are artificial in entirety. While having two scenes worth of content displayed in the same area upon the client may seem odd - there may be some valid purposes in doing so, such as say rendering a larger "continent" (low detail, large area) on one scene, and the local area in another (high detail, low area).

Regards,

Adam

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jon Watte
> Sent: Saturday, 28 February 2009 7:25 PM
> To: Morgaine
> Cc: MMOX-IETF
> Subject: Re: [mmox] MMOX Protocol Proposals
>
> Morgaine wrote:
> > On Sat, Feb 28, 2009 at 7:20 PM, Jon Watte <[email-masked]
> > <mailto:[email-masked]>> wrote:
> >
> >     client/server interface. That doesn't solve any of the hard
> >     problems, like how to interoperate different objects that are
> >     built using different execution environments within the same
> space.
> >
> >
> > flexibility of Opensim but also to the architecture-neutrality of
> MXP.
> >
>
> But architecture neutrality is only a necessary constraint on a
> standard; it's not sufficient to provide interoperability.
> Specifically,
> I don't quite see how MXP supports the case where the same space
> contains entities simulated by different hosts -- given that it
> suggests
> entities are "handed off," that necessarily means that bubbles have to
> use the same technology, which necessarily precludes multi-architecture
> interop.
>
> > On the similarities between MXP and OLIVE, the two architectures look
> > like variations on a theme to me.  In both cases every client
> performs
> > the same simulation, this being of a "shared space/room" in OLIVE and
> > of a "Bubble" in MXP.  In both cases, the communication seems to be a
> > form of P2P, proxy-aided in the case of MXP.  Both approaches seem
> > unable to simulate widely diverse world environments because
> > simulation is done on every client, which means that the
>
> Surely, there is simulation on the client even in Second Life? Else,
> you
> would need to get updates from each object at 60 Hz to be able to show
> smooth movement.
> Specifically, MXP sends state snapshots, and lets the client dead
> reckon
> between those snapshots. That is, in itself, a robust technique, used
> by
> a lot of systems (harking back to before DIS, and used by pretty much
> all networked computer games) -- but it's nowhere near what OLIVE does
> internally. OLIVE requires deterministic simulation on client and
> server, and only forwards time-stamped command input, no state
> snapshots.
> The LESS protocol I have proposed, though, is similar to MXP in this
> regard, because it's based on the "common ground" of state snapshots
> and
> dead reckoning. I based it on that just because it's so common, robust
> and well known, and the fact that MXP is also based on that proposal
> means it's probably a good common ground technology.
> But, that in itself does not lead to interop. There is a difference
> between building a working virtual world protocol, which may be open,
> documented, and unencumbered, and building a protocol that is designed
> for interop between different virtual world implementations.
>
> > same simulation code has to exist on every client for the simulation
> > to be accurate.  This would seem to preclude effective interop with
> > different worlds whose simulation code is not divulged --- at best
> > some rough feedback telemetry can then attempt to reflect something
> > vaguely sensible to "foreign" local simulations.  And in neither case
> > is there a "world-centric" model as in SL or Opensim, since rooms and
> > bubbles aren't really topological entities per se.
> >
>
> Bubbles are topological in the sense that they have location in
> cartesian 3D space. At the same time, they are not topological enough,
> if you want to map them 1:1 to arbitrary technologies, because OLIVE
> uses a sector partition where the shape and size of a given
> sector/bubble can be an almost arbitrary graph (including disjoint),
> and
> other technologies like BigWorld let sectors/bubbles be polygonal
> shapes
> (they use Voroni diagrams to partition space); the bubble concept
> doesn't map to that 1:1, either. When you build a virtual world
> protocol
> (to use as basis of a particular implementation), specifying the
> size/shape of bubbles is required. However, when you design for
> interop,
> specifying that actually may get in the way, and leaving it unspecified
> may actually be preferable.
>
> > I do agree that the hard questions do not appear to have been
> > answered, but this is true for every proposal so far:  the detailed
> > semantics of interop remain to be defined.
>
> Well, I tried to answer some hard questions in LESS. I think the
> biggest
> drawback of the LESS proposal is that it requires support from other
> protocols which have not yet been published (but which I have drafts or
> examples of). However, I believe LESS answers more of the hard
> questions
> than the others.
>
> It may turn out that an agreeable protocol in the end uses the
> marshaling/entity/component/property/ownership separation of LESS, the
> connection/authority negotiation of OGP, and some other bits of MXP,
> but
> I don't think any one of those protocols can stand on its own,
> unmodified, as is. I think LESS would have to be modified the least,
> but
> that's because it attempts to solve the fewest problems, but in the
> most
> detail, of the three :-)
>
> Sincerely,
>
> jw
>
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox

---

From: Jesrad <[email-masked]>
Date: Sun, 1 Mar 2009 09:26:14 +0100

> Surely, there is simulation on the client even in Second Life? Else, you

AFAIK that's precisely how SL works: it sends streams of updates just
like that and there is zero simulation in clients.

On a side note, it's quite to show smooth movement with much lower an
update rate than 60 Hz if you include 3rd or even 4th order info, or
if you stack timestamped updates into a single frame.

On Sun, Mar 1, 2009 at 4:24 AM, Jon Watte <[email-masked]> wrote:
>>    built using different execution environments within the same space.
>>
>>
>> flexibility of Opensim but also to the architecture-neutrality of MXP.
>>
>
> But architecture neutrality is only a necessary constraint on a standard;
> it's not sufficient to provide interoperability. Specifically, I don't quite
> see how MXP supports the case where the same space contains entities
> simulated by different hosts -- given that it suggests entities are "handed
> off," that necessarily means that bubbles have to use the same technology,
> which necessarily precludes multi-architecture interop.
>
>> On the similarities between MXP and OLIVE, the two architectures look like
>> variations on a theme to me.  In both cases every client performs the same
>> simulation, this being of a "shared space/room" in OLIVE and of a "Bubble"
>> in MXP.  In both cases, the communication seems to be a form of P2P,
>> proxy-aided in the case of MXP.  Both approaches seem unable to simulate
>> widely diverse world environments because simulation is done on every
>> client, which means that the
>
> Surely, there is simulation on the client even in Second Life? Else, you
> Specifically, MXP sends state snapshots, and lets the client dead reckon
> between those snapshots. That is, in itself, a robust technique, used by a
> lot of systems (harking back to before DIS, and used by pretty much all
> networked computer games) -- but it's nowhere near what OLIVE does
> internally. OLIVE requires deterministic simulation on client and server,
> and only forwards time-stamped command input, no state snapshots.
> The LESS protocol I have proposed, though, is similar to MXP in this regard,
> because it's based on the "common ground" of state snapshots and dead
> reckoning. I based it on that just because it's so common, robust and well
> known, and the fact that MXP is also based on that proposal means it's
> probably a good common ground technology.
> But, that in itself does not lead to interop. There is a difference between
> building a working virtual world protocol, which may be open, documented,
> and unencumbered, and building a protocol that is designed for interop
> between different virtual world implementations.
>
>> same simulation code has to exist on every client for the simulation to be
>> accurate.  This would seem to preclude effective interop with different
>> worlds whose simulation code is not divulged --- at best some rough feedback
>> telemetry can then attempt to reflect something vaguely sensible to
>> "foreign" local simulations.  And in neither case is there a "world-centric"
>> model as in SL or Opensim, since rooms and bubbles aren't really topological
>> entities per se.
>>
>
> Bubbles are topological in the sense that they have location in cartesian 3D
> space. At the same time, they are not topological enough, if you want to map
> them 1:1 to arbitrary technologies, because OLIVE uses a sector partition
> where the shape and size of a given sector/bubble can be an almost arbitrary
> graph (including disjoint), and other technologies like BigWorld let
> sectors/bubbles be polygonal shapes (they use Voroni diagrams to partition
> space); the bubble concept doesn't map to that 1:1, either. When you build a
> virtual world protocol (to use as basis of a particular implementation),
> specifying the size/shape of bubbles is required. However, when you design
> for interop, specifying that actually may get in the way, and leaving it
> unspecified may actually be preferable.
>
>> I do agree that the hard questions do not appear to have been answered,
>> but this is true for every proposal so far:  the detailed semantics of
>> interop remain to be defined.
>
> Well, I tried to answer some hard questions in LESS. I think the biggest
> examples of). However, I believe LESS answers more of the hard questions
> than the others.
>
> connection/authority negotiation of OGP, and some other bits of MXP, but I
> don't think any one of those protocols can stand on its own, unmodified, as
> is. I think LESS would have to be modified the least, but that's because it
> attempts to solve the fewest problems, but in the most detail, of the three
> :-)
>
> Sincerely,
>
> jw
>

---

From: "Frisby, Adam" <[email-masked]>
Date: Sun, 1 Mar 2009 03:35:17 -0500

Actually, no.

The number of updates/sec is highly variable - and is generally far far less than 60Hz. The client basically assumes that if an object is moving (either position or rotation), then it will keep moving at a specified velocity until told otherwise.

In practice, this means that an object tends to get around 10Hz worth of updates, usually less, but still appears smooth. Under OpenSim's LLClientView, we send updates at a variable speed - by default, 10Hz, but when the scene has more than a specified number of agents, that cuts back to more like 2-3Hz to save on packeting.

Adam

> Jesrad
> Sent: Sunday, 1 March 2009 12:26 AM
> To: Jon Watte
> Cc: MMOX-IETF
> standard;
> by a
> server,
> regard,
> between
> to be
> cartesian 3D
> answered,
> but I

---

From: Jon Watte <[email-masked]>
Date: Sun, 01 Mar 2009 09:59:38 -0800

> I haven't yet had a chance to look at LESS in any detail (although I will), however I would like to point out that deterministic simulation only works if there is an accurate and up-to-date copy of…

You can make deterministic simulation work even if not everyone has the 
same scene graph (!) -- in fact, Forterra has a substantial chunk of IP 
around that particular area. That being said, the LESS protocol is based 
on dead reckoning, just because I believe that will be the easiest to 
accept as a common ground for everybody.

> IMO, a topological distinction between worlds may not actually be ideal at all - it would seem logical to be able to support scenegraphs of infinite dimensions, and there is no reason not to allow…

I believe, in fact, they must intersect each other. Else you can't have 
entities from two different systems interacting in (what appears to be) 
the same space.

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Sun, 01 Mar 2009 10:05:17 -0800

> if you stack timestamped updates into a single frame.

Then that third order information needs to include things like 
collisions that will happen, or you will have to make a choice:
1) display objects "behind time" by whatever your transmission latency is
2) display objects as momentarily going through walls etc, and then 
correcting on the next update

Btw: LESS is designed to allow each implementation to choose which of 
those three it implements (local collision, delayed display, or 
momentary penetrations).

Most common computer games (especially the "action" and "MMO" ones) run 
local collision detection to avoid objects going through walls, even if 
they have an authoritative simulation version on the server. If SL 
doesn't do that, that's fine for them; that probably means they have to 
send a greater amount of update data. For an MMO with forward 
extrapolation and client-side collision, you can get away with as little 
as one update per second in many cases. If you're doing dead reckoning 
without any simulation in display, I would expect that to break down 
below about 15 updates per second, and I would want something like 30 
for "full fidelity" displays.

Anyway, this is one of the reasons why I want to keep the 
server<->client display protocol separate from interoperability -- there 
are simply too many different approaches, each of which is optimized for 
a different use case, and if you try to force another model on the 
original use case, that won't work very well.

Sincerely,

jw

Sincerely,

jw

---

From: Kajikawa Jeremy <[email-masked]>
Date: Mon, 02 Mar 2009 20:21:57 +0900

I specifically listed the client<->server reference in regards to some
use-case
  and apparent discussions appearing that way to me.

I would like to clarify what parts of the use cases need server<->server
or other
  connectivity awareness.

or are we going to be pushing for anything going "external" from one
service servers
  being "emulated" when off that system and appearing on another in some
fashion
  using some kind of bridge service?

using original host style systems integrated into a different system?

asking for clarifying the use case logic to protocols level in this...

Jeremy

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 3 Mar 2009 09:56:22 -0800

These don't all appear to be available as Internet-Drafts.
Officially, IETF meetings discuss Internet-Drafts, not documents
published in other venues.  Internet-Drafts contain the boilerplate
where authors agree to IPR disclosure rules, so it's important from
that perspective as well as for people who attend the meeting but
don't follow the mailing list closely to know what to read.

Unfortunately, the deadline for brand-new Internet-Drafts in the
official repository is tomorrow.

Lisa

On Sat, Feb 28, 2009 at 3:42 AM, Morgaine
<[email-masked]> wrote:
> Just a quick note to highlight that we now have three concrete proposals as
> input to MMOX work.  In order of appearance:
>
> Open Grid Protocol (OGP Draft 3) , extra links here
> MXP: a universal Metaverse eXchange Protocol
> MMOX Live Entity State Stream (LESS) Protocol
>
> Hopefully the Solipsis model often mentioned by Jesrad will be added to this
> list as a concrete proposal at some point, as well as the Qwaq and Croquet
> models since they have expressed interest in interop, and also the Project
> Darkstar and Wonderland models (sadly, no representation from them yet).
>
> I'm tracking the appearance of concrete proposals on my unofficial links
> page at
> https://wiki.secondlife.com/wiki/MMOX#MMOX_Protocol_Proposals_and_MMOX_Draft_Protocols
> .
>
>
> Morgaine.
>

---

From: Jon Watte <[email-masked]>
Date: Tue, 03 Mar 2009 13:28:13 -0800

By request, I have clarified the server-to-server simulation model 
underlying cross-technology interoperability, and re-submitted the LESS 
proposal with a name related to the MMOX:

http://www.ietf.org/proceedings/staging/draft-ietf-mmox-less-protocol-00.txt

Sincerely,

jw

---

From: Mark Lentczner <[email-masked]>
Date: Tue, 3 Mar 2009 14:31:44 -0800

I have submitted the OGP Fundamentals as a draft:
	
	http://www.ietf.org/internet-drafts/draft-lentczner-ogp-base-00.txt

This is a slight re-work of the base protocol upon which the existing  
OpenSim and Second Life interoperability was run this past Summer and  
Fall.

	- Mark

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[email-masked]

Zero Linden
[email-masked]

---

From: "Frisby, Adam" <[email-masked]>
Date: Tue, 3 Mar 2009 18:26:50 -0500

Hi Jon,

Do you have a reference implementation of LESS available?

Regards,

Adam

> Sent: Tuesday, 3 March 2009 1:28 PM
> To: Lisa Dusseault
> Cc: MMOX-IETF

---

From: Jon Watte <[email-masked]>
Date: Tue, 03 Mar 2009 16:05:08 -0800

> Do you have a reference implementation of LESS available?

Not yet. I implemented the previous proposal (from 2007) that LESS is 
based on, but I have updated LESS based on things learned from this 
list, and I have not updated the reference implementation yet. I foresee 
more possible changes, so I'm lying low on that right now.

Sincerely,

jw

---

From: Christian Scholz <[email-masked]>
Date: Wed, 04 Mar 2009 10:39:05 +0100

Just a question: Can somebody enlighten my why everybody is producing 
drafts now? I though we were in the process of defining what we are 
trying to solve. Instead I see solutions for an undefined problem.

-- Christian

-- 
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: Wed, 4 Mar 2009 02:53:09 -0800

today (the 4th) is the deadline for submitting drafts to be considered  
at the upcoming "face to face" meeting in San Francisco. ( see http://www.ietf.org/meetings/74/ 
  )

that the working group will be "chartered to evaluate requirements of  
the virtual worlds problem space" is not an entirely foregone  
conclusion.

internet drafts and RFCs are the currency of IETF working groups, so  
getting things down on paper provides participants with an unequivocal  
statement regarding the submitters intent.

the IETF is generally considered to NOT support a process of creating  
standards by open-ended discussion, but rather to have standards and  
informational documents submitted in a reasonably complete form  
followed by discussion of that document.

in this instance, the LLSD draft was submitted, followed by reference  
to the OGP specs on the SL wiki, followed by Jon Watte's LESS draft,  
followed by the OGP internet drafts.

submitting these drafts now allows them to be discussed in the  
upcoming face to face meeting.

On Mar 4, 2009, at 1:39 AM, Christian Scholz wrote:

> Just a question: Can somebody enlighten my why everybody is  
> producing drafts now? I though we were in the process of defining  
> what we are trying to solve. Instead I see solutions for an  
> undefined problem.
>
> -- Christian
>
> Jon Watte schrieb:
>> Frisby, Adam wrote:
>>> Hi Jon,
>>>
>> Not yet. I implemented the previous proposal (from 2007) that LESS  
>> is based on, but I have updated LESS based on things learned from  
>> this list, and I have not updated the reference implementation yet.  
>> I foresee more possible changes, so I'm lying low on that right now.
>> Sincerely,
>> jw

---

From: Morgaine <[email-masked]>
Date: Wed, 4 Mar 2009 11:14:57 +0000

On Wed, Mar 4, 2009 at 9:39 AM, Christian Scholz <[email-masked]> wrote:

> drafts now? I though we were in the process of defining what we are trying
> to solve. Instead I see solutions for an undefined problem.
>

Christian, coincidentally I was writing a synthesis that addresses your
question as your post came in:  MMOX Progress
Tracking<http://www.ietf.org/mail-archive/web/mmox/current/msg00923.html>
.

In a nutshell though, this has happened because of the IETF deadline for new
drafts for consideration at the BoF.

You are perfectly right though --- work continues on defining what we are
trying to solve, right here on the list.  Those IETF drafts provide the
foundations to be considered at the BoF, but our IETF Contributions here
assist in reaching the rough consensus both at the BoF and also beyond it
once the workgroup is formed.

Note that David's MMOX Problem and
Scope<http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.txt>statement
provides our best current framework for "what we are trying to
solve".  LESS and OGP provide specific examples of proposed solutions within
that problem space.

Morgaine.

On Wed, Mar 4, 2009 at 9:39 AM, Christian Scholz <[email-masked]> wrote:

> drafts now? I though we were in the process of defining what we are trying
> to solve. Instead I see solutions for an undefined problem.
>
> -- Christian
>
> Jon Watte schrieb:
>
>  Frisby, Adam wrote:
>>
>>> Hi Jon,
>>>
>> based on, but I have updated LESS based on things learned from this list,
>> and I have not updated the reference implementation yet. I foresee more
>> possible changes, so I'm lying low on that right now.
>>
>> Sincerely,
>>
>> jw
>>

---

From: Christian Scholz <[email-masked]>
Date: Wed, 04 Mar 2009 12:37:41 +0100

Thanks Morgaine, Meadhbh,

> On Wed, Mar 4, 2009 at 9:39 AM, Christian Scholz <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> question as your post came in:  MMOX Progress Tracking 
> <http://www.ietf.org/mail-archive/web/mmox/current/msg00923.html>.
> 
> In a nutshell though, this has happened because of the IETF deadline for 
> new drafts for consideration at the BoF.
> 
> You are perfectly right though --- work continues on defining what we 
> are trying to solve, right here on the list.  Those IETF drafts provide 
> the foundations to be considered at the BoF, but our IETF Contributions 
> here assist in reaching the rough consensus both at the BoF and also 
> beyond it once the workgroup is formed.

Well, as I said, these seem to me more solutions to yet undefined 
problems. So IMHO David's draft is the important one here.
I would want to propose though that we add a statement that we also try 
to integrate with the web by trying to use standards like OAuth etc. 
where possible unless there is an unsolvable problem which cannot be 
solved by an extension.

That's also the reason why I think some branched out WG or sub-WG for 
discussing identity, service discovery and probably also licensing 
systems might be a good idea as these are really problems far broader 
than just VWs. And I also don't see web people coming in here to discuss 
it if 20 mails per day are more about 3D protocols.

For meeting one of the use cases described in the initial AWG meeting 
which was to have social networks be an Agent Domain (or whatever it 
will be in the MMOX sense in the end) we need to cooperate with them 
anyway. And things like caps will be in the way IMHO.

And in the end we hopefully also want to have clearly scoped 
specifications which do not too much depend on each other.

> Note that David's MMOX Problem and Scope 
> <http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.txt> 
> statement provides our best current framework for "what we are trying to 
> solve".  LESS and OGP provide specific examples of proposed solutions 
> within that problem space.

Sure :-)

Well, I hope we will nevertheless switch a gear back and first gather 
use cases and requirements and also hopefully get more VW vendors to 
participate.

I also hope that at the face 2 face meeting MMOX participants will talk 
to e.g. the OAuth people. They will meet on monday, March 23rd, 
1740-1940 in Continental 4
(see https://datatracker.ietf.org/meeting/74/agenda.html)

-- Christian

---

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

some might argue that it is the group charter that defines the  
objectives and milestones of the group.

the current charter may be found at http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter 
  .

but there are probably a few points that should be mentioned...

a. the IETF standards process is generally not about engaging  
customers, analyzing business requirements, formulating a software  
architecture and/or design and deploying solutions, but rather about  
the specification of wire protocols.
b. the IETF is not a body that supports ongoing research. standards  
produced by the IETF are generally the "consensus" specification of  
multiple previously produced implementations.

so strictly speaking, the MMOX group will likely work on a subset of  
the items listed in David's document at any given time. that being  
said... the people who participate in MMOX will likely be working on a  
larger set of projects. the MMOX charter is intended to reflect the  
consensus of what implementers believe can be codified and  
standardized in the reasonable future with the understanding that if a  
work item is completed or falls out of scope, the group may append  
it's charter to include new items.

additionally... the people who initiated this process are more  
familiar with second life style implementations of virtual worlds.  
between the initial call for participation and the face to face  
meeting, Jon Watte has introduced an additional work item that will  
have to be considered with the existing "second life style" drafts.

so... to recap... if the group's charter seems to be considerably  
smaller than the set of things listed in David's document, that's not  
a mistake, it means we're still hashing out what we can agree to in a  
reasonable time frame (and this means you too... since you're part of  
a project that has coded something OGP related.) there appears to be  
every indication the charter will change over time. and jon's proposal  
needs to get added in there somewhere.

-cheers
-meadhbh

On Mar 4, 2009, at 3:14 AM, Morgaine wrote:

> Christian, coincidentally I was writing a synthesis that addresses  
> your question as your post came in:  MMOX Progress Tracking.
>
> In a nutshell though, this has happened because of the IETF deadline  
> for new drafts for consideration at the BoF.
>
> You are perfectly right though --- work continues on defining what  
> we are trying to solve, right here on the list.  Those IETF drafts  
> provide the foundations to be considered at the BoF, but our IETF  
> Contributions here assist in reaching the rough consensus both at  
> the BoF and also beyond it once the workgroup is formed.
>
> Note that David's MMOX Problem and Scope statement provides our best  
> current framework for "what we are trying to solve".  LESS and OGP  
> provide specific examples of proposed solutions within that problem  
> space.
>
>
> Morgaine.
>
>
>
>
>
>
>
>

---

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

yup. i agree we shouldn't be reinventing the wheel. the current  
charter includes the verbiage "The OGP protocol suite makes use, where  
ever possible, of existing, established standards. For example, image  
data is typed and transfered using MIME and HTTP; serializations are  
encoded in XML and JSON."   adding OAuth or even RTP to the charter  
are not outside the realm of possibility, but it's unclear where we  
would add those bits.

and yup. i'm on the OAuth list too and plan to spend a lot of time  
with the OAuth and web people, attempting to add virtual worlds as a  
use case for OAuth and see if there's any movement on bayeux or  
related efforts (to support the OGP event queue.)

On Mar 4, 2009, at 3:37 AM, Christian Scholz wrote:

>> On Wed, Mar 4, 2009 at 9:39 AM, Christian Scholz <[email-masked] <mailto:[email-masked] 
>> >> wrote:
>> your question as your post came in:  MMOX Progress Tracking <http://www.ietf.org/mail-archive/web/mmox/current/msg00923.html 
>> >.
>> In a nutshell though, this has happened because of the IETF  
>> deadline for new drafts for consideration at the BoF.
> I would want to propose though that we add a statement that we also  
> try to integrate with the web by trying to use standards like OAuth  
> etc. where possible unless there is an unsolvable problem which  
> cannot be solved by an extension.
>
> That's also the reason why I think some branched out WG or sub-WG  
> for discussing identity, service discovery and probably also  
> licensing systems might be a good idea as these are really problems  
> far broader than just VWs. And I also don't see web people coming in  
> here to discuss it if 20 mails per day are more about 3D protocols.
>
> For meeting one of the use cases described in the initial AWG  
> meeting which was to have social networks be an Agent Domain (or  
> whatever it will be in the MMOX sense in the end) we need to  
> cooperate with them anyway. And things like caps will be in the way  
> IMHO.
>
>> Note that David's MMOX Problem and Scope <http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.txt 
>> > statement provides our best current framework for "what we are  
>> trying to solve".  LESS and OGP provide specific examples of  
>> proposed solutions within that problem space.
>
> Sure :-)
>
> Well, I hope we will nevertheless switch a gear back and first  
> gather use cases and requirements and also hopefully get more VW  
> vendors to participate.
>
> I also hope that at the face 2 face meeting MMOX participants will  
> talk to e.g. the OAuth people. They will meet on monday, March 23rd,

---

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

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

> some might argue that it is the group charter that defines the objectives
> and milestones of the group.
> the current charter may be found at
> http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter .
>
>

The above linked document is clearly marked as out-of-date, as follows:

*NOTE: THe following is out of date. It was posted for consideration during
the process of approving the MMOX BOF. The BOF is approved and charter
discussions continued on the MMOX mailing list.*

As our Area Director wrote above, the charter discussions are indeed
continuing in the MMOX mailing list, and the last relevant document that
seeks to define our goals and scope was provided by David both
here<http://www.ietf.org/mail-archive/web/mmox/current/msg00626.html>on
the mailing list and in the IETF
draft<http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.txt>
.

The fact that it has garnered such very widespread support does I think
auger very well for the definition of a suitable MMOX charter.

Morgaine.

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

> some might argue that it is the group charter that defines the objectives
> and milestones of the group.
> the current charter may be found at
> http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter .
>
> a. the IETF standards process is generally not about engaging customers,
> analyzing business requirements, formulating a software architecture and/or
> design and deploying solutions, but rather about the specification of wire
> protocols.
> produced by the IETF are generally the "consensus" specification of multiple
> previously produced implementations.
>
> so strictly speaking, the MMOX group will likely work on a subset of the
> items listed in David's document at any given time. that being said... the
> people who participate in MMOX will likely be working on a larger set of
> projects. the MMOX charter is intended to reflect the consensus of what
> implementers believe can be codified and standardized in the reasonable
> future with the understanding that if a work item is completed or falls out
> of scope, the group may append it's charter to include new items.
>
> additionally... the people who initiated this process are more familiar
> with second life style implementations of virtual worlds. between the
> initial call for participation and the face to face meeting, Jon Watte has
> introduced an additional work item that will have to be considered with the
> existing "second life style" drafts.
>
> so... to recap... if the group's charter seems to be considerably smaller
> than the set of things listed in David's document, that's not a mistake, it
> means we're still hashing out what we can agree to in a reasonable time
> frame (and this means you too... since you're part of a project that has
> coded something OGP related.) there appears to be every indication the
> charter will change over time. and jon's proposal needs to get added in
> there somewhere.
>
> -cheers
> -meadhbh
>
> question as your post came in:  MMOX Progress Tracking<http://www.ietf.org/mail-archive/web/mmox/current/msg00923.html>
> .
>
> Note that David's MMOX Problem and Scope<http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.txt>statement provides our best current framework for "what we are trying to

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 4 Mar 2009 07:50:48 -0500

On Mar 4, 2009, at 4:39 AM, Christian Scholz wrote:

> producing drafts now?

Maybe the IETF deadline for new drafts has something to do with this ?

> I though we were in the process of defining what we are trying to  
> solve. Instead I see solutions for an undefined problem.
>
> -- Christian
>
> Jon Watte schrieb:
>> Frisby, Adam wrote:
>>> Hi Jon,
>>>

---

From: Christian Scholz <[email-masked]>
Date: Wed, 04 Mar 2009 15:54:42 +0100

Marshall Eubanks wrote:
>> drafts now?

Sure, I know this. But I think my main point is if people want to
discuss the problem or the solution at the f2f. And I'd think it first
needs to be the problem while 3 of those specs are more a solution.

But anyway, I guess it never hurts to write things down in a formal way
so you have something to discuss.

-- Christian

-- 
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: Tommi Laukkanen <[email-masked]>
Date: Wed, 4 Mar 2009 17:30:06 +0200

I agree that as with any work it would be good to start with a list of
requirements. Allthough IETF process usually requires almost ready protocol
specification draft as basis it sounds like we need to start by agreeing on
requirements first before trying to get consensus on protocol details.
Community consensus is after all what is needed according to *The Tao of
IETF:*
**
http://tools.ietf.org/html/rfc4677

Getting a consensus on requirements out of this face to face meeting would
be major victory for virtual world protocol standardization.

Instead of using energy on discussing in depth technical details (which by
the way require a lot of engineering competence) it would be more beneficial
to list the business and architecture requirements.

After the requirements has been set it would probably be good idea to give
assignment to your professional engineers to create protocol proposals. That
is if you want a working and high quality protocol. Nonfunctional, overtly
complex or otherwise handicapped protocols do not fly far.

Engineering is not democratic process but question of deducing a solution
from a set of requirements. Requirement specification can be democratic
process. When the protocol fulfills the jointly agreed requirements it is
easy to have general acceptance on the protocol no matter who created the
technical details.

best regards,
Tommi Laukkanen

---

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

yes, but a charter that has hopes of being accepted seems to me to be  
a great idea.

On Mar 4, 2009, at 4:38 AM, Morgaine wrote:

> On Wed, Mar 4, 2009 at 11:55 AM, Meadhbh Hamrick (Infinity) <[email-masked] 
> > wrote:
> NOTE: THe following is out of date. It was posted for consideration  
> during the process of approving the MMOX BOF. The BOF is approved  
> and charter discussions continued on the MMOX mailing list.
>
>
> continuing in the MMOX mailing list, and the last relevant document  
> that seeks to define our goals and scope was provided by David both  
> here on the mailing list and in the IETF draft.
>
> The fact that it has garnered such very widespread support does I  
> think auger very well for the definition of a suitable MMOX charter.
>
>
> Morgaine.
>
>
>
>
>
>
>
>
> On Wed, Mar 4, 2009 at 11:55 AM, Meadhbh Hamrick (Infinity) <[email-masked] 
> > wrote:
> said... the people who participate in MMOX will likely be working on  
> a larger set of projects. the MMOX charter is intended to reflect  
> the consensus of what implementers believe can be codified and  
> standardized in the reasonable future with the understanding that if  
> a work item is completed or falls out of scope, the group may append  
> smaller than the set of things listed in David's document, that's  
> not a mistake, it means we're still hashing out what we can agree to  
> in a reasonable time frame (and this means you too... since you're  
> part of a project that has coded something OGP related.) there  
> appears to be every indication the charter will change over time.  
> and jon's proposal needs to get added in there somewhere.
>
> -cheers
> -meadhbh
>
>> Note that David's MMOX Problem and Scope statement provides our  
>> best current framework for "what we are trying to solve".  LESS and  
>> OGP provide specific examples of proposed solutions within that  
>> problem space.
>>
>>
>> Morgaine.
>>
>>
>>
>>
>>
>>
>>
>>

---

From: David W Levine <[email-masked]>
Date: Wed, 4 Mar 2009 11:37:59 -0500

Notice I very carefully did not write a new charter. My take, is that, if 
we show enough merit at the BOF, we'll end up with a good lively 
discussion there, which the scope/problem document is intended to help 
ground, and from *that* we go back and try and
write a charter which includes the set of deliverables and milestones we 
actually have people willing to commit to work on. 

- David W. Levine
~ Zha Ewry (ISL)

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 4 Mar 2009 08:42:49 -0800

I know it's generally considered good engineering practice to decide
on requirements before deciding on a solution.  But that only works
when the people making decisions are deeply versed in the technology
and the problem domain, and even then people rarely follow a pure
waterfall model.  A cyclical and recursive model is far more common in
practice.

In the case of a BOF, what I recommend is having a bunch of technical
details available in advance, that techies can dive into to understand
the problem domain and technical challenges.  Even a participant
familiar with one system may need examples to become familiar with
other kinds of systems.

However, during the BOF, the BOF chairs will have to cut off detailed
technical discussions when they crop up and bring people back to the
high-level problem statement, goals and so on.  We don't have time for
anything else during the actual physical BOF.

Lisa

---

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

On Wed, Mar 4, 2009 at 2:54 PM, Christian Scholz <[email-masked]> wrote:

>
> Sure, I know this.  But I think my main point is if people want to discuss
> the problem or the solution at the f2f.  And I'd think it first needs to be
> the problem while 3 of those specs are more a solution.
>
> But anyway, I guess it never hurts to write things down in a formal way so
> you have something to discuss.
>
>
>
You're right, and the IETF takes a much stronger line on this issue than a
mere "it never hurts".  :-)  Determining that the scope of the problem is
well defined and understood is considered absolutely essential to a
successful BoF.

RFC5434 on Considerations for Having a Successful Birds-of-a-Feather (BoF)
Session <http://tools.ietf.org/html/rfc5434> contains a veritable treasure
chest of good advice in this area.  Here are some choice quotes:

2. *Recommended Steps*
1e) *It cannot be emphasized enough that, for the BOF, drafts relating to
understanding the problem space are much more valuable than drafts proposing
specific solutions.*

6. *Pitfalls*
2) *Too much discussion/focus on solutions, rather than showing that support
exists for the problem statement itself, and that the problem is
well-understood and scoped.  The purpose of the BOF is almost never to show
that there are already proposed solutions, but to demonstrate that there is
a real problem that needs solving, a solution would be beneficial to the
community, it is believed that a solution is achievable, and there is a
critical mass of community support to actually put in the real work of
developing a solution.*

6.5) *An example of problematic presentations:*
*- presentations on specific solutions, when the purpose of the BOF is to
get agreement on the problem statement and the need for a WG.  Solutions at
this point are too-often "half-baked" and allow discussion to rathole on
aspects of the solutions.  Instead, the focus should be on getting agreement
on whether to form a WG.*

In our case, the above advice is particularly valuable, given that we do not
have a single complete protocol of any kind on the table.  In these
circumstances, and given the current lack of consensus on the problem space,
advocating one or more part-solutions at this stage seems singularly
inappropriate.

I recommend that everybody reads the whole RFC to get the full picture.
It's wonderfully written, and crystal clear on the primary purposes of a BoF
and the necessary conditions for success.

Morgaine.

---

From: Latha Serevi <[email-masked]>
Date: Wed, 04 Mar 2009 09:06:54 -0800

I'm content with the trajectory of discussion here on the MMOX list,
and I think the current set of internet-drafts will serve their purpose,
namely, to form the "everybody expected to read" basis for the BOF.
Perhaps some of them will even end up as target deliverables for a WG.

My hope is that the discussion between now and the BOF will re-focus
on the charter, requirements, and deliverables, for the reasons described
below.

David/Zha suggested that after the BOF we could "go back and try and write
a charter".   I don't like that idea much -- if we can't emerge from this
BOF with consensus on a charter, then we're gonna have to come back
in 6 months or a year and do this all again.

Perhaps I could call out the key suggestions that I extracted from
my reading of http://tools.ietf.org/html/draft-narten-successful-bof-04 --

====

A BOF should demonstrate that
  - there is a problem that needs solving
  - the scope of the problem is well defined and understood
  - the specific proposed deliverables are the right set
  - there are people to do the work
  - there is a reasonable probability of success

To succeed, the focus of the BOF must be on showing that support exists
for the problem statement itself.   Everything should lead to an obvious
answer to the one question: does the room agree that the IETF should form
a WG with the following (specific) charter?

====

If we take this as received wisdom, then during the three weeks before the
meeting, we'll want to work out a charter that we can (almost) all buy into,
and a list of deliverables that the WG will try to produce if it is 
created.  
Then we'll have something we can try for consensus on at the meeting.

Cheers
Latha Serevi

---

From: Charles Krinke <[email-masked]>
Date: Wed, 4 Mar 2009 10:04:42 -0800

Indeed, this is a particularly valuable piece of advice for this group.
Getting all wrapped up in A) c/m/t B) prims/meshes C) Internal sim/viewer
architecture D) currency E) Whether virtualWorldA is better (or worse) then
virtualWorldB is just distracting right now.

All of these things have we spun around the axle on in the last two weeks.

So, with that in mind, lets follow the IETF advice to create a BOF
(BirdsOfaFeather). Oh, I like that one.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Wed, Mar 4, 2009 at 9:06 AM, Latha Serevi <[email-masked]> wrote:

> created.  Then we'll have something we can try for consensus on at the
> meeting.
>
>
>
> Cheers
> Latha Serevi
>
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Dan Olivares <[email-masked]>
Date: Wed, 4 Mar 2009 13:42:33 -0500

"b. the IETF is not a body that supports ongoing research. standards
produced by the IETF are generally the "consensus" specification of
multiple previously produced implementations."

The use of the word generally is important here because there is
nothing saying that we have to do this.  We could discuss an entirely
different wire protocol from any implementation currently in existence
and /as long as we propose it/, it's valid discussion.   Do, however
know that if we agree on a wire protocol that doesn't exist yet, we
must make it exist before it becomes a standard.   That doesn't
preclude it from the process, we can discuss it.   It's just more work
doing it that way because working implementations will need to be
developed before it gets to a 'standard'.

Sincerely

Daniel Olivares

On Wed, Mar 4, 2009 at 6:55 AM, Meadhbh Hamrick (Infinity)
<[email-masked]> wrote:
> the current charter may be found
> at http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter .
> b. the IETF is not a body that supports ongoing research. standards produced
> by the IETF are generally the "consensus" specification of multiple
> additionally... the people who initiated this process are more familiar with
> second life style implementations of virtual worlds. between the initial
> call for participation and the face to face meeting, Jon Watte has
> question as your post came in:  MMOX Progress Tracking.
>
> Note that David's MMOX Problem and Scope statement provides our best current
> framework for "what we are trying to solve".  LESS and OGP provide specific
> examples of proposed solutions within that problem space.
>
> Morgaine.
>
>
>
>
>
>
>
>

---

From: Charles Krinke <[email-masked]>
Date: Wed, 4 Mar 2009 12:26:47 -0800

In discussing this with some of the personalities this morning, I would like
to suggest again that the BoF concentrate on the charter and not on LLSD or
any other specific protocol. It just seems we are too early.

In order to move forward, all those folks that are involved in the low level
protocol maintenace of existing libraries used for interop, such as
JHurliman for libomv need to feel really comfortable with any technical
direction.

So, please, lets follow Lisa's advice and concentrate on the charter and
table any specific protocol consideration until we can find we have some
sort of momentum and consensus first.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Wed, Mar 4, 2009 at 10:42 AM, Dan Olivares <[email-masked]> wrote:

> produced
> with
> trying
> current
> trying
> list,

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: "Frisby, Adam" <[email-masked]>
Date: Wed, 4 Mar 2009 15:40:13 -0500

+1.

The agenda I think needs to cover first what we’re defining before we start pitching too many solutions. Things like LLSD are coming up far too early here – we haven’t even decided on whether it’s needed or not, and what it could be used for if it is.

I’d like to move that we keep the BoF Face to Face meeting agenda to developing a charter. I’m not sure how we can handle remote participation on this one, but perhaps it might be worthwhile getting those with an interest here to register their desired outcomes before the meeting.

Adam

From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Krinke
Sent: Wednesday, 4 March 2009 12:27 PM
To: Dan Olivares
Cc: Jon Watte; MMOX-IETF
Subject: Re: [mmox] MMOX Protocol Proposals

In discussing this with some of the personalities this morning, I would like to suggest again that the BoF concentrate on the charter and not on LLSD or any other specific protocol. It just seems we are too early.

In order to move forward, all those folks that are involved in the low level protocol maintenace of existing libraries used for interop, such as JHurliman for libomv need to feel really comfortable with any technical direction.

So, please, lets follow Lisa's advice and concentrate on the charter and table any specific protocol consideration until we can find we have some sort of momentum and consensus first.

Charles Krinke
OpenSim Core Developer
OSGrid Director
On Wed, Mar 4, 2009 at 10:42 AM, Dan Olivares <[email-masked]<mailto:[email-masked]>> wrote:

Sincerely

Daniel Olivares

On Wed, Mar 4, 2009 at 6:55 AM, Meadhbh Hamrick (Infinity)
<[email-masked]<mailto:[email-masked]>> wrote:
> On Wed, Mar 4, 2009 at 9:39 AM, Christian Scholz <[email-masked]<mailto:[email-masked]>> wrote:
>>
> On Wed, Mar 4, 2009 at 9:39 AM, Christian Scholz <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
mmox mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmox

--
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: "Hurliman, John" <[email-masked]>
Date: Wed, 4 Mar 2009 14:28:03 -0700

+1.

To put the motion in concrete terms, we should not spend 30 minutes of the BoF discussing LLSD ("0:45 - 1:15 : LLSD") unless we are prepared to put all of the submitted technical proposals on the agenda. Let's put together a modified agenda for the BoF that addresses this issue.

John

>Frisby, Adam
>Sent: Wednesday, March 04, 2009 12:40 PM
>To: Charles Krinke; Dan Olivares
>Cc: MMOX-IETF; Jon Watte
>The agenda I think needs to cover first what we’re defining before we
>start pitching too many solutions. Things like LLSD are coming up far
>too early here – we haven’t even decided on whether it’s needed or not,
>and what it could be used for if it is.
>
>
>
>I’d like to move that we keep the BoF Face to Face meeting agenda to
>developing a charter. I’m not sure how we can handle remote
>participation on this one, but perhaps it might be worthwhile getting
>those with an interest here to register their desired outcomes before
>the meeting.
>
>
>
>Adam
>
>
>
>In discussing this with some of the personalities this morning, I would
>like to suggest again that the BoF concentrate on the charter and not on
>LLSD or any other specific protocol. It just seems we are too early.
>
>In order to move forward, all those folks that are involved in the low
>level protocol maintenace of existing libraries used for interop, such
>as JHurliman for libomv need to feel really comfortable with any
>technical direction.
>
>customers,
>the
>familiar with
>smaller
>your
>are
>is

---

From: Dan Olivares <[email-masked]>
Date: Wed, 4 Mar 2009 16:37:05 -0500

Currently, the bof wiki (http://trac.tools.ietf.org/bof/trac/wiki)  says;

MMOX: Massive Multiplayer Online X (Stuff)
    responsible AD: Lisa
     Charter: MmoxCharter (http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter)
     Work items:
             http://www.ietf.org/internet-drafts/draft-hamrick-llsd-00.txt
             Linden Labs Structured Data (documentation of existing solution?)
             Common object model for virtual worlds?
             Security
             EventQ
             X.509, PKIX and MMOX
     Mailing list: [email-masked]
     External info: http://wiki.secondlife.com/wiki/Open_Grid_Protocol

So, based on this, this will be a very Linden Lab focused BoF.     The
charter mentions LLSD as a deliverable.  We're going to be talking
about the charter, EventQueue, LLSD, OGP, and using SSL to secure it
pretty much, based on this.     Is this really what we want to do?

Last call!

Best Regards

Dan

---

From: "Frisby, Adam" <[email-masked]>
Date: Wed, 4 Mar 2009 16:47:53 -0500

I think probably EventQueue doesn't belong on there either.

Common Object Model makes some sense in a generalised solution, as does Security. However this is probably getting too far down the road at the moment - I think sticking to identifying objectives would probably be a more valuable use of time.

Adam

> Dan Olivares
> Sent: Wednesday, 4 March 2009 1:37 PM
> To: Hurliman, John
> Cc: [email-masked]
>      Charter: MmoxCharter
> (http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter)
>      Work items:
> > To put the motion in concrete terms, we should not spend 30 minutes
> of the BoF discussing LLSD ("0:45 - 1:15 : LLSD") unless we are
> prepared to put all of the submitted technical proposals on the agenda.
> Let's put together a modified agenda for the BoF that addresses this
> issue.
> >
> > John
> >
> >>The agenda I think needs to cover first what we're defining before we
> >>too early here - we haven't even decided on whether it's needed or
> not,
> >>I'd like to move that we keep the BoF Face to Face meeting agenda to
> >>developing a charter. I'm not sure how we can handle remote
> >>> analyzing business requirements, formulating a software
> architecture
> >>and/or
> >>> design and deploying solutions, but rather about the specification
> of
> >>wire
> >>> protocols.
> >>> items listed in David's document at any given time. that being
> said...
> >>the
> >>> people who participate in MMOX will likely be working on a larger
> set
> >>of
> >>> frame (and this means you too... since you're part of a project
> that
> >>has
> >>> charter will change over time. and jon's proposal needs to get
> added
> >>in
> >>> there somewhere.
> >>> -cheers
> >>> -meadhbh
> producing
> deadline
> we
> >>> assist in reaching the rough consensus both at the BoF and also
> beyond
> >>it
> best
> producing
> >>>>> and I have not updated the reference implementation yet. I
> foresee
> >>more

---

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

right. i think at this point its a foregone conclusion we'll have to  
come back and re-charter. this is not a failure.

let's use the list and the f2f to move us towards a definition of what  
our objectives are.

i would point out that there is a draft charter listed and i would  
suggest that a process that identifies specific shortcomings of the  
draft charter and recommends specific additions to the draft might be  
a good way to proceed.

Zha (aka David) recently mentioned at a SL event that a meta-objective  
for the group might be something like "try to define objectives and  
milestones that are specific, but not exclusive of other objectives or  
milestones." and i believe the context of the discussion was..  
"okay... there's a SL/OGP focused set of proposals and a LESS focused  
proposal (no doubt soon to be a set of proposals.) can we live in a  
world where we're both not trying to be 'the one true way.'" or at  
least i think the proposal was... "let's first try to define the  
charter in such a way that OGP and LESS can co-exist in the same WG  
before trying to wrestle control of the MMOX group away from each  
other."

honestly.. there's space here for everyone. i don't think that any of  
the implementers on the list are proposing we define "the one true VW  
protocol" here. nor are we trying to rebuild virtual worlds from raw  
bits. (in the past i've recommended people interested in such  
discussions participate in the MPEG-V and VWR processes.) there may be  
a bit of concern that if either LESS or OGP becomes _a_ standard, it  
might be interpreted as _the_ standard. i would like to point out that  
the IETF has specified and the internet seems to be dealing with  
multiple defined standards: witness IMAP and POP coexisting and XMPP  
and SIMPLE coexisting.

at the moment OGP and LESS are very, very far apart in terms of  
assumptions about the "consensual hallucination" that is the virtual  
world. (for those of you keeping score, it's an even bigger disconnect  
than the hypergrid vs. OGP/Teleport "difference of assumptions.")  
but... the point i think i heard Zha mention, and that i would agree  
with is... "they may be miles apart now, but let's explore how they  
might be brought into a unified conceptual model."

however... as interesting as conceptual models are... they aren't  
interoperability specifications by themselves. my personal opinion is  
we would be well served here by focusing in the near term on  
deliverables. i'm just thinking that the IETF is not a place for  
hashing out conceptual models. or rather... teh types of conceptual  
model hashing that would be facilitated by the IETF is the type that  
comes from implementing two radically different implementations with a  
mind towards having to support the other in the future and seeing what  
architectural and implementation concerns come up.

to recap... let's just implement these things... keep looking over  
each other's shoulders and imagine that in three years time we're  
going to have the requirement that an implementation support both. i  
think the process of re-evaluating designs in light of each other's  
protocol will provide a pragmatic framework for eventual unification  
(if in fact such unification is in any way interesting to the world.)  
and i think it will remove many of the flaws that are evident in other  
"design everything before you write a single line of code" style  
specifications (like X.680 / X.690.)

On Mar 4, 2009, at 9:06 AM, Latha Serevi wrote:

> created.  Then we'll have something we can try for consensus on at  
> the meeting.
>
>
>
> Cheers
> Latha Serevi
>

---

From: Charles Krinke <[email-masked]>
Date: Wed, 4 Mar 2009 14:08:47 -0800

We also need to get more participation from the Croquet and Wonderland
folks. I just sent an email to "[email-masked]" asking him, as a
Wonderland core developer to particpate. It might help to Meadhbh and/or
David send an amplifying e-mail.

Lots of folks are worried that this will become some sort of "done-deal" on
Mar 24th, but I think one of the important points is we dont yet have all
the participants even in the same discussion yet.

We have spent a lot of time going around in circles, so this is the time to
start focusing on the process required to pull this off for the benefit of
all.

Charles Krinke
OpenSim Core Developer
OSGrid Director

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

> right. i think at this point its a foregone conclusion we'll have to come
> back and re-charter. this is not a failure.
>
> let's use the list and the f2f to move us towards a definition of what our
> objectives are.
>
> i would point out that there is a draft charter listed and i would suggest
> that a process that identifies specific shortcomings of the draft charter
> and recommends specific additions to the draft might be a good way to
> proceed.
>
> Zha (aka David) recently mentioned at a SL event that a meta-objective for
> the group might be something like "try to define objectives and milestones
> that are specific, but not exclusive of other objectives or milestones." and
> i believe the context of the discussion was.. "okay... there's a SL/OGP
> focused set of proposals and a LESS focused proposal (no doubt soon to be a
> set of proposals.) can we live in a world where we're both not trying to be
> 'the one true way.'" or at least i think the proposal was... "let's first
> try to define the charter in such a way that OGP and LESS can co-exist in
> the same WG before trying to wrestle control of the MMOX group away from
> each other."
>
> honestly.. there's space here for everyone. i don't think that any of the
> implementers on the list are proposing we define "the one true VW protocol"
> here. nor are we trying to rebuild virtual worlds from raw bits. (in the
> past i've recommended people interested in such discussions participate in
> the MPEG-V and VWR processes.) there may be a bit of concern that if either
> LESS or OGP becomes _a_ standard, it might be interpreted as _the_ standard.
> i would like to point out that the IETF has specified and the internet seems
> to be dealing with multiple defined standards: witness IMAP and POP
> coexisting and XMPP and SIMPLE coexisting.
>
> at the moment OGP and LESS are very, very far apart in terms of assumptions
> about the "consensual hallucination" that is the virtual world. (for those
> of you keeping score, it's an even bigger disconnect than the hypergrid vs.
> OGP/Teleport "difference of assumptions.") but... the point i think i heard
> Zha mention, and that i would agree with is... "they may be miles apart now,
> but let's explore how they might be brought into a unified conceptual
> model."
>
> interoperability specifications by themselves. my personal opinion is we
> would be well served here by focusing in the near term on deliverables. i'm
> just thinking that the IETF is not a place for hashing out conceptual
> models. or rather... teh types of conceptual model hashing that would be
> facilitated by the IETF is the type that comes from implementing two
> radically different implementations with a mind towards having to support
> the other in the future and seeing what architectural and implementation
> concerns come up.
>
> to recap... let's just implement these things... keep looking over each
> other's shoulders and imagine that in three years time we're going to have
> the requirement that an implementation support both. i think the process of
> re-evaluating designs in light of each other's protocol will provide a
> pragmatic framework for eventual unification (if in fact such unification is
> in any way interesting to the world.) and i think it will remove many of the
> flaws that are evident in other "design everything before you write a single
> line of code" style specifications (like X.680 / X.690.)
>
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Christian Scholz <[email-masked]>
Date: Wed, 04 Mar 2009 23:40:39 +0100

Meadhbh Hamrick (Infinity) schrieb:
> yup. i agree we shouldn't be reinventing the wheel. the current charter 
> includes the verbiage "The OGP protocol suite makes use, where ever 
> possible, of existing, established standards. For example, image data is 
> typed and transfered using MIME and HTTP; serializations are encoded in 
> XML and JSON."   adding OAuth or even RTP to the charter are not outside 
> the realm of possibility, but it's unclear where we would add those bits.

Sure, we first need to have a rough consensus on the problems to solve 
anyway ;-)

> and yup. i'm on the OAuth list too and plan to spend a lot of time with 
> the OAuth and web people, attempting to add virtual worlds as a use case 
> for OAuth and see if there's any movement on bayeux or related efforts 
> (to support the OGP event queue.)

Sounds great. I actually see virtual worlds as social networks as well 
just with additional 3D services and some additional formats of assets 
(objects and avatars instead of photos or videos). So IMHO they have 
quite a lot in common.

And too bad SF is so far away. But I saw that the next meeting is in 
Stockholm, so I might make that one.

cheers,

Christian

---

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

i'm happy with this suggestion.

i mean i'm not going to tell people they CAN'T discuss what they want,  
but now that we've clearly seen there's life in the virtual worlds  
standardization space, what with the introduction of at least five  
IDs, one of which wishes to define the charter in terms of vendor- 
specific use cases. maybe encouraging a discussion of the charter is a  
good idea.

On Mar 4, 2009, at 12:26 PM, Charles Krinke wrote:

> In discussing this with some of the personalities this morning, I  
> would like to suggest again that the BoF concentrate on the charter  
> and not on LLSD or any other specific protocol. It just seems we are  
> too early.
>
> In order to move forward, all those folks that are involved in the  
> low level protocol maintenace of existing libraries used for  
> interop, such as JHurliman for libomv need to feel really  
> comfortable with any technical direction.
>
> So, please, lets follow Lisa's advice and concentrate on the charter  
> and table any specific protocol consideration until we can find we  
> have some sort of momentum and consensus first.
>
> Charles Krinke
> OpenSim Core Developer
> OSGrid Director
>
> architecture and/or
> of wire
> said... the
> set of
> that has
> added in
> we are
> best current
> foresee more

---

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

we have a request from our area director to include discussions of  
technical proposals.

On Mar 4, 2009, at 12:40 PM, Frisby, Adam wrote:

> +1.
>
> The agenda I think needs to cover first what we’re defining before  
> we start pitching too many solutions. Things like LLSD are coming up  
> far too early here – we haven’t even decided on whether it’s needed  
> or not, and what it could be used for if it is.
>
> participation on this one, but perhaps it might be worthwhile  
> getting those with an interest here to register their desired  
> outcomes before the meeting.
>
> Adam
>

---

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

+1 John's +1 on not spending all the time discussing one draft.

i just want to remind people that at the time that agenda was  
proposed, there was only 1 draft submitted.

i noted that John mentioned "honestly, if we can come out of this with  
a charter that doesn't exclude any participants i will be happy. i  
think that will be a huge step forward from where things are today."

and would comment... the charter _will not_ exclude reasonable  
participants. i fear that we may have slightly different ideas about  
what "interoperability" means and hope  we can get to an working  
definition that doesn't exclude people or proposals.

-cheers
-meadhbh

On Mar 4, 2009, at 1:28 PM, Hurliman, John wrote:

> prepared to put all of the submitted technical proposals on the  
> agenda. Let's put together a modified agenda for the BoF that  
> addresses this issue.
>
> John
>
>> would
>> low

---

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

ohoh!

i think this is also "stale" data. Lisa posted something recently  
explaining that the draft charter on the wiki was there for the  
purpose of justifying the scheduling of the BoF, but that things have  
evolved since way back a month ago.

today is the deadline for draft submissions to be discussed in f2f  
meetings to be submitted. so tomorrow we'll try to bash the agenda so  
there is guaranteed discussion of each draft (or family of drafts) as  
well as a discussion of security requirements, charter bashing and  
time for general discussion.

it's going to be a full agenda,

-cheers
-meadhbh

On Mar 4, 2009, at 1:37 PM, Dan Olivares wrote:

> On Wed, Mar 4, 2009 at 4:28 PM, Hurliman, John <[email-masked] 
> > wrote:
>> +1.
>>
>>> getting
>>>> design and deploying solutions, but rather about the  
>>>> specification of
>>> wire
>>>> protocols.

---

From: David W Levine <[email-masked]>
Date: Wed, 4 Mar 2009 22:00:46 -0500

We have a mandate from our AD to include some technical material, and we 
have, now, five or six submissions. I'm going to suggest that we structure 
the bulk of our energy on
the scope/charter issues, and make sure we include time to spend, say, 
five minutes on each formal submission. Basically at the "This is what 
this proposal addresses, 
this is where it might fit into the space." Ideally, each proposal would 
have an advocate at the BOF, but if not, I think we can take input from 
the submitters and present it. 

I'm not, to be honest, worried, if we don't walk out of the first BOF with 
a Charter. What would bother me, is if we haven't a) shown significant 
real material  and engaged interest to the IETF
(The set of proposals lowers that worry a fair bit) and b) haven't closed 
the ground towards a consensus on what a proper charter would look like. 
In particular, it seems to me one rational
goal would be to have the meeting yield enough insight that we can go back 
to the mailing list an then, bash out a coherent charter for review at the 
next meeting, or possibly even come to
"rough consensus" before then. 

I'd like to thank all the people who submitted  proposals for the meeting, 
I'm especially excited to see Weblins, Forterra, and input from parts of 
the OpenSim community. The broader
a set of ideas we bring to the table, especially ideas associated with 
existing systems, the more we can understand the places where we overlap 
enough to begin creating useful
specifications. Equally, more ideas will also highlight where there is 
disagreement. 

I'm not expecting us to come to consensus on how to solve every problem of 
interop in the Virtual World/immersive internet space. I'm hoping we'll 
begin to formalize some concrete specifications which will 
tackle *parts* of the problem space, and equally, begin to look at what 
parts of the problem space could move towards that level of activity with 
additional discussion and work. 

- David W. Levine
~ Zha Ewry (ISL)