Subject: [mmox] Proposed draft charter and milestone list

From: "Hurliman, John" <[email-masked]>
Date: Fri, 6 Feb 2009 17:21:10 -0700

I have made changes to the draft group charter to make the language more vendor neutral, and have changed the goals and milestones to be more vendor neutral as well as adding in milestones for a rough consensus on the correct approach to several of the MMOX goals.

Description of Working Group:

Virtual Worlds and other Massively Multi-Party Online Applications are of increasing interest to the internet community. Innumerable examples exist of such applications, most using proprietary protocols. With their roots in games and social interaction, Virtual Worlds are now being increasingly used in business, education and information exchange. With a user base expected to grow to beyond 50 million by 2011, creators of such systems have begun to look at ways to make such systems interoperate. There have been several ad hoc efforts since 2007 to develop interoperability. We believe the process would now benefit from a formal, established process.

The objective of the MMOX working group is to provide an application-layer wire protocol for Virtual Worlds to a) enable interoperability between applications, b) provide for access and exchange with other systems on the internet such as identity providers, web services, e-mail and other information storage systems, c) allow network layers to recognize VW traffic and make routing decisions based on its characteristics.

The core work of the group will be the production of a set of application protocols to communicate and interact with the state of Virtual World applications. Foundational protocols will be evaluated for: 1) representing application layer objects and serializing messages between these objects, 2) a messaging abstraction layer to support the unique needs of VW interactions, 3) authenticating protocol endpoints. An attempt will be made to use existing standards wherever possible. For example, image data is typed and transferred using MIME and HTTP; message serializations are encoded in XML and JSON.

The MMOX working group is not proposing the standardization of any one complete proprietary protocol, but the definition of a extensible core protocol and layers of agreed functionality as they are developed. Because the foundational protocols can be deployed before the entire range of VW functions is considered, we believe that the efforts of the MMOX working group are achievable within a reasonable time frame.

Goals and Milestones:

August 2009 Rough consensus on a set of base VW protocols
October 2009  Publication of LLSD Draft as an Informational RFC
October 2009  Publication of an Inter-Simulator Communication Draft as an Informational RFC
February 2010 Progression of base VW protocols to a Proposed Standard
February 2010 Progression of Virtual World Primitive Object Format to Proposed Standard
February 2010 Rough consensus on a VW Authentication and VW Teleport protocol
June 2010 Progression of VW Authentication to Proposed Standard
June 2010 Progression of VW Teleport to Proposed Standard

---

John Hurliman

---

From: Dan Olivares <[email-masked]>
Date: Fri, 6 Feb 2009 19:34:58 -0500

humm

On Fri, Feb 6, 2009 at 7:21 PM, Hurliman, John <[email-masked]> wrote:
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>

---

From: Lawson English <[email-masked]>
Date: Fri, 06 Feb 2009 19:07:39 -0700

And so it begins.... ;-)

L.

---

From: Morgaine Dinova <[email-masked]>
Date: Sat, 7 Feb 2009 11:17:12 +0000

On Sat, Feb 7, 2009 at 12:21 AM, Hurliman, John <[email-masked]>wrote:

> I have made changes to the draft group charter to make the language more
> vendor neutral, and have changed the goals and milestones to be more vendor
> neutral as well as adding in milestones for a rough consensus on the correct
> approach to several of the MMOX goals.

John's changes in respect of vendor and solution neutrality are perfectly
fine from my perspective, so I won't be suggesting any substantive
modifications.  (Note however the removal of the word "proprietary" in the
final paragraph, which may be substantive, depending on what was intended
--- I believe it was there simply by mistake, since the remainder of the
paragraph did not address the subject).  I have tidied up several English,
grammatical or spelling details for the sake of better presentation though,
and I also have a comment to make about the timeline at the end:

> Virtual Worlds and other Massively Multi-Party Online Applications are of
> increasing interest to the Internet community.  Numerous examples exist of
> such applications, mostly using proprietary protocols. With their roots in
> games and social interaction, Virtual Worlds are now being increasingly used
> in business, education and information exchange. With a user base expected
> to grow to beyond 50 million by 2011, creators of such systems have begun to
> look at ways to make such systems interoperate. There have been several ad
> hoc efforts since 2007 to develop interoperability. We believe that the goal
> would now benefit from a formal, established process.
>
> The objective of the MMOX working group is to provide an application-layer
> wire protocol for Virtual Worlds to a) enable interoperability between
> applications, b) provide for access and exchange with other systems on the
> Internet such as identity providers, web services, e-mail and other
> information storage systems, c) allow network layers to recognize VW traffic
> and make routing decisions based on its characteristics.
>
> The core work of the group will be the production of a set of application
> protocols to communicate and interact with the state of Virtual World
> applications. Foundational protocols will be evaluated for: 1) representing
> application layer objects and serializing messages between these objects, 2)
> providing a messaging abstraction layer to support the unique needs of VW
> interactions, and 3) authenticating protocol endpoints. An attempt will be
> made to use existing standards wherever possible. For example, image data is
> typed and transferred using MIME and HTTP; message serializations are
> encoded in XML and JSON.
>
> The MMOX working group is not proposing the standardization of any one
> complete protocol, but the definition of a extensible core protocol with
> additional layers of agreed functionality as they are developed. Because the
> foundational protocols can be deployed before the entire range of VW
> functions is considered, we believe that the efforts of the MMOX working
> group are achievable within a reasonable time frame.
>
> Goals and Milestones:
>
> With regard to the above timeline (which I have left intact for now), I
would like to draw your attention to the third item, and to a matter that I
pointed out in a previous post, which others have affirmed as well:  that
our work is not tied to the specifics of Linden Lab's very particular
implementation.

That implementation exposes the mapping of regions to individual machines
and/or simulators, and hence conflates our very important notion of abstract
communication endpoints with the very non-abstract and non-generic details
of their exposed machinery.  As a result, I do not believe that the
publication of a specification for inter-simulator communication is in any
way related to our work here:  virtual worlds may not even have simulators,
let alone inter-simulator communication.

I am of course in no way discouraging the publication by Linden Labs of
their internal details.  Quite the opposite, I believe that it would be good
for them to have additional eyeballs trained on those details, and I will
read that material avidly.  But that work bears no direct relationship to
the vendor-neutral, inter-world protocol suite that we are developing here,
and therefore while it may be a milestone for Linden Lab, it is not one of
ours.

Morgaine.

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Sat, 7 Feb 2009 09:50:41 -0800

huh? the word "proprietary" in the last paragraph said that the work  
will NOT be the blessing of an existing proprietary protocol. the  
reason it is there is to explicitly call out the fact that the work of  
the MMOX group is NOT to simply define the existing SecondLife  
protocol and put an IETF rubber stamp on it. i am hoping we all share  
that objective.

On Feb 7, 2009, at 3:17 AM, Morgaine Dinova wrote:

