Hi John, Morgaine,

Yes. Speaking as the co-chair of the BoF, I share your concerns. The draft group charter is exactly that, a draft. I think we expect it to be modified before the WG is formed. The draft does take a very Linden-IBM perspective as those were the authors of the draft. The IETF standardization process REQUIRES consensus, so I don't think we're expecting a rubber-stamp.

But, we would like to get people to submit concrete proposals. So let me ask; do you think you guys could come up with verbiage that could be inserted into the charter that would address your concerns? If you look at the charters of other groups, you'll sometimes find wording indicating the group has an exploratory mission as well as one to work on explicit proposals. It sounds like you both would be interested in such language. So, please submit changes to the draft documents you wish to discuss here. If you will attend the meeting in San Francisco, there's space in the agenda for open discussion and Q&A should your concerns not be addressed on the list.

With respect to LLSD, there is a precedent for including vendor names in the names of drafts and RFCs. RFC2437 PKCS#1 : RSA Cryptography Specifications and RFC2040 describing the RC5 cipher (RC5 stands for both "Ron's Code 5" and "Rivest Cipher 5)

We brought LLSD into the public as part of OGP and as an internet draft so we could get comments from the internet community. It might be advantageous if you could describe which portions of the LLSD draft you think need modification.

With regards to hypergrid, can it be specified in the form of an internet draft and discussed here? Is there a willingness by its authors to submit it as a standard?

Cheers!
Meadhbh

Morgaine Dinova <morgaine.dinova@googlemail.com> wrote:

>On Fri, Feb 6, 2009 at 7:47 AM, Hurliman, John <john.hurliman@intel.com>wrote:
>
>> As it is written, the charter and timeline effectively subverts
>> investigation of virtual world platform requirements and the evaluation of
>> different technologies that fulfill those requirements. The charter
>> specifically lists technology proposals from Linden Lab as established
>> solutions to virtual world interoperability. The goals and milestones
>> section lists a timeline for standardizing those solutions exclusively. I
>> understand the need to transition Linden Lab proposals to standards, and I
>> support such a move but not at the expense of excluding all other possible
>> solutions. I propose that the charter and timeline be changed to ensure the
>> agenda is open to additional proposals.
>
>
>John, if the charter, goals and timeline are as you describe, then I agree
>with you 100%.  Rubberstamping existing Second Life technology as a standard
>for virtual worlds would be totally without merit, and endorsing LL's
>current very narrow and unproven OGP solution as THE future Internet
>standard under the aegis of the IETF would be ... well, let's not go there.
>It would clearly be inappropriate, and unhelpful to the development of
>virtual worlds.
>
>However, I do not believe that that is the purpose of this workgroup,
>because you will note that the charter is only a draft in expectation of
>strong input from MMOX members (and OGP is Work in Progress anyway).  Let's
>provide that input immediately, to prevent this starting off on the wrong
>foot.
>
>The charter needs to be phrased unambiguously to make it clear that this
>workgroup is not an IETF PR annex of Linden Lab, but that it is dedicated
>honestly to the creation of a flexible, vendor-agnostic protocol for
>interoperation of diverse virtual worlds, not just now but for several years
>into the future.  That implies extensibility, in breadth and in depth.  And
>it implies openess to alternatives, and a desire to embrace them,
>
>And in particular, it implies a focus on technical merit of solutions, and
>not current business interests.
>
>I agree that we appear to have been given a slightly questionable baseline
>in LLSD ("Linden Lab Structured Data" is hardly a vendor-agnostic name) and
>OGP (Linden Lab's own developing protocol) without any mention of
>alternative approaches like Hypergrid that are already in operation.
>However, these skews and omissions are (I believe) just artifacts of the
>rush to establish MMOX.
>
>Let's see how we can improve this.  I think that it's in our court to set
>the path straight.
>
>Morgaine.
>_______________________________________________
>mmox mailing list
>mmox@ietf.org
>https://www.ietf.org/mailman/listinfo/mmox