>
>
> On Sat, Feb 7, 2009 at 12:21 AM, Hurliman, John <[email-masked] 
> > wrote:
> I have made changes to the draft group charter to make the language  
> more vendor neutral, and have changed the goals and milestones to be  
> more vendor neutral as well as adding in milestones for a rough  
> consensus on the correct approach to several of the MMOX goals.
>
> John's changes in respect of vendor and solution neutrality are  
> perfectly fine from my perspective, so I won't be suggesting any  
> substantive modifications.  (Note however the removal of the word  
> "proprietary" in the final paragraph, which may be substantive,  
> depending on what was intended --- I believe it was there simply by  
> mistake, since the remainder of the paragraph did not address the  
> subject).  I have tidied up several English, grammatical or spelling  
> details for the sake of better presentation though, and I also have  
> a comment to make about the timeline at the end:
>
> Virtual Worlds and other Massively Multi-Party Online Applications  
> are of increasing interest to the Internet community.  Numerous  
> examples exist of such applications, mostly using proprietary  
> protocols. With their roots in games and social interaction, Virtual  
> Worlds are now being increasingly used in business, education and  
> information exchange. With a user base expected to grow to beyond 50  
> million by 2011, creators of such systems have begun to look at ways  
> to make such systems interoperate. There have been several ad hoc  
> efforts since 2007 to develop interoperability. We believe that the  
> goal would now benefit from a formal, established process.
>
> The objective of the MMOX working group is to provide an application- 
> layer wire protocol for Virtual Worlds to a) enable interoperability  
> between applications, b) provide for access and exchange with other  
> systems on the Internet such as identity providers, web services, e- 
> mail and other information storage systems, c) allow network layers  
> to recognize VW traffic and make routing decisions based on its  
> characteristics.
>
> The core work of the group will be the production of a set of  
> application protocols to communicate and interact with the state of  
> Virtual World applications. Foundational protocols will be evaluated  
> for: 1) representing application layer objects and serializing  
> messages between these objects, 2) providing a messaging abstraction  
> layer to support the unique needs of VW interactions, and 3)  
> authenticating protocol endpoints. An attempt will be made to use  
> existing standards wherever possible. For example, image data is  
> typed and transferred using MIME and HTTP; message serializations  
> are encoded in XML and JSON.
>
> The MMOX working group is not proposing the standardization of any  
> one complete protocol, but the definition of a extensible core  
> protocol with additional layers of agreed functionality as they are  
> developed. Because the foundational protocols can be deployed before  
> the entire range of VW functions is considered, we believe that the  
> efforts of the MMOX working group are achievable within a reasonable  
> time frame.
>
> Goals and Milestones:
>
> With regard to the above timeline (which I have left intact for  
> now), I would like to draw your attention to the third item, and to  
> a matter that I pointed out in a previous post, which others have  
> affirmed as well:  that our work is not tied to the specifics of  
> Linden Lab's very particular implementation.
>
> That implementation exposes the mapping of regions to individual  
> machines and/or simulators, and hence conflates our very important  
> notion of abstract communication endpoints with the very non- 
> abstract and non-generic details of their exposed machinery.  As a  
> result, I do not believe that the publication of a specification for  
> inter-simulator communication is in any way related to our work  
> here:  virtual worlds may not even have simulators, let alone inter- 
> simulator communication.
>
> I am of course in no way discouraging the publication by Linden Labs  
> of their internal details.  Quite the opposite, I believe that it  
> would be good for them to have additional eyeballs trained on those  
> details, and I will read that material avidly.  But that work bears  
> no direct relationship to the vendor-neutral, inter-world protocol  
> suite that we are developing here, and therefore while it may be a  
> milestone for Linden Lab, it is not one of ours.
>
> Morgaine.

---

From: [email-masked]
Date: Sat, 7 Feb 2009 14:31:57 -0600

Quoting "Hurliman, John" <[email-masked]>:

> I have made changes to the draft group charter

....
> The objective of the MMOX working group is to provide an   
> application-layer wire protocol for Virtual Worlds to a) enable   
> interoperability between applications, b) provide for access and   
> exchange with other systems on the internet such as identity   
> providers, web services, e-mail and other information storage   
> systems, c) allow network layers to recognize VW traffic and make   
> routing decisions based on its characteristics.

Just a nit... an application-layer protocol isn't a wire protocol.   
You probably want to stay away from using "wire protocol" cuz it might  
sound to to guys like me that you want to replace all the hardware or  
NIC firmware on the whole www.

Application layer might be need refinement as well.  I'm thinking more  
like a 2-layer client layer.  I'd divide it like so...

scriptable VW layer
    VWP = VW ports - non-host protocol ports (something like those  
used in SL's - llListen, llSay)
    host-protocol ports - TCP/IP (yes we have to use this)

MMOX layer published API so that vendors may implement their own VW's,  
games, languages etc.

    implements non-host protocol ports used by scriptable layer.

I see the MMOX layer as the core of a massively distributed OS with  
all the same requiremnts of any OS.  It's a resource manager.   
Possibly this should be divided as well into a massively distributed  
OS and MMOX? see :

http://en.wikipedia.org/wiki/MOSIX
and
http://en.wikipedia.org/wiki/LinuxPMI

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Sat, 7 Feb 2009 13:01:38 -0800

when i say "application layer," i'm referring to things above the  
transport in terms of TCP/IP and above the presentation layer in the  
OSI model.

and when i say "wire protocol," i'm referring to PDUs that move across  
the wire. thus, i think we should be ignoring issues of software  
architecture and internal messaging infrastructure while making an  
application layer protocol that is independent of implementation  
language or even presentation or transport. that is, i would hope we  
could define a protocol that does not REQUIRE a specific transport,  
session management infrastructure or message serialization scheme.  
that being said... LL and the OpenSim community have been focusing on  
messages sent over HTTP(S) over TCP or a custom message format over  
UDP, and i think we SHOULD focus on these transports... there's a fair  
amount of experience with them and working implementations. but  
there's been persistent discussion of other transports and  
serialization schemes, so creating a system that was dependent on  
HTTP(S) over TCP seems a bit like shooting yourself in the foot in  
terms of extensibility.

so... sorry for the confusion... i was using the term "wire protocol"  
to describe things that get put in PDUs and transmitted over a network  
as distinct from the data structures and software that interpret the  
semantics of application layer PDUs.

MMOX could be seen as the core of a massively distributed operating  
system, but that is not it's focus. i'm a touch nervous bringing   
discussions of scripting languages or operating systems into the MMOX  
charter. that being said... many of the application layer objects  
we're talking about will be scriptable, and there's no reason to  
REQUIRE the use of LSL or MONO (or ECMAScript or ... ) in the spec.  
but there are probably very good reasons to be able to communicate  
metadata about objects (including the language of scripts) in MIME  
types or some similar mechanism.

-cheers
-m/∞

On Feb 7, 2009, at 12:31 PM, [email-masked] wrote:

> You probably want to stay away from using "wire protocol" cuz it  
> might sound to to guys like me that you want to replace all the  
> hardware or NIC firmware on the whole www.
>
> Application layer might be need refinement as well.  I'm thinking  
> more like a 2-layer client layer.  I'd divide it like so...
>
> scriptable VW layer
> MMOX layer published API so that vendors may implement their own  
> VW's, games, languages etc.
>

---

From: Morgaine Dinova <[email-masked]>
Date: Sat, 7 Feb 2009 21:36:04 +0000

On Sat, Feb 7, 2009 at 5:50 PM, Meadhbh Hamrick (Infinity) <
[email-masked]> wrote:

> huh? the word "proprietary" in the last paragraph said that the work will
> NOT be the blessing of an existing proprietary protocol. the reason it is
> there is to explicitly call out the fact that the work of the MMOX group is
> NOT to simply define the existing SecondLife protocol and put an IETF rubber
> stamp on it. i am hoping we all share that objective.
>

Of course we share that objective.  But you're missing the NEW logic of that
paragraph:  OGP was referred to in the previous version and is not in the
new one, and therefore any mention of "proprietary protocol" is completely
out of context and meaningless after these edits --- try rereading the
paragraph without remembering that the document used to mention OGP, and
you'll see what I mean.

What's more, the work of the group is to create a new protocol, and under
the aegis of the IETF this would normally be a non-proprietary one, so to
even see that word there comes as quite a shock.  After getting over the
shock, you then ask yourself which protocol was actually being referred to
before, since OGP is certainly not a "complete" one (barely an initial
fragment) and therefore we couldn't be trying to standardize it even with
the old wording.  The whole new semantic just becomes bizarre with that word
in there.

Of course, the intent might have been simply to say that we're working to
establish a PUBLIC AND OPEN PROTOCOL --- no real need to say it, but useful
anyway for social/human reasons.  If that was indeed the purpose of that
word (and that's why I put the disclaimer "may be substantive" in my
introduction), then we should affirm that positively, rather than saying
that we are NOT creating a proprietary protocol.

I hope this explains the brief note I wrote before.  I fixed a dangling and
no longer meaningful semantic left over from the previous version, but if
removing "proprietary" was indeed substantive then we'll have to address the
issue of ownership properly.

Do you think we should add something to affirm that the new protocol will be
an open and public one?  It could be useful, just to remove any possible
doubts from the minds of readers.

Morgaine.

---

From: Morgaine Dinova <[email-masked]>
Date: Sat, 7 Feb 2009 22:30:30 +0000

You're actually both right, Infinity in describing what we're doing, and
Jack in identifying that the phrase "application-layer wire protocol" is not
very well chosen --- I too raised an eyebrow on first read, but I let it
pass on the basis of "well we know what we mean". ;-)

How about fixing the sentence by replacing "application-layer wire protocol"
by "application-layer and on-the-wire protocols", and then following up by
adding an on-the-wire illustration of a typical exchange as supporting
material?  It would improve the documentation too.

Morgaine.

On Sat, Feb 7, 2009 at 9:01 PM, Meadhbh Hamrick (Infinity) <
[email-masked]> wrote:

> when i say "application layer," i'm referring to things above the transport
> in terms of TCP/IP and above the presentation layer in the OSI model.
>
> and when i say "wire protocol," i'm referring to PDUs that move across the
> wire. thus, i think we should be ignoring issues of software architecture
> and internal messaging infrastructure while making an application layer
> protocol that is independent of implementation language or even presentation
> or transport. that is, i would hope we could define a protocol that does not
> REQUIRE a specific transport, session management infrastructure or message
> serialization scheme. that being said... LL and the OpenSim community have
> been focusing on messages sent over HTTP(S) over TCP or a custom message
> format over UDP, and i think we SHOULD focus on these transports... there's
> a fair amount of experience with them and working implementations. but
> there's been persistent discussion of other transports and serialization
> schemes, so creating a system that was dependent on HTTP(S) over TCP seems a
> bit like shooting yourself in the foot in terms of extensibility.
>
> so... sorry for the confusion... i was using the term "wire protocol" to
> describe things that get put in PDUs and transmitted over a network as
> distinct from the data structures and software that interpret the semantics
> of application layer PDUs.
>
> MMOX could be seen as the core of a massively distributed operating system,
> but that is not it's focus. i'm a touch nervous bringing  discussions of
> scripting languages or operating systems into the MMOX charter. that being
> said... many of the application layer objects we're talking about will be
> scriptable, and there's no reason to REQUIRE the use of LSL or MONO (or
> ECMAScript or ... ) in the spec. but there are probably very good reasons to
> be able to communicate metadata about objects (including the language of
> scripts) in MIME types or some similar mechanism.
>
> -cheers
> -m/∞
>
>
>>>  interoperability between applications, b) provide for access and  exchange
>>> with other systems on the internet such as identity  providers, web
>>> services, e-mail and other information storage  systems, c) allow network
>>> layers to recognize VW traffic and make  routing decisions based on its
>>> characteristics.
>>>
>>
>> Just a nit... an application-layer protocol isn't a wire protocol.  You
>> probably want to stay away from using "wire protocol" cuz it might sound to
>> to guys like me that you want to replace all the hardware or NIC firmware on
>> the whole www.
>>
>>  VWP = VW ports - non-host protocol ports (something like those used in
>> SL's - llListen, llSay)
>> I see the MMOX layer as the core of a massively distributed OS with all
>> the same requiremnts of any OS.  It's a resource manager.  Possibly this
>> should be divided as well into a massively distributed OS and MMOX? see :
>>

---

From: "Frisby, Adam" <[email-masked]>
Date: Sat, 7 Feb 2009 19:34:49 -0500

As a personal opinion for the record, the current UDP packeting system employed by Linden Lab and OpenSim deserves absolutely no place anywhere near an IETF formal standard in its current form. The same applies for a large percentage of the custom HTTP hackery going on, in particular things such as the reverse-poll/'EventQueueGet' or the current proposal for HTTP Asset Downloads.

If we are talking standard transports, then there is absolutely no reason to incorporate other standards where they don’t fit. Reliable transport can be done over TCP/IP using some kind of message frame far more easily and sanely than attempting to do the same thing but adding HTTP in there too.

Regards,

Adam

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Meadhbh Hamrick (Infinity)
> Sent: Saturday, 7 February 2009 1:02 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [mmox] Proposed draft charter and milestone list
>

---

From: Morgaine Dinova <[email-masked]>
Date: Sun, 8 Feb 2009 03:50:23 +0000

On Sun, Feb 8, 2009 at 12:34 AM, Frisby, Adam <[email-masked]> wrote:

> As a personal opinion for the record, the current UDP packeting system
> employed by Linden Lab and OpenSim deserves absolutely no place anywhere
> near an IETF formal standard in its current form. The same applies for a
> large percentage of the custom HTTP hackery going on, in particular things
> such as the reverse-poll/'EventQueueGet' or the current proposal for HTTP
> Asset Downloads.
>
> If we are talking standard transports, then there is absolutely no reason
> to incorporate other standards where they don't fit. Reliable transport can
> be done over TCP/IP using some kind of message frame far more easily and
> sanely than attempting to do the same thing but adding HTTP in there too.
>
> I'm glad that someone was brave enough to say this.

I've been a strong supporter of long poll in LL's Architecture Working Group
as a tactic for getting a plain server->client TCP pipe concept through the
massed ranks of "Web-everywhere" people.  However, layering this over HTTP
is not sensible engineering, as Adam suggests, but merely tactical for me.
A TCP stream opened in the client->server direction is perfectly adequate
for transport of an arbitrary multiplexed data stream in the reverse
direction, and it does not need any HTTP chicanery to set it up nor to keep
the downstream pipe busy.  The opening of a TCP stream by client->server
request is sufficient to overcome the problem of unreachable client-side
listeners owing to NAT, firewalls and other blocks.  It does not mandate a
synchronous client->server approach for pumping downstream traffic once the
pipe has been created.

Once established by a client->server request, a TCP stream is an independent
server-client pathway.  HTTP requests from the client may establish
server-side interest lists that result in server->client updates being sent
in perpetuity down such a pathway.  That autonomous server->client stream is
quite foreign to normal HTTP semantics, it does not benefit from HTTP, and
it should be handled outide of HTTP, even if the server is running as a
REST-type service for upstream requests.  To identify the long-term
downstream data pipe with a kept-alive HTTP 1.1 shared response pipe is just
plain wrong, and merely panders to the web-centric view in areas where web
technology is of no benefit.

Multiplexed transmission pipes such as those provided by the
(IETF-sponsored) SCTP protocol could give us everything we need for
server->client data transport, even when opened by a client->server
request.  And if for some reason people prefer to use the more proven TCP,
then a bundle of TCP streams can provide the same functionality (albeit
slightly less effectively and with more overhead), without any dependence on
HTTP and without skewing a very clean multiplexed transport model with
inappropriate web semantics.

I can't second-guess how our efforts in MMOX will turn out, but I would
caution that if we enshrine HTTP response traffic as the recommended
transport for server->client updates then our work will be rapidly rendered
second-best by those who take the direct approach of sending asynchronous
data updates though (shock horror) an asynchronous data pipe.

Morgaine.

PS. I occasionally muse whether the reason why so many 2-party state-update
systems distort the natural asynchronous downstream update process into
web-compliant form is simply because there is no Internet standard for the
job.  Maybe our work here should *start* with defining a mechanism for
asynchronous transmission of LLSD objects over bidirectional multiplexed
client-initiated TCP bundles or SCTP streams.

PPS. Sadly, it would be far too much work to run this idea as a
non-mainstream counter-proposal here.  I would however suggest that Adam's
post be taken as strong advice to ABSTRACT THE DOWNSTREAM LINK.  Then one
day someone may do the job properly.

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Sat, 7 Feb 2009 20:04:42 -0800

Morgaine. we did something to affirm the new protocol will be open and  
public and you asked to have it removed.

On Feb 7, 2009, at 1:36 PM, Morgaine Dinova wrote:

>
>
> On Sat, Feb 7, 2009 at 5:50 PM, Meadhbh Hamrick (Infinity) <[email-masked] 
> > wrote:
> reason it is there is to explicitly call out the fact that the work  
> of the MMOX group is NOT to simply define the existing SecondLife  
> protocol and put an IETF rubber stamp on it. i am hoping we all  
> share that objective.
>
> Of course we share that objective.  But you're missing the NEW logic  
> of that paragraph:  OGP was referred to in the previous version and  
> is not in the new one, and therefore any mention of "proprietary  
> protocol" is completely out of context and meaningless after these  
> edits --- try rereading the paragraph without remembering that the  
> document used to mention OGP, and you'll see what I mean.
>
> What's more, the work of the group is to create a new protocol, and  
> under the aegis of the IETF this would normally be a non-proprietary  
> one, so to even see that word there comes as quite a shock.  After  
> getting over the shock, you then ask yourself which protocol was  
> actually being referred to before, since OGP is certainly not a  
> "complete" one (barely an initial fragment) and therefore we  
> couldn't be trying to standardize it even with the old wording.  The  
> whole new semantic just becomes bizarre with that word in there.
>
> Of course, the intent might have been simply to say that we're  
> working to establish a PUBLIC AND OPEN PROTOCOL --- no real need to  
> say it, but useful anyway for social/human reasons.  If that was  
> indeed the purpose of that word (and that's why I put the disclaimer  
> "may be substantive" in my introduction), then we should affirm that  
> positively, rather than saying that we are NOT creating a  
> proprietary protocol.
>
> I hope this explains the brief note I wrote before.  I fixed a  
> dangling and no longer meaningful semantic left over from the  
> previous version, but if removing "proprietary" was indeed  
> substantive then we'll have to address the issue of ownership  
> properly.
>
> Do you think we should add something to affirm that the new protocol  
> will be an open and public one?  It could be useful, just to remove  
> any possible doubts from the minds of readers.
>
> Morgaine.
>

---

From: Morgaine Dinova <[email-masked]>
Date: Sun, 8 Feb 2009 04:33:46 +0000

> public and you asked to have it removed.

Infinity, the word I removed made no semantic sense in the context of the
new version of the draft that does not refer to OGP and therefore has no
proprietary referent.  It made (some) sense only in the context of your
original version, because OGP might well have been considered proprietary.

Please read my response again.  There is nothing at all remaining in the
draft that hints at the work of MMOX being proprietary, and it would require
a total misunderstanding of the role of the IETF for someone to consider it
otherwise.  That said, I am happy to add an additional line or paragraph to
make it plain that our work is "public and open", as all work of the IETF is
normally expected to be.  The original word "proprietary" did not do that,
and only sowed confusion owing to total lack of context in the new version.

Arguing about one word is not helpful however.  I would instead ask you:  do
you want the charter to make it plain that our work is "public and open"?
If so, then let us find the best form of words to achieve that.

Morgaine.

---

From: Lisa Dusseault <[email-masked]>
Date: Sun, 8 Feb 2009 08:59:25 -0800

Interesting timing:  another BOF proposal this month was to do some
extensions to XMPP.  One of those extensions was BOSH, which is a way of
layering bi-directional streams over HTTP.  Bayeux was also mentioned, and
of course there's COMET.  The HTML5 WG was working on something called "Web
Sockets" for much the same reasons.

Fighting this widespread demand would be counterproductive.  Instead, I am
starting to put people together who've worked on such things separately, and
see if there can be some unification and standardization here.  Bidi HTTP
work must be done in a WG that has the focus and expertise to do it properly
(there is so much deployed HTTP reality that it takes a bunch of experts to
start to cover the terrain).

RESTful applications are even wider spread, and there are a bunch of
already-standardized examples that are nearer or farther from the heart of
HTTP.  Atom and WebDAV and XCAP are pretty much extensions of HTTP (and give
quite varying examples of degrees and styles of "RESTful").  Certificate and
geo-location retrieval IETF protocols are layered on HTTP.  An asset
retrieval formalization based on HTTP sounds, at very first blush, to be
quite appropriate.  (Note that BCP 56 is very obsolete and we've been trying
to find somebody with the time and saintly patience to revise it.)

Separately on the terminology of "application protocol" and "wire
protocol":  we (IETF) use the latter to be any protocol that goes over the
wire at any layer, as opposed to protocols in programming languages (e.g.
Objective-C) or single-computer messaging stacks.   The phrase I use for
lower-layer protocols is... "lower-layer protocols".  Or "sub-IP" or "link
layer" protocols for just the bottom couple layers.

Lisa

On Sat, Feb 7, 2009 at 7:50 PM, Morgaine Dinova <
[email-masked]> wrote:

>
>
> On Sun, Feb 8, 2009 at 12:34 AM, Frisby, Adam <[email-masked]>wrote:
>
> I've been a strong supporter of long poll in LL's Architecture Working
> Group as a tactic for getting a plain server->client TCP pipe concept
> through the massed ranks of "Web-everywhere" people.  However, layering this
> over HTTP is not sensible engineering, as Adam suggests, but merely tactical
> for me.  A TCP stream opened in the client->server direction is perfectly
> adequate for transport of an arbitrary multiplexed data stream in the
> reverse direction, and it does not need any HTTP chicanery to set it up nor
> to keep the downstream pipe busy.  The opening of a TCP stream by
> client->server request is sufficient to overcome the problem of unreachable
> client-side listeners owing to NAT, firewalls and other blocks.  It does not
> mandate a synchronous client->server approach for pumping downstream traffic
> once the pipe has been created.
>
> Once established by a client->server request, a TCP stream is an
> independent server-client pathway.  HTTP requests from the client may
> establish server-side interest lists that result in server->client updates
> being sent in perpetuity down such a pathway.  That autonomous
> server->client stream is quite foreign to normal HTTP semantics, it does not
> benefit from HTTP, and it should be handled outide of HTTP, even if the
> server is running as a REST-type service for upstream requests.  To identify
> the long-term downstream data pipe with a kept-alive HTTP 1.1 shared
> response pipe is just plain wrong, and merely panders to the web-centric
> view in areas where web technology is of no benefit.
>

---

From: Morgaine Dinova <[email-masked]>
Date: Sun, 8 Feb 2009 18:42:51 +0000

Lisa, if you discover any workgroups dedicated to multiplexed server->client
structured object streams that AREN'T layered on top of HTTP, I'd be very
interested to hear about them.  :-)

(If they use HTTP for upstream, that's fine too, as long as the downstream
part is independent.)

Morgaine.

On Sun, Feb 8, 2009 at 4:59 PM, Lisa Dusseault <[email-masked]>wrote:

>> PS. I occasionally muse whether the reason why so many 2-party
>> state-update systems distort the natural asynchronous downstream update
>> process into web-compliant form is simply because there is no Internet
>> standard for the job.  Maybe our work here should *start* with defining a
>> mechanism for asynchronous transmission of LLSD objects over bidirectional
>> multiplexed client-initiated TCP bundles or SCTP streams.
>>

---

From: Morgaine Dinova <[email-masked]>
Date: Tue, 10 Feb 2009 11:20:35 +0000

In order to move our work on the MMOX charter along, and in view of the lack
of further input on the latest version for some days now, I have taken
Infinity's comments as being strongly substantive and therefore have added
words to express the goal of open, non-proprietary ownership.  The first
paragraph of the charter had already mentioned that proprietary protocols
were used in the past, and therefore this is an appropriate place to insert
that our work seeks an open, non-proprietary alternative.

Note that I have not revised the phrase "application-layer wire protocol" as
we do not appear to have converged on a good alternative form of expression
yet.  Possibly there is no need.

This new draft below becomes our latest version.  The previous first
paragraph has been expanded slightly as explained above, and the LL
implementation-specific RFC about simulators has been removed from MMOX
milestones as per my previous submission (containing the reasons for the
change) which did not elicit comment:

>> hoc efforts since 2007 to develop interoperability. We believe that this
>> goal will now benefit from a formal, established process defining open,
>> non-proprietary standards as infrastructure for virtual world
>> interoperability.
>>

>
>> Ideally we should have some representatives from other virtual worlds
> taking part throughout this work, including at this early charter creation
> stage, but in their absence the burden of keeping our goals and protocols
> applicable to more than just the SL family of worlds falls on our own
> shoulders.  I think that these modifications have probably put us on the
> right track at least.
>
> Morgaine.
>

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Tue, 10 Feb 2009 09:15:19 -0800

One aspect of IETF working groups is they are expected to have  
concrete objectives and milestones. "rough consensus on a set of base  
VW protocols" is not an appropriate milestone for a working group. It  
may be a milestone for a group of people trying to make a working  
group, but not for the working group itself. (which probably explains  
why we're having a BoF instead of a working group meeting.) I believe  
the intent of the group is to publish standards for virtual worlds  
interactions, not to establish rough consensus for some future work.  
That being said, we'll obviously have to establish rough consensus as  
a pre-requisite for establishing a standard, i'm just arguing "rough  
consensus" for at least some of the aspects of the wire protocol need  
to be in place before launching the group.

The benefit of pursuing work on specific drafts in a working group is  
the community at large gets to participate in the development on the  
spec. Informational independent submissions to the RFC Editor; that  
is, proposals that are not intended to be draft standards do not need  
to go through the working group process. So "publication of LLSD Draft  
as an Informational RFC" can be pursued as a working group item, but  
honestly, our time is probably better spent on other tasks unless we  
want to move LLSD forward as part of a draft standard.

-cheers
-m/∞

On Feb 10, 2009, at 3:20 AM, Morgaine Dinova wrote:

> In order to move our work on the MMOX charter along, and in view of  
> the lack of further input on the latest version for some days now, I  
> have taken Infinity's comments as being strongly substantive and  
> therefore have added words to express the goal of open, non- 
> proprietary ownership.  The first paragraph of the charter had  
> already mentioned that proprietary protocols were used in the past,  
> and therefore this is an appropriate place to insert that our work  
> seeks an open, non-proprietary alternative.
>
> Note that I have not revised the phrase "application-layer wire  
> protocol" as we do not appear to have converged on a good  
> alternative form of expression yet.  Possibly there is no need.
>
> implementation-specific RFC about simulators has been removed from  
> MMOX milestones as per my previous submission (containing the  
> reasons for the change) which did not elicit comment:
>
>
>
>
> efforts since 2007 to develop interoperability. We believe that this  
> goal will now benefit from a formal, established process defining  
> open, non-proprietary standards as infrastructure for virtual world  
> interoperability.
>
> Ideally we should have some representatives from other virtual  
> worlds taking part throughout this work, including at this early  
> charter creation stage, but in their absence the burden of keeping  
> our goals and protocols applicable to more than just the SL family  
> of worlds falls on our own shoulders.  I think that these  
> modifications have probably put us on the right track at least.
>
> Morgaine.
>

---

From: "Hurliman, John" <[email-masked]>
Date: Tue, 10 Feb 2009 10:40:10 -0700

There seems to be a balancing act between enumerating all of the drafts we will propose to turn into standards and evaluating which drafts have merit in the larger context of the MMOX. I am preparing a draft that will hopefully make the March 2nd deadline (not sure how long the internal legal process will take). Should we wait until it is ready to explicitly add it to the charter and timeline, or can we use language that is concrete enough to move forward but still encompasses other draft proposals?

John

>Sent: Tuesday, February 10, 2009 9:15 AM
>To: Morgaine Dinova
>Cc: [email-masked]
>Subject: [mmox] Making Progress as a Working Group [was: Re: Proposed
>draft charter and milestone list]
>
>One aspect of IETF working groups is they are expected to have concrete
>objectives and milestones. "rough consensus on a set of base VW
>protocols" is not an appropriate milestone for a working group. It may
>be a milestone for a group of people trying to make a working group, but
>not for the working group itself. (which probably explains why we're
>having a BoF instead of a working group meeting.) I believe the intent
>of the group is to publish standards for virtual worlds interactions,
>not to establish rough consensus for some future work. That being said,
>we'll obviously have to establish rough consensus as a pre-requisite for
>establishing a standard, i'm just arguing "rough consensus" for at least
>some of the aspects of the wire protocol need to be in place before
>launching the group.
>
>spec. Informational independent submissions to the RFC Editor; that is,
>proposals that are not intended to be draft standards do not need to go
>through the working group process. So "publication of LLSD Draft as an
>Informational RFC" can be pursued as a working group item, but honestly,
>our time is probably better spent on other tasks unless we want to move
>LLSD forward as part of a draft standard.
>
>-cheers
>-m/∞
>
>	In order to move our work on the MMOX charter along, and in view
>of the lack of further input on the latest version for some days now, I
>therefore have added words to express the goal of open, non-proprietary
>ownership.  The first paragraph of the charter had already mentioned
>that proprietary protocols were used in the past, and therefore this is
>an appropriate place to insert that our work seeks an open, non-
>proprietary alternative.
>
>protocol" as we do not appear to have converged on a good alternative
>form of expression yet.  Possibly there is no need.
>
>	This new draft below becomes our latest version.  The previous
>first paragraph has been expanded slightly as explained above, and the
>LL implementation-specific RFC about simulators has been removed from
>MMOX milestones as per my previous submission (containing the reasons
>for the change) which did not elicit comment:
>
>
>
>
>
>
>			Virtual Worlds and other Massively Multi-Party Online
>Applications are of increasing interest to the Internet community.
>Numerous examples exist of such applications, mostly using proprietary
>million by 2011, creators of such systems have begun to look at ways to
>make such systems interoperate. There have been several ad hoc efforts
>since 2007 to develop interoperability. We believe that this goal will
>now benefit from a formal, established process defining open, non-
>proprietary standards as infrastructure for virtual world
>interoperability.
>
>
>			The objective of the MMOX working group is to provide
>an application-layer wire protocol for Virtual Worlds to a) enable
>exchange with other systems on the Internet such as identity providers,
>web services, e-mail and other information storage systems, c) allow
>network layers to recognize VW traffic and make routing decisions based
>on its characteristics.
>
>
>			The core work of the group will be the production of a
>set of application protocols to communicate and interact with the state
>of Virtual World applications. Foundational protocols will be evaluated
>for: 1) representing application layer objects and serializing messages
>between these objects, 2) providing a messaging abstraction layer to
>support the unique needs of VW interactions, and 3) authenticating
>protocol endpoints. An attempt will be made to use existing standards
>wherever possible. For example, image data is typed and transferred
>using MIME and HTTP; message serializations are encoded in XML and JSON.
>
>
>			The MMOX working group is not proposing the
>standardization of any one complete protocol, but the definition of a
>extensible core protocol with additional layers of agreed functionality
>as they are developed. Because the foundational protocols can be
>deployed before the entire range of VW functions is considered, we
>believe that the efforts of the MMOX working group are achievable within
>a reasonable time frame.
>
>
>
>
>
>			Goals and Milestones:
>
>		Ideally we should have some representatives from other
>virtual worlds taking part throughout this work, including at this early
>charter creation stage, but in their absence the burden of keeping our
>goals and protocols applicable to more than just the SL family of worlds
>falls on our own shoulders.  I think that these modifications have
>probably put us on the right track at least.
>
>		Morgaine.
>
>
>

---

From: Jon Watte <[email-masked]>
Date: Tue, 10 Feb 2009 13:03:55 -0800

Greetings!

I just joined this list, so I don't have the full history. However, 
given that the goal is a non-vendor-specific solution, I think that the 
following milestone seems a little out of place:

Is using the LLSD proposal already a foregone conclusion?

Sincererly,

jw

Morgaine Dinova wrote:
> therefore have added words to express the goal of open, 
> non-proprietary ownership.  The first paragraph of the charter had 
>         Applications are of increasing interest to the Internet
>         community.  Numerous examples exist of such applications,
>         mostly using proprietary protocols. With their roots in games
>         and social interaction, Virtual Worlds are now being
>         increasingly used in business, education and information
>         exchange. With a user base expected to grow to beyond 50
>         million by 2011, creators of such systems have begun to look
>         at ways to make such systems interoperate. There have been
>         several ad hoc efforts since 2007 to develop interoperability.
>         We believe that this goal will now benefit from a formal,
>         established process defining open, non-proprietary standards
>         as infrastructure for virtual world interoperability.
>
>         application-layer wire protocol for Virtual Worlds to a)
>         enable interoperability between applications, b) provide for
>         access and exchange with other systems on the Internet such as
>         identity providers, web services, e-mail and other information
>         storage systems, c) allow network layers to recognize VW
>         traffic and make routing decisions based on its characteristics.
>
>         application protocols to communicate and interact with the
>         state of Virtual World applications. Foundational protocols
>         will be evaluated for: 1) representing application layer
>         objects and serializing messages between these objects, 2)
>         providing a messaging abstraction layer to support the unique
>         needs of VW interactions, and 3) authenticating protocol
>         endpoints. An attempt will be made to use existing standards
>         wherever possible. For example, image data is typed and
>         transferred using MIME and HTTP; message serializations are
>         encoded in XML and JSON. 
>
>
>         The MMOX working group is not proposing the standardization of
>         any one complete protocol, but the definition of a extensible
>         core protocol with additional layers of agreed functionality
>         as they are developed. Because the foundational protocols can
>         be deployed before the entire range of VW functions is
>         considered, we believe that the efforts of the MMOX working
> ------------------------------------------------------------------------
>

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Tue, 10 Feb 2009 14:03:42 -0800

Jon...

LLSD is a specification, not a product. There are at least three  
independent implementations of them including Linden's.

The reason we're publishing LLSD as an internet draft is to establish  
a canonical description of the specification, not to require people to  
purchase a product in order to be "standards compliant."

Publishing LLSD as an internet draft establishes an IETF Trust  
copyright on the document, thereby ensuring that even if we (Linden  
Lab) wanted to, we couldn't limit it's replication.

It might also be interesting to note that LL is not asserting that the  
concept of an abstract type system (as defined in LLSD) is Linden  
encumbered IP. I am not a lawyer, so please check with competent legal  
authority regarding the verity of my next statement... it would seem  
to me that publishing an abstract type system like LLSD which is  
already widely deployed for which Linden does not assert that you must  
license LLSD in order to use it would be "good" because:

* it established prior art for people who might want to use a similar  
abstract type system
* it is an abstract type system that you can use WITHOUT paying a  
royalty to Linden Lab, and
* it's specification is to be published by an organization with a  
respected stance for maintaining the openness of standards.

so... short answer... LLSD _is_ a non-vendor-specific solution.

-cheers
-meadhbh

On Feb 10, 2009, at 1:03 PM, Jon Watte wrote:

> given that the goal is a non-vendor-specific solution, I think that  
> the following milestone seems a little out of place:
>
>> the lack of further input on the latest version for some days now,  
>> I have taken Infinity's comments as being strongly substantive and  
>> first paragraph has been expanded slightly as explained above, and  
>> the LL implementation-specific RFC about simulators has been  
>> removed from MMOX milestones as per my previous submission  
>> (containing the reasons for the change) which did not elicit comment:
>>
>>
>>
>>

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Tue, 10 Feb 2009 14:09:32 -0800

John...

if you've got something that might be worth discussing, i encourage  
you to come up with a draft sooner rather than later. remember...  
draft documents are exactly that... drafts. obviously you want the  
drafts to be as complete as possible.

on the other hand, i'm thinking we're probably going to spend the  
majority of the time of the f2f meeting discussing objectives and  
milestones. so if you're worried about getting the concept on the  
agenda, submitting earlier rather than later is better. also... even  
if you don't hit the march 2nd deadline there's still a lot of room  
for discussion on the mailing list. my gut feeling is even after the  
march f2f meeting, there'll still be a lot of discussion before a WG  
Charter can be hashed out.

-cheers
-meadhbh

On Feb 10, 2009, at 9:40 AM, Hurliman, John wrote:

> There seems to be a balancing act between enumerating all of the  
> drafts we will propose to turn into standards and evaluating which  
> drafts have merit in the larger context of the MMOX. I am preparing  
> a draft that will hopefully make the March 2nd deadline (not sure  
> how long the internal legal process will take). Should we wait until  
> it is ready to explicitly add it to the charter and timeline, or can  
> we use language that is concrete enough to move forward but still  
> encompasses other draft proposals?
>
> John
>
>> concrete
>> is,
>> proprietary
>> the
>> messages
>> our

---

From: Morgaine Dinova <[email-masked]>
Date: Tue, 10 Feb 2009 23:36:48 +0000

On Tue, Feb 10, 2009 at 5:15 PM, Meadhbh Hamrick (Infinity) <
[email-masked]> wrote:

Informational independent submissions to the RFC Editor; that is, proposals
> that are not intended to be draft standards do not need to go through the
> working group process. So "publication of LLSD Draft as an Informational
> RFC" can be pursued as a working group item, but honestly, our time is
> probably better spent on other tasks unless we want to move LLSD forward as
> part of a draft standard.
>
> I tend to agree with that.

In that case, is everyone happy if we remove the LLSD milestone from MMOX's
list?  This will give LL the freedom to publish this internal spec as an RFC
(entirely unrelated to MMOX work), and then MMOX will take that as initial
external input for its consideration, in the same way as it will be using
other non-MMOX specifications.

Should we decide that LLSD is roughly OK but needs some changes for
extensibility or for other reasons, then a new spec can be defined from that
base, and this new spec would then be a MMOX product, while the LLSD of the
RFC would not.  A new name would then probably be required in order to avoid
major confusion.

This tactic should (I hope) also address some of the disquiet that has been
raised concerning the proprietary background of LLSD and its appropriateness
within an IETF standards track protocol.  Using LLSD as an initial base
proposal for data structuring would not imply design endorsement by MMOX in
the way that making it an MMOX milestone surely would.

Morgaine.

> In order to move our work on the MMOX charter along, and in view of the
> lack of further input on the latest version for some days now, I have taken
> Note that I have not revised the phrase "application-layer wire protocol"
> as we do not appear to have converged on a good alternative form of
> expression yet.  Possibly there is no need.
>
>>> with other systems on the Internet such as identity providers, web services,
>>> e-mail and other information storage systems, c) allow network layers to
>>> recognize VW traffic and make routing decisions based on its
>>> characteristics.
>>>

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Tue, 10 Feb 2009 16:11:57 -0800

and replace it with what?

On Feb 10, 2009, at 3:36 PM, Morgaine Dinova wrote:

>
>
> On Tue, Feb 10, 2009 at 5:15 PM, Meadhbh Hamrick (Infinity) <[email-masked] 
> > wrote:
>
> Informational independent submissions to the RFC Editor; that is,  
> proposals that are not intended to be draft standards do not need to  
> go through the working group process. So "publication of LLSD Draft  
> In that case, is everyone happy if we remove the LLSD milestone from  
> MMOX's list?  This will give LL the freedom to publish this internal  
> spec as an RFC (entirely unrelated to MMOX work), and then MMOX will  
> take that as initial external input for its consideration, in the  
> same way as it will be using other non-MMOX specifications.
>
> extensibility or for other reasons, then a new spec can be defined  
> from that base, and this new spec would then be a MMOX product,  
> while the LLSD of the RFC would not.  A new name would then probably  
> be required in order to avoid major confusion.
>
> This tactic should (I hope) also address some of the disquiet that  
> has been raised concerning the proprietary background of LLSD and  
> its appropriateness within an IETF standards track protocol.  Using  
> LLSD as an initial base proposal for data structuring would not  
> imply design endorsement by MMOX in the way that making it an MMOX  
> milestone surely would.
>
> Morgaine.
>
>
>
>
>> protocols. With their roots in games and social interaction,  
>> Virtual Worlds are now being increasingly used in business,  
>> education and information exchange. With a user base expected to  
>> grow to beyond 50 million by 2011, creators of such systems have  
>> begun to look at ways to make such systems interoperate. There have  
>> been several ad hoc efforts since 2007 to develop interoperability.  
>> established process defining open, non-proprietary standards as  
>> infrastructure for virtual world interoperability.
>>
>> exchange with other systems on the Internet such as identity  
>> Virtual World applications. Foundational protocols will be  
>> evaluated for: 1) representing application layer objects and  
>> serializing messages between these objects, 2) providing a  
>> messaging abstraction layer to support the unique needs of VW  
>> interactions, and 3) authenticating protocol endpoints. An attempt  
>> will be made to use existing standards wherever possible. For  
>> example, image data is typed and transferred using MIME and HTTP;  
>> message serializations are encoded in XML and JSON.
>>
>> developed. Because the foundational protocols can be deployed  
>> before the entire range of VW functions is considered, we believe  
>> that the efforts of the MMOX working group are achievable within a  
>> reasonable time frame.
>>
>>
>>
>> Goals and Milestones:
>>

---

From: Morgaine Dinova <[email-masked]>
Date: Wed, 11 Feb 2009 01:48:26 +0000

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

It's not replaced as a MMOX milestone by anything.  Instead it's just USED
as it stands in a Linden RFC, which we would take as external input to
MMOX.  Creating that RFC would of course be a Linden milestone, the direct
publication of a current Linden production standard.

We would then take that as the initial basis for structured data in the MMOX
protocol, defined externally in the same way as we use other standards that
we have not defined.  As you wrote, "our time is probably better spent on
other tasks unless we want to move LLSD forward as part of a draft standard"
---  and I agree, so let's not spend any time on it (ie. it's no longer a
milestone for MMOX deliberation), and instead we use it as it stands unless
someone finds that it is not up to the task.  (Mostly unlikely in my view,
but who knows.)

What would be totally wrong is to not spend any time on it (as you
recommend) but pass it as a MMOX milestone, which it obviously cannot be if
we have not considered it in depth.  That would amount to rubberstamping,
which we all agreed wasn't on the cards.

Omitting it from MMOX milestones would also avoid MMOX endorsement of what
some are considering a proprietary standard (a milestone is a goal and is
therefore necessarily an endorsement).  Others in this thread have already
suggested that it may be somewhat out of step with our claimed
non-proprietary goals, so this addresses their worry in part as well ---
advantages on all fronts and no disadvantages.

Morgaine.

>>>> Virtual Worlds and other Massively Multi-Party Online Applications are
>>>> of increasing interest to the Internet community.  Numerous examples exist
>>>> of such applications, mostly using proprietary protocols. With their roots
>>>> in games and social interaction, Virtual Worlds are now being increasingly
>>>> used in business, education and information exchange. With a user base
>>>> expected to grow to beyond 50 million by 2011, creators of such systems have
>>>> begun to look at ways to make such systems interoperate. There have been
>>>> several ad hoc efforts since 2007 to develop interoperability. We believe
>>>> that this goal will now benefit from a formal, established process defining
>>>> application protocols to communicate and interact with the state of Virtual
>>>> World applications. Foundational protocols will be evaluated for: 1)
>>>> representing application layer objects and serializing messages between
>>>> these objects, 2) providing a messaging abstraction layer to support the
>>>> unique needs of VW interactions, and 3) authenticating protocol endpoints.
>>>> An attempt will be made to use existing standards wherever possible. For
>>>> example, image data is typed and transferred using MIME and HTTP; message
>>>> serializations are encoded in XML and JSON.
>>>
>>>

---

From: Jon Watte <[email-masked]>
Date: Tue, 10 Feb 2009 17:51:52 -0800

> so... short answer... LLSD _is_ a non-vendor-specific solution.

I guess my question is a little higher level than that. Is there a 
particular reason why an existing standard such as ASN.1 or Google 
protocol buffers wouldn't do? I'm all for re-inventing the wheel, if the 
new wheel is actually significantly rounder -- but why standardize 
something new in this particular case? What's wrong with the existing 
standards in this particular area? (And there are literally dozens). Is 
there a survey somewhere that lists the pros and cons?

Sincerely,

jw

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Tue, 10 Feb 2009 18:15:20 -0800

ASN.1 / BER encoding is overkill, currently unused in this community  
comparatively complicated and bug-prone.

Google Protocol Buffers have not been standardized with the IETF and  
define a serialization technique, not an abstract type system.

On Feb 10, 2009, at 5:51 PM, Jon Watte wrote:

> protocol buffers wouldn't do? I'm all for re-inventing the wheel, if  
> the new wheel is actually significantly rounder -- but why  
> standardize something new in this particular case? What's wrong with  
> the existing standards in this particular area? (And there are  
> literally dozens). Is there a survey somewhere that lists the pros  
> and cons?
>
> Sincerely,
>
> jw
>

---

From: Lawson English <[email-masked]>
Date: Wed, 11 Feb 2009 00:01:12 -0700

Jon Watte wrote:
> the new wheel is actually significantly rounder -- but why standardize 
> standards in this particular area? (And there are literally dozens). 
> Is there a survey somewhere that lists the pros and cons?
>
> Sincerely,
>

There's a joke about LLIDL (the IDL associated with LLSD): that it can 
be pronounced "little."

It is a very minimalistic setup, but powerful enough to express just 
about everything passed down the wire in the Second Life system.  All of 
the alternatives that people have pointed me to turn out to be more 
complicated. LLSD was originally devised so that Second Life, written in 
C++, could have a python dictionary-like data type. It's pretty good for 
what it was designed for and I haven't seen anything better (not that 
I've done a huge search or anything).

L.

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 11 Feb 2009 02:23:18 -0500

On Feb 10, 2009, at 12:15 PM, Meadhbh Hamrick (Infinity) wrote:

> concrete objectives and milestones. "rough consensus on a set of  
> base VW protocols" is not an appropriate milestone for a working  
> group. It may be a milestone for a group of people trying to make a  
> working group, but not for the working group itself. (which probably  
> explains why we're having a BoF instead of a working group meeting.)  
> I believe the intent of the group is to publish standards for  
> virtual worlds interactions, not to establish rough consensus for  
> some future work. That being said, we'll obviously have to establish  
> rough consensus as a pre-requisite for establishing a standard, i'm  
> just arguing "rough consensus" for at least some of the aspects of  
> the wire protocol need to be in place before launching the group.
>
> The benefit of pursuing work on specific drafts in a working group  
> is the community at large gets to participate in the development on  
> the spec. Informational independent submissions to the RFC Editor;  
> that is, proposals that are not intended to be draft standards do  
> not need to go through the working group process. So "publication of  
> LLSD Draft as an Informational RFC" can be pursued as a working  
> group item, but honestly, our time is probably better spent on other  
> tasks unless we want to move LLSD forward as part of a draft standard.

I don't quite understand this statement. Draft Standards also do not  
HAVE to go through a WG, and a WG would normally publish any drafts  
(including informational, experimental, etc.) that it thinks need to be
published to fulfill its charter and do its work. In fact, you don't  
HAVE to have a WG at all, you have WG because it improves the process  
and the result.

In the charter I see

The core work of the group will be the production of the Open Grid  
Protocol suite (OGP), a set of application protocols to communicate  
and interact with the state of Virtual World applications.  
Foundational protocols in OGP include the publication of: 1) LLSD, an  
abstract type system for representing application layer objects along  
with serialization rules for protocol messages between these objects.

I don't even see a target status for LLSD, but I do see a reason to  
publish it. Is the charter wrong ? Is this foundational or not ?

If this is foundational, then  in my opinion the WG needs to address it.

Regards
Marshall

---

From: Morgaine Dinova <[email-masked]>
Date: Wed, 11 Feb 2009 08:30:09 +0000

The unique merit that I see for LLSD as a foundational specification over
the two mentioned and others is that LLSD provides an Abstract Data Type
(ADT) system WITHOUT mandating a single form of serialization, and therefore
is well positioned as a lingua franca of representation systems to underpin
interop between many diverse Virtual Worlds (VWs).

Indeed, the existing Internet draft states in Section 3 that "Three
serialization schemes are <b>currently</b> defined: XML, JSON and Binary",
which highlights the possibility of defining other serializations at a later
date.  (But the draft is inconsistent in this, which we will need to
improve.)  This is a very all-embracing approach that avoids rejecting
interop with a particular VW community just because they use a different
serialization.

The two examples given by Jon do the exact opposite since they define unique
mandatory serializations.  I don't think that such rigidity is helpful when
the goal is to bring separate worlds together.  Man's natural tendency to
Balkanize has resulted in a scattering of islands speaking a Babel of
languages, and LLSD's approach works within this diversity by allowing ADT
interchange without evangelizing a particular communications language.

It's worth pointing out that large organizations like Google are in effect
their own country with their own comms language requirements.  Once VWs
become relevant to Google's core business once more (Lively was deemed not
to be and hence was cancelled), we can certainly expect that they will use
Protocol Buffers for their own serialization because Google's entire
internal transport ecosystem is based on it, and hence that choice would
leverage their existing toolsets and capabilities.

Other worlds who could communicate with some hypothetical Google worlds of
the future would then undoubtedly reap the rewards of talking Google's most
efficient language too.  And some world implementors may dive straight into
using Protocol Buffers anyway just for performance reasons.  Choosing an ADT
specification with a 1:N relationship to serializations allows all of this.
It leaves the future open.

This has very important engineering benefits too.  In decoupling the ADT
from transport details, communications can adapt better to each different
environment.  For example, using restricted capability platforms such as
cellphones to run VW clients has huge interest within the VW community, but
the CPU and bandwidth constraints of such a platform strongly discourage use
of relatively heavyweight serializations such as XML that other platforms
might use by preference.

I'm not particularly impressed with the attempt to hardwire in the name of a
particular vendor into what should be a Virtual World Structured Data
specification, but the approach of decoupling the ADT from the serialization
has very good merits, in my view.

Morgaine.

On Wed, Feb 11, 2009 at 2:15 AM, Meadhbh Hamrick (Infinity) <
[email-masked]> wrote:

> Google Protocol Buffers have not been standardized with the IETF and define
> a serialization technique, not an abstract type system.
>
>
>> particular reason why an existing standard such as ASN.1 or Google protocol
>> buffers wouldn't do? I'm all for re-inventing the wheel, if the new wheel is
>> actually significantly rounder -- but why standardize something new in this
>> particular case? What's wrong with the existing standards in this particular
>> area? (And there are literally dozens). Is there a survey somewhere that
>> lists the pros and cons?
>>
>> Sincerely,
>>
>> jw
>>
>>
>